第44期 | 发生故障后要不要追责？
池建强
讲述：池建强大小：6.88M时长：07:31
你好，这里是卖桃者说。今天想跟你聊聊故障管理的事儿。
首先我们得接受一个事实，故障是不可能完全避免的，再牛的软件系统、再知名的科技公司，都无法避免故障的发生。系统正常，只是该系统无数异常情况下的一种特例，这句话出自《Google SRE》这本书，一行 bug 千行泪，道出了程序员们多少辛酸。
所以呢，我们应该做的，就是在故障面前不断的反脆弱。换句话说，在不该出现故障的问题上，不断提升能力和优化流程，减少故障出现的概率。而在出现故障时，要能够做到快速定位、快速修复，并且设定一套应对故障的流程。
故障发生后，最重要的就是快速定位故障源，这是之后一切操作的前提。这点说起来容易，在实际操作中并不简单，因为在复杂的系统架构中，一旦发生故障，很可能出现“多米诺骨牌效应”。也就是说，故障会从一个系统开始一点一点地波及到其它系统，而且这个过程可能会很快，并且是不可逆的。一旦很多系统都在报警，再想快速定位到故障源就不是一件简单的事了。
关于故障定位，亚马逊的做法是比较典型的，极客时间的专栏作者陈皓老师曾分享过亚马逊是怎么定位故障的，他是这么说的啊
在亚马逊内部，每个开发团队至少都会有一位 oncall 的工程师。在 oncall 的时候，工程师要专心处理线上故障，轮换周期为每人一周。一旦发生比较大的故障，比如，S1 全部不可用，或 S2 某功能不可用，而且找不到替代方案，那么这个故障就会被提交到一个工单系统里。几乎所有相关团队 oncall 的工程师都会被叫到线上处理问题。
工作流是这样的，工程师先线上签到，然后自查自己的服务，如果自己的服务没有问题，那么就可以在旁边待命（standby），以备在需要时进行配合。如果问题没有被及时解决，就会自动升级到高层，直到 SVP 级别。
也就是说，一旦出现线上故障，所有相关团队，包括开发、运维、测试等都需要上线处理，各自排查自己负责的模块或服务。这是一种全链条投入排查的手段，比较有效和快速，目的就在于跟故障抢时间。同时还可以对被影响的其他团队做一定的处理，比如做降级处理，这样可以控制故障的范围不被扩散。
相较来讲，这会比由专职的运维团队来处理故障要快得多，因为很多功能性的问题，运维团队并不能完全处理，最终只能把相关的开发人员叫来解决，中间就会耽搁很多时间。
极客时间团队还比较小，我们大量采用了云服务，运维的工作就相对少一点，也没有设置专门的运维团队，不过我们开发了一套自动化运维系统，也设置了 oncall 组，一旦出现问题，会有报警机制，然后全员运维，定位故障，解决问题。
故障修复之后，另一个离不开的话题就是追责，也就是出了故障之后到底要不要惩罚，怎么惩罚。这其实特别考验管理者的水平，很多技术团队氛围变差，程序员怕担事、积极性下降，一个很大的原因就是处罚措施使用不当。
之前，赵成老师在他的专栏《赵成的运维体系管理课》里用一个系列的文章来写了故障管理要怎么做，其中关于追责的观点很有借鉴意义，在这里分享给你。
对于故障的事后处理，我的建议是：一定要区分好两个概念，定责和处罚，定责≠处罚。
定责，事情一定要有人承担责任，并且负责后续改进措施落地。定责一般是故障复盘之后确定的，通过这个过程找到根因，制定改进措施，最终判定责任方，会议和公开场合只体现责任团队，故障系统上会记录到具体责任人，但是这个字段不公开。
这个过程，就一个原则：对事不对人。因为故障复盘这个事情，每个团队都会去做，具体的过程和方式方法没有太大差别，所以这里不讲具体过程和方法。
处罚，也就是是否跟薪资、奖金、绩效考核、晋升资格等等这些跟利益相关的事情挂钩？我的观点是：不能一刀切，不能上纲上线。
这里首先问一个问题，处罚的目的是什么？其实说的直白一点，目的就是想让责任人长记性，别再出纰漏，有效降低再犯错误的概率。
很多严重的故障都来自主观意识薄弱、低级且重复的失误，解决这个主观意识上的问题，我们可以考虑设定高压线。
高压线就是避免因为无意识或意识薄弱导致的严重故障。这样的问题要坚决杜绝，碰一次就要让责任人疼一次，这样，责任人敬畏意识和主观意识提升了，人为失误才会减少，这样的处罚才是有效果的。
但是，对于其他类型的故障，就要区别对待了，比如：
这件事情本身就极具挑战性，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，出了一些问题。
业务高速发展，业务量成指数级增长，但团队人员技能和经验水平整体上还没法很好地应对，导致出现了故障。
团队没有足够的人手，员工主动承担别人做不了或不愿做的事情，在执行过程中出了一些问题。
在这些情况下，只要不是涉及高压线，或者造成了不可挽回的损失，一定要优先鼓励肯定，传递信任，而不是批评和处罚。当然，定责该怎么定就怎么定，但不要惩罚，毕竟，我们的最终目的是从根本上反思，找出问题的根源，避免下次再犯，而不是惩罚人。
作为管理者，一定要对故障有容忍度，在团队内部营造出一种鼓励做事、鼓励向前冲的氛围，而不是制造担心犯错误、担心被处罚的恐慌氛围。否则，员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，想要恢复也会非常困难，最终大概率会导致优秀人才流失，得不偿失。
最后调查一下，你遇到过的最严重的一次故障是什么样的？是删库跑路么？当时你怎么解决的？最后有追责么？期待留言区看到你的精彩故事。
好，今天的话题就先聊到这儿。卖桃者说，明天见。
（编辑：成敏）
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《卖桃者说》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(12)
- 最新
- 精选
莫弹弹我遇到最严重的故障是一次版本迭代，那一次是停机更新，运营的人通知客户晚上8点后更新完毕，更新过程非常漫长，改动数据库，更新有冲突的代码，还有测试新功能是否流畅。 在测试了一个小时后确定没问题，开放登录，结果客户一拥而上，CPU使用率稳定190%，登录都上不去 那会儿我在地铁上，硬着头皮用手机连接服务器找问题，一个小时后定位到数据库压力大，因为前端更新了个功能，添加了个轮询，每个用户每5秒三个请求，查询内容还是带分页的。 然后我让运维加了带宽，让前端去掉轮询，这才把问题解决掉 很宝贵的经验15
djfhchdh之前就被罚过，绩效b-，确实有效，后来就更小心了，有风险的事一概不接112
bradleyzhou不明白这段：“很多严重的故障都来自主观意识薄弱、低级且重复的失误，解决这个主观意识上的问题，我们可以考虑设定高压线。”这种失误难道不应该制定规范流程、把流程固定到脚本代码里吗？为什么还要依赖主观意识的“高压线”？11
吃草🐴~确实需要定一个责任人，但是这不是为了惩罚或者找人背锅，只应该是对事不对人，起到让犯错者长记性，甚至大家都有这个印象，不再犯错即可。 如果公司每次出问题都一定要揪出一个人或一个 Team 作为“反例”，并且只要犯错就会惩罚。那大家都不愿意主动承认错误，那我觉得这个公司也差不多走到头了。 人都会犯错，可能有时候犯了损失比较大的错。但是只要确实尽力了，就不应该狠批了。 我个人由于养成了备份的好习惯，错误几乎都有方式恢复。天性谨慎，有些不敢操作的都会问清楚，确认后再操作。1
怀朔最惨的事情 一个晚上发布7-8个应用 其中A B两个应用项目 分别使用T1 T2（数据表一模一样） 本来发布的时候要统一使用T1表 结果没有流程规范，B应用的人员要求我删除了T1表.故障形成！！！血泪史 最后我刚好在试用期 我被辞退收尾。该事过后 线上敬畏不言而喻 ...（当然最后数据肯定修复的）11
leslie定责是必须的：没有规矩不成方圆。 GOOGLE SRE是赵老师的课程推荐的一本书：当时在学赵老师的课程时买的，确实写的非常不错且非常有道理。其中书中有句话最经典“没有bug的程序，是程序的特殊形态”。运维就是要做好随时应对问题的处理。 老师讲到这个话题我就分享几段个人在不同企业的不同做法。同行们一起探讨交流：1.国内某一线金融企业运维部，所有的运维操作都视频录像，运维不确定的可以上报上级，没有上报的自己全责，上报了且确实发现不是自己的责任-无责。罚款按次数几何基数翻倍，奖励给当月没有犯错的，全年几乎极少犯错超过3次/部门。2.有规矩但不留痕，出了问题直接折腾，压不住了再上报。小错月月有，大家互相不吱声。 完整的操作监控机制：对于错误根据时间翻看记录比较有效；少了一些人性化不过确实非常有效。1- twentyoone“作为管理者，一定要对故障有容忍度，在团队内部营造出一种鼓励做事、鼓励向前冲的氛围，而不是制造担心犯错误、担心被处罚的恐慌氛围。否则，员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，想要恢复也会非常困难，最终大概率会导致优秀人才流失，得不偿失。”同意，不懂的人是因为什么原因呢？
小斧作为管理者，一定要对故障有容忍度，在团队内部营造出一种鼓励做事、鼓励向前冲的氛围，而不是制造担心犯错误、担心被处罚的恐慌氛围。否则，员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，想要恢复也会非常困难，最终大概率会导致优秀人才流失，得不偿失。
等风来做大概率正确的事，防范小概率事件
熊斌遇到过最严重的一次生产事故是高并发导致我们系统在元旦早上宕机，严重影响出单。最后定位到故障点是系统中的业务单元报文的功能，几乎所有节点都开启了，高并发的环境下服务器瞬间被打爆。处理方案是将一些不必要的节点报文落地功能关闭…
收起评论