共计 2990 个字符，预计需要花费 8 分钟才能阅读完成。
美图崇尚的故障文化是“拥抱故障，卓越运维”，提倡的基准是 No-Blame，即「不指摘，重改良」。往年 9 月 TakinTalks 社区已经分享过美图的三段式故障治理办法（美图 SRE：一次线上大事变，我悟出了故障治理的 3 步 9 招），这次重点讲讲故障治理中的最初一个重要环节 —— 故障后的复盘，在这个过程里能够总结吸取经验教训并改良，这样能力让整个零碎的稳定性失去实质性晋升。
作者介绍：美图 SRE 负责人 – 石鹏
TakinTalks 社区专家团特聘讲师。2016 年退出美图，运维技术专家，美图产品 SRE 负责人。目前在美图负责社区、商业化、翻新等全线产品的运维保障工作，同时参加公司日志、监控等基础设施的建设。参加或主导过屡次公司基础设施的调整、革新，在监控、灾备、故障治理、稳定性经营等方面有肯定的教训和积攒。
舒适揭示：本文约 2900 字，预计破费 4 分钟浏览。后盾回复“8201”获取文件材料；回复“交换”进入读者交换群；
一、故障后的复盘该怎么进行？
1.1 故障复盘的黄金 3 问
故障复盘过程怎么去无效发问，这里有个准则能够参考，就是黄金三问：
咱们应该怎么做，能力更快地去复原业务？
咱们应该怎么做，能力防止再次出现相似的问题？
咱们有哪些好的教训能够总结、提炼并固化？
这是咱们在复盘中须要去提问的，自我提问还有相互之间的挑战扫视都是须要的。除了后面这些货色，咱们还有没有一些更高维度视角能够去帮忙晋升整体的稳定性，也就是“咱们还能做什么”？这个也能够去进行自我提问。
1.2 故障定级、定性与定责
1.2.1 故障定级
故障定级的办法规范在不同公司是不同的，比方对故障级别的定义和命名都会有差别：有的公司是用 P0、P1、P2、P3 这样的分级规范，在美图则是按一二三四级去定义级别的，当然定级的逻辑必定都是统一的，那就是影响越大则级别越高。美图的具体做法是参考故障对服务性能的影响、故障的影响时长、故障产生所处时段、对客户的影响范畴这些维度，对不同维度赋以不同的权重，最终累计得出加权分数，而后再依据预设的规范去断定故障到底属于什么级别。
下图是咱们服务端的故障定级规范，客户端有另一套规范，但整体的逻辑是相似的。
下面是咱们的通用规范，不过有局部业务会有个性化的定级需要，比方商业化部门会更关注故障有没有影响支出、造成资损；或者有些业务会更关注有没有影响口碑、造成 PR 事件等；针对这样的需要场景咱们有独自梳理业务个性化定级规范。而后跟这些业务部门进行沟通协商，将相干个性化的规范映射到咱们的通用定级规范中，将大家的定级规范拉齐，如此这个故障定级规范就能够不便地在公司外部做推广应用，进而对故障实现体系化的治理。
1.2.2 故障定性
故障定性其实就是依据故障产生的起因进行无效分类，蕴含代码品质、测试品质、流程标准、变更操作、容量布局、产品逻辑、硬件设施、预案生效、云厂故障等等。
1.2.3 故障定责
后面有讲美图的故障文化叫 No-Blame 不指摘，那为什么还要去做定责呢？这里的定责并不等于惩办、更不等于扣绩效或工资。这里的定责更多的是指要你承当改良的责任，跟大家分享几个断定准则：
高压线准则：各个企业都会有外部的红线，比如说数据安全，凡事触碰到红线责任就会更大一些，也有一些对应的措施。健壮性准则：每一个服务模块本身要有比拟强的自愈能力，比方要做好主备、集群，要做好限流、降级等容灾伎俩等。其中对依赖的治理须要重点关注，原则上外围利用对非核心利用的依赖必须要有降级和限度的伎俩，以此保障本身的健壮性。
第三方默认无责：定责是对内的，即便咱们上云，援用了很多第三方利用，也是默认第三方是没有责任的。这是为了防止外部定责时各种问题都甩锅给第三方，长此以往 SRE 会失去应有的责任心。当然，故障是第三方引起的，咱们理当去追责、索赔，这没有问题，但你在架构设计上、整个稳定性保障上有没有哪些工作是能够欠缺来躲避故障的，这是咱们须要思考的内容。
分段断定准则：局部故障的的链路比拟长，起因可能也不止一个，因而须要去做一些分段的剖析，有利于更全面地扫视故障问题，相干剖析也会更聚焦，最终推导进去的改良措施也会更具针对性。自在裁量准则：尽管咱们有相干规范，然而实操时还是要 case by case，具体事件具体分析，不能齐全一刀切，要保障灵活性。
1.3 输入报告与定期回顾
接下来就是故障报告的产出了，也是整个故障处理过程中比拟重要的一环，下图是美图做故障报告的一个固定模板，在报告中陈说影响性能、故障级别、责任部门 / 责任人、处理过程、改良措施等，把这些故障报告定期进行演绎梳理，个别会依照故障级别、产生工夫、故障类型、责任部门 … 甚至更细的分类去做梳理。
有一点可能会被很多人漠视，就是针对故障总结去做周期性的回顾。像咱们美图会有一个年度指标，制订故障估算，通过故障计分来进行回顾，每产生一个故障会扣你特定的故障分，在周期完结之后，你要去看故障分 / 故障估算的指标是不是达成了。另外，应该周期性地去剖析这些故障的产生是否有法则，是否集中在某些业务部门，是否有集中呈现的时间段，是否频繁呈现跟某些基础设施或组件的关联，以及有没有什么其余的规律性？通过剖析推导进去的改良措施到底有没有落地，整改措施是不是无效？有没有产生过反复的 / 相似的故障？这些都是须要进行周期性回顾的。
二、故障治理的 2 个要点分享
GoogleSRE 里有这样一个数据，大略 75% 的故障都是因为人为操作、人为变更引起的，因而人的因素也须要重点关注。在故障治理这块美图有本人的一套体系，流程体系上将故障分与 OKR 联合来进行。
2.1 通过故障估算管控系统故障
简略说一下故障估算，这个概念来自于 Google SRE，美图在这块有一套本人的体系规定，具体的实际叫故障分，包含故障定级规定 (见前文)、计分规范。每个周期之初咱们年度或者半年度会有一个故障分的估算，每个部门会被调配肯定的故障调配额，当产生了故障就要计分并抵扣配额，最初依据故障分的余额进行周期考核。如果业务线、产品的故障分 (谬误估算) 扣完了，那产品公布迭代的节奏、稳定性建设相干的投入就须要有一些干涉措施了。
2.2 治理须要组织来撑持
组织撑持是比拟重要的，企业宏大部门繁多，如果部门之间的指标不能达成统一，那故障治理将很难推广。美图是有故障治理委员会的，每个 BU 也有接口人，当故障产生了就依据故障断定的准则去做故障定级、定责接着将故障分拆分到对应的部门。故障的估算制订和考核会与部门的 OKR 绑定，用这样行政伎俩来保障咱们整个故障体系的失常运行。
写在最初的话
“稳固是偶尔，异样才是常态”，只有你身处在 IT 行业，不论你是研发、测试、运维，或是其余什么岗位，故障始终都是一个你“避之唯恐不迭”却怎也无奈彻底解脱的梦魇。故障实质上是零碎稳定性被挑战和继续迭代优化的过程，只有了解故障产生的法则、把握故障治理的办法，做好复盘和改良，继续演绎总结和反思，能力做好对故障的治理，能力更好地建设和保障系统的稳定性 —— 既然无奈彻底解脱它，那就了解它、掌控它。
回复【8201】关键词获取讲师 PPT 回复【交换】进入读者交换群点击【查看原文】中转精彩演讲回放
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。https://mp.weixin.qq.com/s/N_…
