最佳实践以最大限度减少网站停机时间

2025年10月20日，影响AWS us-east-1区域DynamoDB端点的DNS解析失败，引发Snapchat、Venmo、Roblox及数千个较小服务数小时的中断。这些团队没有选择糟糕的托管，也没有忘记监控。唯一的共享依赖失败了，所有叠加在其上的服务一起宕机。

这就是网站宕机的不舒服真相：它很少来自你正在监控的那个点。它来自下午4点出错的部署，周六过期的TLS证书，你的自动扩展器迟到30秒才响应的流量激增。诸如“选择好的主机”之类的泛泛建议，面对这些问题时毫无用处。

如果你想防止网站宕机，需要这些管控措施：冗余设计避免单点故障导致停机，支持故障切换的DNS，部署无需停机，流量激增预备，以及比客户更早告知你的监控。

宕机一小时的实际成本

正常运行时间目标用“九”来表示，其背后的计算比看上去更严苛。每增加一个“九”，允许的宕机时间就减少10倍：

换算成金钱，风险变得具体。ITIC年度调查显示，90%以上的中大型企业的宕机小时成本超过30万美元。计算你的数字比多数团队想象的简单：全年在线收入除以8760，得出基础小时收入，但宕机很少发生在普通时段。一家年销售额500万美元的商店，在随机一小时内大约损失570美元，而在销售高峰时段则是其20倍，且未计算SLA补偿、恢复费用及流失客户。

这个数学有两个实际用途。首先，明确选择目标：对大多数业务网站，三个九是合理目标；收入关键路径四个九；五个九是预算决定，不是默认选项。其次，核对供应商承诺与补偿额度；我们的SLA违规计算器可完成转换，我们关于宕机成本的指南深入解析了收入模型。

网站为什么会宕机

预防始于诚实列出原因。大多数网站宕机归于五大类：

• 变更。 部署、配置编辑、模式迁移、依赖升级。谷歌SRE研究指出大约70%的宕机源自生产系统的变更，这使你的发布流程成为你拥有的最大宕机杠杆。
• 容量。 发布、活动或病毒式传播引发的流量激增，超出基础设施承载能力。
• 基础设施。 硬件故障、主机宕机、磁盘满、供应商内部网络分区。
• 依赖。 DNS服务商、CDN、支付API、认证服务、过期TLS证书。2021年6月的Fastly宕机在几秒内使Reddit、gov.uk和纽约时报下线，且他们没有做任何变更。
• 攻击。 DDoS洪水和被利用漏洞压垮或破坏堆栈。

注意缺失什么：“糟糕的主机”并非单独类别。主机质量重要，但它体现于基础设施和容量内，没有优质主机能保护你免于自身部署错误或DNS服务商的故障。以下实践专门对应这五大类。

构建冗余，确保一次故障仍为一次故障

冗余是组件故障与停机的界限。目标简单但需纪律：用户到收入之间无单点故障。

逐层检查堆栈：

• 应用服务器。 至少运行两个实例，负载均衡器后配置，规模保证即使失去一个高峰期依然生存（N+1原则）。跨可用区部署，确保数据中心事件只影响一个实例。
• 带健康检查的负载均衡。 负载均衡器仅在健康检查实际验证应用而非端口时防止宕机。定位就绪状态URL以证明应用能响应流量，分离数据库流的合成检查，设置阈值让慢实例先被剔除，用户察觉前。
• 数据层。 运行数据库副本，自动故障转移，把备份视为未经测试的传言，直到你恢复一个。备份恢复时间应明确，而非意外发现。
• 多区域。 这是昂贵层级。多数团队无需主动-主动设置，但另一个地点的暖备份，通过复制保持同步、DNS故障切换可访问，能把区域云宕机从数小时缩短到几分钟，前提是故障转移经过演练。

从未切换过的冗余是假设，不是保障。像备份一样定期安排故障转移演练：在生产时段有意杀死一个实例，观察系统是否自愈。

事件记载中有个警示：冗余基础设施往往共用控制平面。Fastly有大量冗余硬件，但一个潜在软件缺陷在客户合理配置变更触发下，瞬时影响了其全球约85%的网络。把配置、部署工具和DNS当成各自需要冗余策略的层。

托管Web应用时如何降低宕机风险

