3. 台账数据结构设计：事故ID、时间戳、影响范围、严重等级、责任人、状态等字段定义

事故响应台账是SRE团队在Kubernetes环境下进行故障复盘、趋势分析和合规审计的核心数据载体。一个设计良好的台账数据结构，必须兼顾可追溯性、可查询性和自动化集成能力。本章将定义一套适用于Kubernetes事故场景的标准化字段模型，并给出对应的YAML配置示例。

3.1 核心字段定义与语义

下表列出了事故台账的必填字段和推荐字段，每个字段都对应Kubernetes原生资源或运维元数据，便于后续与集群事件、监控告警系统联动。

字段名 类型 必填 说明与Kubernetes映射
incidentId string (UUID) 是 全局唯一事故标识，建议使用UUID v4。对应Kubernetes Event的uid或自定义资源名称。
timestamp RFC3339 是 事故首次发现时间（UTC）。对应Prometheus Alert的startsAt或Kubernetes Event的lastTimestamp。
severity enum 是 严重等级：P0（灾难）、P1（严重）、P2（一般）、P3（轻微）。对应告警的severity标签。
scope string 是 影响范围描述，如“production/us-east-1/payment-service”。支持命名空间、集群、区域粒度。
status enum 是 当前状态：open、investigating、mitigating、resolved、closed。对应事故生命周期。
assignee string 是 当前责任人（SRE工程师用户名或邮箱）。对应Kubernetes RBAC中的用户或ServiceAccount。
title string 是 事故简要标题，如“支付服务Pod CrashLoopBackOff”。
description text 否 详细描述，包含故障现象、初步诊断结论。
affectedResources []string 否 受影响的Kubernetes资源列表，如[“Deployment/payment-v2”, “Service/payment-svc”]。
rootCause string 否 根因分析结论，通常在resolved后填写。
resolution text 否 解决措施与恢复步骤。
duration int (秒) 否 事故持续时长（从open到resolved）。用于计算MTTR。
tags map[string]string 否 自定义标签，如{“team”: “platform”, “region”: “us-east-1”}。
设计要点： 字段 scope 和 affectedResources 是Kubernetes环境特有的核心字段。通过它们可以快速定位事故影响的命名空间、Deployment、StatefulSet等资源，避免在复盘时手动翻查日志。

3.2 字段关系与事故生命周期

事故台账的字段并非静态存在，而是随着事故处理阶段动态演进的。下图展示了核心字段在事故生命周期中的变化关系。

事故台账字段生命周期 事故台账字段生命周期 1. 发现 2. 调查 3. 缓解 4. 解决 各阶段字段变化： • 发现阶段：incidentId、timestamp、severity、scope、status=open 必须立即写入。 • 调查阶段：assignee 更新为实际处理人，description 补充初步现象，status→investigating。 • 缓解阶段：affectedResources 记录受影响资源，status→mitigating，duration 开始计时。 • 解决阶段：rootCause、resolution 填写完整，status→resolved，duration 停止计时。 • 关闭阶段：status→closed，可附加 tags 用于复盘分类。

3.3 严重等级（Severity）分级标准

在Kubernetes环境中，严重等级直接决定了响应SLA和升级路径。建议采用P0~P3四级分类，并与告警路由、值班调度策略绑定。

等级 标签 定义标准 Kubernetes典型场景 响应SLA
P0 灾难 核心服务完全不可用，影响所有用户或造成数据丢失 etcd集群宕机、控制平面不可用、关键Deployment副本数归零 15分钟响应
P1 严重 主要功能受损，影响大量用户，但存在临时规避方案 Ingress控制器故障、数据库连接池耗尽、节点NotReady 30分钟响应
P2 一般 非核心功能异常，影响部分用户，业务可降级运行 Sidecar容器OOM、日志采集延迟、HPA扩缩容异常 2小时响应
P3 轻微 不影响用户，但需要跟踪修复的运维问题 镜像漏洞扫描告警、Pod Pending（资源不足）、证书即将过期 24小时响应
注意： 严重等级应在事故创建时由值班SRE初步判定，并在调查阶段根据实际影响范围进行升级或降级。严禁将P0事故降级为P2以规避SLA考核。

3.4 状态（Status）流转规则

状态字段是台账工作流的核心，必须严格遵循以下流转方向，避免状态回跳导致数据混乱。

  1. open：事故被创建，尚未分配责任人。系统自动生成incidentId和timestamp。
  2. investigating：责任人已确认，正在收集信息、分析根因。此时应更新assignee和description。
  3. mitigating：已找到临时缓解措施（如回滚、扩容、重启），正在执行。此时应记录affectedResources。
  4. resolved：服务已恢复，根因已定位，resolution字段填写完成。duration自动计算。
  5. closed：复盘完成，所有字段已归档，不可再修改。仅允许添加tags。
事故状态流转图 事故状态流转图 open investigating mitigating resolved closed 状态只能单向流转，不允许从 resolved 回退到 investigating

3.5 Kubernetes CRD 定义示例

将台账数据结构定义为Kubernetes自定义资源（CRD），可以实现事故记录的声明式管理，并直接通过 kubectl 进行增删改查。以下是一个完整的CRD YAML示例：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: incidents.sre.example.com
spec:
  group: sre.example.com
  names:
    kind: Incident
    plural: incidents
    singular: incident
    shortNames:
      - inc
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          required:
            - spec
          properties:
            spec:
              type: object
              required:
                - incidentId
                - timestamp
                - severity
                - scope
                - status
                - assignee
                - title
              properties:
                incidentId:
                  type: string
                  description: "全局唯一事故ID (UUID v4)"
                timestamp:
                  type: string
                  format: date-time
                  description: "事故发现时间 (RFC3339)"
                severity:
                  type: string
                  enum: ["P0", "P1", "P2", "P3"]
                  description: "严重等级"
                scope:
                  type: string
                  description: "影响范围，如 cluster/namespace/service"
                status:
                  type: string
                  enum: ["open", "investigating", "mitigating", "resolved", "closed"]
                  description: "事故状态"
                assignee:
                  type: string
                  description: "责任人邮箱或用户名"
                title:
                  type: string
                  maxLength: 200
                  description: "事故标题"
                description:
                  type: string
                  description: "详细描述"
                affectedResources:
                  type: array
                  items:
                    type: string
                  description: "受影响的Kubernetes资源列表"
                rootCause:
                  type: string
                  description: "根因"
                resolution:
                  type: string
                  description: "解决措施"
                duration:
                  type: integer
                  description: "持续时长（秒）"
                tags:
                  type: object
                  additionalProperties:
                    type: string
                  description: "自定义标签"
实战建议： 将CRD部署到集群后，可以使用 kubectl create incident 创建事故记录，配合 kubectl get incidents 查看台账列表。结合Kubernetes Event和Prometheus Alertmanager的Webhook，可以实现事故台账的自动创建和状态更新。

3.6 字段校验与自动化集成

为了保障数据质量，建议在CRD的 openAPIV3Schema 中配置字段校验规则，并在Controller中实现自动化状态机。以下是一些关键的校验策略：

  • incidentId：使用 pattern: "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$" 强制UUID格式。
  • timestamp：设置 format: date-time，确保时间字符串符合RFC3339标准。
  • severity：使用 enum 限制取值范围，避免非法等级。
  • status：在Controller中实现状态机，拒绝非法状态转换（如从resolved直接跳回open）。
  • assignee：建议与LDAP或GitHub账号联动，确保责任人可追溯。
← 上一章 📖 返回目录 下一章 →