服务器停机一小时损失多少，这个数字怎么算出来

讨论要不要做冗余、要不要升级、要不要迁移的时候，总会遇到一句话：停机损失太大。而这个「太大」到底是什么量级，多数人说不出来。说不出来就意味着没法比较，也就没法判断某项投入值不值。

停机损失是可以算的。它由四块构成：直接交易损失、恢复过程的人力成本、用户流失带来的长期损失、以及信誉折损。前三块能算成数字，第四块只能估区间。而多数人只算了第一块，所以结论往往偏小好几倍。

所以做任何迁移或者架构决策之前，先把自己的停机损失算成一个数。

下面把这四块拆开：每一块怎么取值、什么业务大什么业务小，然后给一个能直接套用的算法，最后讲怎么用这个数字做决策。

上面这些落到实际，终究要挑一台机器来跑——这几家都是云服务器里比较有代表性的，4 家可选，价格从 22 元拉到 43 元

商家	推荐款	配置	带宽与流量	月费	档位参照
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	存储型，盘位优先
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	入门档，先验线路
rabisu	Aydn VPS x8	4 核 8G 60G	500Mbps / 不限	34.5 元	常规口径，注意超售比
spartanhost	10Gbps 系列	4 核 8G 40G	10Gbps / 2T	43.2 元	见正文

第一块：直接交易损失

最后一个：这一块只是起点。

判断方法是别停在这里。

而只算这一块的结论一定会低估。

还有一个：损失也要看订单结构。

判断方法是看高客单价订单的占比。占比高的损失更集中。

而低客单价的订单量多，恢复后能补回一部分。

还有一点：支付环节的中断最致命。

判断方法是看停机是否覆盖支付流程。覆盖的话订单直接失败。

而只是页面打不开的，影响相对小。

最后一个：停机时长要按真实故障算。

判断方法是回看历史故障的平均恢复时间。这个数字比预期长。

而按最理想情况算的，等于自欺。

还有一个细节：停机期间的退款和补偿。

判断方法是看是否有承诺。有承诺的，补偿也是成本。

而这部分常被当成客情而不是成本。

还有一点：停机对预售和下单的影响。

判断方法是看有没有未完成的订单。中断的订单可能需要重做。

而重做的成本也要算。

还有一个：季节性因素。

判断方法是看停机时段是否是旺季。旺季的损失会放大。

而按平季数据估的，会低估。

这一块最好算，就是停机期间本来能产生的收入。

判断方法是取同时段的平均流水。用同一时段做参照最准。比如工作日晚上停机，就取工作日晚上的流水。

而用全天平均值算的，结果会偏离很多。

计算方式是用时段流水除以时长，再乘以停机时长。

判断方法是将流水按小时均摊。这个数字是每小时的机会成本。

而这块只适用于有直接交易的业务。

还有一点：停机期间的需求不一定消失。

判断方法是看需求是否能延后。能延后的只是推迟，不是损失。

而即时性强的需求，停一分钟就少一分钟。

两类需求的差别很大。

判断方法是区分是消费型还是服务型。消费型的损失更接近全额。

而服务型的损失会被后续流量部分补回。

人力成本要按排查加恢复的总时长算，两者往往差很多。sixtynet那几档配置写得细，故障时能少排查几步。

第二块：恢复过程的人力成本

还有一个：值班安排的成本。

判断方法是看是否需要临时加人。临时加人的成本更高。

而这部分通常不在预算里。

还有一点：沟通成本也要算。

判断方法是看需要同步给多少人。同步越多，耗时越长。

而这部分常被当成不产生价值的杂事。

最后一个：人力成本要按全成本算。

判断方法是算上社保和管理分摊。只用工资数会低估。

而这部分差别在长期看很明显。

还有一个：排查期间业务是停着的。

判断方法是把排查时间也算进停机。很多人在算的时候只算修复。

而排查花的那几个小时同样没有收入。

还有一点：外部支持的等待时间。

判断方法是看是否需要服务商介入。等服务的时间也算停机。

而这部分不可控。

还有一个：恢复后的观察期。

判断方法是看需要盯多久。观察期内不能做其他事。

而这部分通常也要计入。

这一块常被完全忽略。

判断方法是统计处理故障需要几个人、多少小时。人力也是钱。

