public/learn-tech
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first commit

Browse Source
This commit is contained in:
张乾
2024-10-16 06:37:41 +08:00
parent 633f45ea20
commit 206fad82a2
3590 changed files with 680090 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

102
专栏/RE实战手册/00开篇词SRE是解决系统稳定性问题的灵丹妙药吗？.md Normal file
View File

@ -0,0 +1,102 @@
因收到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团队交流和调研的过程中，我被问及最多、最频繁的问题。
问题虽然多，但总结起来其实就是两大类：
理念：SRE到底是什么？我们应该怎么来理解它？有哪些关键点？
实践：到底应该从哪里入手建设SRE？组织架构应该怎么匹配？
这些问题确实令人头痛，不过也不用害怕，我先给你吃一颗定心丸，这些问题我们都可以解决。
比如，你想要找到建设SRE体系的切入点，最好的办法就是建立稳定性的标准化。有时你会和周边团队就稳定性问题产生一些争执，说到底就是因为你们没有达成共识的、统一的衡量标准。Google SRE已经给我们提供了很好的标准化手段，也就是SLO。你看，这个问题不就得到解决了吗？
再比如，组织架构如何建设的问题，虽然Google没有给出放之四海而皆准的答案，但经过多年的实践，很多互联网公司甚至是传统企业，都已经积累了很丰富的经验。借鉴这些经验，建设组织架构的问题也能解决。
接下来，这个课程就会带你一一攻克这些问题。
这门课程是如何设计的？
具体来说，整个课程分为两个部分。
第一部分，夯实基础，带你建立SRE稳定性标准。
在这一部分，我会先讲清楚SRE是什么，以及业界衡量稳定性的标准是什么。我会把SLO作为引入SRE的切入点，因为它就相当于我们稳定性标准化的基础。同时，SLO也是稳定性保障的共识机制，有了这个共识，我们才能更好地管理稳定性，消除掉来自周边团队的很多不理解和不认可。
同时，在这一部分我还会引入一个电商的案例，跟你一起看一下，在实际的场景中设定SLO应该考虑哪些因素。
第二部分，SRE最佳实践。
这一部分，我会从“故障”和“组织架构”这两个关键词入手来讲。
第一个是“故障”。我会围绕故障这个影响稳定性的核心事件，结合实践案例，分享应该从哪些方面减少故障发生次数，缩短故障影响时间，进而提升系统可用性及稳定性。
第二个是“组织架构”。这是做SRE绕不开的关键问题，要想做好SRE的落地，必须得有与之匹配的组织架构和协作机制。我会结合我的实践经验，以及我了解到的行业经验，让你看到真实的组织架构设置和跨团队协作模式。
通过这两个维度的学习，从理念到实践，我相信可以系统地解答你心中很多关于SRE的具体疑惑。如果你想从0到1建设SRE体系，有效地管理好你的系统稳定性，希望有一个合理的组织架构有效应对各种稳定性问题，那就和我一起学习吧。
另外，我想和你说说答疑相关的事情。SRE是个非常体系化的内容，我们的课程不会面面俱到。但是没关系，在学习过程中，你可以在留言区大胆提出你的任何疑惑，分享你的思考，我会在留言区答复，和你交流探讨；同时，我也会挑选有代表性的问题，单独成文，有针对性地做补充分享，作为答疑加餐发布出来。
最后，我还想再多啰嗦几句。答案很重要，但往往并不是最重要的东西，在探寻答案的过程中，我们获得的思路和方法更有意义，因为它们可以帮助我们举一反三，在未来更多的场景中发挥价值。希望接下来我们一起探索SRE的这个过程，也能有这样的价值。
好了，那咱就正式开始SRE的学习之旅吧！对了，你是怎么看SRE的？目前都有哪些困惑呢？记得留言和我说说你的情况。
我是赵成，再次欢迎你来到我的课程，我们下一讲见！

102
专栏/RE实战手册/01SRE迷思：无所不能的角色？还是运维的升级？.md Normal file
View File

@ -0,0 +1,102 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
01 SRE迷思：无所不能的角色？还是运维的升级？
你好，我是赵成。
作为这个课程的第一讲，我先从实践的角度，和你聊聊应该怎么理解SRE。
为什么要强调是实践的角度呢？
开篇词里我们就提到过，有人认为SRE就是一个岗位，而且是一个具备全栈能力的岗位，只要有这么一个人，他就能解决所有稳定性问题。这还只是一种理解，而且这个理解多是站在管理者的角度。
也有人站在运维人员的角度，认为做好SRE主要是做好监控，做到快速发现问题、快速找到问题根因；还有人站在平台的角度，认为做好SRE要加强容量规划，学习Google做到完全自动化的弹性伸缩；甚至还有人认为，SRE就是传统运维的升级版，把运维自动化做好就行了。
你看，其实不同的人站在不同的角度，对SRE的理解就会天差地别，但是好像又都有各自的道理。
所以，我特别强调实践的角度，我们不站队，就看真实的落地情况。我总结了一下从实践角度看SRE的关键点，就一个词：体系化。SRE是一套体系化的方法，我们也只有用全局视角才能更透彻地理解它。
好了，下面我们就一起来看怎么理解SRE这个体系化工程。
SRE，我们应该怎么来理解它？
我先给你分享一张图，这是结合我自己团队的日常工作，做出来的SRE稳定性保障规划图。-
-
我们最初画这张图是为了提高故障处理效率，将每个阶段可以做的事情填了进去，并在实践中不断补充完善，最终形成了我们探索SRE的框架图。你应该也发现了，这里面很多事情都很常见，比如容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等。
这就是为什么我一直给你打气，说SRE并不神秘。学习SRE，我们可以有非常熟悉的抓手。但是，我们不能停留在向Google或其他大厂学习具体的技术经验上，而是更应该学习如何将这些技术有机地结合起来，形成一套稳定性体系，让体系发挥出力量，告别只发挥某项技术的能力。
同时，结合这些具体的事情，你应该明白，这些工作并不是某个人、某个角色，甚至是某个团队就可以单枪匹马完成的。比如这里的很多事情要依赖运维自动化，像容量扩缩容，必然会与运维团队有交集；如果做得再弹性一些，还需要与监控结合，就要与监控团队有合作；同时还可能依赖DevOps提供持续交付、配置变更，以及灰度发布这些基础能力，就要与开发和效能团队有交集。
这些能力之间的相互依赖，就决定了从职能分工上，SRE体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以。
所以，不要想着设定一个SRE岗位，就能把稳定性的事情全部解决掉，这明显不现实。你应该从体系的角度出发，设置不同的职能岗位，同时还要有让不同角色有效协作的机制。
从另一个角度来讲，如果当前我们的稳定性建设还仅仅聚焦在某个或某些具体的技术点上，每个角色和团队之间的工作相对还是独立、各自为战的，那就说明SRE体系和组织的真正威力还没有发挥出来。
所以，如果你已经是这些领域的实践者，比如你是一个运维工程师，或者是一位监控开发工程师，又或者是一个DevOps开发工程师，我建议你除了负责当前的事情外，应该更多地关注一下SRE全局视图。这样会帮助你深入了解SRE岗位所需要的技术能力，进而提升你的平台架构能力。
要知道，如果严格遵循Google的要求，SRE岗位对技术要求是非常高的。只有具备了全面的技术能力，拥有了全局架构的思维，你才会在SRE的道路上走得更远。
总结一下，从实践角度来看，SRE的力量不能通过一个岗位、一个或几个技术就发挥出来。SRE是一个体系化工程，它需要协同多个部门、多项技术。
做好SRE的根本目的是什么？
认识到SRE是个体系化的事儿还不够，我们还可以“以终为始”，看看SRE最后要达成什么样的目标，以此来加深对它的理解。
SRE做了这么多的事情，最后的目的是什么呢？
这个答案很明显嘛，就是提升稳定性。但是怎样才算提升了稳定性呢？要回答这个问题，我们有必要来讨论下稳定性的衡量标准。
从业界稳定性通用的衡量标准看，有两个非常关键的指标：
MTBF，Mean Time Between Failure，平均故障时间间隔。
MTTR，Mean Time To Repair， 故障平均修复时间。
还来看前面的SRE稳定性保障规划图，你会发现我们把整个软件运行周期按照这两个指标分成了两段。通俗地说，MTBF指示了系统正常运行的阶段，而MTTR则意味着系统故障状态的阶段。-
-
到了这里，我们也就明白了，如果想提升稳定性，就会有两个方向：提升MTBF，也就是减少故障发生次数，提升故障发生间隔时长；降低MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。
你想，如果我们把故障发生时间的间隔变长，并将故障影响的时间减少，系统稳定性是不是自然就提升了呢？答案是显然的。
从SRE稳定性保障规划图中，可以看出MTTR可以细分为4个指标：MTTI、MTTK、MTTF和MTTV。我把它们的具体解释做了一张图，你可以保存下来，有时间就琢磨一下。这4个指标，你要烂熟于心。-
-
现在，我们再来看SRE稳定性保障规划这张图，你就会理解，为什么要把所做的事情分组分块呈现。目的就是区分清楚，我们做的任何一件事情、开发的任何一套系统、引入的任何一个理念和方法论，有且只有一个目标，那就是“提升MTBF，降低MTTR”，也就是把故障发生时间的间隔变长，将故障影响的时间减少。
比如，在Pre-MTBF阶段（无故障阶段），我们要做好架构设计，提供限流、降级、熔断这些Design-for-Failure的服务治理手段，以具备故障快速隔离的条件；还可以考虑引入混沌工程这样的故障模拟机制，在线上模拟故障，提前发现问题。
在Post-MTBF阶段，也就是上一故障刚结束，开启新的MTBF阶段，我们应该要做故障复盘，总结经验，找到不足，落地改进措施等。
在MTTI阶段，我们就需要依赖监控系统帮我们及时发现问题，对于复杂度较高和体量非常大的系统，要依赖AIOps的能力，提升告警准确率，做出精准的响应。
同时AIOps能力在大规模分布式系统中，在MTTK阶段也非常关键，因为我们在这个阶段需要确认根因，至少是根因的范围。
你看，我们做了很多事情， 新的理念和方法出来后也特别愿意尝试，就是因为有明确的目标，所有工作的开展都是围绕这个核心目标而去的。
好了，按照以终为始的思路，SRE要实现的目标就是“提升MTBF、降低MTTR”，从这个角度出发，我们再次认识到一定要把SRE作为一个体系化的工程来建设，因为单纯在某些技术点上发力是没有多大意义的。
总结
今天我要分享的内容就到这里了。总结一下，你需要记住下面这两点。
第一，我们需要从全局的角度去理解SRE。SRE一定是靠整个技术和组织体系发挥作用的，单纯从某个技术点或环节出发，都无法呈现出效果，也就是说SRE一定要从全局考虑，体系一定要“配套”。
第二，SRE的目的，本质上是减少故障时间，增加系统正常运行时间，也就是 “减少故障，提升MTBF；同时，提升故障处理效率，降低MTTR”。SRE要做的所有事儿，都是为这两个目标服务的。
我想无论你是团队负责人、架构师，还是一线的技术专家，有了这样的全局视角后，就会知道接下来应该从何入手，以及如何与其他团队协作来构建这样的体系。
思考题
开篇词中我们提到过大家对SRE的困惑，比如SRE和DevOps都是很好的方法论，我应该怎么选？到底哪个更适合我？今天我们讲了SRE应该怎么理解，我想对这个问题你应该有答案了。那就请你来说一说，SRE和DevOps到底哪个更适合你？它们有什么区别和相同点？
请你在留言区说出自己的思考，也欢迎你把今天的内容分享给身边的朋友，和他一起讨论。
我们下节课见。

112
专栏/RE实战手册/02系统可用性：没有故障，系统就一定是稳定的吗？.md Normal file
View File

