应急事件响应
测试导致的事故
SRE 故意破坏系统，利用这些测试发现系统的薄弱地方。
在某次测试中发现了额外的系统依赖。
响应
- 终止测试
- 用以前 测试过的方法 回滚了数据
- 找到开发者修复了相关问题
- 制定了周期性测试机制 来保证问题不重现
事后总结
好的方面： 事先沟通，有足够信息推测是测试造成的问题。 快速恢复了系统。 遗留一个代办，彻底修复问题。制定了周期性的测试流程。
不好的方面： 虽然评估了，但是还是发生了问题 没有正确遵守响应流程 没有测试“回滚机制”，发生问题后回滚机制失效。
变更导致的事故
某个周五，某个配置文件推送到所有的服务器。触发了 bug。
响应
- 各个系统开始报警
- on-call 工程师前往灾难安全屋。（有google 生产环境专线）
- 5 分钟以后发布这个配置的工程师发现问题，回滚发布
- 某些服务由于这次发布，触发了别的 bug 一小时后才回复
事后总结
好的方面：
- 监控系统及时报告问题
- 问题被检测后，应急流程处理得当。SRE 要保持一些可靠的，低成本的访问系统
- Google 还有命令行工具和其他访问方式确保能够在其他条件无法访问的时候进行更新和变更回滚。且要频繁测试，让工程师熟悉他们。
- 限速机制，限制了错误的扩散。抑制了崩溃的速度。
从中学到的：
- 变更经过了完整的部署测试没有触发 bug，评估并不危险，但是在全球部署的时候触发了 bug
- 不管风险看起来有多小，都需要严格测试
- 监控系统在灾难中，发出了很多报警，干扰了 on-call 工程师的工作
流程导致的严重事故
常规自动化测试，对一个集群发送了两次下线请求，触发 bug将全球所有数据中心的的所有机器加入到了磁盘销毁的队列
响应
- on-call工程师收到报警，将流量导入其他地区
- 停止了自动化工具
- 用户导入其他地方，响应时间变长，但是还是可以正常使用
- 恢复数据
总结
好的地方
- 反向代理可以迅速的切换用户流量。
- 自动化下线虽然一起下线了监控系统，on-call 工程师快速恢复系统。
- 工程师训练有素，多亏了应急事故管理系统和平时的训练。
从中学到的：
- 事故的根源在于自动化系统对发出的指令缺乏合适的合理性校验。
所有的问题都有解决方案
系统不但一定会出问题，而且会以没有人能够想到的方式出现问题。但是所有的问题都有对应的解决方案。如果想不到解决问题的方法，那就再更大的范围里面寻求帮助。很多时候触发事故的人对事故最了解。
一旦紧急事故过去之后，一定要留出时间书写事后报告。
向过去学习，而不是重复它
- 为事故保留记录
- 提出那些大的，甚至不可能的问题：假如…
- 鼓励主动测试
小结
遇到事故，不要惊慌失措，必要时引入其他人帮助，事后需要记录。把系统改善为能够更好的处理同类故障。
紧急事故管理
无流程管理事故的剖析
- 过于关注技术问题
- 沟通不畅
- 不请自来
事故管理的要素
嵌套式责任分离
事故处理中，让每个人清楚自己的职责。如果一个人处理的事务过多，就应该申请更多人力资源。把一部分任务交给别人。 事故中的角色：
- 事故总控 负责组建事故处理团队，负责协调工作
- 事务处理团队 具体处理事故的团队，唯一能够对系统进行修改的团队
- 发言人 向事务处理团队和关心事故的人发送周期性的通知。维护事故文档。
- 规划负责人 为团队提供支持。如填写事故报告，定晚餐，安排交接。
控制中心
很多时候可以设立一个”作战室“。
IRC 处理事故很有帮助。IRC 很可靠，记录下所有沟通记录。
实时的事故状态文档
事故总控人最重要的职责就是维护事故的实时文档。最好可以多人同时编辑。
明确公开的职责交接
事故总控人的职责能够明确，公开的进行交接很重要。交接结果要宣布给正在处理事故的其他人。
什么时候对外宣布事故
- 是否需要引入第二个团队来帮助处理问题
- 是否时候正在影响最终客户
- 集中分析一个小时后，这个问题是不是依然没有得到解决
最佳实践
- 划分优先级
- 事前准备
- 信任
- 反思
- 考虑替代方案
- 练习
- 换位思考
