每家主机商都会公布一个可用性数字，但很少有人公布它是怎么测量的，这就让这些数字根本无法比较：只统计自家官网彻底中断的服务商，永远会胜过那些把某个城市里一家上游的性能下降也算进去的服务商。本文就是我们状态页背后的方法论：探针部署在哪里，什么算作故障，部分性能下降如何计分，以及为什么只有提前公告的维护，才不会被算进我们的停机时间。
从外部测量，每 30 秒一次
从网络内部测得的可用性只是一种自我评估。我们的可用性由探针来测量，这些探针租自三家互不相关的服务商，分布在三个大洲（欧洲、北美、亚洲），没有一个位于我们自己的数据中心里。每隔 30 秒，每个探针都会检查每一个组件：向每个节点上的金丝雀 VPS 发起一次 HTTP 请求，与 API 完成一次 TCP 握手，向每个解析器发起一次 DNS 查询，通过每家上游发出一次 BGP 可见的 ping，以及登录一次控制面板。状态页展示的是三个探针结果的中位数；原始结果会保存两年。
什么是组件
状态页共列出 40 个组件：六个节点各有网络边缘、VPS 宿主机、独立服务器交付、Windows RDP 和存储层，部署了 GPU 的节点另有 GPU 节点；全局层面则有网站与控制面板、API、开通、支付、DNS 和工单系统。组件是指能够独立发生故障的最小单元。“法兰克福网络”性能下降而“法兰克福存储”仍然是绿色，比一盏笼统的“法兰克福”指示灯能告诉您更多信息。
正常、性能下降、中断
- 正常运行：所有探针都在该组件的延迟预算之内成功（HTTP 为 200 ms，来自最近探针的 ping 为 50 ms）。
- 性能下降：至少有一个探针连续两次检查失败，或者所有探针虽然都成功，但超出了延迟预算。某一家上游丢包率升高、API 变慢、存储节点在负载下重建，都属于这一类。性能下降的时间按一半的权重计入可用性扣减。
- 中断：三个探针都连续两次检查失败，也就是已确认一分钟不可达。中断时间按全额权重计算。
要求连续两次失败而不是一次，是有意为之：丢掉单个探测包并不算故障，而一个不停闪烁的页面，是没有人会信任的页面。代价是，故障要在开始 60 秒后才会显示出来。
百分比是怎么算出来的
对每个组件而言，月度可用性等于 1 − (down_minutes + 0.5 × degraded_minutes) / minutes_in_month。节点整体的数字，是各组件按其所影响的客户数量加权后的平均值，因此，洛杉矶一个存储节点出现性能下降，所占的权重要小于控制面板出现性能下降。一个月 99.99% 的可用性，大约相当于 4 分钟已确认的停机，或 8 分钟的性能下降。我们在公布汇总数字的同时，也公布每个组件各自的数字，正是为了让汇总数字无法掩盖任何问题。
什么算作故障
任何组件处于性能下降或中断状态超过五分钟，就会自动创建一条故障记录，其开始时间取自第一个失败的探针，而不是人工发现问题的时刻。值班工程师会在故障页面上实时发布进展；凡是中断超过十五分钟的故障，会在五个工作日内发布事后复盘。故障记录绝不会被删除；历史页面可以一直回溯到网站上线之初。
维护：提前 72 小时公告，否则计入停机
计划内维护只有在开始前至少 72 小时已发布到状态页，并注明维护窗口和预期影响时，才会被排除在可用性计算之外，而且只排除公告窗口之内的那些分钟。紧急维护（无法等待的安全补丁）与其他停机一样计算在内。这条规则让激励机制保持诚实：我们可以围绕客户来安排计划，而不是围绕统计数字来安排。
哪些不在测量范围内
您自己的服务器。探针测试的是我们的网络、存储层和控制平面，而不是您运行的业务负载。服务器因为磁盘写满而不再响应，不会成为状态页上的故障，尽管控制面板会向您告警。同样，针对某一位客户的攻击如果被防护系统吸收，只要没有影响到其他人，就不算故障；DDoS 防护那篇文章解释了为什么这就是我们的目标。
这些数据如何用于 SLA
条款中的 SLA 补偿，用的正是这同一套数字：您的服务器所在节点的月度数字，按上述权重计算，并不存在另一套可能与公开页面不一致的“SLA 测量”。如果状态页显示您所在节点上个月为 99.9%，补偿会自动计入您的余额，您无需申请。