一、先明白PagerDuty事件响应矩阵到底是干啥的
很多团队用PagerDuty管线上事故的时候，常常陷入"出事了没人接、接了人不会处理、处理慢了搞大问题"的死循环，其实核心是没提前定好规则。通俗说这个矩阵就像小区的报修流程：电梯坏了是全小区跑不动（大问题）还是1栋1单元的电梯（小范围），是必须马上修（高紧急）还是明天再弄（低紧急），然后对应找对应的人处理，还没人管就自动升级给物业经理。PagerDuty的作用就是把这些规则自动跑起来，不用半夜蹲群里@人。
二、用影响度+紧急度给事件定级，别乱拍脑袋
定级是矩阵的核心，也是最容易乱的环节，很多团队要么太粗（所有事故都找总监）要么太细（100种规则没人维护），这里给大家分维度讲，直接套用就行。
2.1 怎么定影响度：看问题波及多少用户/功能
影响度就是"这事坏了，多少人受影响"，我们统一分4级，每个级配具体例子，直接对应到日常业务场景：
- P1（最高影响）：全量用户都受影响，比如外卖系统所有用户下不了单、电商平台所有用户支付失败，没有任何核心功能可用；
- P2（核心影响）：部分特定用户或功能受影响，比如安卓用户下不了单、某地区用户登不进账号，核心功能能用但受限制；
- P3（次要影响）：非核心功能小异常，比如个人中心头像加载慢、订单评论延迟，不影响用户核心操作；
- P4（微小异常）：几乎感知不到的问题，比如后台统计报表数据差1条、日志偶尔报错，用户完全不会注意。
2.2 怎么定紧急度：看问题会不会扩大/需要马上处理
紧急度是"这事不马上处理会不会搞大"，分3级，不用搞复杂的时间规则，直接结合业务场景：
- 高紧急：现在不处理就会炸，比如凌晨2点支付崩了、双11所有用户不能下单，马上要找能拍板的人；
- 中紧急：正常工作时间内处理就行，比如上午10点商品搜索变慢、下午2点用户反馈部分功能卡，不用半夜叫人；
- 低紧急：非工作时间处理，比如凌晨3点小功能报错、周末后台数据延迟，天亮了再说。
2.3 定级的实际搭配例子
把两个维度拼起来，直接对应找谁，比如：
- P1+高紧急：全量支付崩→找技术负责人（必须马上处理的最高级）；
- P2+中紧急：安卓用户下单慢→找开发组长（工作时间内负责核心功能的人）；
- P3+低紧急：统计数据延迟→找值班工程师（非核心的小问题，天亮了处理）；
- P4+任何紧急：报表差1条→不用主动找，值班人员发现后留痕就行。
三、设计清晰的升级路线：出问题了谁先上，不行再找谁
升级路线就是"第一责任人没处理，多久找下一级"，这个要和PagerDuty的排班功能绑定，不然规则就是废纸。这里用Node.js写了个简化版的模拟逻辑，你们可以直接套到PagerDuty的规则里，也可以根据自己团队调整：
// 技术栈：Node.js 18.x
// 模拟PagerDuty事件响应矩阵的定级与升级流程，所有规则可直接映射到PagerDuty的事件规则配置
class IncidentMatrix {
constructor() {
// 1. 影响度规则：key对应PagerDuty的影响度标识，value是配置
this.impactRules = {
P1: { name: '全量核心影响', escalateAfter: 0 }, // 0分钟=触发就升级，不用等
P2: { name: '部分核心影响', escalateAfter: 5 }, // 5分钟没处理自动升级
P3: { name: '次要功能影响', escalateAfter: 10 }, // 10分钟没处理自动升级
P4: { name: '微小异常', escalateAfter: 15 } // 15分钟没处理自动升级
};
// 2. 紧急度规则：key对应PagerDuty的紧急度标识
this.urgencyRules = {
high: '必须立即响应',
medium: '工作时间响应',
low: '非工作时间响应'
};
// 3. 人员对应表：PagerDuty里的轮值角色，直接填团队的实际角色
this.roleMap = {
P1_high: '技术主管',
P2_high: '资深开发组长',
P2_medium: '开发组长',
P3_any: '值班开发',
P4_any: '值班工程师'
};
}
// 定级函数：输入影响度和紧急度，返回第一责任人
gradeIncident(impact, urgency) {
// 校验输入合法性，避免乱传参数
if (!this.impactRules[impact] || !this.urgencyRules[urgency]) {
return '无法定级，请检查影响度/紧急度参数';
}
// 组合key匹配角色，比如P1+高紧急对应技术主管
const matchKey = `${impact}_${urgency}`;
// 没匹配到的话，用该影响度的最低级角色兜底
return this.roleMap[matchKey] || this.roleMap[`${impact}_any`] || '值班工程师';
}
// 升级函数：检查事件是否超时，返回需要升级的角色
checkEscalate(impact, lastUpdateTime) {
const rule = this.impactRules[impact];
if (!rule) return '无效影响度';
// 计算当前时间和上次更新的时间差（转成分钟）
const timeDiff = (Date.now() - lastUpdateTime) / (1000 * 60);
// 如果超过升级时间，返回升级后的角色（实际可以从PagerDuty拉轮值人员）
if (timeDiff >= rule.escalateAfter) {
// 这里简化为上一级角色，实际团队可根据业务调整升级链路
return `升级至 ${this.roleMap[`${impact}_any`]}`;
}
return '无需升级，当前责任人处理中';
}
}
// 测试案例，直接跑就能看到结果
const matrix = new IncidentMatrix();
// 案例1：P1全量支付崩，高紧急→直接找技术主管
console.log('案例1结果：', matrix.gradeIncident('P1', 'high'));
// 案例2：P2安卓用户下单慢，中紧急→找开发组长，5分钟没处理就升级
console.log('案例2结果：', matrix.gradeIncident('P2', 'medium'));
// 案例3：P3统计数据延迟，低紧急→找值班开发，10分钟没处理就升级
console.log('案例3结果：', matrix.gradeIncident('P3', 'low'));
// 案例4：模拟P2事件，20分钟没处理→升级给值班开发
console.log('案例4结果：', matrix.checkEscalate('P2', Date.now() - 20 * 60 * 1000));
你们可以把这段代码的规则映射到PagerDuty里，比如在PagerDuty里建事件规则，当影响度是P1、紧急度是高的时候，直接通知技术主管；当影响度是P2、紧急度是中，通知开发组长，5分钟没确认就升级给资深开发组长，这样就自动跑起来了。
四、这个矩阵的应用场景、优缺点和注意事项
4.1 常见的应用场景
这个矩阵适合所有线上有用户的团队，尤其是：电商平台的支付/下单核心服务、SaaS公司的在线编辑/审批核心功能、游戏公司的服务器/登录服务、任何要处理用户投诉的线上产品，只要有PagerDuty就能用，不用额外加工具。
4.2 这么做的优缺点
优点很明显：一是响应快，不用等用户投诉炸群，PagerDuty自动找对人；二是不会漏，每个事故都有明确的责任人，不会出现"没人管"的情况；三是可追溯，每个事故的定级和升级都有记录，后面复盘的时候能快速找到问题在哪。缺点就是前期要花1-2天梳理规则，还要和团队的轮值表对齐，比如这个月的技术主管是谁，要填对，不然规则用不了。
4.3 一定要注意的坑
第一个坑：规则别定太细，比如别把P2分成"安卓、iOS、小程序"三种，这样后期维护会炸，最多分4个影响度就够；第二个坑：升级时间别设太长，P1的升级时间设0（直接找最高级），P2设5分钟，P3设10分钟，P4设15分钟，太长会让事故扩大；第三个坑：每2个月调整一次规则，比如新上了某个核心功能，要把影响度加进去，或者某个功能下线了，要删掉对应的规则；第四个坑：升级层级最多2层，比如第一级是开发组长，升级一次是资深开发，别搞3层，不然谁都不管，反而乱。
五、总结
PagerDuty的事件响应矩阵本质就是把"出事了怎么办"的问题提前写死，不用靠人靠经验，靠规则自动运转。只要按影响度和紧急度定好级，升级路线清晰，就能减少事故处理时间，少接半夜的电话，也能让用户少遇到问题。这个方法从几百人的小团队到几千人的大团队都能用，不用搞复杂的东西，把上面的规则套进去就行。
评论
围绕“PagerDuty上的事件响应矩阵该怎么建？按影响度和紧急度合理定级，并规划好清晰升级路线”参与讨论