【运维发布】值班升级链：15 分钟无响应的升级机制

实战应用：用在哪里

告警发进群，凌晨三点没人理，故障拖到天亮才处理。值班升级链给每条告警挂一个 900 秒的沙漏：15 分钟无人认领自动升级到主管，30 分钟升级到电话通道，认领即停表，责任到人时间到点。链路的意义不在加班，在把踢皮球的空间压到零：每一级都有明确的接手人与截止时刻。

告警登记与认领停表

告警登记时分配编号、写入流水并挂对应编号的升级定时器；认领动作写明认领人并关掉定时器，流水全程留痕。

local ALERT_ID = 0
function raiseAlert(desc)
    ALERT_ID = ALERT_ID + 1
    setsysvarex("ALERT_" .. ALERT_ID, os.time() .. "|" .. desc .. "|未认领", 1)
    setontimerex(155 + ALERT_ID, 900)
    return ALERT_ID
end
function ackAlert(id, who)
    setsysvarex("ALERT_" .. id, os.time() .. "|" .. who .. " 已认领", 1)
    setontimerex(155 + id, 0)
end

15 分钟与 30 分钟的两级升级

一级超时广播全服并给值班主管发邮件，二级超时再给故障经理通道补发，升级动作全部带时间戳入流水。

function ontimer156()
    sendcentermsg("告警升级：15 分钟无人认领，值班主管已介入")
    sendmail("#主管老李", 902, "告警升级通知", "一级告警 15 分钟未认领，请立即处理", "")
    setontimerex(157, 900)
end
function ontimer157()
    sendcentermsg("告警再升级：已达 30 分钟，故障经理通道已拨通")
    sendmail("#经理老王", 903, "告警再升级通知", "30 分钟未处理，启动电话通道", "")
end

验证与监控

演练三类路径：认领后定时器停表、15 分钟未认领升级一级、30 分钟未处理升级二级；升级邮件的收件人前缀与模板逐项核对。演练选在周中低峰实弹跑，用测试告警把整条链路走一遍，纸面推演漏不了真问题。监控每月升级次数与平均认领时长，升级次数增多说明值班排班或告警质量在恶化。

踩坑记录

告警编号从 1 自增没有持久化，重启后从 1 重新分配，新告警覆盖了老告警的流水键，编号改为带日期前缀。认领函数忘了关定时器，升级照常触发，主管半夜被假升级叫醒两次，认领与停表必须写在同一个函数。升级邮件的收件人漏了井号前缀，两封升级通知石沉大海，邮件模板上线前用测试账号实发验证。sendcentermsg 的升级广播让在线玩家也看到内部术语，广播文案改成通俗表述，细节只留流水里。升级链上线后平均认领时长从 22 分钟压到 6 分钟，机制真正的收益是让响应速度变成看得见的指标。