@ -0,0 +1,112 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
02 系统可用性：没有故障，系统就一定是稳定的吗？
你好，我是赵成，欢迎回来。
我们先来复习一下上一讲的内容，总结下来就是，SRE是个体系化工程，我们通过构建SRE这样一套体系来保证系统稳定性，具体来说就是“提升MTBF，降低MTTR”。有了这样一个激动人心的目标，你是不是想着那咱还等什么，赶快、立马就入手建设SRE体系吧！
嗯，好想法，我也很想咱就直接“撸起袖子加油干”。不过今天我们要先缓一缓，在正式进入SRE落地细节之前，我们得先讨论一下目前业界常用的“系统可用性（Availability）”这个概念，也就是我们常常听到的“3个9”（99.9%或99.95%）、“4个9”（99.99%或99.995%）。
为什么要先来讨论“系统可用性”这个大家已经很熟悉的概念呢？
一方面，系统可用性和我们建设SRE的目标强相关，SRE的稳定性目标其实就是尽量减少系统故障或异常运行状态的发生，提升系统可用的运行时间占比。很明显，这个可用时长就非常关键了。
另一方面，系统可用性这个概念看似简单，但我发现真的深入进去，大家的理解其实有很多不一致的地方，比如到底怎样才算是可用时长，怎样算是不可用时长呢？这个标准是怎么定义的？除了从时间维度来衡量可用性，还有其它的衡量方式吗？“3个9”、“4个9”听起来都很好，那具体来说我们的系统要达到“几个9”才算是稳定的呢？
所以，今天我们先慢下来，花时间把上面这些问题都彻底搞清楚，达成共识，打好基础，咱后面的SRE学习才能事半功倍。
衡量系统可用性的2种方式
那我就直接给答案了，目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度，我们先来看这两个维度的计算公式。
时间维度：Availability = Uptime / (Uptime + Downtime)
请求维度：Availability = Successful request / Total request
这两个公式很简单，我们得深入进去，一一来看。
我们先来看时间维度的系统可用性。用一句话来概括：时长维度，是从故障角度出发对系统稳定性进行评估。
这类计算方式我们最常见，毕竟你的系统在一段时间里不出现故障，就说明它很稳定嘛！不过，在真实的使用场景中，怎么样才算是可用时长，什么情况下又是不可用时长，这个是怎么定义的呢？
细想一下这个问题，你会发现还真有点复杂，那我就举个发烧生病的例子来说明一下。
我们知道，一个人如果发烧了，体温一般会超过37.5度，那如果这个人的体温正好达到这个温度，是不是代表他一定是生病了呢？依据生活经验，我们知道不一定。为什么呢？因为我们判断一个人是否发烧生病，不是只看这一次、一时的体温，还要看他体温是不是持续超过37.5度。
所以，这里就涉及到一个测量方法和判定方法的问题，包含三个要素：一个是衡量指标，比如体温就是衡量指标；第二个是衡量目标，达到什么目标是正常，达不到就是异常，低于37.5度算正常，超过37.5度就是异常，但是单次测量不能说明问题，我们可以多次测量，比如6次中有至少4次低于37.5度才算正常，转化成比例的话就是67%；第三个是影响时长，比如持续超过12小时。
对应到系统上，我们也会用一系列的标准和判定逻辑来说明系统是否正常。比如，系统请求状态码为非5xx的比例，也就是请求成功率低于95%，已经连续超过10分钟，这时就要算作故障，那么10分钟就要纳入Downtime（宕机时间），如果达不到这个标准，就不算作故障，只是算作一般或偶然的异常问题。
这里同样有三个要素：衡量指标，系统请求状态码；衡量目标，非5xx占比，也就是成功率达到95%；影响时长，持续10分钟。
因此，只有当问题达到一定影响程度才会算作故障，这时才会计算不可用时长，也就是上面公式中的Downtime。同时，我们还要求一个周期内，允许的Downtime，或者说是系统的“生病时间”是有限的，用这个有限时间来约束系统稳定性。
下面是我们常见的按时长维度统计的可用性对照表，也就是我们前面提到的几个9：-
-
讲到这里，针对时长维度的稳定性计算方式就比较清楚了，但是从这种计算方式中，你有没有看出一些问题呢？
我想你肯定看出来了，这里最显著的问题就是，稳定性只与故障发生挂钩。
我们来想一想，这样做会带来哪些问题？比如有一个系统，因为网络抖动，有短暂的几秒、十几秒，或者几分钟异常，但是后来系统自己恢复了，业务并没有中断，这时我们按照时长维度来判断，这肯定不会算作系统故障。但是如果这种短暂的影响频度非常高，一天来个5、6次，持续一两周，我们应该可以判定系统运行状况也是不正常的，可能不是故障，但肯定是不稳定了。
所以这种用时长维度来衡量系统稳定性的方式，其主要缺点就是粒度不够精细。这些小的异常问题和它们的影响，如果从更长的周期来看，也是有一定参考价值的。那怎样才能衡量得更精细些呢？
这就需要第二种衡量方式了，也就是从请求维度来衡量系统可用性。
用一句话来说，请求维度，是从成功请求占比的角度出发，对系统的稳定性进行评估。
假定我们的系统一天内有100,000次请求，我们期望的成功率至少是95%，如果有5001次请求失败了，也就是成功率低于95%了，我们就认为系统运行状态是不正常的。
请求维度的系统可用性同样包含三个关键要素，第一个衡量指标，请求成功率；第二个衡量目标，成功率达到95%才算系统运行正常；第三个是统计周期，比如一天、一周、一个月等等，我们是在一个统计周期内计算整体状况，而不是看单次的。
你看，这种方式对系统运行状况是否稳定监管得更为严格，不会漏掉任何一次问题的影响，因为它对系统整体运行的稳定性判定，不仅仅会通过单次的异常影响进行评估，还会累计叠加进行周期性的评估。
到这里，我们就总结出一条至关重要的经验了：故障一定意味着不稳定，但是不稳定，并不意味着一定有故障发生。
到这里，我们掌握了衡量系统可用性的两个维度、两种算法，它们都包含三个关键要素：衡量指标、衡量目标、影响时长/统计周期。这两种算法最后都会落脚到“几个9”上，那系统到底定“几个9”才算是稳定的呢？接下来，我们就来回答这个问题。
设定系统稳定性目标要考虑的3个因素
这个问题其实并没有标准答案，从我的经验来看，到底定“几个9”主要取决于以下三个因素。
第一个，成本因素。
从理论上来说，肯定是9越多稳定性越好，但是相应付出的成本和代价也会更高。比如为了更高的可用性，要有更多的冗余资源投入，甚至要做主备、双活甚至是多活。如果一家公司的业务量和影响力都发展到一定程度，那这个成本不管多高都是必须要付出的。但是，肯定不是所有的公司都需要付出这么高的成本，而是要先考虑ROI（回报率）。这时候就要看企业自身对成本压力的承担情况了。
第二个，业务容忍度。
稳定性怎么设定，很大程度上还要取决于业务上的容忍度。对于核心业务或核心应用，比如电商的交易和支付系统，我们当然是希望成功率越高越好，一般对系统稳定性要求是“3个9”或“4个9”。因为这些系统一旦出问题，就会直接影响整个网站和公司的收益，这些都是钱，所以对稳定性要求必然就会提高。
但是，对于非核心业务或应用，比如商品评论，商品评分等，或许“2个9”也能容忍。因为短时间的评论看不到，并不会对业务收入和用户体验造成太大的影响。
第三个，系统当前的稳定性状况。
结合系统的实际情况，定一个合理的标准比定一个更高的标准会更重要。这个合理的值应该怎么来定呢？
我个人的建议是从系统现状入手，比如，如果系统可用性是低于99%的，那首先第一步是不是可以做到99%，然后再争取做到99.5%，再到99.9%，一步一步朝着更高的标准迈进。同时，这样做也会更容易落地，因为你如果定一个太高的目标，又始终达不成，反而会打击到团队的自信心和积极性。
结合上面这三个因素，对于到底应该定“几个9”这个问题，你应该有了一个更清晰的认识了。
总结
好了，到这里，今天我们要讨论的系统可用性就讲完了。关于系统可用性，业界有两种计算方式，一种是时长维度，另一种是请求维度，这两种方式各有优劣。在SRE的实践中，应该选择哪一个呢？很明显，SRE会更多采用请求维度的统计方式，因为SRE关注的稳定性是系统的整体运行状态，而不仅仅只关注故障状态下的稳定性，在系统运行过程中的任何异常，都会被纳入稳定性的评估范畴中。
这个知识点要拿一整节课来讲，是因为接下来我们就要讨论SRE的稳定性指标和目标了，理解了今天的内容，你才能更好地理解SRE体系中的指标（SLI）和目标（SLO）。今天我先把SLI和SLO这两个概念抛出来，如果你觉得有点陌生，没有关系，准备好下节课和我一起掌握它们。
思考题
对于系统可用性的描述，今天我们仅用了“状态码”这一个指标来示例，但是在实际情况下，我们还会有其它多个指标来同时标识一个系统的稳定性，你能想到还有哪些指标？欢迎你在留言区写下自己的思考。
考虑这些指标的时候，不妨想想你是怎么选择的，你的判断标准是什么？这些也将是我们下节课程的重点内容。
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，和他一起精进。
我是赵成，我们下节课见。

172
专栏/RE实战手册/03SRE切入点：选择SLI，设定SLO.md Normal file
View File

@ -0,0 +1,172 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
03 SRE切入点：选择SLI，设定SLO
你好，我是赵成，欢迎回来。
还是先来复习下上节课讲的“系统可用性”的两种计算方式，一种是从故障角度出发，以时长维度对系统进行稳定性评估；另一种是从成功请求占比角度出发，以请求维度对系统进行稳定性评估。同时，我们还讲到，在SRE实践中，通常会选择第二种，也就是根据成功请求的比例来衡量稳定性：
Availability = Successful request / Total request
SRE强调的稳定性，一般不是看单次请求的成功与否，而是看整体情况，所以我们会把成功请求的占比设定为一个可以接受的目标，也就是我们常说的“3个9”或“4个9”这样的可量化的数字。
那么，这个“确定成功请求条件，设定达成占比目标”的过程，在SRE中就是设定稳定性衡量标准的SLI和SLO的过程。
具体来看下这两个概念。SLI，Service Level Indicator，服务等级指标，其实就是我们选择哪些指标来衡量我们的稳定性。而SLO，Service Level Objective，服务等级目标，指的就是我们设定的稳定性目标，比如“几个9”这样的目标。
SLI和SLO这两个概念你一定要牢牢记住，接下来我们会反复讲到它们，因为落地SRE的第一步其实就是“选择合适的SLI，设定对应的SLO”。
好，那我们就正式开始今天的内容。我会带你彻底理解SLI和SLO这两个概念，并掌握识别SLI、设定SLO的具体方法。
SLI和SLO到底是啥？
SLI和SLO这两个概念比较有意思，看字面意思好像就已经很明白了，但是呢，仔细一想，你会发现它们很抽象。SLI和SLO指的到底是啥呢？
接下来我给你讲一个具体的例子，讲完后，你肯定就能理解了。
我们以电商交易系统中的一个核心应用“购物车”为例，给它取名叫做trade_cart。trade_cart是以请求维度来衡量稳定性的，也就是说单次请求如果返回的是非5xx的状态码，我们认为该次请求是成功的；如果返回的是5xx状态码，如我们常见的502或503，我们就判断这次请求是失败的。
但是，这个状态码只能标识单次请求的场景。我们之前讲过，单次的异常与否并不能代表这个应用是否稳定，所以，我们就要看在一个周期内，所有调用次数的成功率是多少，以此来确定它是否稳定。比如我们给这个“状态码返回为非5xx的比例”设定一个目标，如果大于等于99.95%，我们就认为这个应用是稳定的。
在SRE实践中，我们用SLI和SLO来描述。“状态码为非5xx的比例”就是SLI，“大于等于99.95%”就是SLO。说得更直接一点，SLO是SLI要达成的目标。
通过这个例子，你现在是不是已经理解了这两个概念呢。SLI就是我们要监控的指标，SLO就是这个指标对应的目标。
好，那接下来我们要解决的问题就很具体了。我们应该选择哪些指标来监控系统的稳定性？指标选好后，对应地怎么定它的目标呢？下面咱们就一一来探索。
系统运行状态指标那么多，哪些适合SLI？
我们先来讨论怎么选择SLI。要回答怎么选择这个问题，我们得先来看看都有哪些可供选择的指标。
在下面这张图中，我列举了系统中常见的监控指标。-
-
这些指标是不是都很熟悉？那该怎么选呢？好像每一个指标都很重要啊！
确实，这些指标都很重要。我们可以通过问自己两个问题来选择。
第一个问题：我要衡量谁的稳定性？ 也就是先找到稳定性的主体。主体确定后，我们继续问第二问题：这个指标能够标识这个实例是否稳定吗？ 一般来说，这两个问题解决了，SLI指标也就确认了。
从我的经验来看，给指标分层非常关键。就像上图那样分层后，再看稳定性主体是属于哪一层的，就可以在这一层里选择适合的指标。但是，你要注意，即便都是应用层的，针对具体的主体，这一层的指标也不是每一个都适合。
根据这几年的实践经验，我总结了选择SLI指标的两大原则。
原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
原则二：针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。
还拿我们上面trade_cart的例子来说，主体确定了，就是trade_cart，应用层面的，请求返回状态码和时延就是很好的指标，再来检查下它们能否标识的trade_cart稳定性，毫无疑问，这两个指标都可以，那么请求返回状态码和时延就可以作为trade_cart稳定性的SLI指标。
我们换一个指标，CPU的使用率这个指标适合吗？根据我们刚才说的原则，既然我们关注的是trade_cart的运行状况，而CPU是系统层的指标，所以，在选择应用层SLI的指标时，自然会把CPU排除掉。
你可能会说，这样是不是太武断了呀？
我们简单来分析下。假设CPU使用率达到了95%，但是只要CPU处理能力足够，状态码成功率可能还是保持在4个9，时延还是在80ms以内，用户体验没有受到影响。另外一种情况，假设CPU使用率只有10%，但是可能因为网络超时或中断，导致大量的请求失败，甚至是时延飙升，购物车这个应用的运行状态也不一定是正常的。所以结论就是，CPU使用率不管是10%还是95%，都不能直接反映trade_cart运行是正常还是异常，不适合作为trade_cart这样的应用运行稳定性的SLI指标。
讲到这里，你可能会问，哎呀，你说的这两个原则我理解了，分层也大概能做到，但是我还是需要做很多详细的分析才能选择出SLI指标，有没有什么更便捷、更快速的方法来帮助我选择啊？
嗯，不要着急，还真有这样一套方法。怎么选SLI，我们可以直接借鉴Google的方法：VALET。
快速识别SLI指标的方法：VALET
VALET是5个单词的首字母，分别是Volume、Availability、Latency、Error和Ticket。这5个单词就是我们选择SLI指标的5个维度。我们还是结合trade_cart这个例子，一起看一下每个维度具体是什么。
Volume-容量
Volume（容量）是指服务承诺的最大容量是多少。比如，一个应用集群的QPS、TPS、会话数以及连接数等等，如果我们对日常设定一个目标，就是日常的容量SLO，对双11这样的大促设定一个目标，就是大促SLO。对于数据平台，我们要看它的吞吐能力，比如每小时能处理的记录数或任务数。
Availablity-可用性
Availablity（可用性）代表服务是否正常。比如，我们前面介绍到的请求调用的非5xx状态码成功率，就可以归于可用性。对于数据平台，我们就看任务的执行成功情况，这个也可以根据不同的任务执行状态码来归类。
Latency-时延
Latency（时延）是说响应是否足够快。这是一个会直接影响用户访问体验的指标。对于任务类的作业，我们会看每个任务是否在规定时间内完成了。
讲到这里，我要延伸下，因为通常对于时延这个指标，我们不会直接做所有请求时延的平均，因为整个时延的分布也符合正态分布，所以通常会以类似“90%请求的时延 <= 80ms，或者95%请求的时延 <=120ms ”这样的方式来设定时延SLO，熟悉数理统计的同学应该知道，这个90%或95%我们称之为置信区间。
因为不排除很多请求从业务逻辑层面是不成功的，这时业务逻辑的处理时长就会非常短（可能10ms），或者出现404这样的状态码（可能就1ms）。从可用性来讲，这些请求也算成功，但是这样的请求会拉低整个均值。
同时，也会出现另一种极端情况，就是某几次请求因为各种原因，导致时延高了，到了500ms，但是因为次数所占比例较低，数据被平均掉了，单纯从平均值来看是没有异常的。但是从实际情况看，有少部分用户的体验其实已经非常糟糕了。所以，为了识别出这种情况，我们就要设定不同的置信区间来找出这样的用户占比，有针对性地解决。
Errors-错误率
错误率有多少？这里除了5xx之外，我们还可以把4xx列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx太多，用户也是不能接受的。
或者可以增加一些自定义的状态码，看哪些状态是对业务有损的，比如某些热门商品总是缺货，用户登录验证码总是输入错误，这些虽不是系统错误，但从业务角度来看，对用户的体验影响还是比较大的。
Tickets-人工介入
是否需要人工介入？如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。举一个我们常见的场景，数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。
Tickets的SLO可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月20张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。
这里我给出一个Google提供的，针对类似于我们trade_cart的一个应用服务，基于VALET设计出来的SLO的Dashboard样例，结合上面我们介绍的部分，就一目了然了。-
-
好，VALET我们就讲完了，怎么选SLI指标，你是不是一下子就清楚了。可以说，这是一个我们可以直接复用的工具。上面Google的这张SLO样例图，建议你多看几遍，看到时候，对比思考下自己系统的情况。
如何通过SLO计算可用性？
到这里，我们已经能够根据自己想要保障稳定性的主体，来选择合适的SLI指标了，也知道SLO就是对应SLI要实现的目标，比如“几个9”。
但是，我们前面讲到了系统可用性：
Availability = Successful request / Total request
然后又深入到了提炼具体的SLI，以及设定对应的SLO，那这两者之间是什么关系呢？也就是通过SLO应该怎么去计算我们的系统可用性的呢？这就涉及到系统整体可用性的两种计算方式。
第一种，直接根据成功的定义来计算。-
也就是我们前面定义一个请求的返回状态码必须是非5xx才算成功，同时时延还要低于80ms，同时满足这两个条件，我们才算是成功的，也就是纳入上述公式中Successful request的统计中，用公式来表示：
Successful = （状态码非5xx） & （时延 <= 80ms）
如果还有其它条件，直接在后面增加做综合判定。
但是，这种计算方式存在的问题就是，对单次请求的成功与否的判定太过死板，容易错杀误判。比如我们前面讲对于时延，我们一般会设定置信区间，比如90%时延小于等于200ms这样的场景，用这种方式就很难体现出来。而且，对于状态码成功率和时延成功率的容忍度，通常也是也不一样的，通过这种方式就不够准确。所以，我们就会采取第二种方式。
第二种方式，SLO方式计算。
我们前面讲时延时讲过以下几个SLO，这时我们设定稳定性的时候，就需要把公式计算方式灵活调整定义一下了。
SLO1：99.95% 状态码成功率
SLO2：90% Latency <= 80ms
SLO3：99% Latency <= 200ms
直接用公式表示：
Availability = SLO1 & SLO2 & SLO3
只有当这个三个SLO同时达标时，整个系统的稳定性才算达标，有一个不达标就不算达标，这样就可以很好地将SLO设定的合理性与最终可用性结合了起来。所以，通常在SRE实践中，我们通常会采用这种设定方式。
如果是这样，第一种方式是不是就没有用途了呢？当然不是。第一种计算方式也会有它特有的应用场景，它通常会被利用在第三方提供的服务承诺中，也就是SLA（ Service Level Agreement）。因为对于第三方提供商来说，比如云厂商，它们要面对的客户群体是非常大的，所以很难跟每一家客户都去制定像SLO这么细粒度稳定性目标，而且每家客户对稳定性的要求和感知也不同，就没法统一。
这种情况下，反而是第一种计算方式是相对简单直接的，但是这样也决定了SLA的承诺相比SLO肯定也相对比较宽松，因为SLA是商业服务承诺，如果达不成是要进行赔偿的。关于SLA，最直接的参考资料，就是各个公有云厂商在官网公开的信息资料，你可以找到这些资料，作为自己的一个补充学习。
总结
讲到这里，怎么选择SLI指标、如何制定SLO目标，我们就介绍完了。你需要掌握下面三个重点。
对系统相关指标要分层，识别出我们要保障稳定性的主体（系统、业务或应用）是什么，然后基于这个主体来选择合适的SLI指标。
不是所有的指标都是适合做SLI指标，它一定要能够直接体现和反映主体的稳定性状态。可以优先选择用户或使用者能感受到的体验类指标，比如时延、可用性、错误率等。
掌握VALET方法，快速选择SLI指标。
思考题
最后，给你留一个思考题。
下面我给出一个Google的SLI和SLO设定标准示例，内容很直观，需要你认真研究一下这个文档，结合今天我们所讲的内容，请你尝试按照Google提供的规范格式，制定一个自己所负责系统的SLO。
Google的SLI和SLO设定模板链接：https://landing.google.com/sre/workbook/chapters/slo-document
另外，对今天的内容如果你还有什么疑惑，都可以在留言区提问，也欢迎你把今天的内容分享给身边的朋友，和他一起学习讨论。
我是赵成，我们下节课见。

