网站宕机 1 小时值多少钱:用三个例子算清楚
「网站挂了一小时——没什么大不了。」在算账之前大家都这么说。宕机不是 IT 周报里的空白,而是你仍在付工资、广告和租金,却收不到客户钱的那段时间——他们可能已经去了竞品。
本文给老板和市场一个简单公式、三种业务模型的估算,以及 GA 里看不到的隐性损失。

2026 年为什么又值得算这笔账
大促季前后,云厂商链路故障、DDoS 与 CDN 回源问题仍会波及电商、金融与 SaaS——哪怕你的业务本身「不大」,只要堆在单点 infra 上,同样在风险区。
对任何企业的教训一样:巨头在运营商/云层面抖一下,你单机无冗余的站点更脆弱。问题不是「会不会挂」,而是「挂一小时值多少人民币」。
基础公式
第一版估算够用:
1 小时宕机成本 ≈ (年营收 / 8760) × 峰值系数
8760 是一年的小时数。峰值系数 表示大促、投放或旺季那一小时有多「贵」:
- 普通工作日 — 1.0;
- 广告投放、店庆 — 3–8;
- 618、双 11、电视/直播带货 — 最高约 15。
公式不含全部间接效应,但 10 分钟能给出数量级——足够推动监控、冗余和压测预算。
例 1:服装电商
假设: 年营收 960 万元,毛利率 35%,活动日流量为平日 6 倍。
平均每小时营收:9,600,000 / 8760 ≈ 1,100 元
活动峰值 1 小时(系数 5):≈ 5,500 元
投放日宕机 4 小时:≈ 2.2 万元 错失营收
* 不含烧掉的广告费与退款
若同期百度/信息流日预算 1.6 万元,还有 2,500–4,000 元 点在 503 上。一个「倒霉的上午」轻松超过 2.4 万元。
例 2:B2B 服务,官网获客
假设: 日均 40 条线索,10% 成交,客单价 14 万元,工作日 8 小时。
- 每小时线索:40 / 8 = 5
- 期望每小时营收:(5 × 10%) × 140,000 = 7 万元(均值)
- 考虑销售周期,更 realistic 区间:3.5–7 万元/工作小时
这里更痛的是 SLA 违约:大客户等方案,页面静默,人去了竞品。丢一单就覆盖几个月 infra 支出。
例 3:订阅制 SaaS
假设: 2,000 付费客户,79 元/月,API 对他们的业务关键。
MRR ≈ 15.8 万元。全库「平均一小时订阅费」很小。但 API 不可用一小时意味着:
- 支持工单暴增;
- 退款/补偿请求;
- 事故后一周内 1–3% churn。
若流失 2%:40 × 79 × 12 ≈ 3.8 万元/年 营收——一次 poorly handled incident 的代价。对 SaaS,声誉与流失 常比「那一小时」更贵。
隐性损失:营收报表里看不到的
广告与市场
广告账户不会在站点挂掉时自动停投。点击照扣,转化归零。算法还会降质量分——恢复后 1–2 周 CPC 更高。
SEO 与自然流量
跳出率上升、深度下降——搜索引擎的信号。效果不在事故当天,而是 2–4 周后流量下滑。
支持与运营
客服与 IM 爆炸。销售去灭火而不是关单。5 人团队一小时额外成本 1,200–3,200 元。
法务与合作伙伴
处理个人信息或签 SLA 的客户——宕机可能意味着违约金与合同终止;涉及 PIPL/等保时还有合规后果。
15 分钟算你自己的数
- 取过去 12 个月营收(或 MRR × 12)。
- 除以 8760 —— 得「平均小时」。
- 估最坏场景的峰值系数(大促、直播、season)。
- 若事故时有流量,加 20–40% 给广告与支持。
- 写一行数字给市场负责人——谈监控就有共同语言了。
比想象中更快回本的事
审计后我们常部署的组合:
- 监控(可用性 + 服务器指标 + 钉钉/企微告警)—— 一个 evening 能搭好;
- 页面与重查询缓存—— 负载降 5–15 倍;
- 大投前压测—— 一天工作,省一个「503 早晨」;
- 热备或自动扩容—— 峰值保险。
把实施成本与峰值 1 小时宕机对比——多数项目避免一次事故就回本。
大促季前清单
- 已算宕机小时成本(上文公式)
- 告警:不可用、5xx、响应 > 2 秒
- 压测负载 ≥ 预测 ×3
- 值班人与「谁负责拉起站点」剧本
- 备份与恢复——测过,不是口头
- DNS/云厂商侧 DDoS 防护已开
要点
可靠性不是「IT 奢侈品」,是有 ROI 的营收保险。错误时机的一小时宕机,可能比一个月 infra 维护更贵——尤其算上广告、流失和丢单。
NineLab 帮你按商业模式算真实风险价,并在客户买单之前堵住瓶颈。联系我们。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标,以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定:失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶,且数据增长在分片键上可预期时。