第44期 | 发生故障后要不要追责？
你好，这里是卖桃者说。今天想跟你聊聊故障管理的事儿。
首先我们得接受一个事实，故障是不可能完全避免的，再牛的软件系统、再知名的科技公司，都无法避免故障的发生。系统正常，只是该系统无数异常情况下的一种特例，这句话出自《Google SRE》这本书，一行 bug 千行泪，道出了程序员们多少辛酸。
所以呢，我们应该做的，就是在故障面前不断的反脆弱。换句话说，在不该出现故障的问题上，不断提升能力和优化流程，减少故障出现的概率。而在出现故障时，要能够做到快速定位、快速修复，并且设定一套应对故障的流程。
故障发生后，最重要的就是快速定位故障源，这是之后一切操作的前提。这点说起来容易，在实际操作中并不简单，因为在复杂的系统架构中，一旦发生故障，很可能出现“多米诺骨牌效应”。也就是说，故障会从一个系统开始一点一点地波及到其它系统，而且这个过程可能会很快，并且是不可逆的。一旦很多系统都在报警，再想快速定位到故障源就不是一件简单的事了。
关于故障定位，亚马逊的做法是比较典型的，极客时间的专栏作者陈皓老师曾分享过亚马逊是怎么定位故障的，他是这么说的啊
在亚马逊内部，每个开发团队至少都会有一位 oncall 的工程师。在 oncall 的时候，工程师要专心处理线上故障，轮换周期为每人一周。一旦发生比较大的故障，比如，S1全部不可用，或S2某功能不可用，而且找不到替代方案，那么这个故障就会被提交到一个工单系统里。几乎所有相关团队oncall的工程师都会被叫到线上处理问题。
工作流是这样的，工程师先线上签到，然后自查自己的服务，如果自己的服务没有问题，那么就可以在旁边待命（standby），以备在需要时进行配合。如果问题没有被及时解决，就会自动升级到高层，直到SVP级别。
也就是说，一旦出现线上故障，所有相关团队，包括开发、运维、测试等都需要上线处理，各自排查自己负责的模块或服务。这是一种全链条投入排查的手段，比较有效和快速，目的就在于跟故障抢时间。同时还可以对被影响的其他团队做一定的处理，比如做降级处理，这样可以控制故障的范围不被扩散。
相较来讲，这会比由专职的运维团队来处理故障要快得多，因为很多功能性的问题，运维团队并不能完全处理，最终只能把相关的开发人员叫来解决，中间就会耽搁很多时间。
极客时间团队还比较小，我们大量采用了云服务，运维的工作就相对少一点，也没有设置专门的运维团队，不过我们开发了一套自动化运维系统，也设置了 oncall 组，一旦出现问题，会有报警机制，然后全员运维，定位故障，解决问题。
故障修复之后，另一个离不开的话题就是追责，也就是出了故障之后到底要不要惩罚，怎么惩罚。这其实特别考验管理者的水平，很多技术团队氛围变差，程序员怕担事、积极性下降，一个很大的原因就是处罚措施使用不当。
之前，赵成老师在他的专栏《赵成的运维体系管理课》里用一个系列的文章来写了故障管理要怎么做，其中关于追责的观点很有借鉴意义，在这里分享给你。
对于故障的事后处理，我的建议是：一定要区分好两个概念，定责和处罚，定责≠处罚。
定责，事情一定要有人承担责任，并且负责后续改进措施落地。定责一般是故障复盘之后确定的，通过这个过程找到根因，制定改进措施，最终判定责任方，会议和公开场合只体现责任团队，故障系统上会记录到具体责任人，但是这个字段不公开。
这个过程，就一个原则：对事不对人。因为故障复盘这个事情，每个团队都会去做，具体的过程和方式方法没有太大差别，所以这里不讲具体过程和方法。
处罚，也就是是否跟薪资、奖金、绩效考核、晋升资格等等这些跟利益相关的事情挂钩？我的观点是：不能一刀切，不能上纲上线。
这里首先问一个问题，处罚的目的是什么？其实说的直白一点，目的就是想让责任人长记性，别再出纰漏，有效降低再犯错误的概率。
很多严重的故障都来自主观意识薄弱、低级且重复的失误，解决这个主观意识上的问题，我们可以考虑设定高压线。
高压线就是避免因为无意识或意识薄弱导致的严重故障。这样的问题要坚决杜绝，碰一次就要让责任人疼一次，这样，责任人敬畏意识和主观意识提升了，人为失误才会减少，这样的处罚才是有效果的。
但是，对于其他类型的故障，就要区别对待了，比如：
- 这件事情本身就极具挑战性，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，出了一些问题。
- 业务高速发展，业务量成指数级增长，但团队人员技能和经验水平整体上还没法很好地应对，导致出现了故障。
- 团队没有足够的人手，员工主动承担别人做不了或不愿做的事情，在执行过程中出了一些问题。
在这些情况下，只要不是涉及高压线，或者造成了不可挽回的损失，一定要优先鼓励肯定，传递信任，而不是批评和处罚。当然，定责该怎么定就怎么定，但不要惩罚，毕竟，我们的最终目的是从根本上反思，找出问题的根源，避免下次再犯，而不是惩罚人。
作为管理者，一定要对故障有容忍度，在团队内部营造出一种鼓励做事、鼓励向前冲的氛围，而不是制造担心犯错误、担心被处罚的恐慌氛围。否则，员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，想要恢复也会非常困难，最终大概率会导致优秀人才流失，得不偿失。
最后调查一下，你遇到过的最严重的一次故障是什么样的？是删库跑路么？当时你怎么解决的？最后有追责么？期待留言区看到你的精彩故事。
好，今天的话题就先聊到这儿。卖桃者说，明天见。
（编辑：成敏）