托管决策决定你的宕机下限。签约任何供应商前，怀疑态度看SLA：99.9%仍允许每年8.77小时合同认可宕机，典型补救是远低于宕机成本的服务抵扣。看透营销数字，关注运营信号：公开状态页含真实事件历史，支持团队凌晨3点能用工程师而非脚本响应，以及架构选项（可用区、负载均衡、自动扩展）支持上述冗余设计。

然后有目的地部署工作负载。将应用和数据库分开在不同实例，避免一个内存泄漏饿死另一个。优选允许容量无迁移扩展的供应商及方案，因为压力下重新平台是小宕机变长宕机的路径。

如何从当前托管商获得更多正常运行时间

你很少需要迁移来减少宕机风险。多数供应商已提供工具，少数默认启用。按回报粗略排序：

1. 步骤1：开启自动备份，然后测试恢复。 计时。该时长即最坏恢复时间，事故期间发现需6小时恢复成本极高。
2. 步骤2：在提供商负载均衡器后加入第二应用实例。 即便是入门计划通常只需勾选几美元，能把实例故障改写为无事件。
3. 步骤3：站点前置CDN。 缓存页面（尤其配置了stale-if-error）支持源站困难时继续响应，缓解流量激增及短时宕机。
4. 步骤4：开启自动扩展，最少两个实例。 单实例开始意味着自动扩展触发前站点已降级。
5. 步骤5：从供应商网络外部监控。 主机自身状态面板经常延迟显示故障，且常不展现你的具体影响。外部可用性监控捕捉内部视角看不到的问题。
6. 步骤6：提前了解升级路径。 知道如何联系真实支持、你的计划权益、及供应商事故更新渠道。

让DNS成为弹性层而非单点故障

DNS是团队常忘的层，因为它宕机少，但一旦崩溃则一切皆废：完美的服务器、健康的数据库，却没人能访问。2016年Dyn遭受DDoS攻击即为明证。Twitter、Spotify、GitHub下线数小时，而使用二级DNS的公司仍可访问。

三项实践将DNS从隐患变为主动防御：

• 运行二级DNS服务商。 配置第二权威服务商自动同步区域。多数递归解析器会自动尝试第二套域名服务器，失去一个服务商通常只造成一次支持票，不影响访问。
• 设置灵活的TTL。 主要A记录24小时TTL意味着故障转移需最长一天才遍及所有解析器。常改记录要保持300秒或更低，计划迁移时先降TTL。
• 使用带健康检查的DNS故障转移。 多数托管DNS能探测源站并自动切换到备用IP或区域。配合上文冗余的暖备方案，才是实现多区域自动故障转移机制。

最后闭环：内部网络看不见解析问题，故多外部视角的DNS监控是确认记录对真实用户响应正确的实用方法。

如何更新网站而不影响运行

既然变更导致大多数宕机，本指南最具杠杆的实践是永不要求停机的发布流程，并能秒级回滚。

常规内容更新门槛简单：通过CMS发布不应影响可用性。通过CDN或全页缓存提供页面，变更在站点副本上预演，原子性推送上线。风险较高的工作，如WordPress插件和主题更新，应先在预演环境完成，且总在非高峰时段。

应用发布业界标准模式是与在线版本并行部署，而非覆盖：

1. 步骤1：搭建并行环境。 蓝绿部署维护两个相同生产环境，一个在线一个空闲。使用编排平台的团队可采用滚动替换，原则相同，始终有版本响应流量。
2. 步骤2：数据库变更向下兼容。 模式迁移令“直接回滚”失败。使用扩展收缩模式：先加新列表，发布兼容新旧代码，后续无引用时删除旧结构。
3. 步骤3：部署到空闲环境。 或投放到5%-10%的金丝雀实例。用户继续访问现版本，新版本启动，预热缓存，连接依赖。
4. 步骤4：流量到来前冒烟测试。 用合成检测访问关键页面，跑脚本登录、结账，验证API响应。此处失败仅需重新部署。
5. 步骤5：渐进转移流量。 通过负载均衡权重切换10%流量，监控错误率和响应时间，对比旧版本，合格后升至50%和100%。
6. 步骤6：保持即时回滚准备。 旧环境保持运行直至新发布验证成功。回滚应是一秒级的流量切换，而非小时级重建。

不可避免的维护停机要诚实：返回HTTP 503并带Retry-After头，确保搜索引擎视为临时，向用户展示预计恢复时间，提前公告。良好沟通的20分钟计划维护，远优于未解释的5分钟。

如何防止流量激增期间网站宕机

