千万级投放遇上 503：技术未就绪如何烧掉营销预算

市场负责人按下投放开关。预算已批、素材就绪、人群已圈选。流量涌入——网站挂了。钱花了，订单没有。三个部门同时找责任人。

这不是偶发个案。每当市场与基础设施活在两个世界，就会重演。

从事发内部看——按分钟复盘

设想：广告战役筹备两个月。Brief、策略、层层审批。80 万元投放在百度推广、巨量引擎和 KOL 种草上。启动时间——周一上午 9 点，恰逢大促预热或 618 前哨战。

接下来一周都在扯皮：市场指向 IT，IT 说不知道有投放，老板看着数字沉默。

为什么恢复之后钱还在烧

多数人以为：「网站挂了一阵子，又起来了——顶多丢几个线索」。真实损失往往是这个直觉的数倍。

宕机当下的直接损失

广告平台不知道你的落地页不可用。百度推广、巨量引擎会继续展示广告，对错误页面的点击照样扣费。视出价和量级，可能在几小时内白白烧掉 4,000–24,000 元——没有一个有效触达。

恢复之后的隐性损失

这往往更贵。平台算法会实时评估落地页质量。广告指向不可用站点时，系统记录低质量流量并下调创意/账户权重。站点恢复后，单次点击成本可能比事故前高 1.5–2 倍，效果可持续 2–3 周。

受众与再营销的损失

用户点了广告，看到 503 就离开。再营销像素把他记成「到访者」，却没有真实互动。针对这批「受众」的二次投放，是在向只记住你网站报错的人花钱。

汇总算账

反复发生的三个原因

1. 市场与 IT 没有对话

市场负责人跟老板批了预算，排了档期，配好了广告——却没人问技术团队：流量涨 10–20 倍，服务器扛得住吗？

IT 侧同样不知道周一大投放。基础设施按日均流量 + 20–30% 余量跑着。

这是组织层面的系统性问题，不是某个人的过失——但买单的是业务和具体的人民币。

2. 容量按「正常流量」设计

多数站点按平均负载 + 小幅冗余部署。广告带来 10–20 倍访客时，单机或固定规格集群扛不住。

云厂商未必有错：你买的是某一档容量。真正的问题在无法弹性扩展的架构——没有缓存、没有队列、无法在峰值快速加实例。

3. 上线前没有做压测

压力测试回答一个问题：「如果同时来 X 个用户，会发生什么？」多数公司不做——不是不想，而是没把这一步写进投放 SOP。

于是真实容量上限，往往在预算已经开始燃烧时才被看见。

真实案例：我们怎么修的

一家公司在同类事故后找到我们。新品在百度推广上线，前三天投了约 340 万元。第一天高峰宕机 6 小时。

审计发现：

• 容量按 200 并发设计——广告带来 1,800。
• 产品页未缓存：每个请求直打数据库。
• 关键表缺索引——高负载下全表扫描。
• 没有监控：40 分钟后才从企业微信群得知宕机。

我们做了什么：

• 迁移到可自动水平扩展的云架构。
• 配置 Redis 缓存——数据库负载降 12 倍。
• 补索引并优化最重 SQL。
• 部署监控，临界负载前 2 分钟告警到钉钉/企业微信。

二次投放零故障。转化率提升 23%——仅仅因为页面从 9 秒稳定到 1.4 秒。

清单：大投放/大促前必查

请记住

广告与基础设施是一个系统。不同步时，创意再好、人群再准、出价再精，钱也会蒸发。

大投前检查服务器 readiness，不是 paranoid——它和批预算、写文案一样，是 campaign 准备的一部分。

压测 1–2 天。收拾一次「投放日 503」的后遗症——往往是数周和数十万元损失。

想确认站点能否扛住广告流量？NineLab 提供压测与基础设施审计，找出瓶颈并量化当前容量上限。联系我们。