因收到Google相关通知,网站将会择期关闭。相关通知内容

00 开篇词 SRE是解决系统稳定性问题的灵丹妙药吗?

你好,我是赵成,欢迎加入我的课程,和我一起学习SRE。

为了加强彼此的了解,我先做个简单的自我介绍吧。我在基础架构和运维领域工作有10多年了,现在负责蘑菇街平台技术部,主导中间件、稳定性、工具平台、运维和安全等工作。

2017年底,我在极客时间开了一门课程,叫《赵成的运维体系管理课》,系统整理并分享了我在运维和DevOps方面的经验,带给你不一样的运维思考。

这两年,近距离地接触了很多不同类型、不同规模的企业IT团队,我发现他们为了提升用户价值的交付效率,都在积极采用微服务、容器,以及其他的分布式技术和产品,而且也在积极引入像DevOps这样的先进理念。

这些公司选择了正确的架构演进方向和交付理念,效率自然是提升了一大截。这样的情况,是不是也发生在你的公司、发生在你自己身上?这时候你会发现,效率提升了,但挑战紧跟着也来了:在引入了这么多先进的技术和理念之后,这种复杂架构的系统稳定性很难得到保障,怎么办?

这个问题其实不难回答,答案就是SRE。

这几年业界对SRE的关注越来越多,大家也几乎达成了共识,Google SRE就是目前稳定性领域的最佳实践。也可以说,SRE已经成为稳定性的代名词。

SRE这么厉害,是有什么神奇之处吗?其实,SRE要做的事情并不神秘,我们每天做的监控告警、运维自动化、故障处理和复盘等工作,就是SRE的一部分。你也会发现,Google在介绍SRE的时候,很多篇幅介绍的就是这些我们熟悉的内容。

最近两年,我和团队也花了很多精力来做稳定性保障方面的事情,不断地探索在SRE方面的实践。比如,在日常的稳定性规范制定,监控、压测、服务治理、大促稳定性保障,故障应急和管理,以及组织架构建设等方面,我们都做了尝试,也积累了很多经验。

2019年6月,在SRE领域最具国际影响力的SRECon上,我分享了蘑菇街在容量压测方面的实践经验,和来自全球各大公司的同行们做了一次深度交流,让他们也见识了国内电商大促稳定性保障的技术实力。

从这些经验和交流探讨中,我收获了一条宝贵的经验:要想系统地做好稳定性这件事儿,SRE就是必修科目

同时,我也深刻体会到落地SRE会遇到各种问题,深知大家对SRE的困惑。所以,我系统梳理了自己的经验和调研,打磨出这个课程,目的就是帮你构建起体系化建设SRE的思路。

标杆立在那里,落地SRE有哪些问题?

那SRE在落地时具体会有哪些问题呢?接下来,我先说个我经常遇到的场景吧。

我在外部参加会议演讲或参与交流的时候,经常会有一些朋友向我求助,这里不乏一些公司的CTO、技术VP、总监或架构师,让我帮忙推荐运维或SRE专家。

每次遇到这样的情况,我都会问,你们现在遇到了什么问题,对这样的专家有什么要求。他们就会告诉我当前他们团队遇到的一些状况,比如系统三天两头出问题,有时候遇到一些问题,一排查就要老半天,特别是引入了微服务架构后,问题好像更多了。为了解决这些问题,开发和运维都要投入很多精力,结果却不尽如人意:系统不稳定会被业务团队投诉,好,那就赶快处理问题,但是这时候需求来了,响应不及时,业务团队又会不满意。事后,还要为了谁承担责任推来推去,对团队氛围影响很大。

这种人困马乏却谁都不满意的情况多了,我们就特别希望能找到一招制胜的办法。

这时候,SRE就被当作了灵丹妙药。因此,他们希望我能介绍一些这样的专家,来了就能把这样的问题干脆利落地统统解决掉。

说实话,每次遇到这样的问题,我都非常犯难。因为我发现我身边这样的大牛或专家也非常稀缺,还真不好推荐。另外,也是更重要的一点,从根本上来说,这绝不是招一两个或几个专家就能解决的问题。