176
专栏/RE实战手册/04错误预算：达成稳定性目标的共识机制.md Normal file
View File

@ -0,0 +1,176 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
04 错误预算：达成稳定性目标的共识机制
你好，我是赵成，欢迎回来。
上一讲是我们引入SRE的关键，我们掌握了选择SLI指标和设定SLO目标的方法。你可以先回顾一下内容，看看是不是能回答这三个问题：选择SLI的两大原则是什么？VALET法则是什么？怎么来计算SLO？如果答案都很清晰，那么恭喜你，你攻克了SRE的一个关键知识点；如果有点模糊，那就回去复习一下，咱不求快，但求扎实。
今天，我们就顺着SLO这条线，继续深入，一起来看有了SLO之后，围绕着它我们可以做哪些事情，或者说我们具体应该怎么来应用SLO呢？还有，SLO设定后，是合理还是不合理，我们应该用什么样的方法来评估呢？如果设定得不合理，我们又应该怎么来调整呢？
带着这些问题，开始我们今天的学习。
落地SLO，先转化为Error Budget
SLO是目标，定目标总是一件激动人心的事，但是目标定了之后，这个目标怎么能指导我们的具体工作呢，有时候就没那么一目了然了。
这么说有点抽象，我举个生活中的例子。你通过好几轮考试，拿到了驾照，现在你可以开车上路了。交管局的目标就是你要遵守交规，安全驾驶。这个目标咋实现呢？我们都知道了，就是驾照记分制。你的驾照在1年的这个周期里，总共有12分，扣完了驾照失效，这样你就会关注自己还有几分，特别注意交规。用这个方式，就把你要趋近100%遵守交规的目标转变为你一年只有12分可扣，一个大目标就有了很具体的落地形式。
那同样，SLO目标定好了，很具体，但实施起来不直观，那我们是不是也可以反过来看，制定出一个允许犯错的次数标准，这样我们就监控这些错误就好了。
没错，SRE还真是这么做的，这个概念叫做Error Budget，翻译过来就是错误预算。
错误预算其实和驾照记分制是一样的，最大的作用就是“提示你还有多少次犯错的机会”，并且，错误预算的警示效果比看成功率这种统计数据更直观，感官冲击力更强。
那在SLO中，错误预算是怎么得出的呢？其实计算方式一点都不复杂，简单讲就是通过SLO反向推导出来的。下面我举个例子，你马上就可以理解了。
我们还是以trade_cart购物车这个应用为例，SLO目标就是我们上节课定过的。假设在4周的时间，这个应用所有的请求次数是4,653,680，按照给出的SLO反向推导，就可以得到容许的错误次数，这就是错误预算。-
-
你看，错误预算的计算很简单，起到的警示效果又更强烈，所以在SLO落地实践时，我们通常就把SLO转化为错误预算，以此来推进稳定性目标达成。
那在实际场景下，我们应该怎么应用错误预算呢？下面我给你介绍常见的4种应用方式。
如何应用Error Budget？
1.稳定性燃尽图
第一种是稳定性燃尽图。
当我们制定好错误预算后，就代表了要严格遵守它。如果在一个周期内，比如4个自然周，错误预算被消耗完了，尽管整个过程中没有出现达到故障标准的问题，这个周期的稳定性要求其实也是不达标的。
所以我们需要把错误预算尽可能直观地表现出来，随时可以看到它的消耗情况。当你和团队成员能够时刻看到还有多少犯错的机会时，对生产系统的敬畏心理也会大大增强。而且当错误预算消耗到一定比例，如80%或90%时，就要开始预警，控制各种变更，或者投入精力去解决影响稳定性的问题。
那怎么制作稳定性燃尽图呢？
这里，可以参考Google给出的一个错误预算的燃尽图，这个从技术上，通过你日常使用的监控平台配置一个Metric就可以实现，并不复杂。-
-
在应用错误预算的时候，你要考虑设定一个合理的周期，比如1天、1周或1个月。
1天或1周，周期相对较短，我们通常的建议是4个自然周，这个周期设定更合理，这也是谷歌给出的建议。为什么选4个自然周，而不是1个自然月呢？主要是因为自然月通常会导致跨周的情况出现，相比于4个自然周，在统计上就要考虑额外的边界问题。
同时，在考虑定错误预算的时候，还要考虑到部分特殊场景，这个要根据业务特点来定，比如电商会有双11大促活动，有些产品还要考虑春晚互动活动和抢红包活动，甚至有些社交类产品还要考虑应对突发新闻导致的访问量激增问题等等，这些场景必然因为访问量太大而采取很多限流降级的策略，导致更多的请求失败。
如果这些活动或事件是发生在某个考核周期内，这时要考虑放大错误预算的值，特别是瞬时的错误或失败，应该要有更大的容忍度，简单来讲就是，特殊情况特殊处理，当然最重要的，也要做好特殊保障和应对工作。
2.故障定级
第二种是把错误预算应用在故障定级中。我们判定一个问题是不是故障，或者评估问题影响程度到底有多大，除了看影响时长外，还有一个更具操作性的方法，那就是按照该问题消耗的错误预算比例来评判。
我在《赵成的运维体系管理课》第28讲中分享过蘑菇街的故障定级思路，我们将故障等级设置为 P0~P4 这么 5 个级别，P0 为最高，P4 为最低。
还是以trade_cart购物车为例，结合P0～P4的故障等级设置，一起来看怎么应用错误预算。
trade_cart请求成功率SLO对应的错误预算是25,000次，如果一个问题产生的错误请求数超过了5000次，也就是错误预算一下就被消耗掉20%以上，这时，我们可以把这次故障定为P2级。以此类推，如果消耗30%以上，我们定为P1级，消耗50%以上，定为P0级等等。
当然，我这里是举例，在真正实际工作中，这个具体数值可以根据实际业务情况和容忍度来制定。
可以看到，通过错误预算来定义故障等级就可以做到量化，而一旦可以被量化，就意味着可以标准化，有了标准，我们就可以进而推进达成共识。
3.稳定性共识机制
第三种是用错误预算来确定稳定性共识机制。
前面我们用驾照记分来类比错误预算。现在想想，当你发现自己只剩下1分的时候，你会怎么办？开车肯定会非常小心，比如说慢速行驶，严格遵守交通规则，甚至是不开车，这些行为都是围绕“驾照记分只剩1分”这个结果来做的。
同样，在我们系统稳定性保障过程中，我们也会根据剩余预算的情况，来制定相应的行动措施，来避免我们的稳定性目标，也就是SLO达不成。
那么，当错误预算处于不同状态时，我们一般都会采取哪些常见措施呢？这里我给你介绍两个指导原则。
第一，剩余预算充足或未消耗完之前，对问题的发生要有容忍度。
比如4周的一个周期内，如果错误预算没有被消耗完，我们强调即使出现一些问题，甚至是故障，我们是要容忍的。
比如，网络抖动或设备瞬时切换导致了极短暂的系统不稳定，但是有极少一部分客户反馈了，也可能领导或业务使用时遇到了，结果技术同学就被投诉系统或业务不稳定，然后就要放下手头的工作去排查问题，后续还要花大量的时间去复盘总结和汇报等等。
这个场景发生的原因就是我在开篇词中提到的，每个角色对问题和故障的定义以及理解是不一致的，所以出现问题的时候，任何人、任何角色都可以凭个人感觉对问题影响程度进行评判。
遇到这种情况，你一般是怎么应对的？不知道该听谁的？还是先听一个，一头扎进去排查问题？
现在，你有了SLO和错误预算的判断标准，就有了明确的应对思路。如果预算充足，且单次问题并没有造成大量损耗，那么这次问题就不应该被投诉，也不用以高优先级响应，它应该得到容忍的。
第二，剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更。
为什么这么说呢？因为此时的情况已经说明系统稳定出现了很大问题，不能再让它“带病工作”。同样，这时的业务开发团队，也有权拒绝新的需求，他们首要的事情，应该是跟SRE一起解决影响稳定性的问题，直至问题解决，且等到下一个周期有了新的错误预算后，再恢复正常变更节奏。
从上面这两个原则中我们可以看到，跟驾照扣分触发的行动不同，保障稳定性的行动不是单独某一方就可以完成的，它需要多方共同认可并愿意配合才能真正执行到位。
所以，你在制定SLO和错误预算策略的过程中，要有一个很重要的动作，就是确保与运营、产品和开发达成一致，各方要认可这个策略，并且当策略被触发时，大家也会严格遵守。
可以看到，这里涉及到跨团队沟通共识机制。从推行的角度来讲，建立稳定性共识机制一定是Top-Down，也就是自上而下，至少要从技术VP或CTO的角度去推行，而且当有意见不一致的情况出现时，还要逐步上升，直至CTO角度来做决策。关于这一点，你需要特别注意，一定要自上而下推进周边团队或利益方达成共识。
4.基于错误预算的告警
第四种是把错误预算应用在告警中。
日常工作中，作为一线的工程师，你肯定要接收大量的告警短信，但是这些告警里面很大一部分都是没有实际意义的。为什么这么说呢？因为它们没有行动指导意义，比如CPU使用率80%、成功率低于95%、时延超过80ms等等，这样的告警只是告诉我们有问题、有异常，但是否需要高优先级马上处理，还是说可以先放一放、过一会再处理呢？你可能并没有办法判断。
这样的告警，接收的次数多了，就会变成“狼来了”，你自己变得警惕性不高，当故障真的发生时，你也没法快速响应。
那我们应当如何做告警收敛呢？从我的经验看，有两个解决办法。
第一个，相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条，这种比较简单直接。
第二个，基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到20%或30%等某一阈值时，就意味着问题非常严重了，这种告警信息一旦收到，就要马上做出响应。这样告警数量不多，既达到了收敛效果，又非常精准。
基于错误预算的告警就会涉及到AIOps相关的领域，我就不再展开讲了。这里我分享一个链接，谷歌基于SLO和错误预算的几种告警算法，你可以学习下里面用到的方法。
讲到这里，基于错误预算的4个应用场景就介绍完了，我们小结一下。我们将SLO反向推导出了错误预算，为了让错误预算的警示效果更显著，我们可以利用燃尽图的方式呈现出来；同时，还可以根据每次问题消耗的错误预算比例来制定故障等级，这样就做到了对故障的量化管理；有了量化数据，在向周边团队和上级领导沟通时，也会显得有理有据；最后，基于错误预算我们还可以做到告警收敛，让告警更准确，更具备行动指导价值。
既然我们制定了SLO，推导出了错误预算，也做好了相应的策略，那我们制定的这些目标和规则是否有效果呢？我们应该怎么来评价它们的有效性，又应该怎么进一步迭代优化呢？
下面我们就一起来看一下如何衡量SLO的有效性。
如何衡量SLO的有效性？
衡量SLO及错误预算策略是否有效，其实就是看实际运行后，是否真的能达到我们的期望。我们可以从下面三个关键维度来看。
SLO达成情况。我们用达成（Met），或未达成（Missed）来表示。
“人肉”投入程度。英文表示为Toil，这里用形象一点的“人肉”投入作为它的译意，泛指需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高（High）和低（Low）来表示。
用户满意度。英文就是Customer Satisfaction，可以理解为用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取；虚拟渠道如真机模拟拨测。我们用满意度高（High）和低（Low）来表示。
总共3个维度，每个维度有2种情况，组合起来就是8种情况，我们直接引用Google给出的图表和建议。-
-
针对这8种情况，我们分别给出对应策略。总结一下，应对方式可以分为3类。
第一类，收紧SLO。
这个时候就是目标定得太低了，比如SLO达成（Met），但是用户不满意（Low）。会有什么后果呢？要么投诉多，要么到处吐槽。这就表示我们的SLO设定得太容易达成，没有反馈真实的运行状况。
第二类，放宽SLO。
与第一类相反，目标定太高，总是达不成（Missed），但用户反馈却很不错（High），这种就会造成错误预算提前消耗完，导致很多变更暂停，产品延期，甚至会做一些无谓的优化，这时就可以适当松松绑。
第三类，保持现状，对有问题的维度采取有针对性的优化措施。
比如表格第一行，是我们期望的最理想状态，SLO能达成，人肉投入又低，客户满意度又很高，也没有特别的优化空间，这时我们就可以增加发布和变更次数，更大程度地释放生产力。
你可以参考这个样例，从SLO达成情况、“人肉”投入情况以及用户实际满意度三个维度来衡量自己业务和系统的SLO有效性，该收紧SLO就要提高稳定性要求，但是也不能设定太过超出能力范围的目标，始终达不成，SLO也就没有意义了。当然，在SLO可以达成的情况下，我们还是希望提升我们的用户价值交付效率，围绕着这个终极目标，不断优化自己的SLO和错误预算策略。
总结
今天的内容就讲解完了，我们重点讨论了错误预算，这里我要再强调几个关键点。
错误预算是通过SLO推导出来的，为了达成SLO，就要尽量减少对它的消耗。
错误预算的警示效果更显著，所以我们通常会围绕它来开展稳定性保障工作。落地错误预算可以遵循一些基本原则，比如要对系统故障或问题有容忍度，在预算消耗过快或消耗殆尽之前，SRE有权踩踩“刹车”，减少或拒绝线上变更等等，这些策略要自上而下达成共识。
SLO和错误预算是否合理，基于它们的策略是否有效，我们可以通过SLO达成情况、人肉投入程度和用户满意度三个维度进行评估，进而调整和优化它们。
思考题
最后，给你留一个思考题。
今天我们讨论了把错误预算应用在故障定级中。其中，故障定级有时是一个特别让人头疼的事情，也需要跟周边团队达成一致。你能不能分享一下，在你的团队中，是用什么样的标准来制定故障等级的？
期待你在留言区说出自己的思考，也欢迎你把今天的内容分享给身边的朋友，和他一起讨论。我们下节课见。

133
专栏/RE实战手册/05案例：落地SLO时还需要考虑哪些因素？.md Normal file
View File

