自动产生的事故回应手册

每个工程团队都有相同的事故后续仪式。事故发生了。有人在 Slack 上快速写了一份摘要。另一个人承诺更新手册。排定了事后检讨会议。两周后,手册仍然没有更新,事后检讨文件只完成一半,下次同样的事故再次发生时,值班工程师又得从头开始摸索。

问题不在于懒惰。而是在压力大的事故之后撰写文件是最后一件大家想做的事,而且还得跟下一个 sprint 的功能开发竞争时间。文件债不断累积,直到手册过时到没有人相信它们。

事故回应工作流程

Engineering 入门包包含一个名为 Incident Response 的工作流程。它接收原始事故资料——时间轴、症状、采取的行动、根本原因——并一次产生三个输出。

1. 事故报告 — 结构化的事故后报告,包含:事故摘要、事件时间轴、影响评估(受影响使用者、持续时间、严重程度)、根本原因分析、促成因素,以及立即采取的行动。格式在所有事故中保持一致,这使得跨月份的报告可以进行模式识别。

2. 手册更新 — AI 接收事故细节并产生相关手册的新增内容或更新。如果事故揭露了新的故障模式,它会撰写侦测步骤、诊断指令和补救程序。如果是已知的故障模式但有新的变化,它会更新现有章节。输出是结构化的手册就绪内容,而不是叙述性摘要。

3. 工程主管审查(核准关卡) — 在发布任何内容之前,工作流程会暂停以供审查。工程主管验证时间轴的准确性,确认根本原因分析,并核准手册的新增内容。这个关卡至关重要——AI 产生的手册需要当时在场的人来确认程序是否正确。

4. 事后检讨产生 — 核准后,AI 产生完整的事后检讨文件:发生了什么、为什么发生、什么阻碍了更快的解决,以及防止再次发生的行动项目。每个行动项目都有建议的负责人和优先顺序。

为什么事故文件的一致性很重要

当事故报告使用不同的格式时,你无法比较它们。除非每份报告都使用相同的严重程度等级和分类,否则你无法询问「本季有多少 P1 事故是由资料库问题引起的?」。除非每份报告都包含相同的时间栏位,否则你无法追踪补救时间是否有所改善。

Incident Report recipe 强制执行一致的架构。每份报告都有相同的章节、相同的严重程度类别、相同的时间栏位。随着时间推移,这成为一个你可以查询的结构化资料集,而不只是一个文件资料夹。

工程师仍需做的事

工作流程需要准确的输入。工程师提供:

• 发生了什么 — 事件时间轴、观察到的症状、触发的警报
• 他们做了什么 — 采取的诊断步骤、执行的指令、应用的修复
• 什么造成的 — 根本原因和促成因素

AI 不调查事故——它记录事故。调查、除错、修复——这是工程师的专业。AI 的工作是将该专业知识转化为结构良好的文件,让下一位值班工程师实际可以使用。

手册更新在这里特别有价值。一位刚花了两个小时除错生产问题的工程师确切知道下次要遵循哪些步骤。通常这些知识会留在他们的脑海中或 Slack 对话串中。工作流程将其捕捉在手册章节中,包含具体指令和决策点。

Feature Launch 工作流程

Engineering 套件还包含一个 Feature Launch 工作流程,处理另一个文件缺口:发布沟通。

1. 从 commit 历史和 PR 描述撰写变更日志条目
2. 产生适当详细程度的面向使用者发布说明
3. 如果 endpoint 有变更,更新 API 文件
4. 将所有内容打包以供审查

而 Sprint Cycle 工作流程自动化规划和回顾文件:从待办事项产生 sprint 目标,为新功能建立文件计划,并将回顾笔记结构化为可执行的改进。

完整的 Engineering 套件

Engineering 入门包在 Incident Response 之外还包含两个额外的工作流程:

• Feature Launch — 一次完成发布说明、变更日志和文件更新
• Sprint Cycle — 规划、文件和回顾自动化

独立的 recipe——技术规格撰写器、API 文件产生器、程式码审查回馈、架构决策记录——可以单独运作,或作为自订工程工作流程的构建模组。