官网做完上线真正的运维才开始。线上故障的典型形态是客户打来电话说网站打不开而你手上没有任何数据——不知道是挂了、慢了还是只有他那边打不开。这篇把监控配置与排查链路拆成可落地的清单。一、先分清四类打不开1. 全站不可用DNS 解析失败、源站宕机、证书过期、CDN 回源异常。2. 区域性不可用某一线路或运营商异常常见于单线机房。3. 单页面故障某个路由 500、某个接口超时首页正常。4. 只有部分人打不开本地网络、浏览器缓存、企业防火墙或代理拦截。四类的处理路径完全不同。排查的第一动作永远是先量另一边——从外部探针和另一台网络环境的机器各测一次别只在你自己的浏览器里刷新。二、最小可用的监控配置2.1 外部拨测必配HTTP 探测对首页与 2~3 个关键页产品页、表单页每 1~5 分钟探测一次判据不要只看状态码同时校验响应体的关键词例如页面底部的备案号或版权行否则 302 到维护页也会被判为正常多节点至少覆盖两个不同运营商 / 地域证书到期提醒提前 30 天、7 天各提醒一次。2.2 服务端指标进程存活、CPU / 内存 / 磁盘水位、连接数与慢查询应用日志按级别落盘错误日志单独切分定时任务备份、清理、报表失败要告警——这类静默失败往往几天后才被发现。2.3 前端与业务指标最容易被忽略JS 错误上报window.onerrorunhandledrejection上报到自有端点核心交互埋点表单提交成功率、支付/预约等关键动作的完成率真实用户性能首屏、LCP、接口 P95 延迟。机房视角一切正常、用户端很慢通常就出在这里。三、故障定位链路按顺序做别跳① 是否全站 → 外部拨测 多线路 ping / curl ② 是解析还是源站 → dig/nslookup 比对权威 DNS 与本地结果 ③ 是回源还是 CDN → 绕过 CDN 直连源站比对响应头 ④ 是网络还是应用 → 看源站错误日志与慢查询 ⑤ 是后端还是前端 → 对比接口耗时与首屏渲染耗时 ⑥ 是所有人还是部分人 → 索要用户侧信息网络、浏览器、截图、时间点每一步只回答一个问题避免同时改三处导致无法归因。四、三个高频坑坑 1只看首页探活。首页是静态缓存最不容易挂真正会挂的是查询、下单、提交这类动态路径探测要覆盖它们。坑 2告警噪音淹没真故障。同一故障 5 分钟内重复告警几十条值班人很快就不看了。要做告警聚合与抑制同一目标、同一类型在窗口期内合并为一条。坑 3没有回滚路径。发布即故障时最快的恢复动作是回滚不是现场调试。发布流程里必须同时准备上一个版本的制品、数据库变更的可逆方案、回滚命令。五、上线前后各一次检查清单式上线前全局 404 / 500 页面已定制且不暴露堆栈信息HTTPS 强制跳转、HSTS 与证书链完整站点地图、robots 与结构化数据校验通过关键表单有防重复提交与服务端校验上线后外部拨测已配置并跑满 24 小时错误日志与前端异常上报接通备份任务已执行过一次并演练过恢复告警能真实触达值班人用一次人为触发验证小结可用性不是没出事而是出事时你有数据、有链路、有回滚。先把外部拨测和错误上报配上再谈优化。本文为技术笔记不含任何产品推荐。 
长河君 · 2026/10/14 0:45:22 · 阅读 1.2k 企业官网的可用性监控与故障排查清单：从告警配置到定位链路
官网做完上线真正的运维才开始。线上故障的典型形态是客户打来电话说网站打不开而你手上没有任何数据——不知道是挂了、慢了还是只有他那边打不开。这篇把监控配置与排查链路拆成可落地的清单。一、先分清四类打不开1. 全站不可用DNS 解析失败、源站宕机、证书过期、CDN 回源异常。2. 区域性不可用某一线路或运营商异常常见于单线机房。3. 单页面故障某个路由 500、某个接口超时首页正常。4. 只有部分人打不开本地网络、浏览器缓存、企业防火墙或代理拦截。四类的处理路径完全不同。排查的第一动作永远是先量另一边——从外部探针和另一台网络环境的机器各测一次别只在你自己的浏览器里刷新。二、最小可用的监控配置2.1 外部拨测必配HTTP 探测对首页与 2~3 个关键页产品页、表单页每 1~5 分钟探测一次判据不要只看状态码同时校验响应体的关键词例如页面底部的备案号或版权行否则 302 到维护页也会被判为正常多节点至少覆盖两个不同运营商 / 地域证书到期提醒提前 30 天、7 天各提醒一次。2.2 服务端指标进程存活、CPU / 内存 / 磁盘水位、连接数与慢查询应用日志按级别落盘错误日志单独切分定时任务备份、清理、报表失败要告警——这类静默失败往往几天后才被发现。2.3 前端与业务指标最容易被忽略JS 错误上报window.onerrorunhandledrejection上报到自有端点核心交互埋点表单提交成功率、支付/预约等关键动作的完成率真实用户性能首屏、LCP、接口 P95 延迟。机房视角一切正常、用户端很慢通常就出在这里。三、故障定位链路按顺序做别跳① 是否全站 → 外部拨测 多线路 ping / curl ② 是解析还是源站 → dig/nslookup 比对权威 DNS 与本地结果 ③ 是回源还是 CDN → 绕过 CDN 直连源站比对响应头 ④ 是网络还是应用 → 看源站错误日志与慢查询 ⑤ 是后端还是前端 → 对比接口耗时与首屏渲染耗时 ⑥ 是所有人还是部分人 → 索要用户侧信息网络、浏览器、截图、时间点每一步只回答一个问题避免同时改三处导致无法归因。四、三个高频坑坑 1只看首页探活。首页是静态缓存最不容易挂真正会挂的是查询、下单、提交这类动态路径探测要覆盖它们。坑 2告警噪音淹没真故障。同一故障 5 分钟内重复告警几十条值班人很快就不看了。要做告警聚合与抑制同一目标、同一类型在窗口期内合并为一条。坑 3没有回滚路径。发布即故障时最快的恢复动作是回滚不是现场调试。发布流程里必须同时准备上一个版本的制品、数据库变更的可逆方案、回滚命令。五、上线前后各一次检查清单式上线前全局 404 / 500 页面已定制且不暴露堆栈信息HTTPS 强制跳转、HSTS 与证书链完整站点地图、robots 与结构化数据校验通过关键表单有防重复提交与服务端校验上线后外部拨测已配置并跑满 24 小时错误日志与前端异常上报接通备份任务已执行过一次并演练过恢复告警能真实触达值班人用一次人为触发验证小结可用性不是没出事而是出事时你有数据、有链路、有回滚。先把外部拨测和错误上报配上再谈优化。本文为技术笔记不含任何产品推荐。