网站打不开后的30分钟，是维护方最容易被指责、也最能体现专业度的窗口。此时的目标不是“30分钟内修好所有问题”，而是快速止血、控制影响、统一信息、保留证据，并为恢复争取时间。建议按“确认—分级—沟通—定位—处置—验证—复盘准备”推进。

0—2分钟：确认不是个例，保留现场。

维护方应立即用多网络、多地区、多终端访问，判断是全体用户还是局部用户异常；同时查看监控、状态页、DNS解析、证书有效期、CDN、负载均衡、应用、数据库和第三方依赖。记录首次发现时间、报错页面、影响范围、最近发布和配置变更。此时不要急着重启服务器或删除日志，先截图、保存错误信息、监控曲线和发布记录。很多故障不是“修不好”，而是现场被破坏后无法定位。

2—5分钟：定级并拉起事故群。

按影响面分级：全站不可用、核心功能不可用、部分地区或部分用户异常。立即建立事故沟通群，明确角色：一人指挥，一人技术排障，一人负责对外沟通和客服口径，一人记录时间线。同步升级路径：网络、DNS、CDN、云厂商、安全、数据库、研发负责人。若涉及登录、支付、数据安全或大面积用户投诉，应直接升级，不要层层等待。

5—10分钟：统一对外口径。

确认影响后，尽快更新状态页、公告、社媒和客服话术。首次公告应说明：已知问题、影响范围、正在处理、下一次更新时间。不要猜测原因，不要承诺未经验证的恢复时间，也不要用“系统升级”掩盖一切。客服需要拿到统一FAQ问答和升级窗口，避免不同渠道说法不一致。对内每5—10分钟同步一次进展，防止多头指挥。

10—20分钟：分层定位，优先回滚。

按“用户—DNS—CDN/WAF—负载均衡—Web/应用—缓存/队列—数据库—第三方依赖”逐层排查。重点看最近发布、配置变更、证书到期、域名解析、云资源状态、流量突增、攻击告警、磁盘和连接数、错误日志。若故障与最近变更高度相关，优先回滚；回滚前确认备份和影响范围。不要同时做多个高风险操作，每次只改一个变量并记录结果。

20—30分钟：处置、验证、准备复盘。

能回滚先回滚，能切流先切流，能降级先降级，例如启用静态页、只读模式、关闭非核心功能。恢复后必须验证：多地区访问、登录、下单、支付等核心链路，以及错误率、延迟和监控曲线，确认不是短暂恢复。若30分钟仍未恢复，应发布下一次更新，启动更高等级支持，并保留时间线和证据。若发现异常流量、勒索或数据泄露迹象，应先隔离取证，不随意删日志。恢复后尽快整理时间线、根因、影响、处置和改进项，明确负责人和截止时间。

FAQ问答

1.网站打不开，第一步是不是重启服务器？

不是。应先确认影响范围、保留现场并查看监控和最近变更。盲目重启可能丢失证据，甚至扩大故障。只有在明确服务假死、且有预案和回滚方案时，才按流程重启。

2.多久通知用户比较合适？

确认影响后5—10分钟内应发布首次公告；即使原因未明，也可先说明“已知问题、正在处理”。之后每15—30分钟更新一次，恢复后发布恢复公告和简要说明。

3.如何判断是自身问题，还是云厂商、DNS、CDN问题？

用多网络、多地区测试，检查DNS解析、证书、CDN回源、云厂商状态页和自身监控；同时核对最近发布、配置和错误日志。不要只等厂商回复，也不要只怀疑自己。

4.对外要不要公布详细原因？

首次公告不必猜测根因，重点说明影响和处置进展。根因应在验证后发布；涉及安全、用户数据或合规敏感信息时，应按公司统一口径处理。

5.30分钟还没恢复怎么办？

立即升级事故等级，拉入厂商和专家，优先切流、降级或回滚；保持固定节奏对外更新，指定唯一对外口径，并完整记录时间线，为后续复盘和问责改进做准备。