企业官网建设流程全解析

官网做完上线，真正的运维才开始。线上故障的典型形态是：客户打来电话说"网站打不开"，而你手上没有任何数据——不知道是挂了、慢了，还是只有他那边打不开。这篇把监控配置与排查链路拆成可落地的清单。

一、先分清四类"打不开"

1. 全站不可用：DNS 解析失败、源站宕机、证书过期、CDN 回源异常。
2. 区域性不可用：某一线路或运营商异常，常见于单线机房。
3. 单页面故障：某个路由 500、某个接口超时，首页正常。
4. 只有部分人打不开：本地网络、浏览器缓存、企业防火墙或代理拦截。

四类的处理路径完全不同。排查的第一动作永远是：先量另一边——从外部探针和另一台网络环境的机器各测一次，别只在你自己的浏览器里刷新。

二、最小可用的监控配置

2.1 外部拨测（必配）

• HTTP 探测：对首页与 2~3 个关键页（产品页、表单页）每 1~5 分钟探测一次；
• 判据不要只看状态码：同时校验响应体的关键词（例如页面底部的备案号或版权行），否则 302 到维护页也会被判为"正常"；
• 多节点：至少覆盖两个不同运营商 / 地域；
• 证书到期提醒：提前 30 天、7 天各提醒一次。

2.2 服务端指标

• 进程存活、CPU / 内存 / 磁盘水位、连接数与慢查询；
• 应用日志按级别落盘，错误日志单独切分；
• 定时任务（备份、清理、报表）失败要告警——这类静默失败往往几天后才被发现。

2.3 前端与业务指标（最容易被忽略）

• JS 错误上报：window.onerror+unhandledrejection上报到自有端点；
• 核心交互埋点：表单提交成功率、支付/预约等关键动作的完成率；
• 真实用户性能：首屏、LCP、接口 P95 延迟。机房视角一切正常、用户端很慢，通常就出在这里。

三、故障定位链路（按顺序做，别跳）

① 是否全站？ → 外部拨测 + 多线路 ping / curl ② 是解析还是源站？ → dig/nslookup 比对权威 DNS 与本地结果 ③ 是回源还是 CDN？ → 绕过 CDN 直连源站比对响应头 ④ 是网络还是应用？ → 看源站错误日志与慢查询 ⑤ 是后端还是前端？ → 对比接口耗时与首屏渲染耗时 ⑥ 是所有人还是部分人？ → 索要用户侧信息：网络、浏览器、截图、时间点

每一步只回答一个问题，避免"同时改三处"导致无法归因。

四、三个高频坑

坑 1：只看首页探活。首页是静态缓存，最不容易挂；真正会挂的是查询、下单、提交这类动态路径，探测要覆盖它们。

坑 2：告警噪音淹没真故障。同一故障 5 分钟内重复告警几十条，值班人很快就不看了。要做告警聚合与抑制：同一目标、同一类型在窗口期内合并为一条。

坑 3：没有回滚路径。发布即故障时，最快的恢复动作是回滚，不是现场调试。发布流程里必须同时准备：上一个版本的制品、数据库变更的可逆方案、回滚命令。

五、上线前后各一次检查（清单式）

上线前

• 全局 404 / 500 页面已定制，且不暴露堆栈信息
• HTTPS 强制跳转、HSTS 与证书链完整
• 站点地图、robots 与结构化数据校验通过
• 关键表单有防重复提交与服务端校验

上线后

• 外部拨测已配置并跑满 24 小时
• 错误日志与前端异常上报接通
• 备份任务已执行过一次并演练过恢复
• 告警能真实触达值班人（用一次人为触发验证）

小结

可用性不是"没出事"，而是出事时你有数据、有链路、有回滚。先把外部拨测和错误上报配上，再谈优化。

本文为技术笔记，不含任何产品推荐。