You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
55 lines
1.9 KiB
55 lines
1.9 KiB
3 years ago
|
# 第十五章 事后总结：从失败中学习
|
||
|
|
|
||
|
|
书写事后总结的主要目的是为了保证该事故被记录下来，理清所有根源问题，确保实施有效的措施使得未来重现的几率和影响降低甚至避免重现。
|
||
|
|
|
||
|
|
书写事后总结不是一种惩罚措施，而是给整个公司一个学习的机会。
|
||
|
|
|
||
|
|
## 基本事后总结条件
|
||
|
|
|
||
|
|
事后总结应对事不对人，重点关注如何定位造成这次事件的根本问题。
|
||
|
|
|
||
|
|
- 用户可见的宕机时间或者服务质量降级程度达到一级标准
|
||
|
|
|
||
|
|
- 任何类型的数据丢失
|
||
|
|
|
||
|
|
- on-call工程师需要人工介入的事故,包括回滚、切换用户流量等
|
||
|
|
|
||
|
|
- 问题解决耗时超过一定限制
|
||
|
|
|
||
|
|
- 监控问题，预示着问题是由人工发现而非报警系统
|
||
|
|
|
||
|
|
## 协作和只是共享
|
||
|
|
|
||
|
|
事后总结工作流程的每一步都包括团队协作和知识共享。
|
||
|
|
|
||
|
|
事后总结的过程还包括正式的评审和发布过程，团队首先内部发布，同时依据如下条件评审：
|
||
|
|
|
||
|
|
- 关键的灾难数据是否已被收集并保存
|
||
|
|
|
||
|
|
- 本次事故的影响评估是否完整
|
||
|
|
|
||
|
|
- 造成事故的根源问题是否足够深入
|
||
|
|
|
||
|
|
- 文档中记录的任务优先级是否合理，能否及时解决根源问题
|
||
|
|
|
||
|
|
- 事故处理的过程是否共享给了所有相关部门
|
||
|
|
|
||
|
|
## 建立事后总结文化
|
||
|
|
|
||
|
|
SRE通过组织一些集体活动来更好的建立事后总结文化：
|
||
|
|
|
||
|
|
- 分享本月最佳事后总结
|
||
|
|
|
||
|
|
- 组建事后总结讨论小组
|
||
|
|
|
||
|
|
- 组织事后总结阅读俱乐部
|
||
|
|
|
||
|
|
- 参见命运之轮游戏--再现事后总结场景，扮演其中的角色进行演习活动。
|
||
|
|
|
||
|
|
对投入产出比的质疑是对引入事后总结机制的最大阻力，以下策略来帮助面对这个挑战：
|
||
|
|
|
||
|
|
- 逐渐引入事后总结流程，首先进行几次完整和成功的事后总结，证明其价值并确定书写的条件
|
||
|
|
|
||
|
|
- 确保有效的书面总结，提供奖励和庆祝
|
||
|
|
|
||
|
|
- 鼓励公司高级管理层认可和参与其中
|