文章目录
前言
写完 《复盘要领》 之后， 我感觉我写完了一个模块。
所以，我现在要导入这个模块了：
from 《复盘要领》 import *
对于技术故障，往往是先恢复，后复盘。
因此根据实际的故障复盘需要，一般可分为复盘前、复盘中、复盘后。
一、故障复盘前
对于普通的故障，这个步骤是也就快速带过了，不一定需要。
主要是那些严重复杂的大故障，复盘前需要做较多准备，
比如要拉起一个多人复盘大会议，那么本着“高效会议”的精神，会议前是有必要做些准备的。
1、确定参会人
尽量卷入所有故障相关人员，如故障服务负责人、故障引发人、故障处理人 以及各团队主要负责人。
2、发送会邀
跟主要与会者沟通确认会议时间，并发送会议邀请。
3、准备复盘材料
材料需要能再现故障过程，准备好故障从发生到解决过程中的详细操作记录和各个操作节点的相关监控数据。
4、明确复盘目标
如何让修复过程更加高效，缩短故障持续时间
如何杜绝此类问题再次发生，错不二犯
二、故障复盘中
1、复盘一：让修复过程更加高效，缩短故障持续时间
1.1 明确目标
讨论得出结论：如何让修复过程更加高效，缩短故障持续时间
1.2 评估结果
当前故障持续时间较长，存在改进空间
1.3 分析原因与总结改进
围绕过程，寻找问题点，通常可以从这几方面追根究底：
| 复盘项 | 问题点 | 总结改进 | |
| 监控报警 | 监控是否足够完备？ | 流程监控 | |
| 报警是否足够及时？ | 秒级监控、自动报障 | ||
| 故障响应 | 故障响应时间是否过长、能否缩短、如何缩短？ | 故障电话、主备负责人 | |
| 故障定位 | 故障定位时间是否过长、能否缩短、如何缩短？ | 故障看板、调用网格 | |
| 故障修复 | 故障修复时间是否过长、能否缩短、如何缩短？ | 故障紧急发布通道、大招系统 | |
| 故障流程 | 故障信息同步是否及时？ | 故障信息流转系统 | |
| 用户投诉反馈是否关注到？ | 投诉反馈自动聚合上报 | ||
| 客户端故障公告是否按预期周知到位？ | 联动客服，定期演习；及时弹公告安抚用户 | ||
| 是否还存在不符合流程规范的问题 | 引起二次故障的一些操作等 |
2、复盘二：防止此类故障再次发生，错不二犯
2.1 回顾目标
讨论如何杜绝此类问题再次发生，错不二犯
2.2 评估结果
评估故障影响面
2.3 分析原因与总结改进
| 复盘项 | 问题点 | 总结改进 | |
| 防患于未然 | 有没有故障征兆？ | 系统缺陷的发现机制：运维系统风险工单 | |
| 故障征兆为何没有及时扼杀？ | 系统缺陷的跟进与升级机制 | ||
| 不可抗力 | 挖断光纤 | 备用专线 | |
| 机房断电 | 柴发续供 | ||
| 上联交换机故障 | 带状态服务打散，避免交换机聚集 | ||
| 外网故障 | 客户端容灾，自研解析 | ||
| 用户群体性行为 | 容量灵活伸缩能力 | ||
| 驱动因素 | 为什么要做这个变更操作？ | 必要性把关 | |
| 变更方案和代码变动有没有审核review？ | 变更风险评估 | ||
| 影响面控制 | 是否先发布到测试环境和预发布环境验证效果？ | 增加变更测试和预发布验证的强制流程 | |
| 测试环境和预发布环境，为什么没有感知和拦截异常？ | 预发布验证流程监控反馈建设 | ||
| 这个变更操作有没有灰度 | 强制灰度 | ||
| 这个变更操作是否支持回退？ | 变更前置的回退评估 | ||
| 回退是否足够及时快速？ | 升级加速渠道 | ||
| 系统架构 | 过载保护是否符合预期 | review分析有效输出比例 | |
| 环境耦合情况评估 | 顶层高扇出，底层高扇入 | ||
| 是否柔性可用 | 有损大招机制 | ||
| 变更管理 | 变更权限管理 | 按负责人收敛权限 | |
| 变更计划性 | 严控紧急上线行为 | ||
| 变更时间窗口 | 非工作时间限制变更 | ||
| 变更质量反馈 | 变更监控建设 |
3、让系统背锅
前面强调过，由于个人引起的故障，尤其需要强调主观因素。
否则，一味地归咎于系统，让系统管理员背锅，这是不够道德的。
3.1 流程吞噬责任
流程规范/系统保护措施是得有，好处大家都知道，
比如一个变更系统，能设计成随便无脑点都不会出事，大家自然非常欢迎，毕竟人是如此不可靠的物种，那么容易犯错。
但是，这个度没把握好的话，就容易把流程和系统当成挡箭牌和背锅侠，甚至让人变得本位不愿意担当。
3.2 端掉运维部门
当然，如果针对生产环境的操作类系统是运维部门出品的话，就很容易陷入上面这条死磕系统之路。
一方面，运维本身作为坐拥 “大量高危操作” 的群体，常在河边走哪能不湿鞋，
因此运维如此多的操作，总会难免来几次”误操作“，而这每一次的 ”误操作“ ，又可能是个大故障，
这个代价和压力对整个运维团队来说，是非常沉重的。
另一方面， ”提高安全意识，保持对现网敬畏“ 这种必备的生产环境素养，许多开发同学和运维新人都是难以具备，
甚至有些老油条也会大意出错，
这就导致在运维系统上，总是很难避免出操作故障。
于是，死磕系统（加上各种保护规则，降低大家出错的概率）就变成了速效药，
或者从另一种角度看，这甚至是一种运维自我保护措施，毕竟这些锅，太过于沉重了，而且运维还甩不开。
因此，整体来说，为了避免运维部门被端掉，运维系统的保护建设是有必要的；
但是也需要有个限度，
否则陷入 “流程吞噬责任” 的极致困境，这只会让人越来越容易出错，而运维系统却越来越复杂。
4、无故障复盘
4.1 回顾目标：
比如： 春晚业务洪峰期，无故障
4.2 评估结果：
成功了
4.3 分析原因
为什么成功？
计划多么完美： 计划先行、随机应变
节奏把握多么好： 协作默契
方案多么的周全： 业务解耦、削峰、降级、逻辑前置、异步化、云端控制、质量保证
这样就够了么？
显然，不够！
以上复盘，过于强调主观原因，但是实际上应该将成功更多地归功于客观原因，因为主观复盘结论并无借鉴价值。
正是得益于那些客观问题没发生，所以才能成功，比如：
隐藏bug没爆发
临时工没动作
异次元事件没发生
光纤没被挖
数据没被删
一致性没失效
没有地震等自然灾害
机房没出灾
核心网没故障
… …
于是，就会发现成功并非必然，还有很多潜在的问题和风险需要解决，还需要在性能、可用性、分治、地域容灾方面继续努力。
这样的无故障复盘，才具备长期价值。
三、故障复盘后
1、尽快输出会议纪要
会后及时输出故障复盘会议纪要，避免遗忘重要细节。
2、确认改进措施排期
跟每一位执行人确认改进措施的排期。
3、落实改进措施
安排质量管理/项目管理人员，定期Review改进措施的执行情况，及时暴露执行困难。
4、沉淀故障经验教训
大范围周知；前车覆，后车戒。
