前面介绍了SRE的基础,包括SLI和SLO以及Error Budget(错误预算)。其中:
转化后做稳定性提升保障工作,就是想办法不要把错误预算消耗完,或不能把错误预算快速大量消耗掉。其实在SRE落地实践过程中,主要是解决如下两种情况的问题:
这篇文章,主要说明如何通过应对故障来落地SRE。
绝大多数故障,只要能定位问题根因,往往就能快速解决。
故障处理的生命周期中,大部分时间耗费在寻找和定位问题上面。
分布式系统中,往往优先级最高的是线上业务止血(即Design for Failure策略)。通过服务限流、降级、熔断甚至主备切换等手段,来快速恢复线上业务的可用性。
故障处理的核心:提升MTTR每个环节的处理效率,缩短处理时间,这样才能缩短整个MTTR,减少对错误预算的消耗。
MTTI:故障的平均确认时间。即从故障实际发生的时间点,到出发采取行动去定位前的这段时间。这个环节,主要做两件事:
1)判断出现的问题是不是故障(主要依赖于监控和告警体系);
2)确定由谁来响应和召集人进行处理(需要一套明确清晰的决策及消息分发机制);
这两件事,其实就是SRE中的On-Call机制(一般有专门的NOC岗位来负责响应和召集)。
On-Call机制的核心,就是确保关键角色实时在线,随时应急响应。
1)确保关键角色在线(轮班的各岗位关键角色,需要有backup);
2)组织War Room应急组织(常见的有线上消防群&线上监控告警群);
3)建立合理的消息分发方式(谁值守谁负责,而不是谁最熟悉谁负责);
4)确保资源投入的升级机制(即值班相关SRE角色有权调动其他资源,甚至故障升级);
5)与云厂商联合On-Call机制(对于上云企业,和厂商共建故障信息对接群,定时故障演练);
6)终极方案:针对可能出现的故障,落地故障应急SOP,制定“故障应急处理手册”,这样人人都是SRE。
1)最快最好的熟悉系统的方式;
2)培养和锻炼新人以及backup角色;
3)新人融入团队和承担责任的最佳方式;
在MTTR环节中,MTTK、MTTF、MTTV分别对应故障诊断、故障修复与故障确认。
故障处理的最终目标:采取所有手段和行动,一切以恢复线上业务可用为最高优先级。
1)故障隔离手段缺失(限流、降级、熔断、弹性扩容);
2)关键角色和流程机制缺失(信息同步、方案决策、反馈机制);
3)线上故障灾备演练环节缺失(故障应急SOP、故障应急处理手册);
3.1流程机制
1)故障发生后,On-Call的SRE最开始是IC,有权召集相关角色和资源,快速组织线上消防;
2)如果问题和恢复过程非常明确,IC仍是SRE不做转移,由他指挥每个人要做的事情,优先恢复业务优先;
3)如果问题疑难或影响范围大,SRE可以要求更高级别的角色介入如 SRE主管或总监。一般原则是谁业务受影响最大谁牵头组织。这时IC的职责转移给更高级别的主管。如果是全站范围的影响,必要时技术VP或CTO也可以承担IC职责,或授权给某位总监承担;
4)SRE回归到OL的职责上,负责组织和协调具体的执行恢复操作的动作。
3.2反馈机制
1)定时反馈(10-15分钟),没有进展也要及时反馈;
2)执行操作或变更事先通报,说明变更操作重点和影响范围;
3)尽量减少对执行者的干扰,让执行者能够聚焦;
4)信息要及时同步给客服、PR及商家和其他各类合作方;
5)团队leader收集反馈并传递IC的指令,CL收集信息并在更大范围内同步汇总后的信息,同时传递给外部联系人;
6)除了快速恢复业务,保持信息及时同步和透明也非常关键(便于对用户和其他平台的安抚措施能够快速执行到位)!
注意:信息同步尽量不要用技术术语,尽量以业务化的语言描述,并给到对方大致的预期!
故障复盘的核心:从故障中学习和提升!
故障复盘的教训:故障根因往往不止一个,聚焦引起故障原因都是哪些,是否都有改进空间。
故障复盘的心得:解决问题,而不是不断提出新的问题!
1)第一问:故障原因有哪些?
2)第二问:我们做什么,怎么做才能确保下次不会出现类似故障?
3)第三问:当时如果我们做了什么,可以用更短的时间恢复业务?
注意事项:对事不对人,不允许出现互相指责和埋怨甩锅。故障复盘的核心是找到原因并加以改进,落地优化。
1)健壮性原则:每个组件自身要具备一定自愈和高可用能力,而非全部由下游依赖放兜底;
2)三方默认无责:对内谁受影响谁改进,对外推进第三方改进(稳定性要做到相对自我可控,而不是完全依赖外部);
3)分段判定原则:对于原因较复杂或链路较长的故障,建议分阶段评估,不同阶段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。
在SRE体系中,高效的故障应对和管理工作,需要整个技术团队共同参与和投入。
参考:SRE组织架构的构建原则
要引入SRE体系,并做对应的组织架构调整,首先要看技术架构是否朝着服务化和分布式方向演进。要想在组织内引入并落地SRE体系,原有技术团队的组织架构或协作模式必须要做出一些变革。
基础设施:传统运维这个角色所具备的能力。
平台服务:包括常见的技术中台(有状态的数据产品研发团队)和业务中台(无状态的具有业务共性的业务研发团队)以及业务前台(H5&前端&移动端产品研发团队)。
技术保障平台:微服务和分布式架构下的运维能力,是整个技术架构能力的体现,而不是单纯的运维能力体现。
工程效能平台:负责效能工具的研发,比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现,为基础运维和应用运维提供效率平台支持(对业务理解及系统集成能力要比较强,但是技术能力要求相对就没那么高)。
稳定性保障平台:负责稳定性保障相关的标准和平台,比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划(技术要求和团队建设复杂度较高,需要很多不同领域的专业人员)。
总结:SRE = PE + 工具平台开发 + 稳定性平台开发!
SRE落地经验:以赛带练。
“以赛带练”这个术语最早出自体育赛事中,即通过比赛带动训练(如足球、篮球或田径比赛)。目的是在真实的高强度竞争态势和压力下,充分暴露出个人和团队的不足及薄弱点,然后在后续的训练中有针对性地改进,这样对于比赛成绩的提升有很大帮助,而不是循规蹈矩地做机械性训练。
以赛带练的策略放在系统稳定性建设中非常适用。
通过选择类似的真实且具备高压效果的场景,来充分暴露稳定性存在哪些问题和薄弱点,然后有针对性地进行改进。类似的场景,如电商类产品的双十一大促、社交类产品在春晚的抢红包,以及媒体类产品的突发热点新闻等,对于系统的稳定性冲击和挑战非常大。
再或者是极端故障场景,如机房断电、存储故障或核心部件失效。稳定性建设,一定也是针对极端场景下的稳定性建设。
“以赛带练”的目的就是要检验系统稳定性状况到底如何,系统稳定性还有哪些薄弱点。
案例:双十一大促保障!
1)大促项目kickoff(项目启动会)
2)核心链路技术指标拆解及模型评审(用户模型、流量模型、压测模型)
3)稳定性预案评审(前置预案、主动预案、紧急预案、恢复预案)
4)全链路压测及复盘会议(每轮压测结束都需要进行复盘总结和落地TODO项)
通过上述每个环节的工作细节,让不同角色都参与进来!
除了大促或极端场景之外,将一些案例落地到日常工作中,是提升稳定性的进阶。场景如下:
1)核心应用变更及新应用上线评审;
2)周期性的技术运营以及汇报工作场景;
落地实践,小步快跑胜过考虑太多!
实践需要落实到具体的真实的场景和细节问题上,而不是凭空虚构!
落地SRE要尽可能早的参与到项目中,而非等到线上出问题才考虑引入SRE机制!
SRE 更多的要成为稳定性的监督者和推进者,而不是各种问题的救火队员!
《The Site Reliability Workbook》:兼具普适性和参考性;
《Building Secure&Reliable Systems》:适合进阶阶段阅读;
《Site Reliability Engineering》:SRE落地取得一定成效后阅读;