1. 课程导论：事故响应台账的定义、重要性、在 Kubernetes 环境下的特殊挑战
1.1 什么是事故响应台账？
事故响应台账（Incident Response Log）是一份按时间顺序记录的事故全生命周期档案。它不仅是故障排查的“黑匣子”，更是团队复盘、流程改进和合规审计的核心依据。在 Kubernetes 环境中，台账需要记录从告警触发、诊断分析、恢复操作到事后复盘的全部上下文。
| 台账要素 | 说明 | K8s 环境示例 |
|---|---|---|
| 时间戳 | 每个操作步骤的精确时间（UTC + 时区） | 2025-03-21T14:32:17Z Pod CrashLoopBackOff |
| 告警源 | 触发事故的监控或告警系统 | Prometheus Alertmanager / Grafana |
| 影响范围 | 受影响的命名空间、服务、用户 | production/checkout-service, 30% 5xx |
| 诊断动作 | 执行过的 kubectl 命令、日志查看、调试步骤 | kubectl describe pod, kubectl logs --previous |
| 恢复操作 | 回滚、扩缩容、重启、配置变更等 | kubectl rollout undo deployment |
| 负责人 | 事故指挥官（IC）与各角色 | @sre-oncall-1, @dev-backend |
1.2 为什么事故响应台账至关重要？
- 缩短 MTTR（平均修复时间）：历史台账提供相似故障的快速参考，避免重复排查。
- 合规与审计：金融、医疗等行业要求保留事故记录，台账是 SLO 违约和 RCA 的原始证据。
- 知识沉淀：将隐性经验转化为显性文档，新人可快速上手。
- 流程改进：通过台账识别模式——是配置错误频发？还是扩容策略失效？
关键指标：成熟的事故响应团队，其台账完整率应 ≥ 95%，且事故复盘后 48 小时内完成台账归档。
1.3 Kubernetes 环境下的特殊挑战
Kubernetes 的动态性、分布式和声明式特性，给事故台账带来了传统虚拟机时代不存在的挑战：
- 瞬态 Pod 与日志丢失：Pod 重启或驱逐后，
kubectl logs --previous只能保留最近一次崩溃的日志，更早的上下文丢失。 - 控制平面 vs 数据平面分离：etcd、API Server、Scheduler 等组件故障与业务 Pod 故障的排查路径完全不同，台账需要区分层级。
- 声明式状态漂移：Deployment 的 replicas 被 HPA 自动修改、ConfigMap 被更新、Operator 自动调谐——这些“静默变更”难以追溯。
- 多集群与网格拓扑：跨集群流量、Service Mesh 的 sidecar 注入、Ingress 路由规则，故障域可能跨越多个集群。
- 审计日志量巨大：K8s 审计日志每秒可能产生数千条事件，从中筛选出事故根因如同大海捞针。
常见陷阱：很多团队在 K8s 事故后只记录了“重启 Pod 恢复”，却遗漏了 HPA 触发条件、节点资源水位、调度器日志等关键上下文，导致复盘时无法定位根因。
1.4 事故响应台账在 K8s 中的核心流程
下图展示了从告警触发到台账归档的完整闭环，以及每个阶段在 Kubernetes 环境下的关键动作：
1.5 本课程将如何帮助你？
本课程将带你从零搭建一套生产可用的 事故响应台账系统，完全运行在 Kubernetes 之上。你将学到：
- 如何设计台账的数据模型，兼容 K8s 事件、Pod 日志、审计日志等多源数据。
- 如何用 Kubernetes 原生资源（ConfigMap、Secret、Deployment）部署台账后端服务。
- 如何对接 Prometheus Alertmanager 实现告警自动触发台账创建。
- 如何通过 kubectl 插件和 Operator 模式简化台账录入流程。
- 如何利用 K8s 审计日志自动填充事故上下文。
学习前提：建议你具备基本的 Kubernetes 操作经验（熟悉 kubectl、Pod、Deployment、Service 等核心资源），了解 Prometheus 监控基础。无需提前掌握台账系统知识。