那,为什么大家还总是向我提出推荐SRE专家这样的求助呢?很明显,这是大家对SRE的理解出现了偏差。很多人想当然地认为,SRE就是一个岗位,是一个角色,而且是无所不能的角色。

当然,这只是其中的问题之一。在实际落地SRE时,我们要么是不知道该从何入手,要么就是开始了却总会掉进这样那样的坑里,遇到各种问题和疑惑。

我将大家遇到的问题和疑惑,汇总到了下面这个清单里:

清单很长,你看完什么感受?这些问题不是我凭空臆想出来的,而是在跟众多企业IT团队交流和调研的过程中,我被问及最多、最频繁的问题。

问题虽然多,但总结起来其实就是两大类:

  1. 理念:SRE到底是什么?我们应该怎么来理解它?有哪些关键点?
  2. 实践:到底应该从哪里入手建设SRE?组织架构应该怎么匹配?

这些问题确实令人头痛,不过也不用害怕,我先给你吃一颗定心丸,这些问题我们都可以解决。

比如,你想要找到建设SRE体系的切入点,最好的办法就是建立稳定性的标准化。有时你会和周边团队就稳定性问题产生一些争执,说到底就是因为你们没有达成共识的、统一的衡量标准。Google SRE已经给我们提供了很好的标准化手段,也就是SLO。你看,这个问题不就得到解决了吗?

再比如,组织架构如何建设的问题,虽然Google没有给出放之四海而皆准的答案,但经过多年的实践,很多互联网公司甚至是传统企业,都已经积累了很丰富的经验。借鉴这些经验,建设组织架构的问题也能解决。

接下来,这个课程就会带你一一攻克这些问题。

这门课程是如何设计的?

具体来说,整个课程分为两个部分。

第一部分,夯实基础,带你建立SRE稳定性标准。

在这一部分,我会先讲清楚SRE是什么,以及业界衡量稳定性的标准是什么。我会把SLO作为引入SRE的切入点,因为它就相当于我们稳定性标准化的基础。同时,SLO也是稳定性保障的共识机制,有了这个共识,我们才能更好地管理稳定性,消除掉来自周边团队的很多不理解和不认可。

同时,在这一部分我还会引入一个电商的案例,跟你一起看一下,在实际的场景中设定SLO应该考虑哪些因素。

第二部分,SRE最佳实践

这一部分,我会从“故障”和“组织架构”这两个关键词入手来讲。

第一个是“故障”。我会围绕故障这个影响稳定性的核心事件,结合实践案例,分享应该从哪些方面减少故障发生次数,缩短故障影响时间,进而提升系统可用性及稳定性。

第二个是“组织架构”。这是做SRE绕不开的关键问题,要想做好SRE的落地,必须得有与之匹配的组织架构和协作机制。我会结合我的实践经验,以及我了解到的行业经验,让你看到真实的组织架构设置和跨团队协作模式。

通过这两个维度的学习,从理念到实践,我相信可以系统地解答你心中很多关于SRE的具体疑惑。如果你想从0到1建设SRE体系,有效地管理好你的系统稳定性,希望有一个合理的组织架构有效应对各种稳定性问题,那就和我一起学习吧。

另外,我想和你说说答疑相关的事情。SRE是个非常体系化的内容,我们的课程不会面面俱到。但是没关系,在学习过程中,你可以在留言区大胆提出你的任何疑惑,分享你的思考,我会在留言区答复,和你交流探讨;同时,我也会挑选有代表性的问题,单独成文,有针对性地做补充分享,作为答疑加餐发布出来。

最后,我还想再多啰嗦几句。答案很重要,但往往并不是最重要的东西,在探寻答案的过程中,我们获得的思路和方法更有意义,因为它们可以帮助我们举一反三,在未来更多的场景中发挥价值。希望接下来我们一起探索SRE的这个过程,也能有这样的价值。

好了,那咱就正式开始SRE的学习之旅吧!对了,你是怎么看SRE的?目前都有哪些困惑呢?记得留言和我说说你的情况。

我是赵成,再次欢迎你来到我的课程,我们下一讲见!