零预算治理？先把on-call工时换算成招聘人数

当"降本增效"变成"只降本不增效"

最近听到一个黑色幽默：某大厂SRE团队申请采购监控告警收敛工具，管理层批复"零预算治理，靠人力优化解决"。团队负责人算了笔账——如果不用工具，现有on-call负荷需要扩招3.5个全职工程师。拿着这个数字再去找HR，对方沉默了。

这不是段子，而是当下技术管理的常态。当财务语言（CapEx/Opex）无法打动管理层时，你需要切换到HR语言（Headcount）。

FTE置换模型：把工时变人头

FTE（Full Time Equivalent，全职人力工时）是人力资源规划的通用单位。1个FTE = 2080小时/年（按40小时工作周×52周计算，已含带薪假折算）。

核心公式：

所需FTE = 年度on-call总工时 ÷ 2080 × 负荷系数

负荷系数说明：

• 纯on-call值守（仅响应，不处理）：1.0
• 高干扰on-call（需立即处理+写复盘）：1.3-1.5
• 救火队长模式（7×24待命+跨系统救火）：1.8-2.0

💡 为什么需要系数？ 因为on-call不是普通工时，它伴随睡眠剥夺、上下文切换损耗和burnout风险。一个凌晨3点被叫醒的工程师，次日有效产出通常只有平日的40%。

四步实操：从工单到编制

第一步：采集基线数据（1周）

使用现有监控或手动记录，统计以下指标：

第二步：计算工具节省量

假设采购告警收敛+根因分析工具（如PagerDuty AIOps或国产闪捷等同类方案），行业基准数据：

• 告警降噪率：60-80%（取保守值70%）
• 根因定位加速：MTTR降低40%

节省工时计算：

原on-call工时 = 15h/周 × 52周 = 780h/年
节省工时 = 780h × 70%（降噪） + (120×52×0.45h×40%)（MTTR优化）≈ 546h + 112h = 658h

第三步：FTE换算与成本对比

📌 系数1.5说明：包含社保公积金（1.4）、工位成本（0.1），未计入招聘费用和管理者时间成本。

结论：不花这18万，意味着你需要多申请0.4个HC，且这个岗位需要全年无休地处理无效告警。

第四步：风险溢价调整

如果当前团队已处于以下状态，需在FTE需求上乘以1.2-1.5的burnout系数：

• 近半年有on-call相关离职
• 凌晨2-6点告警占比>30%
• 周末紧急上线频率>2次/月

修正后需求：0.4 FTE × 1.3 = 0.52 FTE，即至少招1个全职工程师才能维持现有运转。

向上管理话术模板

不要直接说"我们需要买工具"，而是：

"基于当前on-call数据，如果不引入自动化手段，Q3需要补充0.5个HC承担告警处理。该岗位需具备Java/Go排障能力，市场薪资范围XX-XX万。建议对比工具方案（年费18万）与招聘方案（年薪+管理成本约42万）的三年TCO。"

关键技巧：

1. 用"HC"代替"钱"：管理层对编制数的敏感度低于直接支出，但HR对编制数敏感，形成交叉压力
2. 展示机会成本："这0.5个HC如果用于业务开发，预计可支撑XX功能提前2周上线"
3. 提供替代方案：如果确实零预算，申请冻结非关键需求，释放现有人力——这通常比招人更让业务方紧张

避坑指南：当计算器遇上政治

⚠️ 不要做的三件事：

1. 不要只算工程师成本
   如果工具还能减少客服工单、减少业务损失，把这些一并折算成FTE（如"减少客服夜班人力0.2 FTE"），杀伤力更大。

2. 不要忽视迁移成本
   如果工具需要2个月迁移期，且期间需要1个工程师全职投入，需在首年成本中+0.1 FTE，避免第二年被翻旧账。

3. 不要承诺"完全替代人力"
   工具只能替代"响应"，不能替代"架构优化"。如果承诺后仍需扩招，你的信用模型会破产。

终极思考：零预算背后的信号

如果管理层在看到这个FTE换算后仍坚持零预算，这不是财务问题，而是战略优先级问题——可能该业务正处于"维持模式"或"弃疗阶段"。此时更理性的做法不是争取预算，而是更新简历，或申请将系统迁移至更低维护成本的架构（如Serverless托管）。

毕竟，用人力填技术债务的坑，最终填进去的是团队的职业生涯。

附：简易FTE计算器（Markdown表格版）

把最后一行数字发给老板，比写十页技术方案管用。