ref="/tag/151/" style="color:#874873;font-weight:bold;">运行手册不是文档，是行动指南
很多人以为运行手册就是把系统架构、部署流程堆在一起，等出事时翻着看。其实这不是运行手册，这是说明书。SRE要的运行手册，是像消防预案一样的东西——灯一灭，大家知道该谁去拉哪个闸。
从一次半夜告警说起
凌晨两点，服务突然500错误。值班工程师打开文档，看到“请检查数据库连接池”。好，那怎么查？登录哪台机器？用什么命令？超时了怎么办？这时候如果还要到处问人、翻聊天记录，故障时间就一分一秒拖长了。
理想的运行手册应该直接告诉他：
ssh sre@db-proxy-prod-03
sudo systemctl status db-pool-manager
journalctl -u db-pool-manager --since \"1 hour ago\" | grep \"max connections\"写清楚“做什么”和“为什么”
比如一条操作写着“重启nginx”，这不够。应该写成：“重启nginx（用于清除卡住的worker进程，避免请求堆积）”。加上括号里的说明，新人也能理解背后的逻辑，而不是机械执行。
再比如，某个临时降级开关的操作，旁边备注一句“此操作会影响推荐排序，恢复后需通知算法组校验数据”，就能避免救火成功却埋下新坑。
把判断逻辑变成清单
不要写“根据情况决定是否扩容”，而要列成 checklist：
- CPU持续>85%超过10分钟？是 → 进入扩容流程
- 最近1小时有发布？是 → 先回滚再评估
- 流量突增来自正常活动？否 → 上报安全事件
这种结构让判断过程标准化，减少依赖个人经验带来的偏差。
定期“演习”验证手册有效性
就像大楼要试消防喷淋，运行手册也得测试。可以搞个小范围演练：模拟缓存雪崩，看团队能不能按手册一步步走完。过程中发现“第4步找不到对应脚本路径”，或者“联系人已离职”，那就是手册需要更新的信号。
某次我们演练时发现，手册里写的监控告警ID已经失效，因为半年前平台升级改了命名规则。这种细节只有真去跑一遍才会暴露。
保持轻量，别变成百科全书
见过一份运行手册写了三百页，连Linux基础命令都收录进去。结果没人愿意看。好的手册应该只包含“非查不可”的内容。常见命令、通用工具这些，链接到公司内部知识库就行。
重点放在那些“只有我们这个服务才这么搞”的地方。比如某个接口必须按特定顺序调用，否则会锁表；又比如灾备切换时，DNS生效前还得手动刷一波CDN缓存。
让手册活在工程师的日常里
每次线上问题复盘后，第一件事不是发通报，而是问：手册有没有覆盖这个场景？没有的话，补上具体操作步骤。这样手册才会跟着系统一起成长。
有个团队做得挺聪明：他们把运行手册集成进告警通知。收到告警邮件时，底部自动附上相关手册章节链接。点开就是对应处置流程，省得再费劲搜索。