系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

# 一分钟精华速览 #

系统故障无法避免,事故发生的原因多种多样,故障定责不是为了指责而是为了后续的优化改进,可很多企业在定责时难免遇到团队、个人之间推卸责任的情况,定责定的到底是什么 “责”?​​TakinTalks​​ 社区的 5 位专家,给出了 6 条具体准则,总结如下:

1. 故障定责不是为了给人定责的,定责在事项上才是明智之举。

2. 故障定责属于管理问题而非技术问题,对事不对人,但对人该有的处罚也还是不可免除。

3. 只要不是人为地恶意地去制造系统的事故,就不要去指责这个人,需要考虑的是怎么来有效管控人为因素。

4. 定责也分正反面,故障发生后我们一般分两类情况,定责和惩责:按事定责,对违规者惩责。

5. 在统一的故障文化下,具体问题具体分析,不指责,重改进。

6. 不放弃对人的追责,允许犯错,但不允许一错再错。

老师们针对今日热点话题都给出了自己的详细回答,感兴趣的可以往下浏览完整回答。👇

— — — — — — — — — — — — — — — — — — — — — — — — —

 

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

在统一的故障文化下,具体问题具体分析,不指责,重改进。

我们倡导的故障文化是「No blame culture」,即「不指责,重改进」。从这里就可以得出我们的关注点是在「事」上的,我们会重点关注故障暴露出来的系统问题、架构问题、流程问题等,然后着手修复和改进。我们尝试和努力创造一个这样的文化氛围,让大家更好地应对和管理故障,将精力聚焦在提升系统稳定性上,而不是导向惩罚等相反的方向。

不放弃对人的追责,允许犯错,但不允许一错再错。

但是,在这样的背景之下不代表我们完全放弃对「人」的追责,毕竟 IT 管理的三大块 ——P (人) P (流程) T (技术 / 工具) 都很重要,在特定的场景下也还是需要保留对人追责的处理方式。这里有一个或许可以借鉴的准则是:“允许犯错,但不允许一错再错”。同时还有两个点需要注意:

① 对人的追责,不一定是具体执行某个引发故障操作的同学,也有可能是业务、系统或工具的负责人,这个需要具体实例具体分析;

② 将责任划分给某个人,也不是直接跟绩效 / 奖金挂钩的,被定责的人更多的是要承担起故障改进的责任。

 

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

 故障定责不是为了给人定责的,定责在事项上才是明智之举。

我坚持一贯以来的观点,故障定责不是为了给人定责的,定责在事项上才是明智之举。通过故障复盘,针对系统代码以及工作流程相关设定改进项,只要按照改进项去优化调整就能大幅度提升的,那我绝对不会去惩罚具体的责任人。但如果按照改进项做了调整和相关规定,可有人不愿意按规章制度去工作导致事故再次发生,那很抱歉这属于态度问题,这个人根本不合格应该直接被开除,没有中间地带可言。

另外要说的就是那些爱折腾的人,可能在初期会多犯一些小错误,但他绝对是有成为系统骨干的潜力,因为人就是在不断的犯错改进中成长起来的。再换个角度,我们也期望我们的系统是能做到防呆的,如果惩罚人,那么大家做事的时候会更加畏手畏脚,对于系统进化,特别是防呆能力的进化上,会变得非常缓慢。

 

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

“责” 即团队或个体管辖内应完成的事务,定责也分正反面。故障发生后我们一般分两类情况,定责和惩责:按事定责,对违规者惩责,两者的使用场景不一样。

我们公司内部故障复盘是由 OC 牵头,基于故障风险体系,针对每一个已发生故障进行的,主要流程如下:校准故障影响面、回放处理过程、剖析故障原因、明确解决方案和改造事项、故障反思及推演。

那么我把定责和惩责的关系,以及到事和到人的场景,贯穿在流程的主要节点中进行分析。

1)校准故障影响面,主要由 OC 结合故障期间的业务损耗和事后的部分用户舆情反馈做最后定量,另一方面,也是故障 “性价比” 的评判依据,如果影响面低,未触发法则,且发现了高价值的架构风险,那么该团队的定责改进分析中,可产出利于团队的好东西,所以说定责其实是正面的。

2)回放处理过程,其实就是为了把故障的干系人圈进来,分析是否在正确的时间做了正确的事情,给团队 / 人惩责,确保没有人违反 “高压线原则”,在我们公司比如单平面变更法则、红黄牌机制等,惩责说白了就是法律的法条,明知有法条而违反,就必须给出惩戒。

3)剖析故障原因,给团队定责,其实就是给事定责。重点在于给各团队切分好自己的责任田,比如 A 服务依赖的 B 服务实例 hang(B 服务由于所在主机硬件性能问题)产生故障,A 服务本身的隔离机制、B 服务在资源分配上的不够优化导致 hang,B 服务所在主机性能问题。这些就是各个团队需要解决自身的责任田。

4)明确解决方案和改造事项,给人定责,就是确定事情的牵头人。就如上面说到,无论直接还是间接,每个团队都有因素,需要确定责任人对自身的改造做跟踪闭环。

5)故障反思及推演,定责涉及方均需考虑自身管辖范围内,举一反三的提升措施。

 

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

故障定责属于管理问题而非技术问题,对事不对人,但对人该有的处罚也还是不可免除。

定责其实是个管理问题而非技术问题。定责以及事故定级本身并不可怕,可怕的是事故不管级别高低都跟人的绩效、晋升挂钩,那最终会导致大家相互指责,甩锅推诿。我相信只要低等级的事故不跟人的绩效与晋升挂钩,大家还是愿意坦诚相待的。B 站在事故定级、定责的标准页面里明确写明 “事故复盘要对事不对人” 的原则。如果在实际事故复盘过程中出现人指责人的行为,负责人或 Leader 应该将事故复盘的焦点引导回事故本身,包括原因分析、过程分析以及后续的改进优化上来。

对事不对人不代表对人没有处罚,针对不同情况有不同的处罚方式。大概分为三种情况:

  • 第一种明确是人的责任导致的事故,比如误操作导致了事故的发生,虽然不是有意为之,但为了引起团队的警醒,我们会有处罚的通告,一般不跟 kpi 绩效挂钩;
  • 第二种是事故定级不高但性质恶劣,或者非常典型,这种我们一般会在内部进行宣讲来引起大家的重视,也会走通知的机制;
  • 第三种就上升到公司层面产生舆情的事故,这一类已经不是技术体系定级能决定的,可能会直接与人和团队挂钩。

 

系统故障工程师居然可以不背锅?看看几家大厂是怎么做到的!(内附故障复盘模板)

只要不是人为地恶意地去制造系统的事故,就不要去指责这个人,需要考虑的是怎么来有效管控人为因素。

谷歌在故障定责这块提过一个范式,想做好故障定责有几个要素,一是要有数据,二是要有代码,三是要有文档流程以及程序,人的重要性是放到最低的。我认为当你把变更发布之类的工作以及人有可能犯错的地方,都通过代码或者数据实现强有效的管控,就能做到不让人为因素随意破坏系统的稳定性,也就表明系统稳定性建设的成熟度达到了较高水准。在稳定性建设领域越来越多企业都在往这个方向优化迭代,就像传统的汽车你一脚油门就直接冲出去了,容易出事故,而现在很多智能汽车、新能源汽车已经具备自动躲闪之类的功能,就能规避一些风险。

发表评论

相关文章