mod

极客时间专栏/SRE实战手册/实践篇/06 | 故障发现：如何建设On-Call机制？.md

@@ -0,0 +1,135 @@
+<audio id="audio" title="06 | 故障发现：如何建设On-Call机制？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/63/8f/634329a384810be3071d1a3b3fe2c38f.mp3"></audio>
+
+你好，我是赵成，从今天开始，我们进入课程实践篇的内容。
+
+在上一部分，我们学习了SRE的基础，需要掌握的重点是SLI和SLO以及Error Budget（错误预算）策略。SLI是我们选择的衡量系统稳定性的指标，SLO是每个指标对应的目标，而我们又经常把SLO转化为错误预算，因为错误预算的形式更加直观。转化后，我们要做的稳定性提升和保障工作，其实就是想办法不要把错误预算消耗完，或者不能把错误预算快速大量地消耗掉。
+
+这么说，主要是针对两种情况：一种是我们制定的错误预算在周期还没有结束之前就消耗完了，这肯定就意味着稳定性目标达不成了；另一种情况是错误预算在单次问题中被消耗过多，这时候我们也要把这样的问题定性为故障。
+
+今天，我们就来聊一聊，为了最大程度地避免错误预算被消耗，当我们定义一个问题为故障时，我们应该采取什么措施。
+
+## 聚焦MTTR，故障处理的关键环节
+
+好了，我们先回顾下在第1讲的时候，提到故障处理的环节就是MTTR，它又细分为4个指标：MTTI、MTTK、MTTF和MTTV，之所以分组分块，也是为了更加有目的性地做到系统稳定性。
+
+<img src="https://static001.geekbang.org/resource/image/3d/dd/3dd910e354da003e234b0340b68e76dd.jpg" alt="">
+
+那么，这四个环节，在我们故障处理MTTR又各自占多长时间呢？下面这个MTTR的时长分布图，是IBM在做了大量的统计分析之后给出的。<br>
+<img src="https://static001.geekbang.org/resource/image/e5/fd/e5b28b0bed414afe8feda4f67b21a6fd.jpg" alt=""><br>
+我们可以看到，MTTK部分，也就是故障定位部分的时长占比最大。这一点，我们应该都会有一些共鸣，就是绝大部分的故障，往往只要能定位出问题出在哪儿了，一般都可以快速地解决故障，慢就慢在不知道问题出在哪儿，所以说我们大部分时间都花在寻找问题上了。
+
+不过，从我实际分析的情况看，很多时候MTTR的时间分布跟这个图会有一些差别，为什么呢？
+
+因为上面这张图是IBM针对网络设施的故障统计出来的，鉴于网络设备部署模式相对简单，以及日志和报错信息比较固定和明确，所以出现问题时，MTTI的判定阶段不会花太多时间。而且真的出现问题，基本上采取的策略一般也是定位到根因，再采取措施处理故障，除了主备切换等冗余措施，基本是没有太多其它手段。
+
+但是，在一个分布式的软件系统下，我们判定一个问题发生在哪儿，影响范围到底是怎么样的，要召集哪些人共同参与定位排查等等，这个反而会消耗更多时间，所以我们看到MTTI阶段占比会更重。
+
+另外，当一个分布式系统发生故障时，我们的策略一定不是找到根因，而是优先恢复业务。所以，我们往往是通过故障隔离的方式，先快速恢复业务，也就是我们经常听到的Design for Failure这样的策略，再具体一点，就是服务限流、降级、熔断甚至是主备切换这样的手段，这样的话，MTTK的占比会有所下降。
+
+因此，从分布式系统的实际情况来看，整个MTTR的时间占比分布大致是这样的：<br>
+<img src="https://static001.geekbang.org/resource/image/8e/ac/8e55074c8ec8e2c741ebeac7f7ae80ac.jpg" alt=""><br>
+其实，不管是不是分布式系统，我们针对处理故障的目的都是比较明确的，就是要提升每个环节的处理效率，缩短它们的处理时间，这样才会缩短整个MTTR，减少对不可用时长的消耗。
+
+今天，我们就先来看MTTR的第一个环节，MTTI。看看在MTTI这个环节我们可以采取哪些措施来提高处理故障效率。关于MTTR中的另外三个环节，也就是MTTK、MTTF和MTTV我们会在后面的课程中继续讨论。
+
+## MTTI：从发现故障到响应故障
+
+MTTI，就是故障的平均确认时间，也就是从故障实际发生时间点，到触发采取实际行动去定位前的这段时间。
+
+这个环节其实主要有两件事情要做：**第一件事，判断出现的问题是不是故障；第二件事，确定由谁来响应和召集**。我们一一来看。
+
+先看第一件事。我们平时遇到的问题很多，但是这些问题的影响不见得都很严重，或者都需要我们立即做出响应去处理。即便是故障，我们也会分不同的响应级别去处理。那我们怎么判断出现的问题是不是故障呢？如果是故障，我们应该以哪种级别去响应呢？
+
+解决方案很明确，就是利用我们在[《04 | 错误预算：达成稳定性目标的共识机制》](https://time.geekbang.org/column/article/215649)中讲过的，根据错误预算制定故障等级的方式来判定响应方式。我们把trade_cart购物车的案例再拿出来，你可以再看下，作为参考。<br>
+<img src="https://static001.geekbang.org/resource/image/cc/c6/cc0987ffd5d5d9391bc58eb505c6ecc6.jpg" alt=""><br>
+在没有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步法”，咱们再一起复习一下：
+
+1. 确保关键角色在线；
+1. 组织War Room应急组织；
+1. 建立合理的呼叫方式；
+1. 确保资源投入的升级机制；
+1. 与云的联合On-Call。
+
+当我们能够很好地做到以上两点的时候，我们就能大幅降低MTTI，也为接下来更高效的故障定位和恢复打下了坚实的基础。
+
+## 思考题
+
+最后，给你留一个思考题。
+
+学完本节课的内容后，你觉得在故障处理中，是优先建设监控体系更重要，还是建设高效的On-Call机制更重要？它们两者应该怎么来结合会更有效？欢迎你在留言区分享你的思考。
+
+如果你在On-Call方面也积累了一些经验，请分享在留言区，也欢迎你把今天的内容分享给身边的朋友。
+
+我是赵成，我们下节课见。

极客时间专栏/SRE实战手册/实践篇/07｜故障处理：一切以恢复业务为最高优先级.md

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

极客时间专栏/SRE实战手册/实践篇/08｜故障复盘：黄金三问与判定三原则.md

@@ -0,0 +1,93 @@
+<audio id="audio" title="08｜故障复盘：黄金三问与判定三原则" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/da/a61c2ffcbab2a2e00be094d7e94f33da.mp3"></audio>
+
+你好，我是赵成，欢迎回来。
+
+前两讲，我们聚焦在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方法是不是一个好的故障复盘分析手段呢？
+
+欢迎你留言分享自己的思考，也可以把今天的内容分享给你的朋友，和他一起学习。
+
+我是赵成，我们下节课见！

极客时间专栏/SRE实战手册/实践篇/09｜案例：互联网典型的SRE组织架构是怎样的？.md

@@ -0,0 +1,114 @@
+<audio id="audio" title="09｜案例：互联网典型的SRE组织架构是怎样的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/65/36/65433a6881c8eba5a01cc52ad4f87936.mp3"></audio>
+
+你好，我是赵成，欢迎回来。
+
+前面三讲，我们从故障这个关键事件入手，讲解了“优先恢复业务是最高优先级”这个原则，基于这个原则，在故障发生后，我们要做好快速响应和应急，并从故障中学习和改进。在这个学习过程中，你应该也能体会到，高效的故障应对和管理工作，其实是需要整个技术团队共同参与和投入的。这就引出了大家落地SRE都会遇到的一个难点：组织架构调整。
+
+那落地SRE必须调整组织架构吗？典型的SRE组织架构是怎样的？接下来，我会用两讲内容和你探讨这些问题，分享我在蘑菇街实践的一些经验。
+
+## 落地SRE必须调整组织架构吗？
+
+好，那我们就开始吧，先给你看一张技术架构图。<br>
+<img src="https://static001.geekbang.org/resource/image/69/ac/69a12388ac0795a84bcdc8489bb196ac.jpg" alt=""><br>
+这是蘑菇街基于微服务和分布式技术的High-Level的架构图，也是非常典型的互联网技术架构图，自下而上共四层，分别是基础设施层、业务&amp;技术中台层、业务前台层以及接入层，在右侧还有一个技术保障体系。如果你平时经常看一些架构方面的图书和文章，或者听过一些技术大会演讲的话，对这样的图应该不陌生。
+
+你也许会问，咦，我们不是讲组织架构吗？咋一上来就说到技术架构上了？别急，我这么讲是有原因的，在讲SRE的组织架构之前，我们需要先明确两点内容。
+
+**第一，组织架构要与技术架构相匹配**。
+
+技术架构实现组织目标，组织架构服务并促成技术架构的实现，所以，我们不会单纯去讲组织架构，一定会结合着技术架构的现状和演进过程来分析。
+
+**第二，SRE是微服务和分布式架构的产物**。
+
+SRE这个岗位，或者说这个通过最佳实践提炼出来的方法论，就是在Google这样一个全球最大的应用分布式技术的公司产生出来的。
+
+正是因为分布式技术的复杂性，特别是在运维层面的超高复杂性，才产生了对传统运维模式和理念的冲击和变革。
+
+如果我们去梳理一下整个软件架构发展的历程，就可以得到下面这张图。我们会发现不仅仅是SRE和DevOps，就连容器相关的技术，持续交付相关的方法和理念，也是在微服务架构不断流行的趋势下所产生的，它们的产生就是为了解决在这种架构下运维复杂度过高的问题。
+
+这样一套架构方法体系，也构成了现在非常流行和火热的概念：云原生架构。<br>
+<img src="https://static001.geekbang.org/resource/image/c0/b8/c00aeaab24ac3cf7cdc518701a33d5b8.jpg" alt=""><br>
+所以，不得不承认，这里的现实情况就是，基本所有的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来负责。
+
+如果我们用一张组织架构图来展示的话，基本形态就是下图：<br>
+<img src="https://static001.geekbang.org/resource/image/84/85/842f14ae8168a7ee1703b5ba26a55f85.jpg" alt="">
+
+## 总结
+
+给出这张组织架构图，我们今天的内容也就讲完了。总结一下，从组织架构的角度来讲，对于稳定性或者说SRE我们可以推导出一个结论：SRE并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。如果从分工来看就是：
+
+**SRE = PE + 工具平台开发 + 稳定性平台开发**
+
+同时，这里的SRE，跟我们前面讲的运维和架构不分家一样，在组织架构上，是与承担技术中台或分布式架构建设的中间件团队在同一个体系中的。
+
+根据我平时的交流情况看，很多的传统行业也基本是按照这样一个模式组建SRE体系，一方面会有向互联网借鉴的原因，另一方面，我觉得也是本质的原因，就是前面我们提到的，组织架构往往是与技术架构相匹配的，技术上如果朝着分布式和微服务架构的方向演进，那必然会产生出类似的组织模式。
+
+讲到这里，一个典型的互联网式的SRE组织架构就介绍完了，但是仅有组织架构是不够的，还需要继续深入下去，看看这个组织下的每个角色是如何与外部协作，如何发挥稳定性保障的具体职能的。所以，我们下一讲就会结合具体的稳定性保障场景，来分享SRE与其他组织的协作模式是怎么样的。
+
+## 思考题
+
+最后，给你留一个思考题。
+
+学习完本节课，你觉得在一个组织进行SRE体系建设和变革过程中，哪个角色最为关键呢？同时，哪个角色是跟你最相关的呢？
+
+欢迎你在留言区分享，或者提出你对本节课程的任何疑问，也欢迎你把本篇文章分享给你身边的朋友。
+
+我是赵成，我们下节课见。

极客时间专栏/SRE实战手册/实践篇/10 | 经验：都有哪些高效的SRE组织协作机制？.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="10 | 经验：都有哪些高效的SRE组织协作机制？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/52/9a/5299653fa0e072f8a90e393c32adcc9a.mp3"></audio>
+
+你好，我是赵成，欢迎回来。
+
+上节课，我们讲了在互联网企业典型的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更多<strong><strong>地**</strong>是负责平台级的策略</strong>，比如，如果出现流量激增，首先要做的就是在接入层Nginx做限流，并发QPS值要设定为多少合适；再比如缓存失效是否要降级到数据库，如果降级到数据库，必然要降低访问QPS，降低多少合适，等等。
+
+而**业务开发则要更多<strong><strong>地**</strong>考虑具体业务逻辑上的策略</strong>，比如商品评论应用故障，是否可以直接降级不显示；首页或详情页这样的核心页面，是否在故障时可以完全实现静态化等等。
+
+**第四步，容量压测及复盘会**。
+
+在容量压测这个阶段，就需要PE、业务开发和稳定性平台的同学来配合了。业务开发在容量规划平台上构造压测数据和压测模型，稳定性平台的同学在过程中要给予配合支持，如果有临时性的平台或工具需求，还要尽快开发实现。
+
+压测过程会分为单机、单链路和全链路几个环节，PE和业务开发，在过程中结合峰值数据做相应的扩容。如果是性能有问题，业务开发还要做代码和架构上的优化，同时，双方还要验证前面提到的服务治理手段是否生效。
+
+压测过程中和每次压测结束后，都要不断地总结和复盘，然后再压测验证、扩容和调优，直至容量和预案全部验证通过。这个过程一般要持续2～3轮，时间周期上要3～4周左右。整个过程就会要求三个角色必须要非常紧密地配合才可以。
+
+到这里，整个保障准备过程就结束了。你可以先思考下，这个过程中每个角色发挥的作用有哪些。接下来，我跟你一起提炼总结下。
+
+第一，PE更加关注线上整体的运行状态，所以视角会更全局一些，业务开发则更关注自己负责的具体应用，以及深入到代码层面的分析工作。
+
+第二，PE会主要负责平台级的公共部件，如缓存、消息和文件等；DBA负责数据库，所起到的作用与PE相同，他们关注这些平台部件的容量评估、服务治理策略，以及应急预案等；而业务开发则会把更多的注意力放在业务层面的容量评估和各类策略上。同时，PE和业务开发关注的内容是相互依赖的，他们的经验也有非常大的互补性和依赖性，所以这个过程，双方必须要紧密配合。
+
+第三，这个过程中，你可能会发现，工具开发和稳定性开发的同学在其中参与并不多，这是因为他们的价值更多体现在平时。我们依赖的各类平台和工具，比如扩缩容、链路分析、测试数据制造、压测流量的模拟等能力，都是通过这两个团队在平时开发出来的。对于这两个团队来说，这个时候出现得越少，他们的价值才是越大的。
+
+讲到这里，对于SRE体系中，每个角色要起到的作用，以及他们之间的协作机制就讲完了，各方职责不同，但是彼此互补和依赖，只有密切合作才能发挥出SRE体系的力量。
+
+## 赛场上的哪些工作可以例行化？
+
+谈完了“以赛带练”这种大促场景下的协作机制，那没有大促的时候，SRE组织中的各个角色平时应该要做些什么呢？
+
+其实，我们前面提到的“以赛带练”的事情，会有一部分转化为例行工作，同时还会增加一些周期性的工作。总结起来就是以下两项主要工作。
+
+**第一项，核心应用变更及新上线业务的稳定性评审工作**。这里就包括前面讲到的容量评估和压测、预案策略是否完备等工作。PE会跟业务开发一起评估变动的影响，比如变动的业务逻辑会不会导致性能影响，进而影响容量；对于新增加的接口或逻辑，是否要做限流、降级和熔断等服务治理策略，如果评估出来是必需的，那上线前一定要把这些策略完善好；同时在测试环境上还要做验证，上线后要关注SLO是否发生变化等。
+
+**第二项，周期性技术运营工作**。这些就包括了我们要例行关注错误预算的消耗情况，每周或每月输出系统整体运行报表，并召集业务开发一起开评审会，对变化较大或有风险的SLO重点评估，进而确认是否要采取改进措施或暂停变更，以此来驱动业务开发关注和提升稳定性。
+
+这里的技术运营工作，是PE职责非常大的转变，因为随着各类平台的完善，很多原来依赖运维完成的事情，业务开发完全可以依赖平台自主完成，无需运维介入。比如代码发布、配置变更，甚至是资源申请。
+
+所以，这时我们会更强调PE从全局角度关注系统，除了稳定性，还可以关注资源消耗的成本数据，在稳定和效率都有保证的前提下，也能够做到成本的不断优化。这样也会使得PE从原有繁琐的事务中抽离出来，能够去做更有价值的事情。关于这一点，也是给运维同学一个转型和提升的建议。
+
+## 总结
+
+好了，我们做下本节课的总结。
+
+我们借助大促这样的场景，通过“以赛带练”的思路来驱动稳定性体系的建设和提升。这个过程中，PE更加关注全局和系统层面的稳定性，并提供各类生产环境的运行数据；而业务开发则会更关注业务代码和逻辑层面的稳定性，与PE互补且相互依赖；而稳定性和工具开发提供平台和工具支撑，保障每一个环节更加高效地完成。最后，我们还会将这些工作例行化，转化成日常的稳定性保障事项。
+
+## 思考题
+
+最后，给你留一个思考题。
+
+对于“以赛带练”的思路，除了今天我们介绍到的，在你实际的工作中还有哪些场景可以尝试？
+
+欢迎你在留言区分享，或者提出你对本节课程的任何疑问，也欢迎你把本篇文章分享给你身边的朋友。
+
+我是赵成，我们下节课见。