简介： 稳定性目前不再局限于大促时的保障和平时的稳定性轮值，越来越体系化，本文基于作者在业务团队工作过程中的沉淀，以及在盒马2年SRE的实战经验，从稳定性心态、监控体系、故障应急体系、资源体系、大促保障机制、日常保障机制等几个层面，就如何做好SRE的工作进行了分享。
前言
low：完全不懂，觉得稳定性就是做别人安排好的一些表格和梳理，不知道自己该做啥，稳定性好low。
烦：各种重复的会议，做好了是应该的，做不好就是责任，很烦很焦虑。
知道该做什么，但是累：各种报警和风险，每天需要担心，想要不管又过不了自己心里那关；大促时候天天熬夜，各种压测，最终自己累得够呛。
发现结合点：发现在采用系统化思维之后，稳定性与系统自身的结合变得紧密，稳定性成为一种基线，找到了稳定性中的关键点和重点。
主动驱动：发现线上业务和线下业务的稳定性差别，理解并主动调整在不同业务团队采取的稳定性策略，探究在稳定性中的自动化、工具化，系统化建立稳定性机制。
形成体系：形成稳定性体系化思考，明确稳定性每一个点在业务团队大图中的位置，探究系统弹性建设。
什么是SRE
一 心态&态度
1 谁适合做稳定性？
必须选择负责任的人
负责任是第一要素，主动承担，对报警、工单、线上问题、风险主动响应，不怕吃苦；一个不负责任的人，遇到问题与我无关的人，边界感太强的人，难以做好稳定性的工作。
原则上不要选择新人
对于团队leader而言，“用新人做别人不愿意做的工作”，这个决定比较容易做出，但是这也相当于是把团队的稳定性放在了一定程度的风险上，用新人做稳定性，其实只是用新人占了稳定性的一个坑而已。新人不熟悉业务，不了解上下游，最多只能凭借一腔热血，对业务和系统感知不足，容易导致线上风险无法被快速发现、故障应急无法迅速组织。
不要用过于"老实"的人
这里的“老实”的定义是不去主动想优化的办法，不主动出头解决问题，但是很能吃苦，任劳任怨，也很能忍耐系统的腐烂和低效；这样的人平时很踏实，用起来也顺手，但是却无法主动提高系统稳定性，有的时候反而会给系统稳定性造成伤害（稳定性就像大堤，不主动升级，就早晚会腐烂）。
2 业务团队如何支持稳定性SRE人员
给资源
稳定性从来不只是稳定性负责人的事情，而是全团队的事情，稳定性负责人要做的是建立机制，主动承担，但是稳定性意识，要深入到团队所有人脑子里，稳定性的事情，要能够调动团队一切资源参与。
给空间
做稳定性的人，往往面临一个尴尬场景：晋升困难，主要是因为在技术深度和业务价值两个方面，很容易被挑战，对于业务团队，一定要留给做稳定性的人足够的思考和上升空间，将稳定性与团队的技术架构升级、业务项目结合起来，共同推动。经过集团安全生产团队的推动，目前在阿里，SRE已经有了自己专门的晋升体系。
区分责任
当出现故障时，区分清楚责任，到底是稳定性工作没有做到位，还是做到位了，但是团队同学疏忽了，还是说只是单纯的业务变化。
3 开发和SRE的区别
开发：了解业务 -> 定位问题 -> 排查问题 -> 解决问题
SRE：了解业务归属 -> 快速定位问题范围 -> 协调相关人投入排查 -> 评估影响面 -> 决策恢复手段
4 SRE心态上的一些释疑
疑惑1：做好了是应该的，出了问题就要负责任
尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了（这一步叫“响应”）。
组织人员，快速定位问题，告知问题初步定位原因。（这一步叫“定位”）
初步影响范围是什么？给出大致数据。（这一步方便后面做决策）
有哪些需要老板、产品、业务方决策的？你的建议是什么？（这一步很关键，很多时候是：两权相害取其轻，你的评估和建议，直接影响老板的决策）
当前进展如何，是否已经止血？（这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况）
作为一个SRE，想做到“不出问题”这个基线，关键还是要靠大家，如何靠大家呢？就是要落地一套稳定性的机制体系，用机制的严格执行来约束大家，这套机制也必须得到团队leader的全力支持，不然无法展开，这套机制包括：
稳定性意识
日常值班机制
报警响应机制
复盘机制
故障演练机制
故障奖惩机制
大促保障机制
梳理。主动梳理团队的业务时序、核心链路流程、流量地图、依赖风险，通过这个过程明确链路风险，流量水位，时序冗余；
治理。主动组织风险治理，将梳理出来的风险，以专项的形式治理掉，防患于未然。
演练。把风险化成攻击，在没有故障时制造一些可控的故障点，通过演练来提高大家响应的能力和对风险点的认知。这一点将在后面详述。
值班。不能仅仅为了值班而值班，值班不只是解决问题，还要能够发现风险，发现问题之后，推动上下游解决，减少值班中的重复问题，才是目标。
报警。除了前面说过的主动响应之外，还要经常做报警保险和机制调整，保证报警的准确度和大家对报警的敏感度。同时也要做到不疏忽任何一个点，因为疏忽的点，就可能导致问题。
疑惑2：稳定性总是做擦屁股的工作
暖曰：“ 王独不闻魏文王之问扁鹊耶？曰：‘子昆弟三人其孰最善为医？’扁鹊曰：‘长兄最善，中兄次之，扁鹊最为下。’魏文侯曰：‘可得闻邪？’扁鹊曰：‘长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，闲而名出闻于诸侯。’魏文侯曰：‘善。使管子行医术以扁鹊之道，曰桓公几能成其霸乎！’凡此者不病病，治之无名，使之无形，至功之成，其下谓之自然。故良医化之，拙医败之，虽幸不死，创伸股维。” ——《鶡冠子·卷下·世贤第十六》
做扁鹊大哥：在系统健康时发现问题
做扁鹊二哥：在系统有隐患时发现问题
做扁鹊：在系统发生问题时快速解决问题
常常思考产品和系统哪里有问题，如何优化，如何体系化？
常常思考有没有更好的办法，有没有提高效率的办法？
常常思考如何让稳定性本身更加有价值，有意义？
这3个问题，我觉得可以从3个方面着手：
稳定性工作，如果要拿到结果，做到可量化，可度量，就一定要在数据化上下功夫，这个数据化，包括如下几个方面：
数据驱动：包括日志标准化和错误码标准化，能够对日志和错误码反馈的情况进行量化。
数据对账：包括上下游对账、业务对账，能够通过对账，保障域内数据校准。
轨迹跟踪：包括变更轨迹和数据轨迹，目标是实现数据的可跟踪，和变更的可回溯、可回滚。
数据化运营：主要是将稳定性的指标量化，比如工单解决时间、工单数、报警数、报警响应时间、故障风险数、代码CR量，变更灰度时长等，通过量化指标，驱动团队同学建立量化意识，并且能给老板一份量化数据。
疑惑3：稳定性似乎总是新人的垃圾场
对于稳定性新人，一定要优先考虑如何响应问题，而不是如何解决问题。
稳定性从来都不是简单的，他的关键，是要做细，这需要细心和耐心。
稳定性不是一个人的事情，要团结团队内的同学，上下游的同学。
（1）3张图
系统间依赖图（也包括业务时序，熟悉业务流程），参考5.4节系统依赖梳理方法。
流量地图（知道上下游系统，团队内系统的流量关系和流量水位，也同时把控系统架构），参考5.3节流量地图。
系统保障图（知道稳定性保障的步骤和打法），参考5.2节作战地图。
（2）3张表
机器资源表（做到占用多少资源，了然于胸，团队需要时能拿得出来），参考第4章资源管控。
异常场景应急表（出现问题时知道怎么应对，演练知道哪里容易出问题），参考3.2节故障场景梳理。
业务近30日单量表（知道哪些业务影响大，哪些业务是重点），参考6.1节黄金链路治理。
二 监控
从运维意义上讲，“发现问题”的描述 和 “监控”的实现之间的对应关系如下：
| 发现问题的需求描述 | 监控的实现 |
|---|---|
1 监控的5个维度
在服务方面没有异常（我把服务错误造成的用户体验，也认为是服务异常）。
在数据上没有出错（我把订单超时等体验，也认为是数据出现了偏差）。
在资金上没有资损（走了兜底逻辑，且按照业务可接受的预定范围兜底造成的损失，不算资损，如兜底运费）。
下图详细解释了这5个维度：
2 监控大盘
最核心业务入口的qps、rt、错误数、成功率，从这个维度可以看到入口流量的大小和相应时间，成功率。这一点，是在知道入口的健康情况。
错误码top N，这个维度可以看到系统运行过程中最核心的错误，快速直观定位问题原因（这个需要打通上下游错误码透传）。这一点，是在快速知晓问题出在哪里。
按业务维度（业务身份、行业、仓储、地区等，根据实际需要决定）分类统计计算的单量、或分钟级下单数量，用于确定核心业务的单量趋势。这一点，只在知道自身业务的健康情况。
核心下游依赖接口、tair、db的qps、rt、错误数、成功率，需要注意的是，这个一般比较多，建议只放最核心、量最大的几个。这一点，是在知道下游依赖的健康情况。
其他影响系统稳定性的核心指标，如限单量，核心计数器等，根据各个团队的核心来决定。这一点，是在个性化定义关键影响点的监控情况。
3 避免监控信息爆炸
推送到手机的报警，如电话、短信报警。
推送到钉钉的报警，如报警小助手、报警。
对于系统监控报警，采用范围报警，比如load，设置集群内超过N %且机器数大于M的机器load都升高了才报警。毕竟对于一个集群而言，偶尔一台机器的load抖动，是不需要响应的。
对于业务报警，一定要做好同比，不但要同比昨天，还要同比上周，通过对比确认，对于一些流量不是很大的业务来说，这一点尤其重要，有些时候错误高，纯粹是ERROR级别日志过度打印，所以只要相对于昨天和上周没有明显增加，就不用报警。
对于qps、rt等服务报警，要注意持续性，一般来说，要考虑持续N分钟，才需要报警，偶尔的抖动，是不用报警的。当然，对于成功率下跌，异常数增加，一般要立即报出来。
复合报警，比如一方面要持续N分钟，一方面要同比昨天和上周，这样来减少一些无需报警的情况。
根据需要设置报警的阈值，避免设置>0就报警这种，这种报警没有意义，一般来说，如果一个报警，连续重复报10条以上，都没有处理，一般是这个报警的通知级别不够，但是如果一个报警，重复10条以上，经过处理人判断，不需要处理，那就肯定是这个报警的阈值有问题。
4 有效发现监控问题
一般来说，一个团队的稳定性问题在3类群里发现：BU级消防群、团队的监控报警群、业务值班群；所以没有必要红着眼睛盯着监控大盘，也没必要对每个报警都做的好像惊弓之鸟，这样很快自己就会疲惫厌烦。
首先当然是要监控治理，做到监控准确，全面，然后按照前面说的，控制报警数量，集中报警群，做到可控、合理。
然后像刷抖音一样，隔三差五（一般至少1个小时要有一次）刷一下报警群，如果报警群里的新增条数在20条以内，问题一般不大，刷一刷就行。
如果突然一段时间内报警陡增，就要看一下具体是什么问题了，小问题直接处理，大问题分工组织协调。
消防群中的问题，要及时同步到团队中。
值班群中的工单，需要关注，并有一个初步的判断：是否是大面积出现的业务反馈，是否有扩大的隐患。
三 故障应急
1 系统可用性的定义
ufried 在2017年的经典弹性设计PPT：《Resilient software design in a nutshell》中，对系统可用性的定义如下：
尽量增加无故障时间
尽量缩短出故障后的恢复时间
2 场景梳理
故障场景梳理，重点在于要把可能出现故障的核心场景、表现、定位方法、应对策略梳理清楚，做到应对人员烂熟于心，为演练、故障应急提供脚本。
通过这种程度的梳理，SRE以及其掌控的故障应对人员，能够快速的明确发生问题的场景，以及场景下的影响、表现、定位方法、应对策略。当然，如果要把这些场景牢记，做到快速应对，就需要依靠：演练。
3 故障演练
对于系统性故障注入（load、cpu、fullGC、线程池等），直接套用集团的mk注入即可。
对于服务型故障注入（下游异常、超时，接口超时、限流），mk也有比较好的支持。
对于订单异常型故障注入，要自主开发较好的错误订单生成工具，注入异常订单，触发故障报警。
对于调度、积压型故障注入，要关注schedulex、异步消息的故障注入方式，同时防止积压阻塞正常订单影响真正的线上业务。
4 故障应急过程
冷静。作为SRE，首先不能慌，没有什么比尽快定位和止损更重要的事情。
拉电话会议同步给大家信息。记住，在出现故障时，没什么比电话会议更加高效的沟通方式了。
参考前面1.4.1节中的SRE人员快速响应流程，在电话会议中同步给大家：
尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了。（这一步叫“响应”） 组织人员，快速定位问题，告知问题初步定位原因（这一步叫“定位”）。 初步影响范围是什么？给出大致数据（这一步方便后面做决策） 有哪些需要老板、产品、业务方决策的？你的建议是什么？（这一步很关键，很多时候是：两权相害取其轻，你的评估和建议，直接影响老板的决策） 当前进展如何，是否已经止血？（这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况）
组织大家按照故障场景梳理的应对方案进行应对，如果没有在故障场景列表中，一定要组织最熟练的人员进行定位和恢复。
故障过程中，对外通信要跟团队和老板统一评估过再说；
处理故障过程中，要随时组织同学们进行影响数据捞取和评估，捞出来的数据，要优先跟老板、业务熟练的同学一起评估是否有错漏。
在处理完故障后，要及时组织复盘（不管GOC是不是统一组织复盘，内部都要更加深刻的复盘），复盘流程至少包括：详细的时间线，详细的原因，详细的定位和解决方案，后续action和改进措施，本次故障的处理结果。
5 与兄弟团队的关系
不能嘲笑别人，看笑话。
不能当没事人，高高挂起，要检查自身。
不能话说的太满，比如说我肯定没故障。
4 资源管控
比如机器资源，要关注当前机器数、额度、load，如：
再比如对数据库资源，要关注数据库的配置、空间、日常和峰值qps、单均访问量（创建一个订单，要读和写DB多少次，这一点很关键）。
五 大促保障机制
对于SRE来说，大促、尤其是双十一，是一年一度的沉淀系统、防止腐烂、摸清水位、剔除风险的最佳时机，所以一定要加以利用。对于团队的其他开发，大促是一次活动而已，对于SRE来说，大促是系统稳定性提升的过程，与其说是保障大促稳定，不如说是“借大促，修系统”。
所以，一定要转变思想，我们做大促保障，不仅是要“保持系统稳定性”的，更是要“提升系统稳定性”的。保持重在压测、摸排水位、限流、预案，而提升重在链路排查、风险治理、流量提升、兜底容灾。
一般的A级大促，或间隔较小的S级大促，应以“保持”稳定为主，但对于双十一、618，这种S级大促，应当以“提升”稳定为主；下面，我们重点就要介绍如何借助大促的机会，来提升系统稳定性。
1 业务团队大促保障的一般流程
一个完善的大促保障包括如下步骤（可参考下面的作战地图）：
明确本次大促的作战地图，明确时间节点和步骤；
输入活动玩法和节点，明确关键时间点和GMV目标、单量峰值；
SRE产出备战报告，其中包括保障目标，大促保障时间节奏，作战地图，流量地图（如果已经绘制出来的话），资源规划地图，业务新的变化和技术的挑战，上下游链路依赖图，核心风险和专项分工（精确到人和完成时间），同时SRE要指定监控、压测、演练、预案专项负责人（leader要为SRE放权和背书）。
SRE绘制流量地图，明确接口流量，模块链路，关键风险。
SRE和开发同学共同梳理上下游接口依赖流量和峰值，给出限流阈值并沟通上下游；
开始链路梳理，一般由熟悉业务和系统的开发同学梳理，然后拉上上下游、梳理同学、测试同学、SRE、leader一起review，review时，SRE要产出5个点：强弱依赖、风险点、限流、降级预案、新业务特征；
根据梳理出来的风险点展开集中治理，大的风险点要开专项治理，这一阶段要全员听调，风险点要各自去做，SRE只负责把控全局、跟踪进度、验收结果。
治理完成后，开展监控走查，更新监控大盘，建议由SRE指定监控专人负责；
压测开始前配置限流，压测过程中还要不断根据情况调节限流值；
开始压测，分为专项重点压测（一般单接口、单机），上下游压测，全链路压测，建议由SRE指定压测责任人；
录入预案，并对预案进行测试和验证，拉上业务、产品、测试一起，组织预案演练，验证预案可行性，要求业务方知晓预案执行后的影响。建议由SRE指定预案和演练责任人。
上述过程中都要记录未完成点和check点，在大促前，要对checklist 逐项check；
产出作战手册，包括值班表，工具清单，大促期间作战流程（精确到分钟级的操作时间点和人员），再次通知业务侧相关预案的影响。
大促开始前一天，SRE要进行战前宣讲，一般包括大促期间发布流程、审批流程、白名单人员名单，工单汇报方法，大促交流群，大促期间的红线和注意事项。
大促结束后，要进行复盘，复盘内容包括：目标是否达到，大促期间达到系统指标、单量，系统、业务的能力亮点，大促保障期间大家做的工作汇总，保障期间的产出亮点，后续action项，未来保障的思考和计划。
2 作战地图
下面一张图，比较详细的介绍了整个双十一作战的过程：一次大促保障，大致分为前期的容量评估和准备阶段，中间的系统健壮性提升阶段，后面的压测摸底、预案演练阶段，最后的战前check和值班阶段。其中前2个阶段才是核心。
在这张作战地图中：
容量准备阶段，重在根据业务活动节点，输入流量和单量，梳理上下游流量压力，绘制流量地图，统计上下游接口压力，评估限流阈值和资源缺口，同时准备资源。这个阶段是关键阶段
系统健壮性提升阶段，重在链路梳理和风险发现，对发现的风险进行专项治理。这个阶段是最核心阶段
在压测阶段，不能只被动的参加全链路压测，还要优先在自己域内进行单点压测和上下游链路压测，这样在全链路压测的时候才不会掉链子。同时，压测要关注几个事情：1，有没有达到流量预期；2，有哪些点是瓶颈点；3，对瓶颈点如何解决，如何降级或限流？4，上下游在压测过程中有没有可能与自己域相互影响的地方；
在预案&演练阶段，要注重实效，不要走形式化，演练的目的是验证预案的可行性和可操作性，不是为了证明“我演练过了”，如果预案不进行演练，在大促时就有可能出现：1，不敢执行预案，因为不知道会发生什么；2，执行了预案之后发现有坑；3，执行了预案之后发现无效；
在战前准备阶段，重在检查和宣讲，检查要查缺补漏，要有checklist，一项项check；宣讲要有作战手册和红线，作战手册要精确到时间点和人，每个时间点由谁做什么要明确；红线一定要宣讲清楚，大促是一场战役，如何报备，如何响应工单，各自分工是什么，哪些红线不能踩，要明确到位，避免低级骚操作带来的风险。
下面重点介绍容量准备阶段（流量地图和评估）和系统健壮性提升阶段（梳理和治理）；
3 流量地图 & 流量评估
绘制流量地图的目的，是让SRE人员对于域内和上下游流量有明确的了解，在心中有一张全局流量的“图”。流量地图应该包括几个要素：
系统核心模块和模块间的依赖关系；（用方块和连线标识）
核心功能流量流向；（用不同颜色的连线区分）
核心接口/功能的单量或qps；（在接口上方标注）
链路上的主要风险点；（用红色方块标注）
在进行流量评估时，关键在于要明白上下游依赖、是否有缓存、平时单量和大促单量：
本域应用名
对方域
对方应用host
业务场景
服务接口
对方owner
依赖方式、强弱
日常峰值
大促预估峰值
缓存击穿情况下的悲观峰值
appname
商品域
xxx-itemhost，精确到host
时间片商品查询
service.method~params
某某
hsf、强，有缓存
1000
2000
5000
e.g.
流量评估除了要跟域内对齐外，更加重要的是上下游的沟通，这一点非常重要，要相互明确各自域的瓶颈、限流、承诺；在对上做出流量承诺的时候，一定要优先考虑保护自己域；在对下提出流量要求的时候，要同时提出有保护措施（如缓存）情况下的正常流量和无保护措施下最糟糕流量。
4 链路梳理 & 治理
这个是SRE能够借双十一提升系统性能的重中之重，一般，我建议遵循下面的方法：
大促保障准备时间有限，所以不能等全都梳理完了之后才开始治理。一般来说是先根据经验和日常的发现，治理一波，同时进行梳理，然后对梳理进行review时，发现新的风险点，并进行治理。
一般由熟悉业务和系统的开发同学梳理，然后拉上上下游、梳理同学、测试同学、SRE、团队leader一起review，review时，SRE要重点关注5个点：
• 强弱依赖
• 风险点
• 限流
• 降级预案
• 新业务特征
功能
细粒度场景
风险点action
限流
降级预案
强弱依赖
新业务
功能描述，根据功能进行划分
将场景细粒度细分，列表化
可能存在的风险点
当前场景的限流评估
当前场景可能存在的降级预案
上下游间的强弱依赖，强依赖的要关联预案、限流、降级等
当前场景从上次大促到现在的增量变更
梳理的目的不是仅仅评估风险，更重要的是治理，治理不一定是代码层面的升级，可能有如下方式：
对可能有流量尖峰、造成系统冲击的接口，加特殊限流，如全局限流、线程数限流；
对流量尖峰，加dts等异步任务，进行削峰填谷；
对需要做降级的地方加降级预案；
对需要兜底容灾的地方加自动兜底；
对强依赖的下游接口，加本地缓存或tair缓存（慎之又慎，同时下游绝对不能期待上游加缓存来降低访问量）；
治理的时候，要注意几个最容易出问题的地方：缓存、异步消息、异步任务、数据库量级、数据库关联查询量或批量更新量（比如1主单关联N子单的情况）、接口超时时间、重试次数、幂等、sql limit和查询上限；
需要提前禁写的，要产出禁写预案
对大促期间可能随时调整的业务参数，要留出口子，方便调整，做好审批流程报备流程、check流程；
在链路治理时，建议可以建立一个aone项目空间或者lark表格，将所有要做的事情，列成工作项，每完成一项勾掉一项，当所有工作项都完成时，项目就结束了，治理也达到了一个水平。
5 压测
在大促保障过程中，提到压测，有同学可能习惯性的将其归结到“全链路压测”中，这个是不全面的，压测应该贯穿整个大促保障的过程。
压测分为3种，分别是单点压测（如：单机压测和单接口压测），单链路压测，全链路压测。
单点压测的目标就是考察单点性能，主要用于发现单机或者单接口的性能水位和性能热点，为了后面计算限流阈值，评估集群规模做准备；应该在大促前就开始，随时可以进行，不一定要在正式环境。如果只是发现性能热点，可以使用火焰图分析；如果是评估性能水位，就要进行摸高，一般对于4核8g的机器，至少要摸到load 到5，cpu利用率到75%，内存到70%，线程数超过800个，这4个指标至少要达到1个才能算。
单链路压测的目标是考虑单链路多个应用间多级调用的性能，用于评估某个功能点的水位，为的是应对活动过程中某个业务的量级，评估的目标是整个链路中至少一个节点达到性能瓶颈为止。整个链路的性能水位，是由最低的那个节点接口/应用决定的。在压测过程中，建议摸高，一直摸到其中一个节点达到瓶颈。单链路压测建议在业务给出活动目标后，就要梳理出核心链路有哪几条，这几条核心链路是一定要压测的。需要注意的是，如果有非核心链路影响了核心链路，那么大促时这个非核心链路要么做降级预案，要么改为核心链路死保。
全链路压测的目标是预演，而不是压测，这一点跟前面的压测是完全不同的，需要特别注意，虽然全链路压测本身也会摸高，但是它摸高是预设目标的，比如本次大促50wqps创建，预计摸高也就是120%，不会一直摸高。全链路压测其实是在将各个团队压测的结果进行汇总并验证，所以现在全链路压测一般要去一次通过。这就要求各个团队要提前调通内部各条单链路。
另外，如果链路有涉及外部partner，建议一定要在压测中走通，不要轻易相信外部partner自己的压测结果，也不能认为“他们承诺了，他们要做到”，这种想法，在大促的时候，partner的承诺无法做到的比比皆是，不要最后坑了自己的业务，导致业务单子积压。
六 故障日常稳定性机制
对于SRE来说，在日常稳定性保障过程中，建立一个行之有效的机制体系，比事必躬亲更加重要。一般来说，SRE在日常稳定性保障过程中，要建立的机制如下：
黄金链路识别治理机制
值班机制
复盘机制
日常资源（机器、中间件）管控和记账机制
日常风险和问题报备机制
团队权限管控机制
日常演练机制
下面重点说一下黄金链路和值班：
1 黄金链路治理
黄金链路，就是核心链路，或者说，是团队的生命线链路，由最核心的应用，最关键的DB，最需要死保的接口，支撑的最核心业务。所以黄金链路的治理就一个目标：不要让非核心的东西，影响了核心的；这里的“东西”，包括业务、系统、db；
黄金链路治理机制，是要在日常工作中，做如下工作：
每隔一段时间（半个月左右），要统计一次线上订单各业务单量，有条件的团队，建议分配专门负责数据驱动的人员，建立fbi报表，或者建立数据分析系统。这些数据产出的目标，是统计业务的量级和趋势，报告最核心单量最大的业务、最容易出问题的业务、和发展最快的业务；
对业务和应用链路，按重要性进行划分。把重要的挑出来，把不重要的，不死人的，可以降级的摘出去；
开始治理，要求核心链路上的系统，不能依赖非核心的接口，不能依赖非核心的db。非核心链路上的任何降级措施，不能影响核心链路的功能；
核心链路和非核心链路，也不能依赖共同的基础组件，注意，核心链路不等同于核心应用，现在很多核心应用里的非核心功能太多了。导致每次改非核心功能，要发布核心应用，甚至两者共用底层组件，导致底层发布影响上层。比如，非核心功能要改一个消息发送接口，正好核心功能也依赖了这个接口，非核心功能改动里的bug，可能导致核心功能挂掉；
核心链路和非核心链路，要有2套发布等级，2种监控等级。防止相互影响。
黄金链路治理做好了，团队出现高等级（P1/P2）故障的可能性会大大降低。
2 值班机制建设
值班，既能让大家熟悉业务，又能让SRE不那么劳累，因此，值班人员一方面要响应报警，另一方面要响应工单。SRE要做的事情，是安排好值班表和值班机制，明确值班人员的职责。一般来说，可以如下建设：
事前：
• 值班人员必须参与故障演练（包括故障止血方法）以及熟练使用各种故障排查工具。
• 值班人员需要明确值班的范围，包括预警群、工单群、线上问题反馈群、答疑群等；
• 值班人员在值班周期内，应该减少业务工作安排；
• 值班人员的值班周期不宜过长或者过短，以一周为宜；
• SRE应该尽可能的多值班，只有对业务熟悉的人，才能更加敏锐的发现系统的问题；
• 新进入团队的同学，应该先值几个月的轮班，通过值班熟悉业务，是最快的方式；
事中：
不管是工单问题还是报警，如果短时间无法定位原因的情况，立即把相关人员拉入电话会议，如果遇到卡点，需要把接力棒明确交接给下一位，事后再回顾卡点的原因。对于会影响上下游的问题（事故），需要立刻通知上下游，可能引起故障的，需要GOC报备。
值班人员自己发现问题后，应该第一时间在群里反馈说处理中，同时通知其他人已经在处理
关闭当前报警的通知（关闭方法集中沉淀到常见问题处理手册），防止电话打爆掩盖其他更重要的报警，事后再重开报警（由当前值班人员保证）
事后：
值班人员和SRE一起组织问题Review，并把涉及到稳定性的操作内容记录在稳定性流程中。对于常见问题的排查沉淀到一处，后续工具化和演练。
值得注意的是，值班不应该是简单的人力消耗，应该花费时间开发工具平台，包括问题智能排查、订单详情查询，业务日志轨迹、数据变更轨迹查询，并且开发问题自动排查、问题解决方案自动推荐机器人，做到自动答疑、自助答疑，减少工单数量，提高问题排查效率。
七 弹性建设
系统的健壮不是没有报警，也不是不出故障，服务、数据、体验都不受影响，我们才认为系统是健壮的。一个系统想要健壮，应该具有一定的弹性，系统的弹性体现在系统是：容灾的、可自愈的、一定程度上容错的、可运营的。
这里，有ufried 在2017年的弹性设计PPT：《Resilient software design in a nutshell》，这个PPT非常清晰准确的阐述了“弹性软件设计”的概念，下图取自该PPT：
对于我个人的实践而言，我自己倾向于重点做好其中的发现、恢复、预防、缓解4个部分。
八 价值建设
我想把“价值建设”这个事情，放到本文的最后，作为对SRE人员提升工作信心的鼓励。
开发人员容易趋向于实现什么，如何做到，Dev工作的目标，是电脑屏幕和系统功能；而SRE，很多都是电脑外的工作：上下游沟通，流量评估，演练组织，资源调度，故障应急，系统治理。工作内容既有代码里的if else，也有Excel上的各种统计，还有PPT上的各种曲线。很多人觉得这样的事情很boring，倾向于做一个专心写代码的美男子，但是一个开发人员，偶尔抬起头看着窗外，心里对那些横跨多域，调度多个资源，影响力辐射多个团队甚至BU的人，也有一丝羡慕和无力感。
SRE恰恰给了这样一个机会，它能让一个级别不怎么高的开发人员，调度域内尽可能多的资源，从事多种能够辐射影响力的机会。
SRE最容易拿到数据，就要去考虑一个问题：价值导向，当前做的事情，有多少数据量，有哪些是无用的长尾的，有哪些可以下线掉。哪些是造成资损的，哪些是需要推动解决的异常订单，哪些是有巨大价值的。哪些是客户抱怨最多的，耗时耗人力最大的。
开发人员容易正向思维，而SRE人员，一定要去做反向思维，通过价值来考量，通过价值反推意义，提效降本。
绝大多数情况下，一个好的SRE，和一个差的SRE，差距就体现在3个方面：好的SRE会随时发现和响应问题，会建立体系化，会极其细致的落地解决方案。 这其中，随时发现和响应，是第一态度，是要持之以恒的心态，而不是一个作秀和表现；落地是基础，是保障稳定的生命线，细致的落地，是决定你是走走过场，还是真的做深的根本；体系化是框架，是决定机制能否持久以及你自己累不累的原因
另外，一个团队（尤其是业务团队）的SRE是极度需要老板的鼎力支持和权力背书的，SRE往往没有组织架构上的权力，这个时候，老板真正意义上的支持就很重要，如果一个SRE，你的老板总是口头上跟你说稳定性不能松懈，但是几乎从来不愿意在稳定性上给你支持，一心只想做业务，你就要考虑2个方面：
1、是不是你做的不落地，没有得到老板信任；
2、换个老板。
但是，如果老板愿意给你时间和空间，也愿意投入资源，给你权力，那你就要认真做好SRE这份工作，做出价值。一般来说，老板愿意给你权力的时候，就意味着老板愿意帮你背责任，所以不要怕出错，要先把态度做出来，老板会支持你的。
但是注意：老板给你的权力用好了，老板才会给你背责任，用不好，责任就是你自己的。这一点无论在哪个团队，无论在哪个层级，都是一样。
参考：
