故障管理:鼓励做事,而不是处罚错误

故障管理:鼓励做事,而不是处罚错误

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

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

关于定责和处罚

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

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

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

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

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

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

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

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

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

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

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

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

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

前面我们分享过这句话:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

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

精选提问

  1. 第三方责任,有没有可借鉴的追责方式

    根本目的,还是为了改进,共同找到改进措施最重要。
    对于第三方,如果要谈责任,公事公办的话,最好的方式就是在合同中约束好,从商务上进行扣款和赔偿。
    
posted @ 2020-07-30 14:32  PassZhang  阅读(40)  评论(0编辑  收藏