云原生事故演练：没有演练的预案，只是文档

很多团队都有事故预案：服务不可用怎么办，数据库慢怎么办，模型服务超时怎么办。文档写得很完整，但从来没演练。真正出事时，权限找不到、命令不熟、告警没人认、回滚脚本没跑过。没有演练的预案，只是文档。

云原生系统组件多，AI 应用链路更长。事故演练不是制造麻烦，而是提前发现预案里的空洞。

一、演练要从真实故障假设开始

不要一上来设计夸张场景。先从真实可能发生的故障开始：Pod CrashLoop、模型网关超时、GPU 节点不可用、队列积压、配置错误。

flowchart TD
  A[故障假设] --> B[注入小范围故障]
  B --> C[观察告警]
  C --> D[执行预案]
  D --> E[恢复服务]
  E --> F[复盘缺口]

演练范围要可控。先在预发，再小流量生产演练。目标是发现问题，不是证明团队勇敢。

二、每次演练都要有退出条件

演练前要写清楚开始时间、影响范围、停止条件和负责人。比如错误率超过某个阈值立即停止，或者演练超过 30 分钟仍未恢复就回滚。

drill_plan:
  scenario: model_gateway_timeout
  scope: staging
  owner: platform_team
  success_criteria:
    - alert_fired_within_2m
    - fallback_enabled_within_5m
    - service_recovered_within_10m
  abort_if:
    - error_rate_above_5_percent

没有退出条件的演练，本身就是风险。

三、演练要检查人和工具

事故恢复不只是系统问题，也是协作问题。谁收到告警？谁有权限？谁能执行回滚？谁通知业务？这些都要在演练里走一遍。

很多问题只有演练才会暴露：值班同学没有集群权限，Dashboard 链接过期，Runbook 命令和当前版本不一致，回滚镜像已经被清理。

四、复盘要变成改动

演练结束不是开个会就完。每个缺口要变成 issue：补告警、改脚本、更新权限、修文档、加自动化。下一次演练要验证这些改动是否真的生效。

事故演练的价值，是让系统和团队都更诚实。它不会让故障消失，但能让故障来时少一点混乱。

演练指标也要量化。比如告警发现时间、定位时间、恢复时间、用户影响范围、是否触发错误升级路径。没有指标，演练容易变成一次“大家辛苦了”的会议。

drill_result:
  detect_time: 90s
  acknowledge_time: 3m
  mitigate_time: 7m
  full_recovery_time: 12m
  gaps:
    - runbook command outdated
    - fallback dashboard missing queue metric

AI 平台还要单独演练供应商故障和 GPU 节点故障。前者验证模型路由和降级，后者验证调度、容量和队列背压。不要只演练最舒服的服务重启。

演练频率不必太高，但要持续。每个月一个小场景，每季度一个跨组件场景，比一年一次大型演习更有用。基础设施的可靠性，是靠一次次小的诚实打磨出来的。

我也建议把演练结果和平台路线图连起来。某个故障反复暴露人工步骤太多，就该补自动化；某个告警总是没人理解，就该改指标和文案。演练不是额外工作，它本来就是基础设施迭代输入。

五、总结

云原生事故演练要从真实故障假设开始，控制范围，设置退出条件，检查人和工具，复盘后落实改动。

预案写在文档里只是第一步。跑过、修过、再跑过，它才真正能托底。