而这部分在停机时长之外，往往还要额外付出。

排查和恢复是两个阶段。

判断方法是分别估算两个阶段的耗时。排查往往比恢复更久。

而只算恢复时间的，会低估总量。

还有数据核对的工作。

判断方法是评估需要核对多少数据。核对量大的，耗时以天计。

而这一步不做，后面会出问题。

还要算上业务方的配合时间。

判断方法是看需要几个部门参与。跨部门协调本身很耗时。

而参与的人越多，成本越高。

第三块：用户流失

最后一个：挽留动作要快。

判断方法是故障后二十四小时内联系。

而拖得越久挽回越难。

还有一个：老客户的挽留成本更低。

判断方法是优先安抚高频用户。他们更值得留。

而全员安抚的资源往往不够。

还有一点：流失要看长期趋势。

判断方法是看三个月后的数据。短期波动不代表流失。

而长期下降才是真问题。

最后一个：流失估算是概率不是确定。

判断方法是给一个区间。区间比单值更有决策价值。

而报单点数字的，容易被质疑。

还有一个：流失不一定立刻显现。

判断方法是看周活和月活的后续变化。滞后下降才是真流失。

而当月数据看不出问题，不代表没事。

还有一点：新用户的敏感度更高。

判断方法是看新老用户占比。新用户遇上故障更容易走。

而老用户因为习惯会容忍。

还有一个：竞争环境的影响。

判断方法是看同期是否有竞品推广。有的话流失更明显。

而这个因素是外部变量。

这是最大的一块，也是最容易被低估的。

判断方法是估算有多少用户在这个时段访问。这些是直接受影响的人。

而这些人的去向，决定了长期损失。

流失率取决于业务的可替代性。

判断方法是看用户切换到别处有多容易。容易切换的，流失率高。

而独占性强的业务，流失率低。

还要算回访成本。

判断方法是估算把流失用户找回来要花多少。这个成本通常远高于留住。

而召回的效果还不一定好。

还有一个维度：口碑传播。

判断方法是看用户是否会主动讨论这次故障。讨论面越大，影响越广。

而这部分损失无法精确计算，只能估区间。

第四块：信誉与信任

还有一个：公开说明的质量影响很大。

判断方法是看是否有明确的说明。说明清楚的能挽回一部分信任。

而含糊的说明会加重不信任。

还有一点：后续的改进要能被看到。

判断方法是定期说明改进进展。持续可见比一次性声明有效。

而这部分需要主动去做。

最后一个：这一块要写进决策文档。

判断方法是明说这是估算。透明比假装精确好。

而隐瞒不确定性的，反而降低可信度。

还有一个：公开讨论的持续时间。

判断方法是看故障是否会被长期提及。持续时间越长，影响越大。

而这部分很难主动消除。

还有一点：对合作伙伴的影响。

判断方法是看是否有对外服务承诺。承诺没兑现要担责。

而这会影响后续合作。

还有一个：内部信任。

判断方法是看业务方是否还会给技术团队机会。信任受损会拖慢决策。

而这个成本最隐性。

这一块最难量化，但不能不算。

判断方法是看业务是否依赖信任。依赖信任的业务，损失更大。

而纯工具型业务的信任损失相对小。

对企业客户的业务，影响更持久。

判断方法是看是否有合同和服务承诺。有承诺的可能涉及赔付。

而赔付之外，还有续约率的影响。

对搜索引擎的影响也要算。

判断方法是看停机是否影响抓取。长时间不可访问会影响收录。

而这个影响会持续一段时间。

还有一个长期因素：下次决策会受影响。

判断方法是看这次故障是否会被反复提起。会的话，后续投入更容易通过。

而这也算一种成本，只是方向不同。

一个能套用的算法

还有一个：算法可以做成表格模板。

判断方法是把参数列好，填数字就能算。

而每次重新推导的，容易出错。

还有一点：把结果存档。

判断方法是保存每次算的过程和结论。

而日后业务变了能对照着看差异。

最后一个：算法要定期更新。

判断方法是业务变化后重算。用户价值和流水都会变。

而用一年前数据的，结论早就过期。

还有一个前提：数据要来自自己的系统。

判断方法是取真实流水和真实用户数。估算不如实测。

而用行业平均值算的，结论会偏。

