3. 事故响应台账的数据模型：必填字段、可选字段与状态机设计
事故响应台账是 GitOps 配置同步机制中记录每一次异常事件的“数据锚点”。一个严谨的数据模型决定了事故能否被快速定位、有效追溯和准确复盘。本章从字段约束和状态流转两个维度，定义台账的核心结构。
3.1 必填字段：事故记录的“骨架”
任何一条事故记录都必须包含以下三个字段，缺失任一字段的记录应被 GitOps 流水线拒绝入库：
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| occurred_at | ISO 8601 时间戳 | NOT NULL，精确到秒 | 事故首次被监控系统或人工确认的时间点，采用 UTC 时区。 |
| impact_scope | 枚举 + 文本 | NOT NULL，长度 1–200 字符 | 影响范围枚举值（SINGLE_SERVICE / MULTI_SERVICE / REGION / GLOBAL）及简要描述。 |
| assignee | 字符串 | NOT NULL，符合 LDAP 或邮箱格式 | 当前事故的第一责任人，通常是值班 SRE 或 On-Call 工程师。 |
实践建议：在 GitOps 仓库中，建议使用 YAML 或 JSON Schema 对必填字段做预校验。CI 阶段若发现
occurred_at 缺失或 impact_scope 不在枚举范围内，应直接阻断 PR 合并。
3.2 可选字段：事故分析的“血肉”
可选字段在事故创建时可以为空，但应在事故生命周期内逐步补充。以下两个字段是复盘和根因分析的核心输入：
- root_cause（文本，最大 2000 字符）：记录事故的根本原因，支持自由文本或引用内部知识库链接。建议使用“5 Whys”或“故障树”分析后填写。
- mitigation（文本，最大 2000 字符）：记录缓解措施的具体操作步骤，包括回滚版本号、配置变更的 Commit SHA、临时降级策略等。
字段演化规则：可选字段一旦填写即不可回退为空。GitOps 配置同步机制应通过 Webhook 或定时巡检，对超过 72 小时仍未填写
root_cause 的事故记录发出告警。
3.3 状态机设计：事故生命周期的“导航图”
事故台账的状态机定义了记录从创建到关闭的合法流转路径。每个状态变更都应在 GitOps 仓库中产生一次 Commit，确保变更历史可审计。
3.4 状态转换规则与 GitOps 约束
每个状态转换都对应 GitOps 仓库中的一次配置变更。下表列出了合法转换及其触发条件：
| 源状态 | 目标状态 | 触发条件 | GitOps 动作 |
|---|---|---|---|
| DETECTED | ACKNOWLEDGED | 值班人认领，assignee 字段非空 | PR 更新 assignee，自动合并 |
| ACKNOWLEDGED | MITIGATING | 开始执行缓解操作 | PR 更新 status，触发自动化 runbook |
| MITIGATING | RESOLVED | 缓解措施已确认生效，mitigation 字段非空 | PR 更新 status + mitigation，自动合并 |
| RESOLVED | CLOSED | 复盘完成，root_cause 字段非空 | PR 更新 status + root_cause，需人工审批 |
| 任意状态 | CANCELLED | 确认为误报或重复告警 | PR 更新 status + 取消原因，自动合并 |
避坑提示：禁止跳过 MITIGATING 直接从 ACKNOWLEDGED 跳转到 RESOLVED。即使事故瞬间自愈，也应在 MITIGATING 状态记录“自动恢复”作为缓解措施，保证台账完整性。
3.5 数据模型在 GitOps 仓库中的表示
以下是一个符合上述数据模型的事故记录 YAML 示例，存储在 incidents/2025/04/inc-20250401-001.yaml：
apiVersion: incident.sre/v1
kind: IncidentRecord
metadata:
name: inc-20250401-001
namespace: prod-east
spec:
occurred_at: "2025-04-01T14:23:00Z"
impact_scope: MULTI_SERVICE
impact_description: "支付网关超时，影响订单创建和退款接口"
assignee: "sre-oncall@company.com"
status: RESOLVED
root_cause: "数据库连接池耗尽，因上游服务突发流量未触发限流"
mitigation: |
1. 紧急扩容连接池从 50 到 200（Commit: a3f2c9e）
2. 临时关闭非核心批量查询路由
3. 触发限流规则，限制单客户端 QPS 至 500
resolved_at: "2025-04-01T14:58:00Z"
closed_at: "2025-04-02T10:00:00Z"
关键设计原则：事故台账的数据模型应保持“创建时宽松，关闭时严格”。必填字段在创建时强制，可选字段在状态推进过程中逐步补全，最终在 CLOSED 状态前完成所有必填和推荐字段的填写。这种渐进式数据完善机制与 GitOps 的渐进式交付理念高度一致。