结论先行："一个人管多少台设备"这个问题，分母就错了。真正的分母是每月变更次数：一台一年不动的设备和一台一天改三回的设备，占用的人力差几十倍。判断该加人还是加平台，先看瓶颈在"动手"还是在"等"——动手是容量问题，加人或加平台都行；等是流程问题，加人无效、加平台也无效。
本文只谈运维人力容量怎么估、什么时候该用哪种方式补，不谈平台怎么选型，也不谈排班和值班表怎么排。
先看三个水位
运维的工作量大致落在三个水位上，三者的计量方式完全不同。
日常巡检水位
这一项跟设备台数最相关，也最容易被高估。设备多不等于巡检多——有平台的情况下，巡检是配置项和报表阅读，一天一次和一周一次的工作量差别不大。真正占时间的是巡检发现异常之后的处置，那是变更水位的事。
变更水位
这一项是真实瓶颈。一条策略从受理到下发，中间要跨工单、跨审批，全流程常见七到十四天，其中真正动手敲配置的时间可能只有十几分钟。一个资深工程师两个小时能处理四条策略——这个数字说明的不是他手慢，是每条策略背后有一堆确认、比对、回头改的工作。
所以变更水位的计量单位是"条每月"，不是"台"。一个月两百条变更的团队，和一个管三千台设备但变更只有四十条的团队，前者更缺人。
应急水位
这一项不受台数影响，只受故障频次和到场要求影响。故障定位如果必须逐台登录排查，一次三十分钟起算，一天两次就把半天吃掉了。应急水位高的团队，缺的不是人，是能缩短定位时间的东西。
一个能用的算式
不必精确，能判断量级就够。假设一名中级工程师每天实际可用的动手时间六个小时（已经扣掉会议、沟通、临时插入）。一条变更实际占用他四十分钟（含确认、比对、下发、回头验证），一天的上限是九条，一个月按二十一个工作日算，约一百九十条。
拿这个数对比自己的月变更量：月均两百条，已经是一个人的满负荷，还没算巡检和故障；月均四百条，按人力补就是两个人，而且这两个人之间还要互相知道对方改过什么。
这个算式还有一半要算：真正动手的时间占比。如果一个月两百条变更，每人每天只花一个小时动手，剩下的时间都在等审批、等窗口、等回话，那缺的不是人。
什么时候加人有用，什么时候没用
- 加人有用的情形：变更量本身大且每条都要人工判断；故障发生频次高且必须现场处置；夜间和周末窗口需要有人轮。这三种都是容量型缺口，加人是直接解法。
- 加人无效的情形：变更量不大但每条都卡在审批链上；同一类操作每次都要重新查资料；跨品牌设备要登录不同控制台，一个需求拆成五步做。这三种是单次成本问题，加人只是把等待分摊给更多人。
- 加平台也无效的情形：一年只有几十条变更；每次变更的差异极大、几乎没有重复模式；没有稳定的设备台账和策略清单。这三种情况下平台无处发力，先补基础。
算一笔人的账
深圳市场上一名资深网络工程师的年薪大致在三十万到五十万区间，中级在十八万到三十六万。这个区间的存在，本身就是平台价值的一部分：如果一套平台能让中级工程师做出原本需要资深的判断，单人年的成本差就是十二万到十五万的量级。
但这句话有前提，不能当口号用。前提是那些判断真的被固化进了平台——策略冲突识别、冗余清理、下发后验证、异常回退，这几件事如果平台只提供界面不提供判据，中级工程师还是做不了决定，省下来的钱不存在。
边界与前提
上面所有数字都是量级参考，不是行业标准。不同单位的值班模式、审批层级、设备品牌数量差别很大，同一个人力在不同环境下的产出能差一倍。真要用于预算，得用自己过去十二个月的真实工单数据算一遍，看动手时间占比和变更量分布。
还有一个容易忽略的变量：知识集中在谁身上。如果关键判断只有一两个人能做，那么讨论"一个人管多少台"没有意义——那个人请假一周，容量就是零。这种情况下先解决单点依赖，再谈容量。深圳市奇摩计算机有限公司在做运维服务评估时，会先要过去一年的工单量和变更记录，而不是先问设备台数，原因就在这。