故障发生后，我们一定要严肃对待，要对关键责任人或责任方定责，但是定责的目的不是处罚，因为故障复盘一旦以处罚为导向，就会导致非常严重的负面效应。

我们应该如何对待定责和处罚呢？今天就来分享一下我的理解，以及我个人的一些处理方式。

关于定责和处罚

定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的。

但是，在具体的执行过程中，我们一定要区分定责和处罚。定责是对事不对人的，但是处罚就变成对人不对事了，因为处罚一定会跟薪资、奖金、绩效、晋升等这些跟个人利益相关的事情直接挂钩。

我的观点是，处罚不能一刀切，更不能上纲上线，一定要慎重。

关于是否处罚，我个人认为可以遵循这样的原则：对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。

这样的规则建议通过设定高压线的方式让团队成员牢记心中，就像“酒后不开车”一样，简单明确。我大致列举几条我们的“高压线规则”。

  • 未经发布系统，私自变更线上代码和配置；
  • 未经授权，私自在业务高峰期进行硬件和网络设备变更；
  • 未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
  • 未经授权，私自在生产环境进行调测性质的操作；
  • 未经授权，私自变更生产环境数据信息。

通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从我们的经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。特别是那种自我感觉没问题，就把命令噼里啪啦敲到线上的操作，是最致命的。

2016 年是公司业务高速发展的阶段，设备扩容比较频繁，网络割接操作也很多。因为没有明确严格的规则，导致团队成员为了赶工期，在白天进行网络设备变更，结果就是严重的 P0 和 P1 故障频发。复盘过程中，很多人的反馈就是：我以为是没问题的，我以为是没影响的。其实恰恰就是因为这种“想当然”，导致了严重故障。

后来我们总结，在这些关键的操作上，如果大家意识到位，能够谨小慎微，绝大多数低级失误都是可以避免的，所以针对这些场景，我们就专门制定了高压线。

制定高压线的效果也是很明显的。在近两年的时间里，我们没有出现过任何一例因为意识缺失或低级失误导致的 P0 和 P1 故障。反倒是跟我们有产品技术合作的第三方厂商，有时会出问题，我们了解下来，基本都是白天变更导致的，要么是没有放到凌晨实施，要么就是白天临时变更，没有准备充分。

所以，制定明确的高压线规则，提升意识，碰一次就要疼一次。这个时候的惩罚是为了提升责任人的敬畏意识和主观意识，人为失误才会减少，处罚也才会有效。

当然，更好的结果是，类似的故障越来少，处罚的执行也基本没有了。

鼓励做事，而不是处罚错误

前面我们分享过这句话：

理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（From SRE，by Brian Redman）

我想很多朋友跟我一样，都会产生共鸣。仔细考虑一下，我们每个人的技术能力提升，甚至是质的提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进，这样一个过程提升起来的。

虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。

发生故障一方面暴露出我们整体技术架构的不足之处，另一方面，也给我们提供了未来改进的方向。同时，也是最重要的，我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，团队和个人素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。

反观另一种管理方式，一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。

所以，作为管理者，当一个故障发生之后，除故障本身外，还要关注更全面的内容，比如关注人、事情背景和前因后果。

列举一下我之前经常遇到的两种情况。

1. 员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现了问题。

这种情况在成熟的技术和产品中也极容易出现，比如开源产品，有时候不翻源码都不知道某个地方埋着深坑。即使是商业产品，像 Oracle 在他的官方 bug 库里列着一堆已知 bug，就是明确告知用户使用时要非常小心，真的碰到 bug 了，官方一般也是建议升级版本。根据我的经验，对于这样一个庞大的 bug 库，不出问题一般没人会去把整个 bug list 都看一遍的。

2. 业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，这个时候可能任何一个小变动都是最后一根稻草。这种时候就需要群策群力，而不是简单处罚了事。

这两种情况都需要全面了解信息之后，再做判断。甚至要优先传递信任，而不是不管三七二十一就直接批评和处罚。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。

在当前这种新业务和新形态不断涌现，又要求快速迭代的背景下，软件开发这种技术工作很大程度上还是要依赖员工的创新和创造。所以在很多情况下，管理者一定要对故障有一定的容忍度，因为员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失，为别人做了嫁衣。

所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。

处罚的“负”作用远超我们的想象

前面讲到，定责不是处罚，是就事论事。员工哪些地方做得不到位，是能力不足还是经验欠缺，这些东西主管可以基于事实，很正式、严肃地表达出来。通常情况下，员工也大多是可以接受的。同时帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。这种情况下，员工的感受是，主管尊重我，在帮助我。

但是，话题和目的一旦转到处罚相关的事情，员工一般会有两种类型的反应：一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑（凭什么罚我不罚别人，又不是我一个人的问题等等）。

这时，员工的注意力也会从怎么改进，转变到为什么要处罚我的角度上来。在这种消极和抵抗情绪中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一句，但是他压根就没听进去。

从我们的经验来看，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。

后来我们就取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。

我的团队中，就出现过类似的情况。有员工导致了线上严重故障，当个季度绩效较差，但是因为全年表现突出，年终仍然是优秀；也有员工，因为连着两个季度触碰高压线，全年又无明显突出的表现，年终绩效也就不理想。

总结

我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。

另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。

最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。

如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！