凌晨 2 点 10 分，警报响起。一名工程师推送了一项配置更改，检出服务开始返回错误，值班主管在 40 分钟后将其回滚。在审查会议上，第一个问题是“是谁推送的更改？”几分钟之内，讨论就变成了某人在凌晨 02 点的判断，没有人追问为什么这项更改在没有进行早期测试的情况下就上线了，为什么警报过了这么久才发出，或者为什么运行手册已经过时。
这是一个示例场景，并非客户案例。之所以容易理解，是因为这种情况确实存在：如果事件回顾只关注最后采取行动的人，最终只会得到一个看似合理的解释，却几乎无法从中吸取任何教训。
本指南面向工程经理和赋能负责人，旨在帮助他们提升分析事故证据和制定可测试改进方案的能力。内容涵盖如何区分技能差距及其所处环境、如何设计实践、如何进行事后总结以及如何衡量评估的有效性。
“无辜”究竟意味着什么，又不意味着什么。
谷歌的《网站可靠性工程》一书明确指出：要真正做到事后分析不追究责任，就必须专注于找出事件的促成原因，而不指责任何个人或团队存在不良或不当行为。书中还阐述了其背后的假设：所有相关人员都出于善意，并根据他们掌握的信息做出了正确的决定。Google SRE 书籍，《事后文化：从失败中学习》.)
无责并不意味着免责。同一章节要求事后分析最终形成行动方案，并明确优先级和负责人。无责调查仍然需要追究责任，但责任的焦点从“谁造成了这件事”转移到“谁将负责使系统更安全，以及何时完成”。如果你的审查忽略了后半部分，那只会是一场愉快的对话，而不是一个学习的过程。
1. 识别行为及其背景
首先要明确你想改变的具体行为。“我们的事故审查只关注最后采取行动的人”是可以观察到的，而“我们的文化过于注重追究责任”则不是。
然后问问自己，这是否真的是技能问题。训练只能解决部分表现不佳的原因。在着手任何工作之前，请先区分以下三种可能性：
- 一项缺失的技能。 审阅者不知道如何构建时间线，区分触发因素和促成因素，或者问“是什么让当时的这一行为看起来合理？”
- 激励。 评论会影响绩效讨论，因此人们会调整自己的言论以保护自己。
- 权威梯度和过往反应。 上个季度提出问题却被告知不要消极的初级工程师，即使训练有素，也不会在这次会议上提出任何问题。
只有第一个问题是培训问题，其他两个问题是环境因素。如果你只培训技能而不改变环境因素，人们就会练习一些在工作场所会受到惩罚的行为。把你目前对原因的看法当作一个假设，在正式启动项目之前，先和工程师们聊聊，看看最近的评估文件，验证一下你的假设。
2. 设定练习的操作条件
只有当工作场所能够应对时，练习才能发挥作用。在任何人进行排练之前，请与负责考核的人员达成以下共识：
- 已批准的职责。 谁负责协调，谁负责制定时间表，谁负责后续行动？明确角色分工，以免协调人擅自行使职权。
- 领导者如何看待民众的诉求。 如果工程师说“部署工具让我跳过了金丝雀测试阶段”，主管接下来该怎么做？事先决定好答案，例如：感谢工程师，将此记录为促成因素，并指派一项行动。
- 主管的回应。 员工演练需要主管做出相应的回应。如果你培训工程师在绩效评估中积极发言，但他们的经理仍然问“这是谁的错？”，那么培训就失去了意义。
对管理人员进行关于绩效考核流程的简短介绍，与对参与者进行培训同等重要。应明确说明绩效考核文件在绩效管理中的用途（包括哪些用途以及不适用哪些用途）。
3. 设计基于行为的学习之旅
卡内基梅隆大学埃伯利中心关于学习目标的指导意见指出，目标、评估和教学策略应该彼此一致，这一点很有价值（埃伯利中心，学习目标）这是设计指导，而不是关于任何特定工具或结果的证据，但它是对该方案的一个很好的检验：如果目标是分析证据并达成可检验的改进方案，那么仅凭回忆问题无法进行评估。
布鲁姆分类法在这里很有用，它可以用来描述任务的认知需求：分析、评估、创造。它描述了任务对人的要求，但并没有解释人们为什么会做或不做，所以不要用它来诊断动机。
一个可行的旅程分为三个阶段。
| 阶段 | 学习者行动 | Delivery |
|---|---|---|
| 准备 | 请阅读您的事件审查政策和简短术语表（触发因素、促成因素、缓解措施、行动项目）。简要诊断检查是必要的前提条件。 | 自主学习。复习检查仅确认先决条件，不复习技能。 |
| 练习 | 分析一份已准备好的事故案例，并商定可测试的改进方案。需要给出有理有据的答复，而不是简单的多项选择题。 | 互动式或引导式案例练习，并对影响因素分析的质量和后续行动提供反馈。 |
| 审核和转移 | 讨论一个模棱两可的选择，然后完成一个新的案例或在监督下进行一次真实的复习。 | 实时辅导或异步复习。在人们有时间将技能运用到工作中之后，检查其应用效果。 |
案例要贴近实际，并请一位经验丰富的工程师进行验证。如果案例在技术上存在错误，会让审阅者对练习结果产生怀疑。
4. 演练情景并进行总结汇报
以下是使用 02:10 场景进行练习的示例。证据包包含部署日志、告警时间线、分页策略、拉取请求和运行手册，所有内容均为虚构。
提示参与者。 “请解释工程师当时为何力推这项变更。请列举你所依据的证据。并告诉我们，在你确信之前，你还需要哪些信息或支持。”
一个站不住脚的回应是这样的：“工程师应该检查一下舞台搭建情况。”它只提到了一个人的名字，没有提供任何依据，也没有提出任何改进建议。
更强有力的回应应该是这样的：“部署日志显示，由于工具中金丝雀部署步骤是可选的，因此变更直接发布了。该拉取请求有一位审核员，他在 20 分钟的审核窗口期后批准了该变更。页面在错误出现 18 分钟后才加载，因为警报阈值设置为 5 分钟平均值。我想知道本月还有多少其他变更跳过了金丝雀部署，以及值班工程师是否被告知过该步骤可以跳过。建议措施：强制此服务层级执行金丝雀部署，负责人：平台团队，检查：在预发布环境中尝试跳过金丝雀部署并确认其被阻止；缩短警报窗口期，负责人：值班主管，检查：根据新的阈值重新重放上周的错误。”
注意它的优势所在。它运用证据，指出限制因素和不确定性，并最终提出可检验的行动方案。
现在进行总结汇报。不要只打分，还要问：
- 证据支持什么？你的假设是什么？
- 团队实际有权采取哪些行动？
- 在下次正式评估中，什么因素会让你更容易重复这种行为？什么因素会让你更难重复这种行为？
第三个问题最为重要。它揭示了第二部分中提到的条件。如果三位参与者都说“我的经理会问是谁干的”，那么你就发现了一个培训无法消除的限制因素。
5. 衡量行为和后续行动
关键问题在于，如何证明学习者能够分析事故证据并达成可验证的改进方案。以下是一个可供参考的评估标准。这只是一个建议，需要与经验丰富的工程师共同调整，并非经过验证的准备标准。
| 标准 | 可观察的证据 | 0 | 1 | 2 |
|---|---|---|---|---|
| 任务执行 | 分析证据并商定改进方案；记录所采取的行动及其背后的证据。 | 缺失或未得到支持 | 部分，但有相关遗漏 | 完整且符合既定标准 |
| 推理 | 解释了限制条件、替代方案和不确定性；影响因素不仅限于最后一步行动。 | 缺失或未得到支持 | 部分，但有相关遗漏 | 完整且合理 |
| 边界 | 使用经批准的程序；当信息或权限不足时寻求帮助 | 缺失或未得到支持 | 部分，但有相关遗漏 | 完整且合理 |
应单独定义关键错误，例如，明确指出某个人是错误原因，或者提出一项没有负责人的行动。高总分绝不能掩盖关键失误。
就测量本身而言：
- 影响因素分析的质量。 将项目实施前后的评论进行比较，并由一位不知晓具体情况的人员，按照相同的评分标准进行评分。使用未公开的后续案例以及真实案例。
- 跟进。 计算所有已提出的行动项中，已指定负责人、已测试且已完成的行动项所占的比例。说明分母和时间范围。
- 将观察与过程变化相结合。 认真参与一次真正的评审。之后检查一下各项行动事项的落实情况。
报告数量需谨慎。如果项目结束后记录的事故和险情数量增加，可能意味着安全状况改善、信任度提高，或者新的工具简化了记录流程。跌倒事件的发生也可能意味着问题减少或人们不愿透露信息。在将任何变化归因于培训之前，请先查看同期发生的具体情况，并避免声称存在未经测量的效果。
以上埃伯利指南阐述了如何进行协调一致，但并不能证明这种方法可以减少事故发生。请保留您自己的基线数据和后续数据，并将其视为本地证据。
即使技能提高后，哪些限制因素可能仍然存在？
对赞助商要坦诚相告：
- 审核文件仍可能作为绩效决策的参考依据。
- 面临交付压力的团队可能会忽略一些代价高昂但明智的做法。
- 跨队行动可能会停滞不前，因为没有人拥有边界的控制权。
- 资深工程师可能仍然主导讨论。
更完善的分析并不能消除这些问题。需要针对这些问题制定单独的流程变更计划。
将其应用于 AhaSlides
AhaSlides 支持自适应学习、交互式学习，并可在直播和自主学习之间灵活切换。在此过程中，可能包括自主学习的准备步骤、包含开放式问答提示的直播或引导式案例分析环节（确保每位参与者在小组讨论前完成分析），以及会后的后续任务。具体的创作、评分和报告功能应在使用前通过演示验证，并与您自己的案例进行比对。任何涉及人工智能、模拟器或与您的事件管理工具集成的功能，在演示之前都应视为外部功能。
下一步： 请参考以上标准，并与一位资深工程师共同进行调整，然后构建您将要使用的案例。如果您想了解这种实时、自主学习的学习方式， 预约 AhaSlides 工作流程演示 一旦你拟定了案例和评分标准。
