共计 2688 个字符，预计需要花费 7 分钟才能阅读完成。
# 一分钟精髓速览 #
系统故障无奈防止，事变产生的起因多种多样，故障定责不是为了指摘而是为了后续的优化改良，可很多企业在定责时不免遇到团队、集体之间推卸责任的状况，定责定的到底是什么“责”？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 绩效挂钩；第二种是事变定级不高但性质顽劣，或者十分典型，这种咱们个别会在外部进行宣讲来引起大家的器重，也会走告诉的机制；第三种就回升到公司层面产生舆情的事变，这一类曾经不是技术体系定级能决定的，可能会间接与人和团队挂钩。
只有不是人为地歹意地去制作零碎的事变，就不要去指摘这个人，须要思考的是怎么来无效管控人为因素。
谷歌在故障定责这块提过一个范式，想做好故障定责有几个因素，一是要有数据，二是要有代码，三是要有文档流程以及程序，人的重要性是放到最低的。我认为当你把变更公布之类的工作以及人有可能犯错的中央，都通过代码或者数据实现强无效的管控，就能做到不让人为因素随便毁坏零碎的稳定性，也就表明零碎稳定性建设的成熟度达到了较高水准。在稳定性建设畛域越来越多企业都在往这个方向优化迭代，就像传统的汽车你一脚油门就间接冲出去了，容易出事变，而当初很多智能汽车、新能源汽车曾经具备主动躲闪之类的性能，就能躲避一些危险。
收费【故障复盘模板】支付
