IT运维值班制度，7×24小时故障响应流程

很多中小团队并没有真正落地的IT运维值班制度，7×24小时故障响应流程往往停留在口头约定。
本文从零基础出发，讲清楚如何用一套可执行的排班表、告警分级和升级机制，让故障在发生后的第一时间有人接手、有流程可循、有记录可查。

先明确适用场景与前置准备

这套制度适合自有服务器或云主机超过5台、业务对停机敏感的中小团队。
如果只有一两台测试机，暂时不需要完整值班体系。

落地前需要准备三样东西：

• 一份值班人员名单，包含姓名、联系方式、擅长领域（系统/网络/数据库/应用）。
• 一个告警接收渠道，推荐企业微信机器人、钉钉群机器人或 PagerDuty 类工具。
• 一份故障等级定义表，明确什么情况算 P1、P2、P3。

以 Prometheus + Alertmanager 为例，告警通道配置片段如下：

receivers:
  - name: 'oncall-webhook'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key'

配置完成后重启 Alertmanager：

systemctl restart alertmanager
systemctl status alertmanager

看到 active (running) 说明告警通道已生效。

排班表怎么排才可持续

7×24小时不等于每个人随时待命。
常见做法是主备轮值制：每天一人为主班，一人为备班，主班15分钟内未响应则自动转备班。

排班周期建议按周轮换，避免频繁倒班导致疲劳。
值班表可以放在共享文档中，格式如下：

| 日期 | 主班 | 备班 | 响应时限 |
|------|------|------|----------|
| 周一 | 张三 | 李四 | 15分钟 |
| 周二 | 李四 | 王五 | 15分钟 |

关键点：主班和备班不能同时休假，排班表至少提前一周公布。
如果团队人数少于4人，建议采用“工作日轮值+周末轮流”的折中方案。

故障响应流程怎么走

当告警触发后，按以下步骤执行：

1. 确认告警：值班人员在15分钟内响应，在告警群回复“已收到，正在排查”。
2. 初步定级：根据影响范围判断等级。P1（核心业务不可用）、P2（部分功能异常）、P3（性能下降但不影响使用）。
3. 启动处理：P1 故障立即拉起临时处理群，通知技术负责人；P2 由值班人员自行处理并同步进展；P3 记录后次日处理。
4. 升级机制：P1 故障超过30分钟未恢复，升级至技术总监；超过1小时未恢复，启动应急预案。
5. 记录归档：故障恢复后24小时内填写故障记录，包含时间线、根因、修复动作。

一个可直接复用的故障记录模板字段：故障时间、恢复时间、影响范围、根因、处理人、改进项。

常见坑与避坑说明

• 只排班不验证：排了班但从不测试告警是否能触达值班人，等于没排。建议每月做一次告警演练。
• 所有告警都设为最高级：会导致值班人员麻木，真正的 P1 反而被忽略。务必做告警分级和收敛。
• 没有升级路径：值班人员联系不上或不会处理时，故障会卡住。必须明确升级人和升级时限。
• 值班无补偿：长期无偿值班会导致人员流失，建议配套调休或补贴制度。

效果验证与持续改进

制度上线后，用三个指标验证是否有效：

• 响应及时率：15分钟内响应的告警占比，目标应高于95%。
• 平均恢复时间（MTTR）：从告警触发到恢复的平均耗时，按月统计并对比趋势。
• 漏报率：未被值班人员发现的故障数量，理想值为0。

每月复盘一次，把高频故障整理成知识库文档，减少下次处理时间。
IT运维值班制度的核心不是排班表本身，而是让每一次故障都有人负责、有流程可依、有记录可查。
7×24小时故障响应流程跑顺之后，团队才能真正从被动救火转向主动运维。

常见疑问

值班人员不在电脑前怎么办？
建议配置手机端告警推送，企业微信和钉钉都支持移动端接收。同时明确备班人员在主班失联后自动接手。

小团队人少排不过来怎么办？
可以采用“核心时段值班+夜间备班”的方式，夜间告警通过电话呼叫转移，不要求实时在线。

告警太多怎么收敛？
先按服务重要性分级，只对 P1、P2 告警设置实时推送，P3 告警汇总为日报。同时合并重复告警，例如同一台主机多个指标异常只发一条。