原文[1]：Michael Hart[2] - 2023.09.11
无责文化的概念在其他行业由来已久，虽然具体的历史不详，但可以说，自从 2016 年出版了权威著作《SRE : Google 运维解密》[3] 后，无责文化“正式”成为科技行业的一部分。
我对“无责文化”的总结是：当服务出现故障、事故或漏洞时，假定相关人员的初衷是好的，但要么他们没有获得正确的信息来做出更好的决定，要么工具让他们犯了错。
在 Arctic Wolf 公司[4] 任职期间，我接受并宣传无责文化，并将其带入组织的每一个角落，当然也包括事后分析流程。这种文化自然而然地发展，并在某些情况下朝着我意想不到的方向发展。在阐述我对“无责”的定义之前，我想先分享一个自己的故事，虽然有点尴尬，但却勾勒出了我的心路历程。
曾几何时，我年轻气盛，是一家大型制造公司的 Unix 系统管理员。有一次，我接到夜间电话，说在进行建筑物消防系统维护时，数据中心的电源被切断，制造工厂立即停工，损失惨重。在随后召开的根因会议（当时行业内还没有使用现代的事后分析语言）一开始，我就脱口而出，大意是这次会议完全是浪费时间，因为我们知道是消防部门切断了电源。场面一度很尴尬，而我发现坐在我旁边的那位先生正是消防队长。他完全有权利对我的责备表示愤怒，但他却静静地解释了确定根因的过程，而没有指责我。事实证明，我的看法大错特错，原因就像经常发生的那样，是一连串的故障和意想不到的行为，没有人能预料到最终的结果。
那段经历让我记忆犹新，主要是因为那是一个令人尴尬的时刻，但却给我上了几堂重要的课，这需要一些时间来消化。那个时刻清楚地展示了如何归咎于人，而不是“无责”。更重要的原因是，消防队长为我树立了一个非常好的领导榜样，一位资深领导者利用这个机会指导一名新员工度过了一个可能很糟糕的局面。他很可能不知道他对我的职业生涯产生了多大的影响，但我非常感谢他那天的耐心指导。
我最喜欢的无责行为公开范例是 2017 年 2 月 28 日 AWS S3 在 us-east-1 区域的宕机，导致互联网大面积瘫痪。AWS 在公开的事后分析报告[5]中写道：“一名授权的 S3 团队成员使用既定的操作手册”...进行了一些维护，该团队成员无意中引入了一个拼写错误，导致了故障。AWS 的回应本可以是“某员工犯了错，我们解雇了他”，但相反，我对该回应的简要总结是：该工具没有足够的防护措施，服务恢复速度不够快。AWS 通过建立更多的防护措施来解决这一问题，并对服务恢复时间进行了改进。
无责文化朝着一个意想不到的方向发展，事后我对此感到高兴，那就是不点名批评超出团队范围的个人。这可能导致高层领导（他们可能并不完全理解无责文化）产生一种误解，认为他们的团队没有对自己的工作负责。小团队中才华横溢的开发人员通常会很快指出自己的错误，但我坚持认为，当有人指出自己的错误时，不要停止事后总结，而是要继续研究如何改进工具和信息。个人的名字在事后分析中并不重要，但向公司领导传达改进系统所需的步骤才是最关键的。
在承担问题责任与不点名之间找到平衡是很困难的，但随着组织的发展，这一点变得越来越重要。虽然我期望团队在事后分析或私下承认任何错误、拼写问题、预设等，但他们的名字不应出现在发布给更广泛组织的任何文档中。去掉名字会给团队成员带来心理上的安全感，防止领导层或其他人归咎于个人并采取行动。我见过领导者在看到名字后立刻采取报复行动，比如解雇，但也见过领导者延迟行动，影响日后的补偿或晋升决定。在我的理想世界里，是整个团队及其相应的领导对事件负责。
在对无责文化的定义中，我“假定......是出于好意”。但我一直明确告知团队，有一个不成文的例外条款：如果事故/宕机/漏洞是由于蓄意行为引起，或者由于错误引起但随后被掩盖，会立即产生后果，很可能导致相关人员需要另谋高就。蓄意行为造成损害很容易理解，而且很可能会涉及到执法部门，但掩盖错误则值得更多关注。我有两个例子，一个是负面的，一个是正面的：
我曾参与一个响应团队，当时有一个人犯了错误，然后试图掩盖痕迹。这导致了长达 48 小时的重大宕机，随后不久该人被解雇。组织领导层明确表示，此人被解雇的原因不是因为犯错，而是因为试图掩盖错误。在我做系统管理员的时候，一位同事不小心删除了一个生产数据库。他立即停下操作并说：“大家，我刚刚搞砸了，需要帮助。”我们立即团结起来，想出了解决方案，避免了一次昂贵的宕机。这位同事本可以掩盖错误，而我们可能永远不会发现数据库为什么消失，但因为我们有无责文化和出色的团队，该同事有“心理安全线”，能够立即请求帮助。在我职业生涯的早期，一位领导告诉我，“如果你偶尔不弄坏点东西，说明你工作还不够努力。”任何运行生产服务的人每天都在经历这种情况，知道犯错会导致宕机的风险。当犯错时，最好的办法就是立即上报给团队和领导，请求帮助补救问题。在 Arctic Wolf 公司，我们有一个文化信条：“快速报告坏消息”，我们将其应用于项目和事件中，这对公司的成功贡献巨大。无论是生产中出现的问题，还是即将到来的会导致数月返工的容量规划阈值，抑或是在项目中发现的会严重延迟交付的问题，团队成员都会因为快速提出坏消息而受到奖励和表扬。
无责文化不能仅仅保留在事后分析中，它需要在日常生活中贯彻和推广。CircleCI 公司[6] 的 Rob Zuber[7] 在 《无责文化的价值》[8] 中很好地总结了这一点：“事件是我们检查无责文化的显微镜”，以及“……在事件响应中表现出来的文化，将直接反映出你在最平常的环境下，通过每一天、每一个行动建立起来的文化”。
建立无责文化是一个复杂的话题，但非常值得投入大量时间，因为它将带来一个健康且高效的组织。
参考资料[1]原文: https://www.gybe.ca/a-few-words-about-blameless-culture/[2]Michael Hart: https://www.gybe.ca/about/[3]《SRE : Google运维解密》: https://sre.google/workbook/table-of-contents/[4]Arctic Wolf 公司: http://www.arcticwolf.com/[5]公开的事后分析报告: https://aws.amazon.com/message/41926/[6]CircleCI 公司: https://circleci.com/[7]Rob Zuber: https://www.linkedin.com/in/robzuber/[8]《无责文化的价值》: https://circleci.com/blog/value-of-blameless-culture/
