4、告警响应角色与职责：值班工程师、SRE负责人、技术主管、业务方、升级机制
告警来了，谁该动？
这个问题，我见过太多团队栽跟头。有的告警响了半小时没人理，有的一个普通告警把CTO都拉进群。说白了，就是角色没定义清楚。
今天咱们就把这五个角色掰开揉碎讲清楚。值班工程师、SRE负责人、技术主管、业务方，还有升级机制。嗯，一个都不能少。
4.1 值班工程师：第一道防线
值班工程师，就是告警响应的第一棒。我习惯叫他们「守门员」。
这个角色不需要多资深，但必须够稳。我见过一个刚入职三个月的小伙子，半夜三点接到磁盘IO告警，五分钟内定位到是日志轮转脚本挂了，手动触发后恢复。这就是好苗子。
- 7×24小时响应告警，确认是否真实故障
- 执行标准操作流程（SOP）中的应急操作
- 判断是否需要升级，并触发升级流程
- 记录告警处理过程，填写事件单
这里有个坑。我曾经遇到值班工程师把「告警确认」和「告警修复」混为一谈。他收到告警后，点了个「已确认」就去睡觉了。结果第二天发现服务挂了四小时。
4.2 SRE负责人：技术指挥官
SRE负责人，说白了就是值班工程师的「后援」。当值班工程师搞不定时，就该SRE负责人上场了。
我个人习惯，SRE负责人必须满足两个条件：一是对系统架构了如指掌，二是能扛得住压力。你想想看，凌晨三点被叫起来，电话那头是业务方在催，这时候慌不得。
| 场景 | SRE负责人介入时机 |
|---|---|
| 告警持续超过15分钟未恢复 | 立即介入 |
| 影响面超过单个模块 | 立即介入 |
| 值班工程师连续两次操作失败 | 立即介入 |
| 常规告警，值班工程师已处理 | 无需介入，但需审核事件单 |
我记得有一次，数据库主从延迟告警，值班工程师重启了从库三次都没用。我接手后发现是主库的一个大事务在跑，从库追不上。直接切了只读流量，等事务跑完再恢复。前后十分钟搞定。
4.3 技术主管：决策者与资源协调者
技术主管这个角色，很多人理解错了。他们以为技术主管就是来写代码修bug的。其实不是。
技术主管的核心价值是「决策」和「协调」。当故障需要跨团队协作，或者需要停服、回滚等高风险操作时，技术主管必须拍板。
- 故障影响核心业务超过30分钟
- 需要停服或数据回滚
- 涉及多个技术团队协调
- 需要对外发布故障公告
4.4 业务方：需求提出者与影响评估者
业务方，说白了就是「被影响的人」。他们不负责修系统，但负责告诉你「这事儿有多严重」。
我遇到过最头疼的情况：系统挂了，技术团队在拼命修，业务方在群里一直问「什么时候好」。其实双方都急，但信息不对称。
所以我的建议是：给业务方一个固定的信息同步渠道，比如每10分钟在群里发一次进展。不需要技术细节，只需要说「预计恢复时间」「当前影响范围」「我们正在做什么」。
- 确认故障对业务的实际影响（如：订单无法提交、页面加载慢）
- 提供业务优先级（如：先恢复支付功能，再恢复查询功能）
- 协助通知客户或合作伙伴
- 参与事后复盘，提出业务层面的改进建议
4.5 升级机制：从「有人管」到「管得好」
升级机制，是整个告警响应体系的「安全网」。没有升级机制，再好的角色定义都是空谈。
我见过最糟糕的升级机制是什么？就是「谁官大谁说了算」。CTO半夜被拉进群，然后所有决策都要等他拍板。这不对。
升级机制应该是「按能力升级」，不是「按级别升级」。
# 标准升级路径示例
Level 0: 值班工程师（5分钟内响应）
├─ 解决 → 关闭告警
└─ 无法解决 → 升级到 Level 1
Level 1: SRE负责人（10分钟内介入）
├─ 解决 → 关闭告警
└─ 无法解决 → 升级到 Level 2
Level 2: 技术主管（15分钟内介入）
├─ 解决 → 关闭告警
└─ 需要跨团队 → 升级到 Level 3
Level 3: 技术委员会/CTO（30分钟内介入）
└─ 重大故障决策（停服、回滚、数据修复）
另外，升级要有时间阈值。比如：
- P0告警：5分钟未确认 → 自动升级到SRE负责人
- P1告警：15分钟未恢复 → 自动升级到技术主管
- P2告警：30分钟未关闭 → 自动升级到SRE负责人
为什么要设时间阈值？因为人都会犹豫。你想想看，凌晨三点，值班工程师可能在想「再试一次吧」。但系统不会犹豫，时间一到自动升级，这才是靠谱的机制。
4.6 角色协作流程图
下面这张图，是我自己团队一直在用的角色协作流程。说白了，就是告警来了之后，每个人该干嘛。
这张图的核心逻辑就一句话：每个人都知道自己该在什么时候做什么事，也知道搞不定时该找谁。
最后说一句。角色定义得再好，不执行也是白搭。我建议每季度做一次「告警响应演练」，模拟一个真实故障，让所有人走一遍流程。你会发现，平时说得头头是道的人，一演练就露馅了。嗯，演练就是照妖镜。