2026年5月19日Evgeny · 高级系统工程师

网站宕机 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 分钟算你自己的数

  1. 取过去 12 个月营收(或 MRR × 12)。
  2. 除以 8760 —— 得「平均小时」。
  3. 估最坏场景的峰值系数(大促、直播、season)。
  4. 若事故时有流量,加 20–40% 给广告与支持。
  5. 写一行数字给市场负责人——谈监控就有共同语言了。

比想象中更快回本的事

审计后我们常部署的组合:

  • 监控(可用性 + 服务器指标 + 钉钉/企微告警)—— 一个 evening 能搭好;
  • 页面与重查询缓存—— 负载降 5–15 倍;
  • 大投前压测—— 一天工作,省一个「503 早晨」;
  • 热备或自动扩容—— 峰值保险。

把实施成本与峰值 1 小时宕机对比——多数项目避免一次事故就回本

大促季前清单

  • 已算宕机小时成本(上文公式)
  • 告警:不可用、5xx、响应 > 2 秒
  • 压测负载 ≥ 预测 ×3
  • 值班人与「谁负责拉起站点」剧本
  • 备份与恢复——测过,不是口头
  • DNS/云厂商侧 DDoS 防护已开

要点

可靠性不是「IT 奢侈品」,是有 ROI 的营收保险。错误时机的一小时宕机,可能比一个月 infra 维护更贵——尤其算上广告、流失和丢单。

NineLab 帮你按商业模式算真实风险价,并在客户买单之前堵住瓶颈。联系我们

主题常见问题

流量形态与数据往往与生产不一致。需要场景、与线上一致的指标,以及可回滚的逐步加压。

常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。

不一定:失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。

垂直扩展与查询优化触顶,且数据增长在分片键上可预期时。

想把这些落地到你的系统里?

介绍一下你的现状 —— 我们会给出工作计划,以及值得写进 SLA/SLO 的可衡量指标。

查看全部:高负载

高负载2026年6月7日
工业物联网:为什么传感器试点进不了生产环境

工业 IoT 典型踩坑:从演示级设备到 1000+ 传感器。停机成本估算、MQTT/边缘/云架构, 以及试点扩容前的检查清单。

阅读文章
高负载2026年5月31日
Marketplace 微服务:什么时候必要,什么时候是多余的数百万

给 CEO/CTO 的决策框架:5 个该拆服务的信号、4 个过早微服务化的征兆, 以及「一上来就做京东架构」在 startup 上的真实成本。

阅读文章
高负载2026年5月21日
Redis、队列与缓存:不买新机器也能让网站快 10 倍

「服务器正常」却为何还慢:Redis 该缓存什么、哪些任务进队列、何时上 CDN, 以及不增加主机账单时可预期的优化数字。

阅读文章
高负载2026年5月17日
千万级投放遇上 503:技术未就绪如何烧掉营销预算

解析广告战役因网站宕机而打水漂的原因:量化真实损失、三大系统性成因,以及大促/大投前 基础设施准备清单。

阅读文章