1 | 一流的人生，就是看着别人犯错误，自己不犯错误，吸取经验教训； |
互联网工程师，特别是后台工程师，经常遇到线上出问题，引起事故。事故有大有小，影响不一，有些能自动恢复，有些影响巨大刻骨铭心。今天就来聊聊运营事故的处理及预防。
如何处理运营事故
虽然发生运营事故是大家都不想看到的，但是真发生了，还是有处理的方法。
1、第一时间同步给leader
为什么要同步给leader呢？自己弄好，谁也不说行吗？肯定不行，纸包不住火。同步给leader只有好处，没有坏处。 同步后，你可以专心处理事故，leader会帮你决策处理方法，通知相关人，评估事情的严重性，寻找经验更丰富的人等。因为leader一般经验丰富，能够快速定位问题，帮你出主意，做决策。如果影响相关团队，还能帮你协调外部资源。如果自己一个人处理，处理不好会事情越来越严重，影响越来越大。处理好了，也违反了流程。按照流程办，就不会出大问题。处理流程也是在众多流血的事故中总结出来的。
2、快速恢复
工程师都有个习惯，遇到问题喜欢弄明白，有学习精神。但是在发生事故时，第一时间想的应该是如何快速恢复，而不是讨论技术和学习。只要能快速恢复和降低事故影响的办法，都是可行的。就像在战士受伤时，衣服也可以撕开当纱布止血用，这时衣服和流血比，还是止血重要。 例如：有的事故是发布新特性导致主流程出了问题，那么即时回滚，比查问题更重要，先回滚恢复，再查为什么。不要让用户的体验一直在流血。
不能快速恢复怎么办
评估影响
看下都哪些用户受影响，影响范围，和严重程度怎么样？如果恢复要多长时间，能恢复在什么程度？有没有替代的方案来处理，即使没有那么完美。
安民告示
通知相关人，整理话术，对外通知出了什么问题，多久会恢复。让外部有个准备，知道发生了什么事情，不会有人乱猜，而引起更严重的误会。
壮士断臂
有时要作出决策，要考虑柔性，舍弃一些正常的功能来保证主功能。决策要砍脖子，到底是手旁边的，还是脑袋旁边的脖子？
事后复盘
事故发生后，要进行详细的复盘，分析原因整改，要记录事故详细过程，事故的原因，造成的影响，改进措施和排期。
如何预防事故
事故发生的原因
事故发生的原因有很多，本质都是一个“变更”。
发布导致变更
用户行为变更
来的用户多了，热点事件导致用户对某种操作变多了。引起系统过载等问题。一般还是容量管理没有做好，不能应对大流量。 要对容量有个评估，能应对多少请求，当用户行为变更时，能够及时扩容，或柔性可用。
依赖变更导致
是另外一个系统变更所为，到底是自己的防御编程没做好，还是依赖方的程序没写到位？
bug触发
代码中写了“定时炸弹”，例如做系统初期分配的空间写的太小了，随着规模扩大，突破的分配。 有些代码没有用，却放到那里，阴差阳错又被调用了。 既然有这么多原因，如何预防呢？
对变更要保有敬畏之心
每一次代码变更，发布变更。都要谨慎，认真执行review和发布流程。要有柔性预案。要有防范事故的意识。例如：申请ip都是同一机房的，如果线路断了怎么办，机房停电呢？能不能备份了数据，能不能快速搭建一套新的服务，有没有备机？ 但是事故发生的原因多种多样，有防范意识很好，但是也难应对所有情况。
1 | 吾生也有涯，而知也无涯 。以有涯随无涯，殆已！ |
为了不“殆已”，要抓住主要环节，最终的出口——监控。不管发生什么问题，都能即使发现，尽早预警。对SLA的指标监控。这是能够做到的。很多事故不是发生了处理不了，而是没发现。发现问题要比解决问题更难。 除此之外要能控制上限，例如发奖，总有个预算，万一多发了，也不至于把钱都发出去。给用户发短信，也不会一天发超过10条，如果超了就别发了。
总结
事故的减少，本质还是人的意识提高。 按照流程规范开发和运维，就不会出大问题。 不要两次被一块石头绊倒，从事故报告中吸取经验教训，减少事故。像圣斗士一样，不会被同一招打倒两次。