故障复盘的重要性无需多说,每一次故障都是宝贵的学习机会,本人接手故障复盘工作已经半年有余,从一开始的手足无措,慢慢变得游刃有余。以下内容为本人从网上查阅学习多个专家经验,并结合工作经历总结而来,仅供参考。
一、故障复盘目的
- 通过复盘总结教训,找到根因,从根本上进行优化和改进,后期工作中规避问题再发生。
- 有策略的、系统性的去组织复盘踩过的坑,还原事实,找到薄弱点加以改进。
- 最终目的是鼓励做事,而不是处罚失败。
二、 故障复盘原则
- 鼓励做事和质量改进,反对推诿扯皮不作为;鼓励公开透明,反对掩盖问题;鼓励整体的系统思考和团队协同,反对把问题推给个人。
- 明确宗旨,拒绝甩锅:故障复盘的目的是为了找出问题,明确改进方案避免再次踩坑。要尽量对事不对人,避免形成对某一方的批评会。
- 心态开放,理性务实:敢于承认自己的问题,接受自己的不足。同时,在尊重他人的前提,每个人都可以就故障过程充分发表观点和看法。
- 鼓励快速恢复、鼓励通过演练发现更多的线上问题等。
三、 故障复盘运作机制
3.1 故障复盘前准备
3.1.1 提交故障报告
故障直接原因方(非最终认定的故障责任方)在故障发生后3个工作日内提交故障报告。如故障原因涉及多个部门,需跨部门共同协助撰写故障报告。
3.1.2 确定复盘owner
每次故障复盘都必须有唯一的复盘owner,故障复盘owner负责主动引导大家,推动复盘进度。复盘owner的主要职责如下:
- 复盘开始前,由复盘owner根据故障处理报告初稿来推动所有故障干系方完成时间线的梳理,比如某时间点做了哪些操作,产生了什么结果等;搜集故障影响范围,与各个关联方核实影响的数据,包括业务指标、系统指标、其他指标(客诉、舆情影响等)。关键信息通过截图等进行佐证,结合故障处理报告形成故障复盘报告初稿。
- 复盘会议中,复盘owner要主动引导参会人员,推动复盘进度,避免出现一些无意义的指责、与故障无关的发散讨论等。
- 复盘会议后,结合故障处理报告形成故障复盘报告定稿,发给所有故障干系人及相关领导。
3.1.3 确定故障干系人
复盘owner确定故障直接原因方、关联(受影响)方等与故障有关的干系人。
3.1.4 组织复盘会议
确定故障复盘时间、形式及地点、参会人员等,并组织召开复盘会议。
- 时间要求:故障发生后一周内,时间拖到久容易遗忘故障细节
- 参会人员要求:故障干系人必须全部参与,复盘owner在复盘文档中记录参会人员名单,必要时抽调SRE专家团队,视故障的危害程度来确定是否需要更高层级的管理人员到场
3.2 故障复盘关键流程步骤(包括但不限于)
3.2.1 故障背景概述
故障的背景要解释清楚本次故障的基本情况,即发生了什么故障,影响了什么业务(产品)等。
3.2.2 对齐故障影响范围
讲清楚本次故障的影响范围,包括影响时间段、影响的业务、影响的系统(服务)、订单量、用户量、客诉量,以及有无产生资金损失等等。
3.2.3 故障时间线回放
故障时间线回放是指从故障的最源头开始,从旁观者的角度重新梳理一遍故障的详细过程,包括每个时间点的人员操作、指标变化、监控告警、系统异常、业务实际情况等等。注意对以下几个关键时间点进行识别。
- 故障发生时间点: 即这个故障实际上是从什么时候开始的。
- 业务指标变化时间点: 业务指标开始下跌、开始恢复等。
- 监控告警发出时间点: 即监控是从什么时候发现异常的,告警什么时候发出的。告警的级别、接收人是否响应超时等相关信息都要记录进来。
- 人员介入响应时间点: 故障对应的系统值班owner是从什么时候开始响应的。
- 异常定位时间点:即定位到故障的异常点。
- 关键操作时间点:是否做了一些应急预案,包括重启、恢复、止血、高可用配置等。还需要理清楚每个操作的结果,即每个操作之后,报错面有无缩小、系统资源水位有无变化等。
- 确认故障恢复时间点: 通过测试验证或者观测业务指标、系统日志等确认系统已经恢复。
根据以上时间点计算出故障平均修复时间(MTTR),然后逐个沟通讨论如何缩短其中的每一个环节耗时。MTTR详细释义见附录。
3.2.4 深挖根因
在复盘过程中,既要明确诱因,更要深挖根因。可以基于5why分析法深挖根因,多问几个为什么,层层递进。5why分析法释义详见附录。
3.2.5 改进项汇总
提升系统可靠性的两个关键手段:降低故障发生概率(MTBF)和缩短故障持续时间(MTTR)。参考第3步的MTTR分解环节和第4步的故障根因分解环节,推导出我们对于本次故障复盘的改进事项。在梳理改进事项的时候,还要从流程制度、团队组织、系统设计、底层工具平台综合考虑。改进项需遵循SMART原则,SMART原则释义详见附录。此外每条改进项必须有明确的责任人牵头人,确保每一条改进措施有人跟进有人负责。
3.3 故障定级定责
复盘owner组织所有干系人确定故障干系方部门每一方责任占比以及故障级别,明确扣罚明细。定级定责标准参见各自故障考核管理办法。这里注意,故障定级定责标准规则要明确,并能够与各方达成一致,此外,故障定级定责标准要不断回头看,针对有争议的地方不断修缮,这样就会最大程度地减少扯皮推诿的情况出现
3.4 故障复盘结果通告
复盘owner根据复盘会议及故障定责结果、最终的故障原因、改进方案等结论,在原故障报告的基础上,修改完善并形成最终定稿,以邮件的形式发给所有故障干系人及相关领导进行上报和周知,方便干系人及领导查阅整个复盘报告,同时让改进计划中涉及的各方明确知晓后续相关工作。
四、故障改进及闭环
故障复盘后由复盘owner(或其他)将故障信息(也就是故障报告里的内容)录入故障管理系统,系统将向故障改进措施负责人派单,整改负责人整改完成后在系统回单并提交整改完成的证明材料,由复盘owner审核通过后方可关闭工单,这样可以保证整改措施的,实现故障闭环管理
五、奖励机制
根据故障复盘过程中各位干系人及SRE专家团队表现(是否及时提交故障报告,配合度、是否积极改进、积极献策等维度逆向评价并给予相应奖惩,目的是鼓励各位主动复盘主动改进。
附录:相关名词解释
一、5why分析法:所谓5why分析法,又称“5问法”,也就是对一个问题点连续以5个“为什么”来自问,以追究其根本原因。虽为5个为什么,但使用时不限定只做“5次为什么的探讨”,主要是必须找到根本原因为止
有一次,丰田汽车公司副社长大野耐一发现,有一条生产线上的机器总是停转,原因是保险丝被烧断了。虽然每次都及时更换保险丝,但用不了多久又会被烧断,严重影响整条生产线的效率。他觉得,更换保险丝并没有解决根本问题。于是,大野耐一与工人进行了问答对话。
一问:“为什么机器停了?”答:“因为超负荷,保险丝被烧断了。”
二问:“为什么超负荷呢?”答:“因为轴承的润滑不够。”
三问:“为什么润滑不够?”答:“因为润滑泵吸不上油。”
四问:“为什么吸不上油?”答:“因为油泵轴磨损松动。”
五问:“为什么磨损了呢?”答:“因为没有安装过滤器,混进了铁屑等杂质。”
经过连续五次追问“为什么”,才找到问题的真正原因,解决的办法就是在油泵轴上安装过滤器。
二、MTBF:即平均无故障时间,即平均无故障工作时间,是衡量一个产品(尤其是电器产品)的可靠性指标。单位为“小时”。它反映了产品的时间质量,是体现产品在规定时间内保持功能的一种能力。具体来说,是指相邻两次故障之间的平均工作时间,也称为平均故障间隔。
三、MTTR:即故障的平均修复时间,对MTTR进行拆解,得到如下几个时间段:MTTR = MTTI + MTTK + MTTF + MTTV
- Mean Time To Identify (MTTI): 从故障开始到应急响应介入的时间,一般是考察监控告警、人员值班oncall的合理性。
- Mean Time To Know (MTTK):从应急响应介入到故障定位的时间,主要考察根因分析、可观测性等工具的能力。
- Mean Time To Fix (MTTF): 从故障定位到故障恢复的时间,主要考察应急预案、快恢体系的能力。
- Mean Time To Verify (MTTV):从故障恢复之后到确认故障已经解决的时间,一般通过用户反馈、自动化测试等确认恢复。
四、SMART原则
- S – 必须是具体的(Specific),改进项必须是可以落地的,不要泛泛而谈。
- M – 必须是可以衡量的(Measurable),即改进项是可以评估的,比如通过故障演练来检验依赖关系的有效性。
- A – 必须是可以达到的(Attainable),在当前的技术环境下,这个改进项是可行的。
- R – 与其他目标具有一定的相关性(Relevant),可以理解与本次故障中其他改进项有关联性。
- T – 必须具有明确的截止期限(Time-bound),要写清楚改进项的截止时间,在到期之后进行验收。
五、KISS复盘原则
KISS复盘法(Keep保持、Improve改进、Start需要开始、Stop需要停止)
实践案例:
对微盟本次事故做复盘分析,以帮助大家更好的理解本次事故的原因和改进措施,并从中吸取宝贵经验。
事故经过回放
时间线,关键举措,结果
2月23日,线上生产环境及数据,遭到恶意破坏,导致系统服务不可用。
2月25日,紧急恢复了核心业务的线上生产环境,新用户使用不受影响,但是旧数据无法恢复。
2月28日,恢复了所有业务的线上生产环境,老用户可以登录,恢复了微站产品的所有数据。
3月1日晚8点,全面找回数据,做数据一致性和线上体验。
3月2日凌晨2点至8点,进行数据恢复上线演练,演练完成后系统数据回滚到3月2日的数据。
3月2晚上10点至3月3日上午9点,进行数据恢复上线,将2月23日与3月2日的数据进行合并,所有数据恢复完成。
实际在做事故复盘的时候,描述不会那么简略,必须包含:谁在什么时间点,做了什么,结果是什么。力求真实还原当时事故发生时的情况。这个环节,先申明不定责,只需要把事故过程描述出来,以便做下一步的事故分析。
事故复盘分析
改进措施,改进计划,定责
在做事故复盘分析时,对于事故过程的每个步骤,进行展开讨论,这一步我们做了什么?没做什么?怎么做效果会更好,我们如何改进?然后将分析的结果写下来,我们以微盟事故为例,分析结论如下:
1、引入外部安全专家,一起评估整改方案。这个操作并不是说微盟的数据安全团队没人。当然了,出了这么大的事情,数据安全团队是难辞其咎的。引入外部安全专家,主要是解决公信力的问题。出了这么大的事,你说你要整改,谁还敢信啊?引入外部专家,能解决信任问题。但是,方案落地工作还是微盟安全团队自己做的,也就是说,干活的还是同一拨人。
2、放弃自建数据库服务,全面使用腾讯云的云数据库。可以看出来,之前的方案是采用腾讯云的物理机,然后自建MySQL集群方案。大家会觉得奇怪,为啥要这么干?既然用了腾讯云,那还不用整套云数据库?原因不外乎,一是不愿意把自家最核心的数据资产,放在别人家里,哪怕你家有很好的保险柜,人性使然。二是对自己的数据方案、团队能力,都比较有信心,认为不就是个数据库嘛,搞得定。
3、数据安全机制的执行过程有漏洞。在改进措施中强调了,严格执行授权审批、使用腾讯云CAM进行云资源管理、分级授权,高危动作进行二次授权。比方说删库跑路这类操作,必须二次授权。倒不是说之前没有这些制度,只是没有严格执行。引入外部审计还是有必要的。
4、对开发/测试/预发布/正式环境,未做严格分离。这种情况在许多互联网公司,是非常普遍的,一是因为多套环境的建立,需要花费软硬件成本,二是需要专门团队和成熟的维护工具。做好了,工程效能得到极大提高,弄不好就磕磕绊绊,还不如开发、测试、正式环境混用,虽然有安全隐患,但是架不住方便啊。于是,大家就默认了,忽略了最基本的安全问题,平时没什么,一旦碰上情绪不稳定的运维人员,就悲剧了。
5、缺乏多云灾备、双活方案。老K在上一篇文章中,就做过论断:微盟本次事故,缺乏数据中心双活方案、数据灾备方案,不幸都被言中了。从整改措施里,也可以看到将建立三个城市的全备份的冷备系统架构。
6、缺乏日常演练。故障演练,指的是人为随机造成系统故障,比如偷偷到机房,随便拔掉某台机器网线或电源,看看系统能不能自恢复。高级一点的,是用软件来对生产环境进行故障注入,类似阿里的混沌工程、奈飞(Netflix)的Chaos Monkey等,通过随机制造的故障,检验系统的高可用性,暴露结构性风险。
最后一步,整理改进计划,落实到具体负责人,时间点,由QA团队进行跟进,跟踪短期和中长期的改进措施,直到执行结束。
以上,我们采用互联网公司事故复盘的方法,对微盟整个事故做了分析,关键是思路和方法。我们要善于借鉴他人的宝贵经验,毕竟1.5亿的经验教训,这个学费不是每个公司都交得起的。
总体来看,事故给微盟造成的负面影响是短期的,只要微盟顺利解决技术管理问题,那基本面对微盟仍然有利的。而事故给微盟带来的教训,却是非常宝贵且有长期价值的。从这一点来讲,长期看微盟一点都不亏。