@ -0,0 +1,133 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
05 案例：落地SLO时还需要考虑哪些因素？
你好，我是赵成，欢迎回来。
前面几节课，我们按照层层递进的思路，从可用性讲到SLI和SLO，再到SLO所对应的Error Budget策略。掌握了这些内容，也就为我们建设SRE体系打下了一个稳固的基础。
今天，我用一个电商系统的案例，带着你从头开始，一步一步系统性地设定SLO，一方面巩固我们前面所学的内容，另一方面继续和你分享一些我在实践中总结的注意事项。
案例背景
我先来给你介绍下电商系统案例的基础情况，框定下我们今天要讨论的内容范围。
一般来说，电商系统一定有一个或几个核心服务，比如要给用户提供商品选择、搜索和购买的服务等。但我们知道，大部分用户并不是上来就购买，而是会有一个访问的过程，他们会先登录，再搜索，然后访问一个或多个商品详情介绍，决定是放到购物车候选，还是选择物流地址后直接下单，最后支付购买。
这条从登录到购买的链路，我们一般称之为系统的核心链路（Critical Path），系统或网站就是依靠这样一条访问链路，为用户提供了购买商品的服务能力。
至于电商系统的其它页面或能力，比如网站政策、新手指导、开店指南等等，这些对用户购买服务不会造成太大影响的，相对于核心链路来说，它的重要性就相对低一些。
我们要给电商系统设定SLO，大的原则就是先设定核心链路的SLO，然后根据核心链路进行SLO的分解。接下来，我们就一步步拆解动作，看看怎么实现这个目标。
核心链路：确定核心应用与强弱依赖关系
要确定核心链路的SLO，我们得先找到核心链路。怎么实现呢？
我们可以先通过全链路跟踪这样的技术手段找出所有相关应用，也就是呈现出调用关系的拓扑图，下面我给了一张图，这个图你应该并不陌生，这是亚马逊电商分布式系统的真实调用关系拓扑图。之所以这么复杂，是因为即使是单条路径，它实际覆盖的应用也是很多的，特别是对于大型的分布式业务系统，可能会有几十甚至上百个路径，这些应用之间的依赖关系也特别复杂。
-
面对这样复杂的应用关系，是不是感觉无从下手？那就继续来做精简，也就是区分哪些是核心应用，哪些是非核心应用。这是要根据业务场景和特点来决定的，基本上需要对每个应用逐个进行分析和讨论。这个过程可能要投入大量的人工来才能完成，但这个是基础，虽然繁琐且费时费力，也一定要做。
这里我简单举个例子说明。
比如用户访问商品详情的时候，会同时展现商品评价信息，但是这些信息不展现，对于用户选择商品也不会造成非常大影响，特别是在双十一大促这样的场景中，用户在这个时刻的目的很明确，就是购买商品，并不是看评价。所以类似商品评价的应用是可以降级的，或者短时间不提供服务。那这种不影响核心业务的应用就可以归为非核心应用。
相反的，像商品SKU或优惠券这样的应用，直接决定了用户最终的购买金额，这种应用在任何时刻都要保持高可用。那这种必须是高可用的应用就是核心应用。
就这样，我们需要投入一些精力一一来看，确定哪些是核心应用，哪些是非核心应用。梳理完成后，针对电商系统，我们大概可以得到一个类似下图的简化拓扑关系（当然了，这里仍然是示例，相对简化，主要是保证效果上一目了然）。-
-
这张图就呈现出一条典型的电商交易的关键路径，其中绿色部分为核心应用，蓝色部分为非核心应用。
这个时候，我们又要进行关键的一步了，就是确认强弱依赖。
核心应用之间的依赖关系，我们称之为强依赖，而其它应用之间的依赖关系，我们称之为弱依赖，这里就包含两种关系，一种是核心应用与非核心应用之间的依赖，另一种是非核心应用之间的依赖。
好了，至此，我们就确定了这个电商系统的核心应用和强弱依赖关系，也就是找到了这个系统的核心链路。那我们就可以设定这条核心链路的SLO了，并基于此设定其他的SLO。这时应该遵循哪些原则呢？
设定SLO有哪些原则？
针对核心和非核心应用，以及强弱依赖关系，我们在设定SLO时的要求也是不同的，具体来说，可以采取下面4个原则。
第一，核心应用的SLO要更严格，非核心应用可以放宽。 这么做，就是为了确保SRE的精力能够更多地关注在核心业务上。
第二，强依赖之间的核心应用，SLO要一致。 比如下单的Buy应用要依赖Coupon这个促销应用，我们要求下单成功率的SLO要99.95%，如果Coupon只有99.9%，那很显然，下单成功率是达不成目标的，所以我们就会要求Coupon的成功率SLO也要达到99.95% 。
第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。 这样做是为了避免由非核心应用的异常而导致核心应用SLO不达标。
第四，Error Budget策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO没有达成，那整条链路，原则上是要全部暂停操作的，因为对于用户来说，他不会判断是因为哪个应用有问题，导致的体验或感受不好。所以，单个应用的错误预算消耗完，都要停止变更，等问题完全解决再恢复变更。当然，也可以根据实际情况适当宽松，如果某个核心应用自身预算充足，且变更不影响核心链路功能，也可以按照自己的节奏继续做变更。这一点，你可以根据业务情况自行判断。
如何验证核心链路的SLO？
梳理出系统的核心链路并设定好SLO后，我们需要一些手段来进行验证。这里，我给你介绍两种手段，一种是容量压测，另一种就是Chaos Engineering，也就是混沌工程。
容量压测
我们先来看容量压测。容量压测的主要作用，就是看SLO中的Volume，也就是容量目标是否可以达成。对于一般的业务系统，我们都会用QPS和TPS来表示系统容量，得到了容量这个指标，你就可以在平时观察应用或系统运行的容量水位情况。比如，我们设定容量的SLO是5000 QPS，如果日常达到4500，也就是SLO的90%，我们认为这个水位状态下，就要启动扩容，提前应对更大的访问流量。
容量压测的另一个作用，就是看在极端的容量场景下，验证我们前面说到的限流降级策略是否可以生效。
我们看上面电商交易的关键路径图，以Detail（商品详情页）和Comment（商品评论）这两个应用之间的弱依赖关系为例。从弱依赖的原则上讲，如果Comment出现被调用次数过多超时或失败，是不能影响Detail这个核心应用的，这时，我们就要看这两个应用之间对应的降级策略是否生效，如果生效业务流程是不会阻塞的，如果没有生效，那这条链路的成功率就会马上降下来。
另外，还有一种场景，如果某个非核心应用调用Detail的次数突然激增，对于Detail来说，它自身的限流保护机制要发挥作用，确保自己不会被外部流量随意打垮。
其实类似上述这两种场景，在分布式系统中仅仅靠分析或画架构图是无法暴露出来的，因为业务变更每天都在做，应用之间的调用关系和调用量也在随时发生变化。这时候就需要有容量压测这样的手段来模拟验证，进而暴露依赖关系问题。并且，有些问题必须要在极端场景下模拟才能验证出问题，比如各种服务治理措施，只有在大流量高并发的压力测试下，才能被验证出是否有效。
Chaos Engineering-混沌工程
好了，接下来看第二种混沌工程。
我们知道，现在混沌功能非常流行，因为它可以帮助我们做到在线上模拟真实的故障，做线上应急演练，提前发现隐患。很多公司都很推崇这种方法并在积极学习落地中。
其实，刚才我们讲容量压测也提到，容量压测是模拟线上真实的用户访问行为的，但是压测过程中，如果我们模拟极端场景，可能也会造成异常发生，但这时的异常是被动发生的，不过从效果上来讲，其实跟混沌工程就很相似了。只不过，混沌工程是模拟故障发生场景，主动产生线上异常和故障。
那我们怎么把混沌工程应用在SRE中呢？一般来说，故障发生的层面不同，我们采取的方式也会不同。
这里我简单介绍一下，比如对于机房故障，有些大厂会直接模拟断电这样的场景，看机房是否可以切换到双活或备用机房；在网络层面，我们会模拟丢包或网卡流量打满；硬件和系统层面，可能故意把一块磁盘写满，或者把CPU跑满，甚至直接把一个服务器重启；应用层面，更多地会做一些故障注入，比如增加某个接口时延，直接返回错误异常，线程池跑满，甚至一个应用集群直接下线一半或更多机器等。
其实混沌工程也是一个非常复杂的系统化工程，因为要在线上制造故障，或多或少都要对线上业务造成影响，如果模拟故障造成的真实影响超过了预估影响，也要能够快速隔离，并快速恢复正常业务。即使是在稳定性体系已经非常完善的情况下，对于混沌工程的实施也要极为谨慎小心。对于一个模拟策略上线实施，一定是在一个隔离的环境中经过了大量反复验证，包括异常情况下的恢复预案实施，确保影响可控之后，在经过多方团队评审或验证，才最终在线上实施。
从这个角度来讲SRE和混沌工程是什么关系，就非常清晰了，混沌工程是SRE稳定性体系建设的高级阶段，一定是SRE体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才会考虑的。
所以，引入混沌工程手段要非常慎重，我建议大可不必跟风过早引入，还是优先一步步打好基础再做考虑。
应该在什么时机做系统验证？
我们有了验证整个系统SLO的手段，但是我们可以看到，这两个手段都是要在生产系统上直接实施的，为了保证我们的业务正常运行，那我们应该选择在什么时机，以及什么条件下做系统验证呢？
我们可以参考Google给出的建议。
核心就是错误预算充足就可以尝试，尽量避开错误预算不足的时间段。因为在正常业务下，我们要完成SLO已经有很大的压力了，不能再给系统稳定性增加新的风险。
同时，我们还要评估故障模拟带来的影响，比如，是否会损害到公司收益？是否会损害用户体验相关的指标？如果造成的业务影响很大，那就要把引入方案进行粒度细化，分步骤，避免造成不可预估的损失。
这里，我和团队通常的做法，就是选择凌晨，业务量相对较小的情况下做演练。这样即使出现问题，影响面也可控，而且会有比较充足的时间执行恢复操作，同时，在做较大规模的全站演练前，比如全链路的压测，会做单链路和单业务的单独演练，只有单链路全部演练通过，才会执行更大规模的多链路和全链路同时演练。
总之，生产系统的稳定性在任何时候，都是最高优先级要保证的，决不能因为演练导致系统异常或故障，这也是不被允许的。所以，一定要选择合适的时机，在有充分准备和预案的情况下实施各类验证工作。
总结
今天我们结合一个电商案例，讨论了在落地SLO时还要考虑的一些实际因素。你需要重点掌握以下4点：
先设定核心链路的SLO，然后根据核心链路进行SLO的分解。
确定一个系统的核心链路，关键是确认核心应用和非核心应用，以及强弱依赖关系。这个过程在初始执行时，需要大量人工投入和分析，但是这个过程不能忽略。
强依赖的核心应用SLO必须与核心链路SLO一致，弱依赖的非核心应用SLO可以降低，但是必须要有对应的限流降级等服务治理手段。
通过容量压测和混沌工程等手段，对上述过程进行验证，但是一定要在错误预算充足的情况下执行。
思考题
最后，给你留一个思考题。
我们知道，不同的业务场景，考虑的限制因素也是不同的，对SLO设定也是一样的。本节课我们分享了一个电商业务应该要考虑的因素，你是不是可以按照这个思路，分享一个不同于电商的业务场景，应该或可能要考虑哪些特殊因素呢？
期待在留言区看到你的思考，也欢迎你把今天的内容分享给身边的朋友。
我是赵成，我们下节课见。

145
专栏/RE实战手册/06故障发现：如何建设On-Call机制？.md Normal file
View File