还有一点：算法要能调整参数。

判断方法是把关键数字做成变量。不同场景改参数即可。

而写死的算法，用一次就废了。

还有一个：结果要能解释给别人听。

判断方法是每一步都能说明来源。说不清的部分要标出来。

而这决定了结论能不能被接受。

第一步，算出每小时的机会成本。

判断方法是取高峰时段的流水均摊到小时。这个数字作为基数。

而用低谷时段的，会严重低估。

第二步，加上人力成本。

判断方法是人数乘以人均时薪乘以预估工时。三个数都要估。

而这个数字通常比想象的大。

第三步，加上流失带来的长期损失。

判断方法是受影响用户数乘以流失率乘以单个用户的价值。

而这个值的计算需要用户生命周期数据。

第四步，加上信誉折损的估计值。

判断方法是按前述机会成本的一个比例估算。比例按业务类型取。

而这个比例没有标准答案，需要结合经验。

最后把四项相加，得到一个区间而不是一个点。

判断方法是给出上下限。区间比单点更诚实。

而只报一个数字的，容易被当成精确值。

不同业务的量级差别

还有一个：混合业务的损失要分类算。

判断方法是按业务线拆开。合并算会互相掩盖。

而分类之后才能看出哪块最脆弱。

还有一点：新业务和老业务的敏感度不同。

判断方法是分别评估。新业务基础薄，损失更明显。

而这会影响投入的先后顺序。

最后一个：把自己的业务归类清楚。

判断方法是按主要损失在哪一块判断。

而这决定了改进方向的优先级。

还有一个：社交类业务损失偏口碑。

判断方法是看用户是否会公开抱怨。公开的损失更大。

而这部分传播最快。

还有一点：企业服务损失偏合同。

判断方法是看是否有服务水平约定。有约定的按约定赔。

而约定的赔付往往有上限。

还有一个：内部工具的损失偏效率。

判断方法是把受影响的人时折成钱。折出来的数字通常不小。

而这部分最不容易被当回事。

交易型业务的损失集中在第一块。

判断方法是看是否有实时成交。有的话，停机等于直接损失。

而这类业务对可用性要求最高。

内容型业务的损失主要在第三块。

判断方法是看用户依赖程度。依赖高的，流失明显。

而这类的恢复相对容易，因为内容还在。

内部系统的损失集中在第二块。

判断方法是看有多少人受影响。受影响的人越多，人力成本越高。

而外部客户的感知较弱。

工具型业务的损失比较分散。

判断方法是看是否有替代方案。替代多的，流失率高但影响面小。

而这类业务的容错空间反而大一些。

算出来的损失如果高于冗余成本，就该考虑加一台。云途那条产品线从二十二元起步，多做一台备机的门槛并不高。

这个数字怎么用在决策上

最后一个：定期重算这个数字。

判断方法是每半年一次。

而业务变了，这个数也变了。

还有一个：数字要能落到具体动作。

判断方法是拿数字对应一个方案。不做就成了空谈。

而只给数字不给方案的，很难推动。

还有一点：把数字和预算放在一起比较。

判断方法是看投入产出比。差别明显就好决策。

而差别不明显的，可以先做便宜的方案。

最后一个：把结论写成一句话。

判断方法是能一句话说清停机一小时值多少。

而说不清的，说明还没算明白。

还有一个：拿这个数字和竞品的可用性对比。

判断方法是看同行的停机频率。对比能说明投入是否合理。

而这比自己拍脑袋准。

还有一点：把损失按年汇总。

判断方法是按预估的故障次数乘单次损失。年化之后压力更直观。

而单次数字容易被低估。

还有一个：把改进项的收益也算成区间。

判断方法是同样用上下限。两边都是区间才能比。

而只有一个确定数的结论，说服力不足。

第一个用途是判断冗余值不值。

判断方法是把冗余的年成本除以预估的故障次数。和单次损失对比。

而这个对比能给出明确答案。

第二个用途是判断迁移窗口。

判断方法是按损失的大小选时段。损失小的时段做迁移。

而选在高峰做的，等于白扔钱。

第三个用途是判断投入优先级。

判断方法是比较不同改进项的收益。收益大的先做。

而这个排序比凭感觉可靠。

第四个用途是说服业务方。

