凌晨三点全员被叫醒,结果是一个按钮的文案错误——事故的响应没有定级标准,狼来了的疲惫与真故障的延误同时发生。事故定级用 P0 到 P3 的四档标准,让响应的力度与影响的程度精确匹配。
---事故的定级:影响面与时长的矩阵
function Severity.classify(incident)
local scope = incident.affectedPlayers -- 受影响玩家数
local duration = incident.durationMin -- 预计持续
-- P0:全服不可用或资损
if scope >= 0.8 or incident.fundLoss then
return 'P0'
end
-- P1:核心功能受损
if incident.coreBroken or scope >= 0.3 then
return 'P1'
end
-- P2:非核心受损,有替代方案
if scope >= 0.1 then
return 'P2'
end
return 'P3'
end
定级的标准两条轴:影响的玩家比例与故障的持续时间——全服不可用或资金损失是 P0,核心功能受损影响三成以上是 P1,非核心功能受影响但有替代方案是 P2,边缘的体验问题归 P3。定级决定响应的资源:P0 电话叫醒全部值班与主管、15 分钟内响应;P1 群内即时响应;P2 与 P3 的工作时间处理。定级的人有明确的授权:值班的工程师可以自行定级 P2 以下,P1 以上需要主管确认——定级的权威避免互相推诿。
---响应的流程:定级后的标准动作
local RESPONSE = {
P0 = { ack = 5, update = 15, team = '全员' },
P1 = { ack = 15, update = 30, team = '值班+模块负责' },
P2 = { ack = 60, update = 120, team = '模块负责' },
P3 = { ack = 240, update = 480, team = '模块负责' },
}
function Severity.respond(level, incident)
local std = RESPONSE[level]
-- 确认时限内的首次响应
if os.time() - incident.at > std.ack * 60 then
Ops.alert('响应超时', level, incident.id)
end
-- 周期性的进展通报
incident.nextUpdate = os.time() + std.update * 60
end
响应的流程按定级走标准的动作:确认的时限、进展通报的周期、参与的团队——P0 的通报每 15 分钟一次,哪怕没有进展也要同步「正在处理」。定级的动态调整:影响扩大的事故升级定级,升级后响应的标准同步提升——事故是动态的,定级也跟着走。复盘的定级校准:每次事故后回看定级是否恰当,定级的标准在案例中持续精化。
响应的时效达标率统计:各定级的首次响应与恢复时长对照标准的达成率;定级的准确率复盘:降级与升级的判定偏差,反馈给定级标准的迭代。
定级曾经只看影响的系统数不看玩家数,内部系统的小故障定了 P0,玩家的真实体验才是定级的锚。响应的超时曾经没有升级机制,超时的 P1 拖成 P0 才被关注,升级的自动化告警补上。定级的标准曾经有歧义,「核心功能」的定义各人理解不同,核心功能的清单显式列出。
定级的标准与响应的预案进值班手册,标准的文字精确到可执行。定级的培训进新人的入职:定级的判断力是值班的核心能力。定级的数据进季度的稳定性报告,事故的分布与响应的改进有据可依。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 攻城战前的城防准备通常是帮主一人操心的后勤活。城墙修筑赛把城防建设变成行会全员可参与的竞赛:攻城前一周开…
实战应用:用在哪里 行会成员的付出经常被忽视:连续一个月全勤、攻城战首杀、基金大额投入,这些贡献没有正式的认可渠道。行会授勋…
实战应用:用在哪里 首充礼包的转化率高度依赖展示效果:一张静态图配一行文字的弹窗转化率不足三成,动态展示礼包内容物与价值对比…
实战应用:用在哪里 比奇安全区的设计初衷是新手的避风港,但红名玩家仗着守卫不攻击红名而无视安全区规则。安全区守卫驱逐触发让红…
实战应用:用在哪里 行会转让、装备销毁、大额交易这类操作一旦出错不可逆转,事后追责全靠口头描述。关键双录机制在操作前后各留存…
实战应用:用在哪里 服务器资源的使用趋势靠人记不现实,容量不够时才发现已经超限运行一个月。容量月报自动汇总每月的 CPU、内…