@ -0,0 +1,145 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
06 故障发现：如何建设On-Call机制？
你好，我是赵成，从今天开始，我们进入课程实践篇的内容。
在上一部分，我们学习了SRE的基础，需要掌握的重点是SLI和SLO以及Error Budget（错误预算）策略。SLI是我们选择的衡量系统稳定性的指标，SLO是每个指标对应的目标，而我们又经常把SLO转化为错误预算，因为错误预算的形式更加直观。转化后，我们要做的稳定性提升和保障工作，其实就是想办法不要把错误预算消耗完，或者不能把错误预算快速大量地消耗掉。
这么说，主要是针对两种情况：一种是我们制定的错误预算在周期还没有结束之前就消耗完了，这肯定就意味着稳定性目标达不成了；另一种情况是错误预算在单次问题中被消耗过多，这时候我们也要把这样的问题定性为故障。
今天，我们就来聊一聊，为了最大程度地避免错误预算被消耗，当我们定义一个问题为故障时，我们应该采取什么措施。
聚焦MTTR，故障处理的关键环节
好了，我们先回顾下在第1讲的时候，提到故障处理的环节就是MTTR，它又细分为4个指标：MTTI、MTTK、MTTF和MTTV，之所以分组分块，也是为了更加有目的性地做到系统稳定性。
那么，这四个环节，在我们故障处理MTTR又各自占多长时间呢？下面这个MTTR的时长分布图，是IBM在做了大量的统计分析之后给出的。-
-
我们可以看到，MTTK部分，也就是故障定位部分的时长占比最大。这一点，我们应该都会有一些共鸣，就是绝大部分的故障，往往只要能定位出问题出在哪儿了，一般都可以快速地解决故障，慢就慢在不知道问题出在哪儿，所以说我们大部分时间都花在寻找问题上了。
不过，从我实际分析的情况看，很多时候MTTR的时间分布跟这个图会有一些差别，为什么呢？
因为上面这张图是IBM针对网络设施的故障统计出来的，鉴于网络设备部署模式相对简单，以及日志和报错信息比较固定和明确，所以出现问题时，MTTI的判定阶段不会花太多时间。而且真的出现问题，基本上采取的策略一般也是定位到根因，再采取措施处理故障，除了主备切换等冗余措施，基本是没有太多其它手段。
但是，在一个分布式的软件系统下，我们判定一个问题发生在哪儿，影响范围到底是怎么样的，要召集哪些人共同参与定位排查等等，这个反而会消耗更多时间，所以我们看到MTTI阶段占比会更重。
另外，当一个分布式系统发生故障时，我们的策略一定不是找到根因，而是优先恢复业务。所以，我们往往是通过故障隔离的方式，先快速恢复业务，也就是我们经常听到的Design for Failure这样的策略，再具体一点，就是服务限流、降级、熔断甚至是主备切换这样的手段，这样的话，MTTK的占比会有所下降。
因此，从分布式系统的实际情况来看，整个MTTR的时间占比分布大致是这样的：-
-
其实，不管是不是分布式系统，我们针对处理故障的目的都是比较明确的，就是要提升每个环节的处理效率，缩短它们的处理时间，这样才会缩短整个MTTR，减少对不可用时长的消耗。
今天，我们就先来看MTTR的第一个环节，MTTI。看看在MTTI这个环节我们可以采取哪些措施来提高处理故障效率。关于MTTR中的另外三个环节，也就是MTTK、MTTF和MTTV我们会在后面的课程中继续讨论。
MTTI：从发现故障到响应故障
MTTI，就是故障的平均确认时间，也就是从故障实际发生时间点，到触发采取实际行动去定位前的这段时间。
这个环节其实主要有两件事情要做：第一件事，判断出现的问题是不是故障；第二件事，确定由谁来响应和召集。我们一一来看。
先看第一件事。我们平时遇到的问题很多，但是这些问题的影响不见得都很严重，或者都需要我们立即做出响应去处理。即便是故障，我们也会分不同的响应级别去处理。那我们怎么判断出现的问题是不是故障呢？如果是故障，我们应该以哪种级别去响应呢？
解决方案很明确，就是利用我们在《04 | 错误预算：达成稳定性目标的共识机制》中讲过的，根据错误预算制定故障等级的方式来判定响应方式。我们把trade_cart购物车的案例再拿出来，你可以再看下，作为参考。-
-
在没有SLO和错误预算这个体系时，我们通常会根据用户投诉，或客服对同一问题的重复反馈来判断。比如10分钟内，有超过50个用户投诉无法购买商品、支付不成功或者优惠券未生效等问题，我们就会启动应急响应。不过，一旦等用户和客服反馈，就说明故障影响已经非常恶劣了，用户也已经处于无法忍受的状态了。
显然这种方式并不高效。既然我们已经搭建了SRE体系，设定了SLO，能对稳定性进行量化管理，那我们就能比用户更快发现问题并响应问题了。至于用户投诉和客服反馈的渠道，只能是作为我们的辅助手段。
所以，我们可以根据设定的SLO和错误预算，准确判断发生的问题是否是故障，并依据故障等级决定我们采取什么样的措施去处理这些问题，大大提高反应效率。
接着来看第二件事，谁来响应和召集。这件事很容易理解，如果我们判定这个问题就是一个故障，首先要有人能判定，接下来需要哪些人来介入，并能够把相关的人员召集起来，一起来处理故障。
这两件事，其实就是SRE里面提到的On-Call机制。
我们可以看到，第一件事其实主要依赖于我们的监控和告警体系。这里我想再强调一下，在On-Call阶段，并不是所有的告警我们都要响应，如果不影响稳定性，一般的告警是可以降低响应级别的，我们只需要响应基于SLO的告警。
我和很多公司交流过，发现大家都非常重视监控体系的建设，监控指标梳理得也非常全面，而且各种监控技术和产品都会使用。比如，从最早的Zabbix，以及日志系统栈ELK，再到近两年随着Kubernetes而火爆起来的Prometheus等等，从技术上来说，这一点不是太大的问题。但是，第二件事往往容易被我们忽视，也就是On-Call的流程机制建设。
关于On-Call的两个案例
在正式讲流程机制之前，我先分享两个关于On-Call的案例。
第一个案例是发生在我自己团队里的，当时遇到一次大数据产品HBase故障。那是一个周六的下午，负责数据平台的运维同学收到了故障告警，出现了部分节点不可用，同时依赖该产品的搜索和推荐等业务也开始反馈异常，进而影响到广告曝光，导致资金损失。
问题出现后，我们很快明确了故障的严重程度，开始联系对应的负责人上线一起处理。因为是周末，所以需要一个个打电话联系，同时我们的HBase已经上云，所以处理过程又需要云产品的同事介入，这就又涉及到跨组织的协调。云产品内部又有分工，一线服务、二线产品研发支持，所以这个协调过程又是一个比较长的链条。再加上其他的权限问题，所以等相关人员就位开始真正排查问题的时候，距离发生故障已经有很长一段时间了。
当时我大致统计了下，仅仅协调人员到位并上线开始处理问题，这个过程就花去了45分钟，而真正解决问题的环节只用了15分钟。
第二个例子是国内第一大企业IM产品。因为产品本身的特点，每天早上八点半到九点，会有一波使用高峰，产品经常在这个时间段出故障。同时呢，这个时间段正好是互联网公司通勤时间，大部分技术员工都在上班的路上，根本没办法处理问题，导致故障时间过长。
所以为了保证及时响应，企业决定分批上下班，一批人早上在家值守，甚至是守在电脑旁随时应急，其他员工准时上班。等过了产品使用高峰期，值守的员工再陆续从家里出发上班。同时，下班也错开时间，保证有人可以及时响应。
这种错时保障机制，很多电商企业在大促保障或者重大活动期间也经常用，就是确保关键角色必须在线，随时应急响应。
通过以上两个案例，我们发现从整体上讲，如果要缩短MTTI时长，技术相关的监控告警很重要，但更关键的是一整套协作机制。这也是为什么像Google这样技术体系已经如此完善的公司，还要强调On-Call机制的重要性。
那么，我们怎样才能建设好On-Call 的流程机制呢？
On-Call的流程机制建设
接下来，我就跟你说说，在蘑菇街我们是怎么做的，我把这个流程总结为“On-Call关键5步法”。
1.确保关键角色在线。
这里的关键角色不是指一两个值班的运维或SRE人员，而是整个产品体系中的所有关键角色。比如电商就需要安排核心业务应用（如用户、商品、交易、优惠及支付等）的Owner，或Backup中至少有一人参与On-Call轮班。不过，接收故障告警或第一时间响应故障的，一般是运维、PE或SRE这样的角色，业务开发同事要确保及时响应SRE发起的故障应急。
2.组织War Room应急组织。
我们有专门处理故障的“消防群”（暗含着灭火的意思），会将这些关键角色纳入其中，当有故障发生时会第一时间在消防群通报，这时对应的On-Call同事就要第一时间最高优先级响应呼叫（Page）。如果是工作日，对于严重故障，会立刻组织成立War Room，责任人会马上聚到一起；如果是非工作时间，则会通过电话会议的方式拉起虚拟War Room。
3.建立合理的呼叫方式。
在On-Call的落地过程中，我们经常会遇到的一种情况，就是谁最熟悉某个系统，谁就最容易被7*24小时打扰。比如系统或应用的Owner或者是架构师，出现问题的时候一定是找这些同事处理的效率最高，所以就会造成这些同事被默认为On-Call。
但是这样做会极大地影响这些同事在正常业务开发上的精力投入。他们要么总是被打断，要么就是经常通宵处理问题，导致第二天无法正常工作，甚至在非工作日也得不到正常的休息。
这种情况下，我们建议使用固定的On-Call手机，建立手机与所有On-Call系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应IDC机房运维等等。这样我们在On-Call时就不再找具体的哪个人，而是手机在谁手中，谁就承担On-Call职责。除非问题迟迟得不到解决，或者遇到了疑难杂症，这种时候再呼叫其他同事参与进来。
无论是SRE、架构师，还是一线开发，熟悉某个系统的最快最好的方式就是参与On-Call，而不是看架构图和代码。所以，有效的On-Call机制，可以让团队更深刻地认识到目前系统的存在哪些问题，对自己的痛苦状态也会有更深刻的感受，进而对后面的改进措施才能更有针对性和落地性。同时，On-Call也可以培养和锻炼新人和Backup角色，这也是让新人尽快融入团队和承担责任的最好的方式。
4.确保资源投入的升级机制。
这个跟前面几条有相关性，有很多团队认为On-Call就是设置几个人值班，所有的事情都交给这几个人做；最极端的还会认为所有的事情，都应该是冲在最前线的运维或SRE来完成。但是，在分布式架构这种复杂场景下，这种思路是明显不可行的。
这里最核心的一点就是要给到运维和SRE授权，当他发现问题不是自己或现有On-Call人员能解决的时候，他有权调动其他必要资源投入。如果故障等级偏高，一下无法明确具体找哪些人员投入的时候，SRE或运维可以直接上升到自己的主管或相关主管那里，要求上级主管协调资源投入。必要时，还可以上升到更高级主管，甚至CTO或技术VP来关注。所以，授权非常关键，这一点的具体操作层面，我们会在后面的故障处理过程中再详细介绍。
5.与云厂商联合的On-Call。
现在企业上云是大势所趋，绝大多数情况下，我们对问题和故障的处理，是离不开与云产品工程师一起高效联动的。所以，我们应该把云产品和云厂商作为我们系统的一部分，而不是单纯的第三方。而对于云厂商来说，也要考虑把客户业务作为自身业务的一部分，只有这样双方才能紧密合作。我们应该提前做好与云厂商之间的协作磨合，联合故障演练，必要的授权等等。
总结
最后，我们做一下简单的总结。
我们按照MTTR的细化分段可以看到，处理故障的第一个环节就是MTTI，也就是故障发现阶段。这个阶段，我们要靠基于SLO的告警，更加精准地告知我们当前系统的稳定性出现的问题，并根据对SLO的影响程度，也就是错误预算的消耗情况作出判断，是否定性成故障。如果是故障，我们就要启动应急响应，而高效快速的应急响应，是要靠On-Call的流程机制来保证的。
关于建设On-Call的流程机制，我给你分享了我自己团队的“On-Call关键5步法”，咱们再一起复习一下：
确保关键角色在线；
组织War Room应急组织；
建立合理的呼叫方式；
确保资源投入的升级机制；
与云的联合On-Call。
当我们能够很好地做到以上两点的时候，我们就能大幅降低MTTI，也为接下来更高效的故障定位和恢复打下了坚实的基础。
思考题
最后，给你留一个思考题。
学完本节课的内容后，你觉得在故障处理中，是优先建设监控体系更重要，还是建设高效的On-Call机制更重要？它们两者应该怎么来结合会更有效？欢迎你在留言区分享你的思考。
如果你在On-Call方面也积累了一些经验，请分享在留言区，也欢迎你把今天的内容分享给身边的朋友。
我是赵成，我们下节课见。

143
专栏/RE实战手册/07故障处理：一切以恢复业务为最高优先级.md Normal file
View File

@ -0,0 +1,143 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
07 故障处理：一切以恢复业务为最高优先级
你好，我是赵成，欢迎回来。
上一讲我们讨论了MTTR的第一个环节，也就是MTTI（故障发现）阶段的应对措施。今天我们继续来看MTTR的另外三个环节，也就是MTTK、MTTF和MTTV阶段，这三个对应的就是故障诊断、修复与确认，我们一起来看在这些环节应该做好哪些事情。
今天的内容，我会围绕一条基本原则展开，那就是：在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。这也是我们故障处理过程中的唯一目标，没有第二个。
相信你一定理解这句话我想要表达的意思，但是在执行过程中，我们往往就是很难执行到位。原因是什么呢？
讲到这里，我先分享一个我自己团队的案例，因为这个案例非常典型，其中暴露出来的问题，你很有可能也遇到过。
我们先一起来看下。
一次应急操作导致的故障蔓延
在2016年的双十一前，我们蘑菇街策划了一场预热活动，各种优惠券非常诱人，当时确实吸引了大量的用户来参与。这个活动是秒杀类型，瞬时的并发量非常大，我们很乐观地以为做好了十足的准备。
然而真实情况是，一到时间点就出现了用户下单失败问题。当时，我们赶紧采取限流措施，但是发现下单请求仍然大量阻塞，用户访问超时失败。后来进一步排查，发现请求都阻塞在了价格计算的SQL语句上。这个信息很快传递到了DBA这里，DBA就马上采取措施：既然有阻塞，那扩容就是最快的手段，先尝试一下再说，所以马上做了Slave节点扩容。
因为当时情况紧急，DBA承受的精神压力也特别大，遗漏了做数据完整性和一致性校验，在数据没有完全同步完成的情况下，就把扩容节点上线了，结果就是阻塞问题有一定缓解，却出现了计费价格错误这种严重的业务故障，也就是优惠券的价格优惠没有用到，用户多付了钱。毫无疑问，紧跟着我们就收到了大量的用户投诉。
继续定位根源问题，我们发现用户的访问模型跟原来预估的不一致，当前的代码逻辑无论如何也支撑不住这样的访问量，唯一的方式就是紧急修改代码，然后做测试验证再上线。但是这样要花费非常长的时间，完全超出了活动时间，所以我们最终不得不临时取消预热活动，通过给用户退费或补发优惠券的方式来安抚客户。
后来，我们复盘总结，认为这次故障的发生和持续蔓延有三个原因。
第一个，故障隔离手段缺失。
之所以引发这样的故障，其实就是没有提前考虑到对应的故障隔离手段，比如有效的限流、降级和熔断。如果这些措施不具备，从技术层面其实已经很难采取有效的手段了，所以最后的结果就是，要么提前终止活动，要么等代码优化完成上线。
因此，这里业务恢复慢，根本原因不是响应不及时，处理流程不高效等等，这个跟处理过程关系不大，而是从根本上就不具备业务恢复的技术手段。所以结合你自身的工作情况，也要进行一个反思：是不是业务模型评估得不够准确？在Design-For-Failure的高可用设计上做得不够？等等。
第二，关键角色和流程机制缺失。
在处理故障过程中，DBA发现SQL语句执行阻塞了，觉得扩容有效，就马上去做了，并没有一个共同决策和反馈的机制。抛开态度，单从结果上讲就是忙中添乱，导致出现更为严重的衍生故障。
所以，我的总结就是，没有有效的故障应急处理流程，分工不明确，关键角色缺失，没有决策、反馈和通报机制，导致整个过程混乱失控。
第三，没有演练。
处理故障失败，导致预热活动以失败告终，其实也是因为我们缺乏演练，在面对真正的问题时，场面混乱，没有章法。
这里我说的是缺少演练，其实在我实际了解的很多案例中，但凡故障处理不好的，基本就是没有任何演练，这里又分为两种。
一种是我们前面讲的第一个原因，故障隔离手段缺失。要么缺失手段，不知从何入手，要么就是有限流降级等故障隔离策略，但是不敢尝试和演练。为什么呢？就是担心演练有可能也会影响正常业务，但这也侧面说明我们的技术方案仍然不够成熟和完善。因为如果在相对比较宽松的氛围下，都不敢演练不敢操作，那真正出问题的时候就更不敢乱动，或者动了系统会导致更多意想不到的状况。所以，我们应该借助演练的手段，来倒逼我们考虑得更完善才可以。
另一种就是整个应急流程基本跑不起来，要么是人凑不齐，要么是很多团队不愿意配合，只要是这种理由导致的无法演练，基本出现故障后，整个应急状态就是失控的。因为大家都是慌乱状态，平时都缺少配合和协作，在这种高压状态下，大家就更顾不上或者不知道该怎么配合了。
这么复盘下来，故障响应其实是两个方面，技术方面和流程机制方面。技术问题我们这里就不再做详细介绍了，你可以有针对性地看下我第一季课程里的第21讲《极端业务场景下，我们应该如何做好稳定性保障？》内容。
这里，我们重点来讨论如何建立有效的故障应急响应机制。
如何建立有效的故障应急响应机制
关于这一点，我们接着上一讲的内容说，当一个问题被定性为故障，这时我们就要成立War Room，如果是在办公时间，大家可以聚集到同一个会议室，或者同一块办公区域集中处理；如果是非办公时间，可以是视频、电话或微信会议的方式，形成虚拟的War Room。但无论是真实还是虚拟的War Room，根本目的是快速同步信息，高效协作。
在特别时期，比如双十一这样的大促活动，我们团队的做法一般是空出一个楼层，让所有参与保障的同事坐在一个楼层办公。在已经形成双十一文化的阿里，他们把这样的办公地点称为“光明顶”，各大高手齐聚于此，共同保障业务和系统稳定。
仅仅有War Room这样一个聚集形式还是不够的，既然我们把解决故障类比成战争，我们就一定要有一套相对应的指挥体系才可以，这个体系里面，我认为最重要的就是“关键角色分工”和“沟通机制”。
这里我先给你介绍下Google的指挥体系，然后再结合我自己的实践来展开。
关键角色分工
Google的故障指挥体系，是参考了美国消防员在处理1968年森林大火时建立的应急指挥体系，体系中有三个核心角色。
Incident Commander，故障指挥官，简称为IC。这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。
Communication Lead，沟通引导，简称CL。负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA或者是某个SRE来承担都可以，但是要求沟通表达能力要比较好。
Operations Lead，运维指挥，简称OL。负责指挥或指导各种故障预案的执行和业务恢复。
这里其实还有一类角色，虽然不在指挥体系内，但是也非常重要，我们也要做一下介绍：Incident Responders，简称IR。就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是QA等。
流程机制
在我自己团队的具体实践和场景中，我们按过程来分，会有如下的一个流程机制。
故障发现后，On-Call的SRE或运维，最一开始就是IC，有权召集相应的业务开发或其它必要资源，快速组织War Room。
如果问题和恢复过程非常明确，IC仍然是SRE，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先。
如果问题疑难，影响范围很大，这时SRE可以要求更高级别的主管介入，比如SRE主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织。这时SRE要将IC的职责转移给更高级别的主管，如果是全站范围的影响，必要时技术VP或CTO也可以承担IC职责，或者授权给某位总监承担。
从我们的实践经验来看，如果是大范围的故障，一般就是平台技术总监或电商业务的技术总监来承担IC职责，接下来他就可以从更高的层面组织和协调资源投入并有效协作。这时SRE会回归到OL的职责上，负责组织和协调具体的执行恢复操作的动作。
反馈机制
有了角色分工，也明确了流程，那整个故障响应是否高效的关键就是沟通机制了，这里我重点分享下我们团队在反馈上的一些经验和心得。
反馈的重要性是再怎么强调都不为过的。有时涉及的团队和人员比较多，很多具体执行的同事就只顾闷头定位和排查了，往往没有任何反馈，甚至做了很多的操作也是自行决定，不做通报。这时就会出现上面案例说的场景，极有可能衍生故障或者导致故障更大范围的蔓延，这是极为影响协作效率和决策的。
我们一般要求以团队为单位，每隔10～15分钟做一次反馈，反馈当前处理进展以及下一步Action，如果中途有需要马上执行什么操作，也要事先通报，并且要求通报的内容包括对业务和系统的影响是什么，最后由IC决策后再执行，避免忙中出错。
这里我要强调一点，没有进展也是进展，也要及时反馈。很多团队和成员往往会抱怨，我专心定位问题还没结果呢，有什么好反馈的呢？但是没有进展也是进展，IC会跟OL以及团队主管决策是否要采取更有效果的措施，比如10分钟之内还没定位结果，可能我们就会选择做有损的降级服务，不能让故障持续蔓延，这个时候，反馈就显得尤为重要。
同时，在这个过程中，为了尽量减少对执行者的干扰，让执行者能够更聚焦，我们一般要求团队Leader来收集反馈并传递IC的指令。CL也要收集信息，他要做的不是传达指令，而是在更大范围内同步汇总后的信息，同时还要整理信息传递给外部联系人。
到这里，我们会发现在故障处理过程中，特别是影响范围较大的故障，其实还会涉及一类非技术群体，这一类角色Google SRE并没有提，但是我们实践中会发现这一部分人也非常关键，比如客服、PR以及商家和其它各类合作代表等等。
为什么说他们也非常关键呢？因为我们要知道，故障之所以带来巨大的压力，很大程度上是因为业务影响导致的用户投诉和抱怨，以及合作伙伴们利益受损带来的各类负面情绪，这类抱怨和情绪有时候还会直接发泄到公司高管那里，这时压力就会层层透传下来。
所以，除了要做好怎么快速恢复业务，信息同步的及时和透明也非常关键，并且有些安抚措施必须要快速执行到位。
比如，现在更多的用户习惯在朋友圈、微博或知乎这样的社交平台发表意见，所以在用户不了解背景信息的时候，会表达一些情绪，甚至有些媒体为吸引眼球做夸大或抹黑的报道。为了遏制这些负面影响，公司PR要出面与平台或媒体沟通，并通过这些社交平台的官方账号做统一的信息同步，做到及时透明。
再比如，故障可能会对用户、商家或合作渠道造成利益损失，这时就需要运营和产品团队及时制定补偿策略，例如补偿优惠券等，并通过客服同步给用户和合作伙伴，这些对于安抚用户情绪至关重要。
所以，上述CL的信息收集、汇总以及与非技术团队的沟通就至关重要，怎么沟通呢？一定不是用技术术语，而是以尽量业务化的语言描述，并且要给到对方大致的预期，比如我们正在做什么，大致多长时间会恢复，如果不能恢复，大约多长时间内会给一个反馈等等。
这些措施的有效执行，会大大减少故障之外的干扰因素，让技术团队能够更专注于故障本身的处理。相反，如果这些事情不重视，我们就会发现，会有各种渠道和各种层级的领导以及接口人来质问你：“到底什么时候可以恢复？你们的系统为什么总是这么不稳定？”
所以，如果故障的影响范围很广，那我们就要考虑得尽量周全，这时的故障处理在一定程度上，就不单单是技术团队的问题了，而是需要整个公司都投入资源的。
这样需要全公司共同配合的事情，想要很顺畅地执行，那就一定要在日常做演练。同时有些事项比如反馈信息的模板，对外通报的模板都要提前建立好，每个角色只要按照模板填写内容即可，可以极大地保证沟通效率。
总结
好了，我们来做下总结。
故障处理过程中效率如何，其实取决于三个因素：技术层面的故障隔离手段是否完备；故障处理过程中的指挥体系是否完善，角色分工是否明确；故障处理机制保障是否经过足够的演练。
我们可以看到，想要高效地处理故障，并不是说我在技术层面做到完备就可以了，这是一个需要体系化建设和反复磨炼才能最终达成的目标。
思考题
最后，我留一个问题给你，想听听你的看法。
我在本节课中提到，故障应急过程中要有一个指挥官角色，他有权调动所有必要的角色参与到应急过程中，那么在你的公司或团队中，是由谁来指挥，或者说是由谁来承担这个角色的呢？
欢迎你在留言区分享，也希望你把本篇文章转发给你身边的朋友。
我是赵成，我们下节课见。

