服务器日常系统开发与维护 SOP

发布/回滚 · 配置变更 · 日常巡检 · 值班响应 · 故障演练 · 变更评审 · 告警闭环——把发布策略、可观测性、容器运行时三块能力落到一张值班表里。

场景问题

游戏区服要 7×24 稳定跑，"日常维护"不是"没事就好"，而是一整套值班动作：

• 发版永远不空档：赛季更新、活动上线、hotfix 全挤在一起。上一次滚更是 3 小时前，下一次可能就在 20 分钟后。发出去、发不回、发一半都是常态。
• 配置比代码变得更勤：新活动的开关、限流阈值、副本 buff 系数一天调好几次。配置变更没走灰度出事，回滚要比代码回滚更难（老版本不认新字段）。
• 告警不是"看红点"：凌晨三点手机响，你要 5 分钟内判定"这是重大故障还是抖动"，10 分钟内决定"止损还是继续排查"，30 分钟内出稳定结论。
• 演练是必须：从来没演练过的恢复流程，真出事时几乎必然踩坑（详见 stateful-recovery 的"必须定期演练"警告）。

发布、变更、告警不是彼此独立的操作，它们共同组成"日常 SOP"。这份 SOP 决定值班的人在事故来临前先做过多少次演练、事故来临时能不能按流程动作、事故过后能不能沉淀经验。

实现方案

七件套 SOP 全景

每件套按同一张卡片写清：入口条件 / 动作清单 / 成功指标 / 失败动作。

① 发布 / 回滚

② 配置变更

配置变更三板斧：评审 / 灰度 / 回滚点——三样缺一，事故必到。

③ 日常巡检

分三级：每日 / 每周 / 每月。清单不长，但必须每次都走完：

④ 值班响应

告警 → 值班 → 处置的四段式：

告警分级（对齐值班响应时限）：

⑤ 故障演练

Chaos 演练类型清单，按爆炸半径从小到大：

演练前签发 + 止损策略：每次演练要有 announce → kick-off → observe → abort-condition → close-out 五步；abort-condition 命中立刻结束演练，不硬扛。

⑥ 变更评审

每一次变更（代码、配置、依赖、拓扑）走 CAB（Change Advisory Board）三步：

1. 发起方自评：变更范围、影响面、回滚方案、灰度批次
2. 同侪评审：架构点 / SRE / 值班三方 review
3. 值班确认：值班日历不冲突（避免与大版本、赛季、大活动同期）

免审白名单要极窄：紧急 hotfix（P0/P1 事故下）+ 已模板化的配置项（比如某类活动的开关）。其余一律入审。

⑦ 告警闭环

告警设计三原则（对齐 observability）：

1. 可行动：每条告警必须对应一个明确动作。"P99 > 200ms" 不可行动；"P99 > 200ms 持续 5 分钟" + "预案：先看下游依赖，再看容量" 才可行动。
2. 可分类：每条告警必须打 severity 标签（P0/P1/P2/P3），落到告警平台分级路由；P2/P3 不 wake 人。
3. 不淹没：静默 / 去重 / 升级三件套——同类告警 15 分钟内静默、重复告警合并为一条、超时未 ack 自动升级到二线。

为什么这么做

• 为什么是"SOP"而不是"文档"：日常运维的核心是拉平人差——不同人在同样场景下的动作差异必须收敛到几步内，否则事故只会发生在经验最少的那次值班上。SOP 不是给"看着办"留空间，是给"照着做"留台阶。
• 为什么"发布 + 配置 + 变更"要合并成一条日常线：三者本质是同一件事的三种粒度（大版本 / 配置项 / 单参数），日常工作里它们互相耦合（配置依赖代码新字段、变更依赖发布节奏）。分开写就会出现"配置变了但代码没跟上"、"发布回了但配置没回"的对齐事故。
• 为什么值班响应用四段式：Ack → Mitigate → RCA → Post-Mortem 是把"人的注意力"分配到最需要的阶段。先止血、后查因：查因是慢工，止血是分钟级动作，混淆两者 = 事故规模持续放大。
• 为什么告警设计比告警本身重要：告警噪音本身就是事故——它让真事故没人看。所以告警设计的目标不是"告警越全越好"，而是"告警到达时能被行动"。

为什么别的选择不行

• "临时手工执行、不建 SOP"：靠个人英雄主义撑值班表，一次交接、一次离职、一次深夜情绪化决策就把知识清空。
• "发布就用 kubectl apply、不走灰度"：单点回滚极慢、爆炸半径极大、无法量化验收。RollingUpdate 六模式对比与灰度八步存在的意义就是把"直接生效"这种最危险的动作从默认路径删掉。
• "配置变更等同于代码变更、走一样的流程"：配置变更的发生频率比代码高 10 倍，若走同样重的评审，运营节奏立刻卡死；若走同样轻的评审，事故立刻爆发。所以配置需要独立的三板斧（评审 / 灰度 / 回滚点）而不是共用代码 CI/CD。
• "告警越多越安全"：告警的边际效用递减——第 100 条告警的价值可能是负的（它让第 1 条告警被淹没）。减告警比加告警更工程化。
• "演练只在测试环境做"：测试环境的负载、依赖、数据量都与生产不同，测试环境的演练验证不出生产的失败模式。关键流程必须在生产做一次，且提前签发、随时可 abort。

沉淀结论

• 日常运维 = 一份七件套 SOP（发布/回滚 / 配置变更 / 日常巡检 / 值班响应 / 故障演练 / 变更评审 / 告警闭环），每件套按"入口条件 / 动作清单 / 成功指标 / 失败动作"四段固化。
• 发布策略、可观测性、容器运行时是三块能力，日常 SOP 是把它们装到值班表里的用法——本篇不讲原理，讲流程。
• 三板斧铁律：评审 / 灰度 / 回滚点——变更任何东西都缺一不可。
• 值班四段式：Ack → Mitigate → RCA → Post-Mortem——先止血、后查因，混淆两者事故就放大。
• 告警设计三原则：可行动 / 可分类 / 不淹没——减告警比加告警更工程化。
• 备份、演练、恢复三者都必须"做一次就是零、每周一次才叫有"——没演练过的能力不存在。

记忆口诀

七件套：发布/回滚 · 配置变更 · 日常巡检 · 值班响应 · 故障演练 · 变更评审 · 告警闭环
每件套四段：入口条件 / 动作清单 / 成功指标 / 失败动作
变更三板斧：评审 / 灰度 / 回滚点——缺一必炸
值班四段式：Ack 5m / Mitigate 10m / RCA 30m / Post-Mortem 3 天
告警三原则：可行动 / 可分类 / 不淹没——减告警而非加
巡检三级：日 = 指标水位依赖 / 周 = 慢查证书备份 / 月 = 依赖趋势演练
演练五步：announce / kick-off / observe / abort-condition / close-out
三不做：无回滚点变更 / 不灰度直接全量 / 变更后立刻下班

内容来源

综合整理。参考方向：Google SRE Book（值班、演练、告警设计章节）、Netflix Chaos Engineering、腾讯游戏后台运维实践、ITIL 变更管理框架、以及站内 release-strategy / observability / container-runtime / stateful-recovery 的日常应用视角。

自测：合上资料能说清楚吗？