如何处理运营事故

终于发布完成了，还没等休息，收到一堆告警短信，收件箱都快炸了；

刚发完特性不到一天，客服群里用户反馈，数据错了，多扣钱了；

半夜睡觉，突然被短信吵醒，业务崩溃了……

以上这些场景，对于做过后台大系统的人来说，都应该有遇到过。每次线上事故都会让人刻骨铭心，都会扰乱你的日常。

事故是不可避免的，只要有人写的程序，就会有bug，就会酿成事故。遇到事故，我们应该怎么办呢？

告知leader和相关人

事故会影响业务，千万别想隐瞒，自己偷偷修改。遇到问题要先抛出来，把影响情况如实地告诉leader和相关人。然后就不是你一个人在战斗，会有人帮你想办法，check你修复的方法。帮助你尽快地度过危机。如果一个人捂着，默默地修改，会头脑不清醒，可能会一根筋。曾经就有人直接到数据库修复用户数据，没备份，结果都改乱了，越忙事情越多。如果事故影响很大，要通知公关，和更高层的leader。你的leader会帮你做这些事，帮你处理。让你专心处理线上问题。事故发生时一般人都是很紧张的，有些人改问题手都是抖得，想想几百万用户都登录不上，是多么可怕。尽快告知上级，会有经验更丰富的人帮你，挺你，所以这才是第一要做的。

尽快恢复业务

来不及了，快上车。事故来时如排山倒海，例如用户都登录不上，页面打不开，游戏掉线。查看是哪行代码导致意义不大。一般事故都是更改发布导致，变化导致问题。所以确定是发布问题，马上回滚，让业务恢复到正常水平。中间如果有操作，详细地记录下来，方便日后复盘。有些单机的日志，也要拷贝，防止时间长了日志被滚掉。

因为架构，或访问量突增导致的事故，马上扩容，恢复业务。真的到山穷水尽，不能马上恢复，发条微博，安民告示，告诉你的用户，你正在努力恢复中也好，一般都是由公关来发，开发给出评估的结论。

用测试系统复盘，修复问题，重新起航

线上的问题已经修复了，但是程序的bug还没找到。这时才是慢慢地找问题，仔细修复。在测试环境构造出问题的场景，修复后再验证，是否不再发生。经过详细的测试，没有问题，再次发布起航，把新特性发出去。

总结事故，防微杜渐

人不应该被同一块石头绊倒两次，每次事故也是一次财富。认真总结，积累经验，认真总结，防止下次再犯。成本最低的是吸取别人的教训，以后哪些地方要测试，哪些地方要小心。每一次总结都是一次进步。不要因为事故被打到，增强心态，提高遇事不乱的能力。变被动为主动，主动发现，预防事故，积累经验，提高意识。

最后，祝大家都少发生事故，业务越来越稳定！