103
专栏/RE实战手册/08故障复盘：黄金三问与判定三原则.md Normal file
View File

@ -0,0 +1,103 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
08 故障复盘：黄金三问与判定三原则
你好，我是赵成，欢迎回来。
前两讲，我们聚焦在MTTR阶段，我跟你分享了从故障发现到故障处理的一些经验。但是，即便我们身经百战，做足了准备，故障的发生依然是很难避免的。这时候，我们也没必要太沮丧，SRE中有一条很重要的原则可以帮到我们，那就是“从故障中学习和提升”，也就是故障复盘。
那么，今天我会专门用一节课，来和你分享我在故障复盘过程总结的经验。
故障复盘的黄金三问
提起故障复盘，我自己的团队也是踩了很多坑，说出来都是血泪史。
最开始，我们坚信既然要复盘，那就一定要追根溯源，找到根因，最好是一次性解决所有问题，一次性把事情做对肯定是最高效的呀。
但是，在执行的过程中，我们发现，对于根因的理解和定义，每个人或每个角色都不一样。而且，一旦设定为找根因，那就只能有一个，还特别容易根据找到的根因来定责，导致把原本的寻求根因是什么，转变为“责任是谁”的问题。本来是想通过复盘来引导改进的，但是很容易画风一变，开始推诿扯皮，故障复盘会就开成了批斗会，每个参与的人都要承受很大的心理压力。
我这么说，不知道你是不是有同感。接下来我给你讲两个特别常见的情况，你也感受下。
比如，服务器故障导致上面业务也发生问题了，从业务开发同学的角度来看，这肯定是因为服务器不稳定造成的呀，根因就是服务器故障啊！但是从系统维护同学的角度来看，硬件故障属于不可控事件，所以这种情况下，根因应该是业务应用层没有做到高可用。你看，不同的角度，不同的分析判断。就这个情况来说，你觉得根因是什么？
再比如，网络瞬时抖动了一下，导致很多业务请求失败，严重的还导致了请求阻塞，服务不可用。那这种情况下根因是什么？是网络不好？还是业务应用没有做好容错和重试这种高可用机制？
上面这两种情况还算简单的。如果我们已经用到了公有云或私有云，基础设施都已经完全是第三方提供的时候，问题就不单单是内部的责任之争了，还会涉及甲乙双方之间的定责，必定会出现更多大的利益争执。这样的争执多了，一地鸡毛，但是对改进没有任何帮助。
后来我们的故障复盘做得越来越多，发现在真实的场景下，造成故障发生的因素确实会有很多；而且故障处理时间过长，迟迟无法恢复的原因也会有很多，如果再出现了衍生故障，可能又会有各种其他的原因。
经历过这样很痛苦的阶段后，我们总结出一条很重要的经验和观点，甚至是颠覆你对故障根因认知的观点：故障根因不止一个，与其争论根因是什么，不如一起看看引起故障的原因都有哪些，是不是都有改进的空间。
思路转变后，我们会将所有导致故障和衍生故障发生、业务恢复过程中耗时较长、以及做出错误决策的原因和环节都提炼出来，把这些都算是故障原因，然后针对这些问题和环节制定改进措施。
那这些原因和环节该怎么找呢？我们在做故障复盘的时候，首先会结合Timeline来做，也就是按照MTTI、MTTK、MTTF和MTTV先做一个分类；然后针对耗时长的环节，反复讨论改进措施是什么；最后定好责任人和时间点，后续持续跟进执行状况。
如果把这些经验再提炼一下，那就是我们总结出来的故障复盘黄金三问：
第一问：故障原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
具体开复盘会的时候，就是紧扣着这三问来进行的。除此之外不允许出现相互指责和埋怨的情况，如果出现，会议主持者要及时控制并打断。会议主持者这个角色，一般情况下，跟我们上一讲提到的CL（Communication Lead），也就是“沟通引导”是一个角色，在我们公司内部叫技术支持。
故障判定的三原则
通过黄金三问，我们找到了故障发生的原因，也明确了做什么可以优化，那接下来就是落地了。要落地，就要明确到底应该由谁来承担主要的改进职责。注意，这里我没有用谁应该承担主要责任，而是承担主要的改进职责，也就是由谁来执行改进措施。
具体怎么来做呢？我们制定了一些故障判定原则，最重要的就是下面这三条。
1. 健壮性原则。
这个原则是说每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等。例如，在B依赖A的状态下，被依赖方A出现问题，但是能够快速恢复，而依赖方B无法快速恢复，导致故障蔓延。这时，承担主要责任的是依赖方B，而不是被依赖方A。
我们前面介绍的服务器和网络类故障，其实就适用这个原则。如交换机故障发生主备切换导致的网络瞬时或短暂抖动，从网络设备这个组件来说，自身是有自愈能力的，而且在极短的时间内就可以恢复。如果应用因为抖动而失败、无法自愈，这种情况，业务应用就不能以服务器或网络故障为理由，不承担改进职责。
再比如，我们之前讲的强弱依赖问题。原则上，核心应用对非核心应用的依赖必须要有降级和限流手段。如果因为非核心应用的故障或者瞬时高并发访问，导致核心应用故障，这种情况下，主要的改进责任在核心应用，非核心应用只需要配合改造。
2. 第三方默认无责。
这一条是上一条的延伸，如果使用到了第三方的服务，如公有云的各类服务，包括IaaS、PaaS、CDN以及视频等等，我们的原则就是默认第三方无责。
这种涉及第三方服务的情况，在判定改进责任时会分为两部分，对内谁的服务受影响谁改进，并对外推进第三方改进，但是一定要按照我们之前讲的，稳定性一定要做到相对自我可控，而不是完全依赖外部。
比如，一个应用使用了CDN服务，如果一家CDN厂商服务出现问题，要做到随时可以切换到另外一到两家，这时就不能以某家CDN服务故障为由不做改进。如果用到了云存储，如S3、OSS或COS这样的服务，一定要保证存储有主备，当一个区域有问题时，也要做到可切换，甚至容忍一定的业务有损，但是必须保障全量没有大问题。
如果再提升下高可用视角，就要考虑做到双活或多活，单个Zone甚至单个Region出现问题时，也能做到切换。
对内，默认第三方无责，稳定性责任一定是内部角色承担，这样做有时看起来虽然不太合理，但这样做的目的，就是让内部意识到稳定性和高可用一定是我们自己的责任，决不能依赖任何一个第三方。这就相当于一个国家的军事国防，可以跟外部形成统一战线，可以做联合演习共同防御，但是绝不可能完完全全交给另外一个国家去建设和控制。
同时，这也是防止业务上云后，内部将大量的问题丢给外部云厂商去承担，甚至是让云厂商“背锅”，久而久之，内部员工对于稳定性的责任心就丢失掉了。
3. 分段判定原则。
这个原则主要应用在情况比较复杂的场景。当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断。比如我们在上一讲提到的大促故障案例，前半段是由于模型评估不准，没有故障隔离手段造成的，但是后半段，就是因为DBA的误操作，以及流程机制不完善造成的。
这样分段判定会让故障问题更聚焦，改进措施也会更有针对性。
讲到这里，故障判定的一些关键原则就讲完了。 做个小结，这些原则的根本出发点就是希望你摒弃 “根因只有一个” 这个的观点，以更开放的心态去寻找不足，而且要从自身找不足，目的就是找到更多可以改进的地方，不断从“故障中学习和改进”。
总结
今天的内容就讲完了，我们再来复习下。在做故障复盘时，我的经验和建议是：不要纠结于故障根因到底是哪个，而是把更多的注意力放在做哪些事情，可以提升故障处理的效率，缩短业务故障时长。
为了达到这个目的，我们定义了故障复盘的黄金三问，同时还设定了三个判定原则，明确改进措施的主要职责应该由谁来承担。希望通过这些具体的问题和原则，能帮助你做好故障复盘。
关于故障，我再说几句掏心窝子的话：“故障是系统运行的常态，正常才是特殊状态”。所以，你无论作为什么角色，一定要以一颗平常心来对待故障，能做到这个程度不容易，这就需要我们更加辩证地看待故障，我们一定要做到鼓励改进，而不是处罚错误。
思考题
最后，给你留一个思考题。
你可能还听说过5W分析法，就是针对故障复盘至少问5个为什么，通常就可以找到比较深层次的原因，或者是根因。你有没有用过5W的方法呢？你觉得5W方法是不是一个好的故障复盘分析手段呢？
欢迎你留言分享自己的思考，也可以把今天的内容分享给你的朋友，和他一起学习。
我是赵成，我们下节课见！

122
专栏/RE实战手册/09案例：互联网典型的SRE组织架构是怎样的？.md Normal file
View File

