管理层问能不能直接减on-call人手？从工程质量和风险角度怎么回

凌晨两点，支付链路抖动。值班群里同时炸出142条告警：CPU高、QPS跌、DB连接池满、CDN回源超时、业务自定义阈值触发。原本该两个人轮值，但编制砍掉一个后，只剩你一个人盯着屏幕。前十分钟你在过滤噪音，第三十分钟才意识到是底层存储IO打满，错过了黄金止血窗口。故障复盘时，业务损失按分钟计费，而“少招一个值班”省下的那点人力成本，连一次P2事故的赔偿零头都盖不住。

这就是管理层问“我们降低on-call人员编制不就行了？”时，工程侧必须直面的现实。减人不是优化，是把风险往后拖；告警治理不是成本中心，是系统可靠性的免疫系统。

一、为什么“减人”等于拆防火墙？

先看三个必然发生的工程反噬：

1. 告警疲劳呈指数级放大：人少了，单次值班覆盖的告警量不变甚至因系统复杂度上升而增加。大脑对重复、低价值提示的脱敏速度极快。真实数据表明，当值班人员日均处理无效告警超过20条，关键告警漏看率会从5%飙升至35%以上。
2. MTTR被动拉长：人手不足时，工程师的第一反应是“快速恢复”，而不是“定位根因”。重启、回滚、扩容三板斧轮番上，问题没解干净，下次同等规模触发更严重。故障恢复时间拉长，连带引发二次雪崩的概率成倍增加。
3. 隐性技术债堆积：没人有精力写Runbook、补监控盲区、做混沌演练。代码里的竞态条件、配置漂移、依赖单点全在暗处生长。等真出事，排查成本直接翻倍。

砍编制，表面看是省了工资和排班表，实际是抽掉了故障发现、遏制、复盘的缓冲层。这在工程上叫“拆防火墙”。

二、告警质量才是系统的免疫系统

免疫系统怎么工作？不是靠堆白细胞数量，而是靠精准识别、分级响应、清除病原、形成记忆。告警体系同理：

• 高信噪比：把抖动、预期内波动、已自动愈合的事件过滤掉，只留需要人工介入的真实异常。
• 分级路由：P0直call电话+钉钉强提醒，P1走群，P3进工单池次日处理。不同级别匹配不同的响应SLA和升级策略。
• 闭环反馈：每次告警必须关联工单或变更记录，事后能追溯误报根因，反向修正阈值或补充自动化脚本。

当这套机制跑通，系统自己就能拦截80%以上的无效打扰。剩下20%才是真正需要人类工程师出场判断的“病原体”。这时候on-call人数根本不需要堆，一个人能顶原来三个人的有效产出。

三、清洗告警：如何加固防火墙

清洗不是删告警，是重构告警的生成逻辑和消费链路。落地分四步：

1. 基线盘点：拉取过去90天所有告警，按来源、级别、频次、是否触发工单分类。找出Top 20噪音源。通常你会发现，3个配置不当的阈值贡献了60%的无效量。
2. 动态阈值替代静态阈值：用同比/环比基线+滑动窗口替换死板的固定值。比如晚高峰DB连接数到80%是常态，不该告警；但凌晨3点突然到50%，反而要亮红灯。
3. 告警聚合与抑制：同根因事件打组。网络抖动导致下游一连串超时，只报根节点，下游自动抑制。配合变更窗口自动静默，避免发布期间告警风暴。
4. Runbook与自动化前置：每条保留的告警必须绑定处置手册。能自动扩容、切流、清缓存的，直接走自愈流程；不能的，明确第一步查什么日志、第二步核对哪个指标。值班人员从“消防员”变成“指挥官”。

做完这四步，你会发现：告警总量可能降70%，但真正需要人看的P0/P1一条没少。这就是加固防火墙。减人是拿掉砖块，治理是换钢筋水泥。两者性质完全不同。

四、向上沟通的工程语言与节奏

管理层关心的是ROI和风险可控。别只谈技术理想，用数据对齐：

• 给基线：当前月均告警量、误报率、平均响应时间、近半年因告警疲劳导致的漏报/误操作次数。
• 给对比：治理前后MTTR变化、人工介入时长下降比例、自动化自愈覆盖率。明确写出“省下的值班工时，可以投入到架构防腐或自动化建设”。
• 给试点：选一个非核心但告警密集的业务线做2周灰度。用A/B数据证明：编制不变、告警治理后，值班压力降40%，故障升级率降60%。拿到结果再推全局。
• 给底线：明确P0覆盖要求。如果一定要减编制，必须同步承诺告警信噪比提升至X%以上，否则签署风险豁免单。工程团队不背无数据支撑的KPI。

可靠性不是靠人海战术熬出来的，是靠信号过滤和流程设计撑起来的。把on-call当成本砍，短期财报好看，长期技术底座漏水；把告警当免疫系统养，前期投入治理，后期系统自己会替你值班。选哪条路，看的是团队到底想把钱省在明面，还是把风险藏在暗处。