如何应对事故

一 点睛

互联网业务的线上事故很难避免，有时会因为研发的代码出现 bug 导致，有时会因为外部环境发生变化而引起事故。我们能做的是尽量减少人为事故，防止出现低级事故，降低外部不可抗事故的影响。

二 处理事故

1 上报信息

出现事故第一时间向上级上报信息。

自己弄好，谁也不说行吗？肯定不行，纸保不住火。将事故信息上报给上级只有好处，没有坏处。

规范的事故处理流程是在众多“流血”的事故中总结出来的宝贵经验。隐瞒不上报肯定是不行的。

2 快速恢复

事故发生后，第一时间想的应该是如何快速恢复系统，而不是研究技术。只要能快速恢复系统和降低事故的影响，任何办法都是可行的。

例如，有的事故是因为发布的新特性导致主流程出了问题，那么马上回滚就可以恢复服务了。如果执着于查找问题的原因，那么用户一直体验的是有 bug 的服务。

三 管理预期

有时不能快速恢复系统，就要及时管理好用户预期，不要让事故的影响继续扩大。

1 评估影响

评估哪些用户受影响，以及影响的范围和严重程度。如果恢复，则需要多长时间，能恢复到什么程度？有没有替代的方案——即使方案没有那么完美？

2 “安民告示”

对外通知系统出了什么问题，多久会恢复。让外部有一个准备，知道发生了什么事情，不会有人乱猜而引起更严重的误会。

3 “壮士断臂”

有时要做出决策，要考虑柔性，舍弃一些正常的功能来保障主功能。

四 复盘总结

事故发生后，要进行详细的复盘，分析原因并进行整改，记录事故的详细过程、事故的原因、造成的影响，以及改进措施和排期。

事故的案例也要定期存档、完整保存。不仅是事故相关人，其他没有参与事故处理的开发人员也要定期学习，通过实际的案例来吸取教训。

既要防止一个人多次踩入一个坑，也要防止一个坑被多个人踩入。

五 有效预防

事故发生的原因很多，本质都是因为“变更”。

1 发布导致变更

每次发布都要有详细记录，并且能一键回滚。重要发布知会客服、产品等相关人员。

2 用户行为变更

热点事件导致用户的某种操作变多了，引起系统过载等问题。一般还是因为没有做好容量管理，不对应对大流量。架构师要对容量有一个评估（能应对多少请求），当用户行为变更时，能够及时扩容或实现柔性可用。节假日或促销活动前，要提前评估容量，做好预案。

3 依赖变更

指依赖的第三方服务发生了变更，导致系统处理出现异常，甚至影响全部请求的处理。虽然是另外一个系统变更所为，导致服务质量下降，但本质上还是系统的防御式编程没做好，把出错的影响放大。

4 触发 bug

在代码中写了“定时炸弹”。

还有的时候，有些代码没有用，却放到某个地方不删除，最后阴差阳错又被调用了，引起问题。

六 谨慎变更

每一次代码变更、发布变更都要谨慎，认真执行评审和发布流程。要有柔性预案，以及防范事故的意识。

事故发生的原因是多种多样的，即使有防范意识，也很难应对所有情况。监控此时起了大作用。不管发生了什么问题，都能及早发现问题，尽早预警——对 SLA 的指标进行监控。很多事故不是发生了处理不了，而是没发现。发现问题比解决问题更难。

总之，事故的减少，本质上还是因为安全意识的提高。按照流程和规范进行开发和运维工作，就不会出大问题。