@ -0,0 +1,122 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
09 案例：互联网典型的SRE组织架构是怎样的？
你好，我是赵成，欢迎回来。
前面三讲，我们从故障这个关键事件入手，讲解了“优先恢复业务是最高优先级”这个原则，基于这个原则，在故障发生后，我们要做好快速响应和应急，并从故障中学习和改进。在这个学习过程中，你应该也能体会到，高效的故障应对和管理工作，其实是需要整个技术团队共同参与和投入的。这就引出了大家落地SRE都会遇到的一个难点：组织架构调整。
那落地SRE必须调整组织架构吗？典型的SRE组织架构是怎样的？接下来，我会用两讲内容和你探讨这些问题，分享我在蘑菇街实践的一些经验。
落地SRE必须调整组织架构吗？
好，那我们就开始吧，先给你看一张技术架构图。-
-
这是蘑菇街基于微服务和分布式技术的High-Level的架构图，也是非常典型的互联网技术架构图，自下而上共四层，分别是基础设施层、业务&技术中台层、业务前台层以及接入层，在右侧还有一个技术保障体系。如果你平时经常看一些架构方面的图书和文章，或者听过一些技术大会演讲的话，对这样的图应该不陌生。
你也许会问，咦，我们不是讲组织架构吗？咋一上来就说到技术架构上了？别急，我这么讲是有原因的，在讲SRE的组织架构之前，我们需要先明确两点内容。
第一，组织架构要与技术架构相匹配。
技术架构实现组织目标，组织架构服务并促成技术架构的实现，所以，我们不会单纯去讲组织架构，一定会结合着技术架构的现状和演进过程来分析。
第二，SRE是微服务和分布式架构的产物。
SRE这个岗位，或者说这个通过最佳实践提炼出来的方法论，就是在Google这样一个全球最大的应用分布式技术的公司产生出来的。
正是因为分布式技术的复杂性，特别是在运维层面的超高复杂性，才产生了对传统运维模式和理念的冲击和变革。
如果我们去梳理一下整个软件架构发展的历程，就可以得到下面这张图。我们会发现不仅仅是SRE和DevOps，就连容器相关的技术，持续交付相关的方法和理念，也是在微服务架构不断流行的趋势下所产生的，它们的产生就是为了解决在这种架构下运维复杂度过高的问题。
这样一套架构方法体系，也构成了现在非常流行和火热的概念：云原生架构。-
-
所以，不得不承认，这里的现实情况就是，基本所有的SRE经验都是基于微服务和分布式架构的，也都是在这样一个基础下产生的。大到BAT、头条和美团等，中等规模如蘑菇街，甚至是在传统行业中落地比较突出的，如部分运营商和银行。
那么，想要引入SRE体系，并做对应的组织架构调整，首先要看我们的技术架构是不是在朝着服务化和分布式的方向演进。如果架构还没这么复杂，其实也没有必要引入SRE这么复杂的运维体系，这本身就不匹配；再就是如果没有对应的架构支持，SRE技术层面的建设就没有切入点，想做也没法做。
总的来说，如果我们的技术架构朝着微服务和分布式的方向演进，那我们可以考虑落地SRE，这时候，我们的组织架构就要匹配我们的技术架构，也就是说，要想在组织内引入并落地SRE这套体系，原有技术团队的组织架构，或者至少是协作模式必须要做出一些变革才可以。
那下面我就以蘑菇街的技术架构为例，带你一起来看，在这样一个技术架构体系下，SRE的角色、职责分工以及协作模式应该是怎么样的。
蘑菇街的SRE组织架构实践
我们回到在开头给出的技术架构图，可以看到上下左右总共分了五块区域，我们就分块来看。
先看最下面的基础设施层，我们现在也定义为IaaS层，主要是以资源为主，包括IDC、服务器、虚拟机、存储以及网络等部分。
这里基础设施层和所需的运维能力，其实就是我们常说的传统运维这个角色所要具备的能力。但是这一层现在对于绝大多数的公司，无论在资源层面还是在能力层面，都有很大的可替代性。如果能够依托云的能力，不管是公有云还是私有云，这一部分传统运维的能力在绝大部分公司，基本就不需要了。
接下来往上，我们来看中台这一层。这里包括两部分，技术中台和业务中台。
技术中台主要包括我们使用到的各种分布式部件，如缓存、消息、数据库、对象存储以及大数据等产品，这一层最大的特点就是“有状态” ，也就是要存储数据的产品。
业务中台层，就是将具有业务共性的产品能力提炼出来，比如用户、商品、交易、支付、风控以及优惠等等，上面支撑的是业务前台应用。
什么是业务前台呢？如果以阿里的产品体系来举例，可以类比为淘宝、天猫、盒马、聚划算这样的业务产品。
无论这些业务前台的形态是什么样，但是都会利用到中台这些共享能力。这两层就是微服务化形态的业务应用了，这些应用最大的特点就是“无状态”，有状态的数据都会沉淀到刚才提到的技术中台的产品中。
最上面是接入层，分为四层负载均衡和七层负载均衡。前者因为跟业务逻辑不相关，所以通常会跟基础设施层放在一起，由传统运维负责。但是七层负载需要做很多业务层面的规则配置，所以通常会跟中台和前台一起运维，那这部分职责应该属于哪个角色呢？我们接下来就会讲到。
中台及前台的运维职责是怎么分工的呢？
技术中台的很多部件相对比较标准和通用，而且在公有云上也相对比较成熟了，比如数据库和缓存，对于绝大部分公司是可以直接选择对应的公有云产品的，比如蘑菇街，基本都已经将这些能力迁移到了云上。
在没有上云之前，我们的中间件团队会自研对应的技术产品，这部分产品的运维也会由中间件团队自运维。很多大型的公司会有专门的平台运维团队，负责整个中间件产品的运维。
业务中台和前台这两层的运维职责，通常就是我们常说的应用运维、PE（Production Engineer）或者叫技术运营这样的角色来承担。在我自己的团队是统一用PE来代表的。
其实这里PE的职责跟我们前面讲的SRE的职责已经非常接近了。在国内，PE这个角色与Google定义的SRE所具备的能力，最大差别就在于国内PE的软件工程能力有所缺失或相对较弱。这就导致很多基于技术中台的自动化工具、服务治理以及稳定性保障类的平台没办法自己研发，需要由另外一个团队来支撑和弥补，也就是图中技术中台的衍生部分，技术保障体系。
PE这个角色，是我们未来引入SRE实践的非常关键一环，PE要跟业务开发团队一起对业务系统的稳定性负责。
那我们接着看技术保障体系。
技术保障平台，这部分的能力一定基于技术中台的能力之上生长出来的，是技术中台的一部分，如果脱离了这个架构体系，这个技术保障体系是没有任何意义的。
所以这里我们又要强调一个理念：“运维能力一定是整个技术架构能力的体现，而不是单纯的运维的运维能力体现”。微服务和分布式架构下的运维能力，一定是跟整个架构体系不分家的。
它们的具体依赖关系，我在图中已经标示出来，你可以结合我给出的图示再体会和深入理解一下。
回到技术保障体系的建设上，我们看下架构图的右侧，它又分为效率和稳定两块。
工具平台团队，负责效能工具的研发，比如实现CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持。
这个要更多地介入到研发流程中，因为流程复杂度比较高，而且还要对接很多研发平台，如Git、Maven、代码扫描、自动化测试以及安全等平台，所以对业务理解及系统集成能力要比较强，但是技术能力要求相对就没那么高。
稳定性平台团队，负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划。我们会看到这个团队主要是为稳定性保障提供支撑，平台提供出来的能力是可以直接支撑业务开发团队的，反倒是PE这样的角色并不会直接使用。
这个团队和人员的技术能力要求会比较高，因为这里面很多的技术点是要深入到代码底层的，比如Java的字节码或Socket网络；有时还要面对海量数据，以及低时延实时计算的处理，比如全链路跟踪和监控；甚至是门槛更高的AIOps，还要懂专业算法。所以这个团队的建设复杂度会比较高，会需要很多不同领域的专业人员。
好了，到这里，我们从技术架构入手，层层剖析，分析了对应的人员安排和能力，你会发现，按照分层进行职责分工就是：基础设施和接入层的4层负载部分属于传统运维；技术中台如果自研，也就是我们常说的中间件团队，开发同学自己负责对应的工作，如果上云，则由PE负责；业务中台、业务前台以及接入层的7层负责均衡，同样是由PE来负责。
如果我们用一张组织架构图来展示的话，基本形态就是下图：-
总结
给出这张组织架构图，我们今天的内容也就讲完了。总结一下，从组织架构的角度来讲，对于稳定性或者说SRE我们可以推导出一个结论：SRE并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。如果从分工来看就是：
SRE = PE + 工具平台开发 + 稳定性平台开发
同时，这里的SRE，跟我们前面讲的运维和架构不分家一样，在组织架构上，是与承担技术中台或分布式架构建设的中间件团队在同一个体系中的。
根据我平时的交流情况看，很多的传统行业也基本是按照这样一个模式组建SRE体系，一方面会有向互联网借鉴的原因，另一方面，我觉得也是本质的原因，就是前面我们提到的，组织架构往往是与技术架构相匹配的，技术上如果朝着分布式和微服务架构的方向演进，那必然会产生出类似的组织模式。
讲到这里，一个典型的互联网式的SRE组织架构就介绍完了，但是仅有组织架构是不够的，还需要继续深入下去，看看这个组织下的每个角色是如何与外部协作，如何发挥稳定性保障的具体职能的。所以，我们下一讲就会结合具体的稳定性保障场景，来分享SRE与其他组织的协作模式是怎么样的。
思考题
最后，给你留一个思考题。
学习完本节课，你觉得在一个组织进行SRE体系建设和变革过程中，哪个角色最为关键呢？同时，哪个角色是跟你最相关的呢？
欢迎你在留言区分享，或者提出你对本节课程的任何疑问，也欢迎你把本篇文章分享给你身边的朋友。
我是赵成，我们下节课见。

113
专栏/RE实战手册/10经验：都有哪些高效的SRE组织协作机制？.md Normal file
View File

@ -0,0 +1,113 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
10 经验：都有哪些高效的SRE组织协作机制？
你好，我是赵成，欢迎回来。
上节课，我们讲了在互联网企业典型的SRE团队中，一般包含几个关键角色，PE、工具开发和稳定性开发，他们分别承担的职责就是业务运维、建设运维自动化平台和建设稳定性平台。在建设这些平台的过程中，这些角色对内要与中间件团队合作，基于微服务和分布式的架构来开发各类平台；对外，还要与业务开发配合，将提升效率和稳定性的能力提供出去。
但是仅仅有组织架构，有了队形还是不够的，各个团队和角色之间必须要配合协作起来才能发挥出SRE的作用，特别是对外与业务开发的合作，这样才能是一个有机的整体。
那怎样才能将这些角色有效地组合到一起呢？今天我就和你分享下我的经验，总结起来就是四个字：以赛带练。
什么是“以赛带练”？
“以赛代练”这个术语最早也是在一些体育赛事中提出来的，完整解释是通过比赛带动训练。比如足球、篮球或田径等比赛，目的就是让运动员在真实的高强度竞争态势和压力下，充分暴露出个人和团队的不足及薄弱点，然后在后续的训练中有针对性地改进，这样对于比赛成绩的提升有很大帮助，而不是循规蹈矩地做机械性训练。你也注意到，我用的是“带”，而不是“代”，所以整个过程不是用比赛代替训练，它更主要的作用是带动。
同样，这样的策略放在我们的系统稳定性建设中也非常适用。你也可以选择类似的真实且具备高压效果的场景，来充分暴露我们的稳定性存在哪些问题和薄弱点，然后有针对性地进行改进。
类似的场景，比如说极端的海量用户访问，像电商类产品的双十一大促、社交类产品在春晚的抢红包，以及媒体类产品的突发热点新闻等等，用户瞬时访问的流量是极大的，对于系统的稳定性冲击和挑战也就非常大。再或者，是极端的故障场景，比如机房断电、存储故障或核心部件失效等等。
所以，我们讲稳定性建设，一定也是针对极端场景下的稳定性建设。
不知道你有没有发现，其实我们有很多的稳定性保障技术和理念，比如容量规划和压测、全链路跟踪、服务治理、同城双活甚至是异地多活等，基本都是在这些场景下催生出来的，甚至是被倒逼出来的。
如果针对这样的极端场景，我们都可以从容应对，那你可以想象一下，日常一般的问题或小故障处理起来自然也就不在话下了。而且，目前各大电商网站的大促已经基本日常化，每月都会有，甚至每周每天都会有不同的促销活动，所以在这种密集程度非常高的大促节奏下，“以赛带练”的效果就会更加突出。
可以看到，“以赛带练”的目的就是要检验我们的系统稳定性状况到底如何，我们的系统稳定性还有哪些薄弱点。
那么，如果你在自己的团队来落地“以赛带练”的话，一定要先考虑自己的业务系统应对的极端场景到底是什么，然后基于这些场景去设计和规划。
SRE的各个角色如何协作？
赛场有了，要打好这场仗，我们得保证上赛场的选手们能够通力协作。对于我们想要达成的稳定性目标来说，就是要有一套高效的SRE协作机制。接下来我还是以电商大促这个场景为例，跟你分享我们SRE团队中各个角色的分工，以及可以通过哪些组织形式把各个角色组织起来。
想要把电商大促这场赛事做漂亮，保障准备工作至关重要。这个准备工作前后共有四个关键步骤，我们就一步一步来看。
第一步，大促项目开工会。
在这个会议上，我们会明确业务指标，指定大促项目的技术保障负责人，通常由经验丰富的业务技术成员或平台技术成员承担，同时会明确技术团队的分工以及各个团队的接口人，然后根据大促日期，倒排全链路压测计划。分工和计划敲定了，接下来就是一步步执行了。
第二步，业务指标分解及用户模型分析评审会。
业务指标分解和用户模型分析阶段，需要业务开发和PE团队共同配合，主要是共同分析出核心链路，同时PE要分析链路上的应用日常运行情况，特别是QPS水位，这里就要利用到我们前面03讲中示例的SLO的Dashboard，结合这两点，大致判断出要扩容的资源需求。
这里你可能会有疑问，为什么业务开发和PE要一同分析？因为每个PE是要负责一整条核心链路上的应用的，所以PE可以识别出更全局的链路以及整条链路上的容量水位情况。而每位业务开发往往只专注在某几个应用上，所以他可以把业务目标拆解得更细致，并转化成QPS和TPS容量要求，然后分配到一个个具体应用上，并且每个应用的Owner在后面要确保这些应用能够满足各自的QPS和TPS容量要求。
从这个过程中，你会发现，PE会更多地从全局角度关注线上真实的运行状态，而业务开发则根据这些信息做更细致的分析，甚至是深入到代码层面的分析。
同时，业务开发和PE在分析的时候，就要使用到稳定性开发团队提供的全链路跟踪和监控平台了，而不是靠手工提取日志来做统计分析。
接下来，根据容量评估的结果，由PE准备扩容资源，然后业务开发的应用Owner，通过运维自动化平台，做完全自动化的应用部署和服务上线即可，整个过程无需PE介入。
第三步，应急预案评审会。
在预案准备阶段，仍然是PE与业务开发配合，针对核心链路和核心应用做有针对性的预案讨论。这时就要细化到接口和方法上，看是否准备好限流、降级和熔断策略，策略有了还要讨论具体的限流值是多少、降级和熔断的具体条件是怎样的，最后这些配置值和配置策略都要落到对应的稳定性配置中心管理起来。
这里PE更多地是负责平台级的策略，比如，如果出现流量激增，首先要做的就是在接入层Nginx做限流，并发QPS值要设定为多少合适；再比如缓存失效是否要降级到数据库，如果降级到数据库，必然要降低访问QPS，降低多少合适，等等。
而业务开发则要更多地考虑具体业务逻辑上的策略，比如商品评论应用故障，是否可以直接降级不显示；首页或详情页这样的核心页面，是否在故障时可以完全实现静态化等等。
第四步，容量压测及复盘会。
在容量压测这个阶段，就需要PE、业务开发和稳定性平台的同学来配合了。业务开发在容量规划平台上构造压测数据和压测模型，稳定性平台的同学在过程中要给予配合支持，如果有临时性的平台或工具需求，还要尽快开发实现。
压测过程会分为单机、单链路和全链路几个环节，PE和业务开发，在过程中结合峰值数据做相应的扩容。如果是性能有问题，业务开发还要做代码和架构上的优化，同时，双方还要验证前面提到的服务治理手段是否生效。
压测过程中和每次压测结束后，都要不断地总结和复盘，然后再压测验证、扩容和调优，直至容量和预案全部验证通过。这个过程一般要持续2～3轮，时间周期上要3～4周左右。整个过程就会要求三个角色必须要非常紧密地配合才可以。
到这里，整个保障准备过程就结束了。你可以先思考下，这个过程中每个角色发挥的作用有哪些。接下来，我跟你一起提炼总结下。
第一，PE更加关注线上整体的运行状态，所以视角会更全局一些，业务开发则更关注自己负责的具体应用，以及深入到代码层面的分析工作。
第二，PE会主要负责平台级的公共部件，如缓存、消息和文件等；DBA负责数据库，所起到的作用与PE相同，他们关注这些平台部件的容量评估、服务治理策略，以及应急预案等；而业务开发则会把更多的注意力放在业务层面的容量评估和各类策略上。同时，PE和业务开发关注的内容是相互依赖的，他们的经验也有非常大的互补性和依赖性，所以这个过程，双方必须要紧密配合。
第三，这个过程中，你可能会发现，工具开发和稳定性开发的同学在其中参与并不多，这是因为他们的价值更多体现在平时。我们依赖的各类平台和工具，比如扩缩容、链路分析、测试数据制造、压测流量的模拟等能力，都是通过这两个团队在平时开发出来的。对于这两个团队来说，这个时候出现得越少，他们的价值才是越大的。
讲到这里，对于SRE体系中，每个角色要起到的作用，以及他们之间的协作机制就讲完了，各方职责不同，但是彼此互补和依赖，只有密切合作才能发挥出SRE体系的力量。
赛场上的哪些工作可以例行化？
谈完了“以赛带练”这种大促场景下的协作机制，那没有大促的时候，SRE组织中的各个角色平时应该要做些什么呢？
其实，我们前面提到的“以赛带练”的事情，会有一部分转化为例行工作，同时还会增加一些周期性的工作。总结起来就是以下两项主要工作。
第一项，核心应用变更及新上线业务的稳定性评审工作。这里就包括前面讲到的容量评估和压测、预案策略是否完备等工作。PE会跟业务开发一起评估变动的影响，比如变动的业务逻辑会不会导致性能影响，进而影响容量；对于新增加的接口或逻辑，是否要做限流、降级和熔断等服务治理策略，如果评估出来是必需的，那上线前一定要把这些策略完善好；同时在测试环境上还要做验证，上线后要关注SLO是否发生变化等。
第二项，周期性技术运营工作。这些就包括了我们要例行关注错误预算的消耗情况，每周或每月输出系统整体运行报表，并召集业务开发一起开评审会，对变化较大或有风险的SLO重点评估，进而确认是否要采取改进措施或暂停变更，以此来驱动业务开发关注和提升稳定性。
这里的技术运营工作，是PE职责非常大的转变，因为随着各类平台的完善，很多原来依赖运维完成的事情，业务开发完全可以依赖平台自主完成，无需运维介入。比如代码发布、配置变更，甚至是资源申请。
所以，这时我们会更强调PE从全局角度关注系统，除了稳定性，还可以关注资源消耗的成本数据，在稳定和效率都有保证的前提下，也能够做到成本的不断优化。这样也会使得PE从原有繁琐的事务中抽离出来，能够去做更有价值的事情。关于这一点，也是给运维同学一个转型和提升的建议。
总结
好了，我们做下本节课的总结。
我们借助大促这样的场景，通过“以赛带练”的思路来驱动稳定性体系的建设和提升。这个过程中，PE更加关注全局和系统层面的稳定性，并提供各类生产环境的运行数据；而业务开发则会更关注业务代码和逻辑层面的稳定性，与PE互补且相互依赖；而稳定性和工具开发提供平台和工具支撑，保障每一个环节更加高效地完成。最后，我们还会将这些工作例行化，转化成日常的稳定性保障事项。
思考题
最后，给你留一个思考题。
对于“以赛带练”的思路，除了今天我们介绍到的，在你实际的工作中还有哪些场景可以尝试？
欢迎你在留言区分享，或者提出你对本节课程的任何疑问，也欢迎你把本篇文章分享给你身边的朋友。
我是赵成，我们下节课见。

