3. 值班角色与职责定义：L1 / L2 / L3 分级模型
在 SRE 值班体系中，将支持人员划分为三个层级（Tier 1 / Tier 2 / Tier 3，简称 L1 / L2 / L3）是业界公认的最佳实践。这种分层模型的核心目标是：快速过滤常见问题，精准升级复杂故障，避免所有工程师被同一波告警淹没。
以下从角色定位、职责边界、升级触发条件三个维度展开定义。
3.1 三级角色划分与职责边界
| 层级 | 角色名称 | 核心职责 | 响应时效 | 典型成员 |
|---|---|---|---|---|
| L1 | 一线值班员 | 告警确认、标准化处置、工单创建、用户沟通 | ≤ 5 分钟 | 初级 SRE / 运维工程师 |
| L2 | 二线值班专家 | 故障诊断、临时规避、代码热修复、数据库干预 | ≤ 15 分钟 | 高级 SRE / 中间件负责人 |
| L3 | 三线研发负责人 | 架构级修复、根因定位、补丁发布、变更回滚决策 | ≤ 60 分钟 | 核心开发 / 架构师 / 技术经理 |
关键原则：L1 不要求解决所有问题，但必须完成“确认-分类-升级”的标准动作。L2 不要求修复代码缺陷，但必须提供临时止血方案。L3 不要求立即响应，但必须对最终根因负责。
3.2 升级机制与触发条件
升级不是“人找人的电话接力”，而是由 SLO 阈值 + 超时计时器 + 人工判断 共同驱动的自动化流程。以下为标准化升级矩阵：
| 升级方向 | 触发条件 | 升级动作 | 通知渠道 |
|---|---|---|---|
| L1 → L2 | L1 处置超时 10 分钟 / 未知错误类型 / 影响面 > 5% 用户 | 自动创建升级工单 + 拉入 L2 值班群 | PagerDuty / 钉钉 / Slack |
| L2 → L3 | L2 处置超时 30 分钟 / 需要代码变更 / 数据损坏风险 | 发起紧急变更流程 + 通知 L3 值班经理 | 电话 + 即时消息 + 视频会议 |
| L3 → 管理层 | 故障持续 > 2 小时 / 涉及合规 / 重大数据丢失 | 启动重大事故管理（MIM）流程 | 管理层邮件 + War Room |
实践建议：升级路径必须提前在值班手册中写死，包括每个层级的备用联系人（Escalation Path）。避免在故障发生时临时翻通讯录。
3.3 值班角色升级流程（SVG）
下图展示了一次典型故障从 L1 到 L3 的完整升级路径，包含时间轴与决策节点：
3.4 角色职责矩阵（详细版）
以下表格进一步拆解每个层级在 告警处理、变更执行、沟通汇报、文档记录 四个维度的具体职责：
| 职责维度 | L1 一线值班 | L2 二线专家 | L3 三线研发 |
|---|---|---|---|
| 告警处理 | Ack 告警、执行 Runbook、分类打标 | 深度诊断、临时配置修改、流量切换 | 代码级修复、架构调整、数据修复 |
| 变更执行 | 仅执行标准变更（已审批） | 执行紧急变更（需 L3 授权） | 审批并执行高危变更 |
| 沟通汇报 | 在值班群通报故障状态 | 向 L3 汇报故障分析结论 | 向管理层汇报事故报告 |
| 文档记录 | 填写工单、更新 Runbook | 编写故障分析（Troubleshooting Log） | 输出根因分析（RCA） |
常见误区：不要让 L1 值班员承担“必须解决所有告警”的压力。如果 L1 在 5 分钟内无法通过 Runbook 解决，应当立即升级，而不是继续尝试。延迟升级是值班体系失效的首要原因。
3.5 值班角色与平台工程的关系
平台工程的核心目标之一是 降低 L1 的认知负荷。通过构建自助服务门户和标准化 Runbook，平台团队可以将 70% 以上的 L1 告警处理流程自动化，让一线值班员从“消防员”转变为“流程执行者”。
以下 SVG 展示了平台工程如何支撑 L1/L2/L3 的分层协作：
3.6 值班角色定义清单（Checklist）
在落地 L1/L2/L3 模型时，建议团队逐项确认以下清单：
- L1 值班员 是否拥有所有标准 Runbook 的访问权限？
- L2 值班专家 是否具备数据库只读查询、配置热更新、流量切换的权限？
- L3 研发负责人 是否在非工作时间保持电话畅通？
- 升级超时时间是否已在告警平台中配置（PagerDuty / AlertManager）？
- 每个层级是否有明确的备用联系人（Backup）？
- 是否定期进行“升级演练”，测试 L1→L2→L3 的响应时效？
总结：L1/L2/L3 不是职级高低，而是响应速度与问题深度的分工。平台工程的目标是让 L1 处理得快，L2 诊断得准，L3 修复得彻底。三者通过自动化升级机制形成闭环，而不是各自为战。