判断方法是拿出数字而不是形容词。数字更容易达成共识。

而说「损失很大」通常没人当真。

还有一个用途：确定恢复目标。

判断方法是按损失反推可接受的停机时长。超过这个时长就要上冗余。

而这个目标比拍脑袋定更合理。

几个常见的算错

还有一个：把期望当成实际。

判断方法是按最坏情况算。期望值只是参考。

而按最坏算的，方案会更稳健。

还有一点：忽略了恢复后的补偿成本。

判断方法是看是否要给用户补偿。补偿也是支出。

而这部分常在事后才想起来。

最后一个：算完要找人复核。

判断方法是让业务方看一遍。他们对流水更熟。

而两边数字对不上，就说明有一处理解错了。

还有一个：把计划内维护当成零损失。

判断方法是看维护期间业务是否可用。不可用就有损失。

而放在夜间也只能降低不能消除。

还有一点：忽略连锁故障。

判断方法是看是否有依赖关系。一处故障可能引发多处。

而这会让损失成倍增加。

还有一个：把恢复当成修复完成。

判断方法是看数据是否一致。不一致的还要修数据。

而修数据往往比修服务更久。

算错一：只算交易额。

判断方法是看有没有漏掉另外三块。漏掉的往往占大头。

而这个错误最普遍。

算错二：用全天平均算高峰。

判断方法是按实际停机时段取值。时段不同差别巨大。

而这个错误会让结论差好几倍。

算错三：把可延后的需求算成损失。

判断方法是区分即时需求和延迟需求。混在一起会高估。

而这个高估会导致过度投入。

算错四：忘了算恢复时间。

判断方法是把排查和恢复都算进去。实际停机时长往往更长。

而按故障发生时刻算的，会低估。

降低损失最直接的是把恢复时间压下去。rabisu那个按月付费的档环境独立，做恢复演练随时能来一次。

怎么降低停机损失

还有一个：把日志和监控做好。

判断方法是确认能快速定位。定位快的恢复也快。

而没有监控的，光找问题就要几个小时。

还有一点：把联系人和权限准备好。

判断方法是确认谁有权限操作。缺权限会卡住。

而这个卡壳最常见。

最后一个：把降级方案提前准备好。

判断方法是列出哪些功能可以关闭。

而临时想的，往往来不及。

还有一个：把关键路径做成可切换。

判断方法是看切换需要多久。能在分钟级切换的，损失可控。

而这需要提前做演练。

还有一点：把状态设计成可重建。

判断方法是看故障后能否重建。可重建的恢复更快。

而依赖现场状态的，恢复会拖长。

还有一个：把用户通知做好。

判断方法是看是否有公告渠道。及时通知能减少用户流失。

而这个动作几乎零成本。

第一个办法是缩短恢复时间。

判断方法是准备恢复预案。有预案的恢复快得多。

而这个投入产出比最高。

第二个办法是把损失转移到影响小的时段。

判断方法是把计划内维护放在低峰。这能避免大部分损失。

而计划外故障无法选择时段。

第三个办法是降低单点依赖。

判断方法是找出所有单点。每去掉一个，风险就降一档。

而单点往往不止一处。

第四个办法是做好降级方案。

判断方法是确认核心功能能给用户可用状态。降级比全挂好得多。

而这个方案常被忽略。

还有一个基础动作：把备份验证一遍。

判断方法是实际恢复一次。没验证过的备份不算备份。

而验证过的，恢复时间会准确很多。

把整篇收一句

最后一个提醒：这个数字不是用来吓人的。

判断方法是拿它做比较。

而有比较，决策才有依据。

停机损失由四块构成：直接交易、恢复人力、用户流失、信誉折损，只算第一块会低估好几倍。

算法是：高峰时段流水均摊成小时基数，加上人力和流失的长期损失，再按比例估信誉折损，四项相加得出区间。

这个数字的用途是：判断冗余值不值、选迁移时段、排投入优先级、定恢复目标。

最后一句：说不清停机损失多少，就没法判断任何一笔投入值不值。

本文只为提供市场讯息，所有内容及观点仅供参考，不构成投资建议，不代表本站观点和立场。投资者应自行决策与交易，对投资者交易形成的直接或间接损失，作者及本站将不承担任何责任！