15章 事后总结：从失败中学习
事后总结包括该事故所造成的影响，为缓解该事故的措施、事故的根本原因，以及防止未来问题重现的后续任务。
需要书写事后总结的标准：
1.永不可见的宕机时间或者服务质量降级程度达到一定标准
2 任何类型数据丢失
3.on-cal工程师需要人工介入的事故
4.问题解决耗时超过一定限制
5.监控问题（预示着问题由工程师发现，而非报警系统）
原则：对事不对人，不抱怨，不指责。
最佳实践：避免指责，提供建设性意见。
协作和知识共享：
事后总结工作流程的每一步都包括团队协作和知识共享。
优先选择以下功能：
1.实时协作。---使写作过程可以很快收集数据和想法。
2.开放评论系统-使大家可以参与进来，提供解决方案，以及提高事故细节覆盖程度
3.邮件通知--可以在文档中给其他用户发消息，或者引入其他人来共同填写文档。
内部发布->正式评审->发布
1.关键的灾难数据是否已经被收集并保存起来了？
2.本次事故的影响评估是否完整?
3.造成事故的根源是否足够深入
- 文档中记录的任务优先级是否合理，能否及时解决根源问题。
5.这次事故处理的过程是否共享给所有部门。
最佳实践：所有的时候总结都需要评审。
建立事后总结文化：
Google通过高级管理层的主动参与协作和评审环节来不断加强内部事后总结文化，但是有工程师自主驱动，效果会更好。
组织活动形式：
1.本月最佳事后总结。--每周新闻邮件
2.google 事后总结小组--本小组共享与内部和外部事后总结。
3.事后总结阅读俱乐部。
4.命运之轮。--刚加入的sre需要参加，角色扮演。
面对投入与产出质疑，可采用策略：
1.逐渐引入。
2.确保对有效的书面总结提供奖励和庆祝。
3.鼓励公司高级管理层认可和参与其中。
最佳实践：公开奖励做正确事的人。
最佳实践：收集关于事后总结有效性的反馈。
事故总结小组：---对事不对人。
协调内部各种部门的事后总结流程.建立事故总结模板，用流程管理工具自动化数据收集，以及自动化元数据收集一般进行趋势分析。
将最佳实践共享给不同产品部门。
