网站可用性月报的价值不在于把数字做得好看，而在于让“这个月到底停了多少、该不该算、算多少”有据可查。按月核算的核心是两件事：一是统一统计口径，明确哪些时间计入分母、哪些请求算作失败；二是把计划内维护窗口从不可用时间里合规扣除，同时保留可审计的记录。很多团队月末对账时争议不断，根源往往不是技术问题，而是月初没有约定口径、维护窗口没有留痕、监控数据没有分层。本文围绕按月核算的完整流程，拆解指标定义、维护窗口扣除规则、数据采集与对账方法、月报呈现结构，并给出可直接落地的执行建议。

一、先定口径：可用性指标到底怎么算

可用性按月核算，第一步不是拉数据，而是写清楚公式。常见口径有三种：按时间计算、按请求计算、按业务可用性计算。三者结果可能相差几个百分点，混用就会导致月报无法对比。

第一，按时间口径适合基础设施层。公式为（当月总分钟数 ? 不可用分钟数 ? 合规扣除的维护分钟数）÷（当月总分钟数 ? 合规扣除的维护分钟数）× 100%。例如 30 天的月份共 43200 分钟，不可用 43 分钟、维护窗口扣除 120 分钟，则可用性为（43200 ? 43 ? 120）÷（43200 ? 120）≈ 99.90%。

第二，按请求口径适合应用与接口层。用成功请求数除以总请求数，通常以 5 分钟为聚合粒度，避免单次抖动放大误差。需要明确哪些状态码算失败：一般 5xx 全部计入，4xx 按约定处理（多数场景不计入，防止爬虫与扫描流量污染数据）。

第三，按业务可用性口径适合面向用户的页面。以关键路径（登录、下单、支付）的探测成功率为主，配合真实用户监控数据校正。它更贴近用户体验，但采集成本高，建议与请求口径并行展示。

口径确定后要写进月报首页，形成版本化文档。每次调整口径必须注明生效月份，历史数据不追溯重算，否则趋势图会失真。

二、维护窗口扣除：能扣什么、不能扣什么

维护窗口扣除是最容易产生争议的部分。对外承诺的可用性通常不包含计划内维护，但“计划内”需要同时满足多个条件，否则不应扣除。

第一，必须提前公告并留痕。一般要求提前至少 24 小时（涉及核心系统建议 72 小时）通过公告页、邮件或工单通知，记录包含开始时间、预计时长、影响范围、回滚方案。没有留痕的“临时维护”不能计入扣除。

第二，必须在约定窗口内执行。多数合同会把窗口限定在业务低峰期，例如每日 02:00–06:00，或每月固定不超过 4 小时。超出窗口的部分应计入不可用时间，不能顺延扣除。

第三，必须实际发生且不超预估。申报 120 分钟、实际停 40 分钟，只能扣 40 分钟；实际停 180 分钟，超出 60 分钟按不可用计。这一条能有效防止维护窗口被当成“免责额度”。

第四，紧急安全补丁与故障恢复不适用扣除。紧急变更虽然必要，但属于非计划中断，应老老实实计入不可用时间，并在月报中单列说明原因与改进措施。区分“计划内”与“紧急”的界限要在制度中写明，避免事后解释。

三、数据采集与月末对账：让数字经得起追问

可用性数据的可信度取决于采集链路是否完整。单一监控源容易漏报或误报，建议至少三条链路交叉验证。

第一，外部多节点探测。在三个以上地域部署 1 分钟粒度的 HTTP 探测，覆盖首页与关键接口，用于判断“服务是否可达”。探测点故障要能自动剔除，避免把监控自身问题误判为业务中断。

第二，服务端日志与网关指标。以网关的请求量、错误率、P95 延迟为主，用于计算请求口径可用性。日志要保留原始错误码，便于月末抽样复核失败请求的真实成因。

第三，事件工单与变更记录。所有中断必须关联工单，记录发现时间、恢复时间、影响范围、责任人与根因。月报中的不可用时长应与工单时长逐条对齐，差异超过 5 分钟必须说明。

月末对账建议固定流程：先冻结数据（每月 1 日 10:00 导出上月全量指标），再由运维与业务双方各自核算一遍，最后合并差异清单。对账差异通常集中在三处——监控漏报的短时抖动、跨零点的中断被计到两个月、维护窗口与故障时间重叠。跨零点事件应按实际分钟数拆分到对应月份，重叠部分优先计入不可用时间，不得重复扣除。

四、月报结构与呈现：从数字到可执行结论

一份能推动改进的月报，结构比精度更重要。建议固定五个板块，控制在两页以内。

第一，结论先行。首页给出当月可用性、目标值、达成情况、不可用总时长、扣除维护时长、未达标原因一句话概括。管理层通常只看这一页。

第二，趋势与对比。展示近 6 个月可用性曲线、与目标的差距、环比变化。曲线要标注口径版本与重大变更时间点，避免读者误读。

第三，事件明细。按影响时长排序列出当月全部中断，包含起止时间、持续分钟、影响用户比例、根因分类（变更、容量、依赖、人为）。TOP3 事件需附改进项、责任人与完成时限。

第四，维护窗口台账。列明申报时长、实际时长、扣除时长、公告链接，形成可审计凭证。

第五，下月计划与风险提示。包括已排期维护、潜在容量风险、未闭环改进项。月报不是终点，改进项的闭环率应作为下月跟踪指标。

需要强调，可用性目标不是越高越好。99.9% 对应每月约 43 分钟不可用，99.99% 对应约 4.3 分钟，成本相差数倍。目标应结合业务场景设定，内部系统与交易系统的标准必须分开。

FAQ问答

Q1：维护窗口扣除需要提前多久公告？

A：一般至少提前 24 小时，核心系统建议 72 小时，并通过公告页、邮件或工单留痕。没有留痕的维护不能计入扣除。

Q2：维护实际用时小于申报时长，按哪个扣除？

A：按实际发生时长扣除。申报 120 分钟、实际停 40 分钟只能扣 40 分钟，剩余部分不得留存为额度。

Q3：跨零点的中断如何分摊到月度报表？

A：按实际分钟数拆分到对应月份，分别计入各自的不可用时长。跨月部分不得整段计入某一个月。

Q4：紧急安全补丁停机能否算作维护窗口？

A：不能。紧急变更属于非计划中断，应计入不可用时间，并在月报中单列原因与改进措施。

Q5：按时间和按请求两种口径结果差异大，以哪个为准？

A：以合同或 SLA 约定为准，未约定时建议以请求口径为主、时间口径为辅并行展示。两者口径必须在月报中同时注明，不得混用。

总之，网站可用性月报的质量取决于口径统一、留痕完整、对账可复核。建议本月就完成三件事：把可用性公式与维护窗口规则写成版本化文档并公示；为每条中断建立工单与时间戳，确保月末能逐条对齐；固定每月 1 日冻结数据、双方对账的流程。坚持三个月，月报就会从“解释数字”变成“驱动改进”的管理工具。