网站所有者通常通过客户发现网站宕机的方式得知自己的网站宕机：通过支持邮件、退款通知，或第二天早晨分析仪表板中出现的结账下降数据。到那时，事故已经发生数小时且收入已经损失。
网站可用性监控是提前捕捉宕机事件的实践。但“网站是否在线”实际上是一个比看起来更难回答的问题。网站可能返回200 OK，但结账按钮损坏。网站可能从美国可访问，而欧洲不可。网站可能技术上在线，但用户因DNS提供商超时或凌晨2点SSL证书过期而无法正常使用。
本指南涵盖网站可用性监控的运营方面：检查什么，从哪里检查，频率如何，以及警报触发时该做什么。它为自行运营网站的所有者而非拥有专用仪表墙的SRE团队编写。目标是设置一个你可以信任的监控，然后直到它提醒你之前都能忽略它。
“可用性”的实际含义
“服务器响应”和“用户可以购买东西”之间存在差距。可用性监控就是活跃在这一差距之中。
一个简单的正常运行时间监控检查会ping你的URL并寻找200状态码。这是最低标准。它检测灾难性故障（服务器宕机、DNS损坏、网络不可达），却漏掉了更细微的问题：结账时支付处理器返回500错误，CDN配置错误导致空白页面，JavaScript错误使Safari上的登录按钮失效。
真正的可用性监控在多个检查层面叠加，使“网站在线”意味着真实用户使用真实浏览器、在真实位置，能够完成他们想做的事。Dotcom-Monitor词汇表有更完整的网站可用性定义，如果你需要正式版本。
一个常见的真实宕机模式：周五晚上发布部署了一个新的分析标签。HTML依然返回每个区域的200 OK，所以基础运行时间工具整个周末都显示正常。周一早上，支持部门票据爆满，因为第三方标签阻止了Safari上结账表单的提交处理。真实浏览器对结账页的检测会在一个轮询周期内捕捉到此失败。仅HTTP检测无法做到。
为什么可用性监控重要
停机成本因业务不同而有巨大差异，但损害类别是一致的：交易丢失、服务水平协议违约、品牌声誉受损、搜索排名因爬虫在长时间宕机期间访问错误页面而受罚，以及全员响应事故的内部成本。
对于电商网站，即使在高峰流量期间宕机几分钟也可能意味着数千美元的订单损失。对于SaaS提供商，持续一次宕机可能触发服务等级协议抵扣，并侵蚀多年建立的客户信任。对于媒体和出版网站，突发新闻周期中的宕机意味着流量彻底流失。
可用性监控缩短了问题发生和修复之间的时间窗口。该检测平均时间（MTTD）往往是减少事件总影响的最大杠杆。
可用性监控如何工作
大多数可用性监控依赖合成检测：由分布在全球的监控节点自动发送请求。这些检测以固定间隔运行——从几秒到几分钟不等——并记录目标是否在可接受时间内正确响应。
典型检测包括某地理位置的监控代理向你的URL发送HTTP请求，然后根据一套规则评估响应。是否返回了2xx状态码，还是触发了关键服务器错误？响应时间是否低于阈值？页面是否包含预期内容？页面上的所有资源是否成功加载？
检测失败时，监控系统通常不会立即触发警报。它通常会从同一节点重试，并且同样重要的是从不同节点重试。这可以过滤瞬时网络故障和监控节点本身的局部问题，否则会产生持续的误报警。只有在多个地点确认失败时，系统才会升级为警报。
如何监控网站正常运行时间：每个网站需要的五种检查
标准建议是“监控正常运行时间”。这会遗漏大部分故障面。下面是五种检测类型，它们能捕获网站所有者在生产中实际看到的宕机。
1. HTTP(S)状态检查
基础检查。访问一个URL，期望2xx响应，其他情况发警报。配置首页、定价页、结账页及任何与付费流量关联的落地页。此举能捕捉硬宕机和SSL握手失败。
从多个地点运行。一个美国数据中心的检查会显示“在线”，而悉尼客户看到CloudFront错误。
2. DNS解析检查
无法解析的网站等同于不存在，哪怕服务器健康。DNS问题通常因提供商宕机（Route 53曾出现过数次）、域名过期或记录变更后的传播问题引起。
DNS监控检查会针对几个公共解析器解析你的域名，并在答案意外变化或查询失败时发警报。
3. SSL证书有效性
证书会过期，会被吊销，会在Let’s Encrypt续期失败时被错误配置。遇到过期证书警告的访客会立即流失，他们不会点击“高级 > 仍然继续”。
SSL证书监控检查证书链、过期日期和吊销状态。将过期警报设置为30天、14天、7天前触发。你需要有时间无事故地更换证书。
4. 全页真实浏览器检查
200响应不等于页面正常工作。现代网站依赖JavaScript包、第三方脚本（分析、支付、聊天）和CDN资源。任一失败都会导致HTML依旧返回2xx，但页面失效。
真实浏览器网页监控以Chrome的方式加载页面，执行JavaScript，并确认关键DOM元素出现。这类检测捕捉“网站看似损坏”的问题，是纯HTTP检查漏掉的。
5. 关键事务检查
SaaS应用最重要的检查是“用户能否登录”。电商网站则是“用户能否完成结账”。这些是多步骤流程，涉及会话、表单提交、API调用及最终确认页。
合成监控以脚本执行用户旅程（登录、搜索、加入购物车、结账）并在任一步骤失败时报警。Dotcom-Monitor的EveryStep允许你在真实浏览器中录制这些流程，无需编写代码。
如果只设置一项超出基础HTTP的检查，请选它。事务监控最接近实际收入信号。
选择监控间隔和地点
从哪里检查
单一监控地点是监控的单点故障。如果你的检查节点在弗吉尼亚，且AWS us-east-1有区域故障，将产生错误宕机警报。如果节点在弗吉尼亚，而CDN欧洲边缘降级，你将错过真实宕机。
解决方法是在多地理位置分布检测。Dotcom-Monitor的全球监控网络在北美、欧洲、亚太和南美的数据中心运行检测。
小型网站以三到五个地点足够。挑选主要客户群附近的点，以及一个边缘点监测网络路径问题。不要花钱买30个地点的监控，如果客户全部集中在一国。
实用规则：当至少两个地点在30–60秒窗口报告失败时发警报。该窗口约为两个连续的1分钟检测周期，过滤瞬时单节点故障，同时快速捕获真实宕机。
检查频率
检查频率权衡成本与检测时间。常见间隔：
- 1分钟：收入页面（结账、登录、付费流量落地页）。
- 5分钟：主营销页面及API监控
- 15分钟：次要页面、内部工具和低流量内容。
5分钟检测意味着宕机可能持续5分钟你才得知。该窗口的成本取决于受影响页面每分钟带来的收入。Dotcom-Monitor的可用性计算器帮你基于SLA估算。
1分钟检测成本更高（部分工具按检测计费，其他按监控器计费）。对绝大多数小站，三个收入路径1分钟覆盖，其他处5分钟覆盖是理想方案。
真正引起注意的警报路由
这里的失败模式是警报疲劳。如果监控频繁因每个小故障提醒，你会忽视它，真实宕机时也反应迟钝。几个实用规则：
设定N中M政策。不要单个失败检测就报警。连续3次检查中2次失败才报警（或5次中3次）。这大幅减少误报且不明显延迟真实报警。
区分关键与非关键。结账出错警报应在凌晨3点电话通知。营销页面响应变慢警报可白天在聊天渠道通知。为不同类型警报设置独立路由。Dotcom-Monitor警报功能支持按监控器渠道分配、升级链及上下班时间规则。
计划维护期使用抑制窗口。若发布预计有30秒波动，维护期间抑制相关监控警报，不要禁用。抑制应自动过期。
延迟升级。首个联系人5分钟内未确认，通知第二人。15分钟未确认通知第三人。打断会议无妨，错过宕机不可。
设置死人的开关。监控工具不报警不代表站点正常。设置心跳检测，10分钟无检测则告警。这捕获监控供应商自身故障。
分层警报渠道。关键警报用电话或短信，而非邮件。邮件适合日报汇总及99.95% SLA违约报告。警告放入嘈杂的Slack频道没问题，凌晨3点电话报警应该是真的问题。
警报触发时该做什么
警报是过程的开始，不是结束。提前写好三类最可能警报的处置流程。目标是移除事故前5分钟的决策负担。
“网站宕机”警报的最简运行手册：
- 打开监控仪表盘。确认至少两个地点失败后再视为真实故障。
- 检查最近部署。若发布在30分钟内，先回滚再调查。
- 查上游：DNS提供商状态页、CDN状态页、托管商状态页。大多数宕机源自其他服务故障。
- 若为第三方问题，发布到你自己的状态页，停止自行修复尝试。
- 若为本方问题，查看应用日志错误激增，定位失败服务，重启或回滚。
- 解决后做15分钟事故总结，记录失败项、发现方式、修复过程，避免三个月后忘记细节。
常见故障模式及表现
一份简短的实地指南，使警报不成为你首次见到故障症状的时刻。
过期SSL证书。所有HTTPS检查同时失败。若你提供端口80检测，HTTP检查仍可通过。修复：更换证书。预防：T-30、T-14、T-7天的过期警报。
DNS提供商宕机。部分检查失败，部分通过，区域无清晰规律。TTL决定用户视角宕机持续时长。修复：更换提供商或等待恢复。预防：同一域名设置辅助DNS提供商。
CDN区域性故障。某地区检测失败其他通过。页面返回5xx或挂起。修复：清理CDN缓存或切回源站。预防：多区域检测，分钟级发现。
部署导致JavaScript包损坏。HTTP检测通过（200 OK），真实浏览器检测失败，因关键DOM元素缺失。表现：客户反馈“按钮不工作”。修复：回滚。预防：关键页真实浏览器检测及通过合成检测成功方可部署。
第三方脚本超时。页面加载缓慢。事务检测在依赖脚本的步骤（聊天、小工具、分析、A/B测试）间歇失败。修复：脚本异步加载，设置超时，如非必要则移除。预防：关键页面加载时间警报。
如何选择合适的工具
市场上有几十种选项。UptimeRobot和Pingdom擅长基础正常运行时间监控。StatusCake、Site24x7和Uptrends在价格和功能广度上竞争。Datadog Synthetics和New Relic Synthetics适合已有APM平台的团队。
评估顺序问题：
- 是否从客户实际所在区域进行检测？
- 是否支持真实浏览器检查及多步骤事务，而非仅HTTP？
- 警报是否集成实际使用的渠道（短信、电话、PagerDuty、Slack）？
- 是否提供客户可订阅的公共状态页？
- 关键检测1分钟频率的价格如何？
Dotcom-Monitor提供全栈单平台：正常运行时间、合成监控、Web应用监控、API，外加警报层和正常运行时间及SLA报告。查看定价了解1分钟多检测覆盖适合你的站点情况。
本周行动计划
对你的前三大收入页面从至少三个地理位置设置1分钟HTTP(S)检测。添加SSL过期监控。在最重要事务（登录或结账）添加真实浏览器检测。配置基于2中3失败策略的短信警报。写下每个警报触发时的处置方案。
