1. 事故响应台账概述
1.1 定义事故响应台账
事故响应台账（Incident Response Ledger）是一份结构化的、不可篡改的数字化记录，用于捕获从事故发现、响应、诊断、修复到复盘的全生命周期数据。在SRE实践中，台账不仅是“日志”，更是驱动系统可靠性改进的核心数据资产。
核心定义：事故响应台账 = 结构化事故记录 + 时间线 + 动作追踪 + 根因分析 + 改进项闭环跟踪。
一份标准的事故台账条目通常包含以下字段：
| 字段类别 | 字段示例 | 说明 |
|---|---|---|
| 标识信息 | INC-2025-00123 | 全局唯一事故编号，按年份+序号自动生成 |
| 时间线 | 检测时间、确认时间、恢复时间 | 精确到秒，用于计算MTTD/MTTR |
| 影响范围 | 受影响服务、用户百分比、错误率 | 量化事故严重等级（S1~S4） |
| 响应动作 | 回滚版本、扩容实例、切换流量 | 按时间顺序记录每步操作及执行人 |
| 根因分析 | 5Whys结论、故障类型 | 区分代码缺陷、配置错误、基础设施故障 |
| 改进项 | Action-001: 增加配置校验 | 关联GitOps仓库PR，跟踪闭环状态 |
1.2 台账在SRE中的核心价值
事故响应台账是SRE三大核心支柱——服务等级目标（SLO）、错误预算、事后复盘（Postmortem）——之间的数据桥梁。没有台账，SRE团队将失去量化改进的依据。
- 量化可靠性指标：台账提供MTTD（平均检测时间）、MTTR（平均恢复时间）的原始数据，直接支撑SLO计算与错误预算消耗分析。
- 消除重复事故：通过根因分类，识别高频故障模式，驱动永久性修复，避免“救火循环”。
- 审计与合规：完整的事故记录满足SOC2、ISO 27001等合规审计要求，证明团队具备规范的事故管理流程。
- 团队学习与知识沉淀：台账是组织级的事故知识库，新成员可通过历史台账快速了解系统脆弱点与应对策略。
- 改进项跟踪：每条台账关联明确的Action，从“发现问题”到“解决问题”形成闭环，防止改进项石沉大海。
SRE黄金信号与台账的映射：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）——每次事故台账都应记录这四个维度的异常值，便于后续趋势分析。
1.3 台账与GitOps的关系
GitOps是一种以Git仓库作为单一事实来源（Single Source of Truth）的运维模式。事故响应台账与GitOps的结合，本质上是将事故驱动的配置变更纳入版本控制与自动化同步轨道。
两者的关系可以从三个层面理解：
| 层面 | 台账角色 | GitOps角色 | 协同价值 |
|---|---|---|---|
| 配置变更溯源 | 记录事故根因（如配置错误） | 保存每次配置变更的Git提交历史 | 通过台账ID关联Git commit，快速定位引入缺陷的变更 |
| 改进项自动化 | 生成Action：修改配置、增加校验 | 通过PR/MR提交配置修改，自动触发同步 | 台账Action直接链接到GitOps仓库PR，实现“记录即变更” |
| 回滚决策支持 | 记录回滚时间点与影响范围 | 提供一键回滚到上一个已知良好版本的能力 | 台账中的回滚操作可精确对应GitOps的Revert commit |
常见误区：台账与GitOps的集成不是简单的“在台账里贴一个Git链接”。真正的集成要求：台账中的每个Action都必须对应一个可追溯的GitOps PR，且PR的合并状态应自动更新台账中的改进项状态。否则，改进项仍然可能被遗漏。