流量激增是最可预测的宕机原因，因为你通常是制造者：产品发布、促销、打折、邮件轰炸。存活下来是排练问题，不是运气。

• 将工作推向边缘。 CDN缓存页面能吸收将压垮源站的激增。页面请求降至源站请求的极少数，区分临时加服务器与从容应对激增。
• 为计划事件预先扩容。 自动扩展响应需数分钟，但电视广告激增秒到。预知事件提前扩容，让自动扩展处理误差。
• 负载测试需是预估峰值2到3倍。 预估多低少高。远超预期测试揭露真实瓶颈，常非Web层而是数据库、内部API或串行第三方调用。
• 排队溢出流量。 极端事件使用按限速放行的候客厅，保证放行用户站点可用，优于全站宕机。
• 优雅降级。 通过特性开关有序关闭推荐、搜索建议、个性化，确保结账正常。降级次序必须提前冷静设计，而非激增时匆忙决定。

监控告警：比用户更早发现问题

上述实践均降低宕机概率。监控限制宕机时长，因为总宕机时间=检测时间+响应时间+修复时间，而检测是三者中最经济压缩的。

构建监控层级顺序：

1. 步骤1：从多地区外部检查可用性。 内部监控与基础设施共命运，和它一起损坏。多个地理位置独立合成监控捕捉区域故障和供应商问题，内部仪表盘看不到。检查如何在地点间轮动也重要；详见并行与轮转监控权衡。
2. 步骤2：检查每一层可能失败，不只首页。 首页200状态不代表结账可用。监控DNS解析、TLS证书过期、前端依赖的API，以及真实浏览器中用户交易（登录、购买）。
3. 步骤3：检查频率匹配正常运行目标。 5分钟检查防御不了每月仅允许4.4分钟宕机的四个九SLA。对收入路径用1分钟检查，其他放宽间隔。
4. 步骤4：症状告警，发出警报前验证。 仅用户可见错误召唤值班工程师，不因CPU抖动报警。触发前需第二地点确认，排除大部分误报。详见我们关于网站监控告警的指南，包含升级设计与噪声消除。

算算自己堆栈：5分钟检查加15分钟人工响应，修复前已20分钟宕机。1分钟检查且升级路径紧凑，事故缩短至5分钟以内。

事故响应：缩短未能避免的宕机时间

部分宕机难免，事先演练的团队恢复时间仅为常人的一小部分。三大要素：

• 可预测故障的运行手册。 证书过期、数据库切换、区域宕机、DDoS攻击：均有精确命令及决策点清单。凌晨3点，无人即兴应变好。
• 真实更新的状态页。 宕机期间沉默放大名誉损失。数分钟内确认，设定更新频率，并用人类语言书写。
• 无责追责的事后复盘及截止日期。 每起事件生成带负责人和日期的改进行动，否则复演。持续季度跟踪平均检测和平均恢复时间；两数揭示整体系统是否进步。

Dotcom-Monitor如何助你减少宕机

Dotcom-Monitor是本指南阐述的所有检测层：正常运行监控平台，从全球多点监控位置观察你的网站，是你自身基础设施不具备的外部视角。

• 真实浏览器监控。 从外部监控地点用真实浏览器实例加载页面，捕获渲染时间、元素级错误及瀑布图和视频，助力故障根因分析。
• EveryStep脚本实现事务监控。 录制登录、搜索、结账等多步骤流程，多区域持续回放Web应用监控。这是部署章节提及的冒烟测试，全天候运行。
• 多协议覆盖。 HTTP(S)、REST和SOAP API、DNS解析、TLS证书有效性及过期、FTP、邮件和TCP/ICMP基础设施检查，确保依赖层与页面同时被监控。
• 为正常运行设计的告警。 多点验证告警、升级组及与你值班团队使用的呼叫和聊天工具集成。

检测时间是宕机公式中的首个数字，Dotcom-Monitor的使命是保持它最小。

总结

减少网站宕机不是单一决策，而是一系列决策叠加：冗余设计让组件故障无感，次级DNS让常被忽视的层不致抹除你，蓝绿发布让最常见的宕机源头（自身变更）不再失控，流量激增演练让你对激增心中有数，外部监控让漏网事件都量化为分钟。

从最划算入手：本周测试恢复备份，今天检查DNS TTL，下次部署前在收入关键路径上加外部监控。每阻止一小时宕机，价值远超实施这些措施所花的午后时光。

常见问题解答