#一分钟精华速览#
系统故障无法避免，事故发生的原因多种多样，故障定责不是为了指责而是为了后续的优化改进，可很多企业在定责时难免遇到团队、个人之间推卸责任的情况，定责定的到底是什么“责”？
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绩效挂钩；
第二种是事故定级不高但性质恶劣，或者非常典型，这种我们一般会在内部进行宣讲来引起大家的重视，也会走通知的机制；
第三种就上升到公司层面产生舆情的事故，这一类已经不是技术体系定级能决定的，可能会直接与人和团队挂钩。
只要不是人为地恶意地去制造系统的事故，就不要去指责这个人，需要考虑的是怎么来有效管控人为因素。
谷歌在故障定责这块提过一个范式，想做好故障定责有几个要素，一是要有数据，二是要有代码，三是要有文档流程以及程序，人的重要性是放到最低的。我认为当你把变更发布之类的工作以及人有可能犯错的地方，都通过代码或者数据实现强有效的管控，就能做到不让人为因素随意破坏系统的稳定性，也就表明系统稳定性建设的成熟度达到了较高水准。在稳定性建设领域越来越多企业都在往这个方向优化迭代，就像传统的汽车你一脚油门就直接冲出去了，容易出事故，而现在很多智能汽车、新能源汽车已经具备自动躲闪之类的功能，就能规避一些风险。