104
专栏/RE实战手册/答疑没什么能阻挡你拓展边界的渴望.md Normal file
View File

@ -0,0 +1,104 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
答疑 没什么能阻挡你拓展边界的渴望
你好，我是赵成。
最近一直关注你的留言，我发现大家有一些共性的问题，所以专门准备了这次答疑加餐，和你分享我的一些想法，还有我看到的特别有洞见的留言，我们一起继续交流。今天我总共梳理了六个问题，前五个和SRE的落地及概念有关，最后一个关于个人成长，那我们就开始吧。
小团队，实践SRE可以从哪些方面入手？中小型公司资源有限，怎么做才能让系统全方位地稳定起来呢？
如果确实资源有限，我的建议是跟业务开发坐到一起，就不要独立去做一些事情了，这时还是以满足业务开发的需求为主。如果时间精力充足，可以先从一些重复繁琐工作的自动化入手，先提升效率再说。
再就是，团队规模小的时候，其实恰恰是提升技能全面性的机会，因为这时分工没有这么细，从网络、服务器、操作系统，再到Web服务器、应用服务器、数据库、缓存等等，都是学习和接触的好机会。
随着业务的增长，未来团队变大，就可以考虑SRE体系化了，建议先做一些分布式、微服务和高可用架构方面的知识储备，未来随着实践的深入，视野自然会逐步打开。
如何定义一个故障？有什么具体方法吗？粒度怎么界定？
定义一个故障，我觉得有两种方式。
一种是我们SRE课程第04讲中错误预算的计算方式。这种方式是从技术维度来定义，通常会用在一些技术产品中，比如云计算行业里的CDN、云存储，或者是一些提供开放API调用的服务，这种产品根据调用的返回码、响应时延以及错误码等等就可以评估系统稳定性，具体方式我在课程里有详细讲到，你可以再复习一下。这里的关键还是找到能够衡量稳定性的指标，并设定稳定性指标的SLI和SLO，进而推导出错误预算。如果一开始不好衡量，就先从当前的实际情况出发，比如成功率的SLO是98%，那就看怎么提升到99%，再到99.9%，逐步提升。
还有一种是我在《赵成的运维体系管理课》第 28 讲中讲到的，如果我们负责的是一个业务系统，比如电商类的，这时就要从业务维度进行分析，比如影响到的交易额、订单数、访问用户数等等。我给你放一张图，你可以参考下。
SRE是否需要从项目开始就参与系统架构设计？如果只是在项目上线运行后才接触，遇到架构不合理的地方如何处理？
SRE是不是要在项目开始的时候就参与到系统架构设计中，答案是肯定的。即使不是在项目开始时介入，也要在做技术方案和架构设计阶段就要参与进来，这个时候不一定参与架构本身的设计，但是要给架构提出明确的稳定性要求，比如哪些是核心部件？它们的稳定性要求应该是怎么样的，也就是SLO要达到多少？承诺的容量水平是多少？如果要做到高可用，是需要集群模式，还是主备模式？故障时的应急切换机制应该怎么设定？等等。这些要求决定了高可用的架构应该怎么设计。
如果是上线后才接触，还是先从SLO入手，建立SLO的稳定性衡量标准，然后看哪里不达标，就推进解决。SRE更多的要成为稳定性的监督者和推进者，而不是各种问题的救火队员。
国内传统行业的SRE组织架构是什么样的，有必要设置SRE岗位吗？
国内传统行业的SRE组织架构基本也是我在09讲中提到的组织架构。其实最开始我也很好奇传统行业会不会特别不一样，后来走访了一些企业后，我发现其实是殊途同归的，因为不论是传统行业还是互联网行业，大家选择了相似的架构演进方向，就需要有配套的组织架构，无论是实线的组织架构，还是虚线的协作模式，形式上大致相似。
至于是否有必要设置SRE岗位，我觉得真的不能把SRE只当成一个岗位来看，它实际传递的是一种稳定性的理念。遵循这种理念去做，这个岗位是不是叫SRE其实都已经不重要了，比如在阿里和蘑菇街，甚至是国外的Facebook，都叫做PE，在这些公司里PE在职责上跟SRE是一样的。
讲到这里呢，就多说一下PE（Production Engineer）这个角色，翻译成中文是生产系统工程师，最早是由雅虎定义出来的一个岗位，注意，这个岗位不是运维。这个角色的职责其实是由软件架构师承担的，也就是架构师负责设计架构，参与核心功能研发，对于产品了解得也最全面，所以系统上线后，维护的工作自然由他来承担，同时，随着线上问题的解决和处理，以及对线上问题的反思和总结，他又会不断完善架构设计和改造，是一个不断正循环的过程。
所以，你看，PE这个角色从一开始就是有非常高的要求的，并不是普通角色能承担的。阿里也是在收购了雅虎中国后，将PE的角色和先进机制引入到了阿里的技术体系中，国外很多公司也沿用了PE这样的角色，可以说从根本上，PE跟SRE的要求和作用是一样的。
DevOps和SRE有什么区别？
这个问题，是我在第01讲中留的作业题，我发现很多同学的回答已经非常深入了，我分享两位同学的理解。
来自于加硕同学：
DevOps核心是做全栈交付，SRE的核心是稳定性保障，关注业务所有活动，两者的共性是都使用软件工程解决问题。
DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频地迭代来满足市场需求，抢占市场（产品的迭代是关乎一整条交付链的事），高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，运维必须开启DevOps来实现全栈交付。因为不断的迭代交付（也就是俗称的变更）是触发故障、非稳定性的根源，而对于互联网产品来说，服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。
来自无聊的上帝：
DevOps主要是以驱动价值交付为主，搭建企业内部的功效平台。SRE主要需要协调多团队合作来提高稳定性。-
例如：-
与开发和业务团队落实降级；-
与开发和测试团队推动混沌工程落地；-
与开发团队定制可用性衡量标准；-
与开发、测试、DevOps、产品团队，共同解决代码质量和需求之间的平衡问题。
我为什么觉得这两位同学的留言有见地呢？因为他们都找到了看待这个问题的全新的角度，不是单纯地比较这两者应该采用什么技术，做什么事情，而是聚焦到我们要解决什么问题上。DevOps的出发点是“更加高效地交付用户价值”，而SRE的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同，那么在执行的时候，要解决的问题也就会有所差异。
在工作职责和经验有限的情况下，怎么不断提升自己，拓展自己的能力边界？怎么提高英语水平？怎么提升编码能力？
我觉得对于我们技术人来说，最好的提升自己的方式就是实践，解决实际问题，然后思考总结，比如输出总结文章等等。解决的问题越多，能力自然会提升，边界和视野自然会打开。
关于提高英语水平，我觉得也是一样，就是多听多看多说。
这一部分，我不打算分享太多细节，为什么呢？因为我觉得关于学习和成长，是需要我们每个人沉下心来从一点一滴做起的，比如从读第一篇英文文章和论文开始，不懂的单词一个一个查清楚，一句话看不懂，耐心多读几遍，今天读不懂，明天后天再回头来读，再体会。
学习真的就是这样一点一滴积累，耐住性子，一开始可能积累得会比较慢，但是慢慢地就会越来越快。
所以，最终的建议就是，从现在开始，先做起来再说吧。
讲到这里，我就给你推荐一下系统学习SRE的资料吧，我认为到目前为止，最体系化的学习资料就是Google官方发布的3本书，全英文版，要学习英语就从他们开始学起吧。
关于这三本书的阅读循序，建议你先读兼具普适性和参考性的第二本，然后再看第一本，最后读第三本。
好了，今天的答疑就到这里了。学习的过程中，如果你还有什么疑惑或者心得体会，欢迎继续写在留言区，和大家一起交流。

43
专栏/RE实战手册/结束语聊聊我的SRE落地心路历程.md Normal file
View File

@ -0,0 +1,43 @@
因收到Google相关通知，网站将会择期关闭。相关通知内容
结束语 聊聊我的SRE落地心路历程
你好，我是赵成，不知不觉我们已经来到了结束语，非常感谢你的一路陪伴。
学完咱们的专栏，我想对于SRE到底是怎么一回事儿这个问题，你应该有一个大致的了解了。就像我们在开篇词中提到的，SRE真的没有那么神秘，你平时在做的很多事情本身就属于SRE的范畴，学到这里，你应该对此深有体会了。
其实这个感受我也是在不断实践的过程中总结出来的。刚接触这个概念的时候立马被它吸引，但同时也觉得这东西有点儿高大上，自己有种心有余而力不足的感觉。幸好和团队一起，就是一点一点死磕，解决一个又一个具体的问题，然后因为一直有这样一个大的框架和目标在那里，最后慢慢发现，这个框架居然已经落地得差不多了。如果总结下我自己实践SRE的心路历程，我觉得王阳明《传习录》里的“知者行之始，行者知之成”就特别恰当、准确。
你是不是在想，这不就是知行合一嘛，也没啥特殊啊！嗯，确实是，听起来、说起来都挺简单的，但是很多时候我们想要做到还真不容易。
其实，在学习这个课程的过程里，我们也需要知行合一，从知出发，到行完成一个闭环，然后积累新的知，把这个知行的循环一直继续下去。
这么说，有点抽象，这里我特别举咱专栏里一位同学的例子。这位同学名字叫胡凯，他一边学习课程，一边和我探讨一些SRE问题。每次提问，他总是可以带着具体场景和具体问题，非常有针对性，而且针对不同的场景，他又会有自己的一些见解和解决方案，然后在与我讨论的过程中，不断迭代优化他的思路和方案，特别是在SLO设定这一块，因为很多监控指标都是现成的，他马上就根据我们课程里给出的VALET方法，整理出了一个新的表格，这种从更多SLO维度分析稳定性的方法，一下子就解答了他之前一直以单一维度判断稳定性的很多疑惑和问题。
像胡凯这样的同学，我们专栏里还有很多，大家都提出了非常好的问题，也分享了自己的思考和总结。这个我们一起交流探讨的过程，对于我来讲也是一次难得的学习机会，我想这就是“教学相长”的意义吧。
那么，接着这个话题，我再唠叨几句我的期待吧。这个课程基础篇的几讲是我花费心思最大的内容，因为我想从基础上就讲明白SRE的一些概念和理论。说实话，这部分内容也是需要你花费很大的精力和实践去消化的。如果你之前有过一些实践，再结合我们的课程去看的时候，你会发现理解起来就会轻松很多，也会有更多的收获；如果你现在还没有那么多的实践，这些内容你理解起来还没那么直观，那接下来就要抓住工作中的具体场景和问题，先去实践下，再回过头来看这几讲，到时候你肯定会有不一样的理解，我也会在这里，继续等你提出更好的问题来。
所以你看，对于我们从书本、课程中学习到的知识，要想把它们真正地转化为自己的能力，唯一的方法就是实践、思考、优化实践，并且不断重复这个过程。
对于我们要学习的SRE来说，也是这样。我认为很多人之所以没能好好落地SRE，一个最大的障碍不是技术难度、甚至不是组织架构和文化等问题，而是大家先把自己局限在了概念上，很多人深深地沉浸在SRE到底是什么，它跟现在非常流行的DevOps、AIOps、混沌工程以及各类中台的概念到底是怎样的一个关系？我们该怎么选？……纠结在这样那样的问题中，结果就是在问题漩涡中停滞不前，迈不出第一步，那就永远都走不前去。
这时候应该怎么做呢？我的建议就是，从你遇到的实际问题出发，从你所在的实际场景出发，解决问题，满足场景需求，先做起来再说，然后参考优秀的实践案例和分享，再做优化和调整。
其实，在蘑菇街实践SRE的时候，我们也不是天天把SRE挂在嘴边，也不是动不动就提DevOps、AIOps这些名词的，相反，我们提到的更多是面对某个场景，我们的容量评估应该怎么做？细化到每个应用、每个接口上限流阈值是多少，降级和熔断的具体判断策略是怎么样的？发生故障时，我们Step by Step的响应过程应该是怎么样的？需要哪些人参与？大家应该怎么协作？对于监控，怎么才能更准确？需要用到什么具体算法，参数应该怎么设定？……
你看，这些问题基本都是针对具体问题和具体场景的，而且针对这些问题和场景业界都已经有非常多的经验和案例供我们参考了，也就是我们大有可为的地方太多了。你可以设想一下，如果这些问题都能够解决得很好，我们是不是就已经达到了SRE的标准了呢？我们是不是就已经是SRE了呢？
我想答案是肯定的。
好了，到这里，我们专栏的内容就全部结束了。Google给我们呈现的SRE是理论性的、指导性的，业内在这方面的实践还是相对稀缺。想要更好地落地SRE，那就需要我们每一个团队和每一个热爱SRE的同行一起实践、一起总结、一起分享。
那还等什么，SRE并不神秘，让我们一起探索出一条适合我们自己的SRE实践之路。