研发平台可用性统计要剔除异常时段，核心是先固定公式、时间窗和统计范围，再按事先约定的分类准入规则判断每段异常是否剔除、剔除在分母还是分子，最后并列披露剔除前后两个数值。本文围绕研发管理平台自身运行可用性，给出可复算、可留痕的剔除口径与计算步骤。
要点总览（TL;DR）
- 剔除异常时段前先固定可用性公式、统计时间窗和服务范围，否则剔除结果无法复算，也无法跨月比较。
- 异常按五类处理：计划内维护、外部依赖故障、不可抗力通常从分母剔除并附证据；平台自身缺陷不剔除只标注；误报核实后不计入。
- 计算时先合并重叠区间再扣减，剔除后可用性 = 1 −（原始不可用时长 − 可剔除时长）÷（统计总时长 − 可剔除时长）。
- 剔除前后两个数值并列披露，并把剔除比例作为治理指标按月监控，防止分类认定变宽。
- 目标值结合历史基线与业务影响设定，配合MTTR、故障次数一起看，不套用通用达标线。
评估目标：可用性统计要回答什么问题
本文的评估对象是研发管理平台自身的运行可用性，包括登录、工作项、附件、接口等用户可感知的服务入口。业务流水线的构建成功率、发布交付时效属于持续交付范畴，不纳入这套统计。明确这一边界，是为了让指标回答一个具体问题：在平台团队可控的范围内，用户能否稳定地访问和使用平台。
剔除异常时段的目的，是让指标反映平台可控范围内的表现。例如云厂商区域故障、企业网络中断导致的不可用，平台团队既无法预防也难以在故障期间消除，将其计入会压低指标，却无法指向可改进的动作。剔除的价值在于把改进注意力集中到平台自身能改变的部分。
剔除同时存在滥用风险。如果规则模糊、事后临时认定，剔除就可能变成美化数字的手段，把平台自身缺陷包装成外部原因。控制风险的做法有三条：剔除规则在统计周期开始前书面约定；每段剔除都有起止时间、影响范围、责任归属和证据；剔除结果经过指定角色审批并留痕。规则一旦确定，周期内不因结果好坏而调整。
指标与范围：可用性公式、时间窗与统计边界
可用性有两种常用算法，选哪一种要在规则中写明，不能混用。第一种是时间口径：可用性 = 1 − 不可用时长 ÷ 统计总时长。第二种是请求口径：可用性 = 成功请求数 ÷ 总请求数，等价于 1 − 失败请求数 ÷ 总请求数。时间口径适合用户量相对稳定、故障表现为整体不可访问的平台；请求口径适合调用量大、局部失败可被请求量稀释的场景。两种口径对同一故障给出的数值可能不同，因此披露时必须注明所用公式。
统计时间窗建议固定为自然月，便于与月度汇报对齐；也可以采用滚动30天，平滑单月波动。无论选哪种，都要写明起止时刻和时区，例如“每月1日00:00至月末最后一日24:00，北京时间”。时长单位统一为分钟，可用性百分比保留两位小数，避免不同报告之间精度不一致。
服务范围要列成清单，逐项统计或按约定权重合成。常见范围包括：登录与认证、核心工作项读写、附件上传下载、开放接口、通知与消息。范围清单的作用是防止口径漂移——某月只统计登录、下月统计全部模块，数值就不可比。若采用加权合成，权重需事先确定并说明依据。
“不可用”需要判定阈值，否则短暂抖动与真实故障无法区分。可选的判定方式包括：核心入口连续失败达到设定时长（如连续3分钟以上无法完成登录）、监控探测错误率超过设定门槛（如5分钟内错误率高于50%）、或关键接口连续多次超时。阈值应结合平台实际探测频率设定，并在规则中写明探测点位置和探测频率，保证他人可以复现判定过程。
| 定义项 | 建议口径 | 需在规则中写明 |
|---|---|---|
| 公式 | 时间口径或请求口径，二选一 | 所选公式及选择理由 |
| 时间窗 | 自然月或滚动30天 | 起止时刻、时区 |
| 单位与精度 | 分钟；百分比保留两位小数 | 四舍五入规则 |
| 服务范围 | 登录、工作项、附件、接口等清单 | 逐项统计或加权合成及权重 |
| 不可用判定 | 连续失败时长或错误率门槛 | 探测点、探测频率、阈值 |
异常时段分类与准入条件
异常时段按成因分为五类，每类的剔除结论不同。分类的意义在于把“是否剔除”从个案争论变成规则判断：同类异常按同一结论处理，减少人为裁量空间。
| 异常类别 | 典型情形 | 剔除结论 | 证据要求 | 确认角色 |
|---|---|---|---|---|
| 计划内维护 | 版本升级、数据库变更、证书更换 | 从分母剔除，需提前公告 | 变更单、维护公告、实际起止记录 | 平台负责人审批 |
| 外部依赖故障 | 云厂商区域故障、企业网络中断、第三方认证服务不可用 | 按约定处理，通常从分母剔除并标注 | 厂商故障公告、网络侧记录、监控截图 | 运维负责人确认 |
| 不可抗力 | 机房断电、自然灾害 | 从分母剔除 | 事件记录、第三方证明 | 平台负责人审批 |
| 平台自身缺陷 | 代码缺陷、配置错误、容量不足 | 不剔除，仅标注 | 故障复盘、工单记录 | 仅登记，不进入剔除审批 |
| 误报 | 监控抖动、探测点自身异常 | 核实后不计入不可用 | 监控复核记录、人工验证 | 运维负责人确认 |
平台自身缺陷原则上不剔除，这是整套规则的关键约束。缺陷导致的不可用正是平台团队应当改进的对象，把它剔除会让指标失去改进指向。允许的做法是标注成因，在报告中单列“自身缺陷导致的不可用时长”，供复盘使用。
计划内维护从分母剔除的前提是提前公告并控制在约定窗口内。未公告的变更、超出窗口的维护，按普通故障处理。外部依赖故障的剔除需要证据链完整：厂商公告的时间段要与平台受影响时间段对应，不能仅凭“当时云上好像有问题”认定。
剔除审批建议设置两级：运维负责人确认事实与证据，平台负责人审批是否剔除。每条记录至少包含异常编号、分类、起止时间、影响模块、影响用户或请求量、证据链接、审批人和审批时间。审批记录与统计结果一并归档，供后续审计复算。
数据口径与证据：时间戳、影响面与缺失值处理
剔除结论要可复算，前提是数据字段齐全。每段异常至少记录以下字段：异常开始时间戳、结束时间戳、影响模块、影响用户数或请求量、发现方式（监控告警、用户报障、巡检）、成因分类、证据链接、审批状态。时间戳统一到同一时区并精确到分钟，跨时区团队尤其要在规则中写明换算方式。
数据来源建议双源交叉核对：监控系统给出客观的探测失败记录，工单系统给出用户报障与处理过程。两者时间不一致时，以监控记录为准界定不可用区间，工单记录用于补充影响面信息。只有单源记录时，在字段中标注来源，便于复核时判断可信度。
缺失值的处理要保守。结束时间缺失时，按“截至恢复确认时刻仍不可用”计入，待补充后再调整，并在当期报告中标注待补；影响面缺失时，按该模块全量用户计，宁可高估影响也不低估。保守处理的目的是防止因数据不全而少算不可用时长。
重叠异常需要先合并再扣减。同一时间段内既有外部依赖故障又有平台缺陷时，合并为一段，按对平台更不利的结论处理（即不剔除），避免同一分钟被两次扣除导致可用性虚高。合并规则应写成：取并集区间，分类按“不可剔除优先”原则确定。
计算步骤：从原始时长到剔除后可用性
计算按固定顺序执行，每一步的产物都可被他人复核。
- 确定统计总时长。自然月按实际天数换算为分钟，例如30天为43200分钟，31天为44640分钟。
- 汇总不可用时段。依据监控与工单记录，列出所有满足不可用判定阈值的区间，形成原始不可用清单。
- 按分类标记可剔除段。对照异常分类准入表，逐段标注“可剔除”或“不可剔除”，并附证据与审批状态。
- 合并重叠区间。对可剔除段与不可剔除段分别做区间合并，消除重复计时。
- 计算剔除前可用性。剔除前可用性 = 1 − 原始不可用总时长 ÷ 统计总时长。
- 计算剔除后可用性。剔除后可用性 = 1 − （原始不可用总时长 − 可剔除时长）÷ （统计总时长 − 可剔除时长）。
- 并列披露两个数值，并附剔除时长、剔除比例和不可剔除的自身缺陷时长。
剔除落在分母还是分子，取决于异常性质。计划内维护和不可抗力通常从分母剔除，即统计总时长减去维护时长，同时该时段也不计入不可用；外部依赖故障按约定处理，若约定为平台不可控，同样从分母剔除并标注；平台自身缺陷不从分子剔除，其时长完整保留在不可用部分。规则中要明确写出每类异常的落点，避免计算时临时判断。
边界情况需要预设处理方式。统计窗内无任何请求时，请求口径的分母为零，此时不计算可用性，标注“无流量”而非记为100%；时间口径下统计总时长不会为零，但若整月处于维护状态，应单独说明。统计窗内发生跨月故障时，按分钟切分到各自月份，不整段计入某一个月。
算例：一个月的异常时段剔除全过程
以下数值均为假设，仅用于演示计算过程，不作为任何达标线。设统计窗为30天，即43200分钟，采用时间口径。
| 编号 | 异常情形 | 起止 | 时长（分钟） | 分类 | 是否剔除 | 落点 |
|---|---|---|---|---|---|---|
| A | 版本升级停机 | 第8日 22:00–23:00 | 60 | 计划内维护 | 是 | 分母 |
| B | 云厂商区域网络故障 | 第15日 10:00–12:30 | 150 | 外部依赖故障 | 是 | 分母 |
| C | 工作项服务缺陷导致登录后报错 | 第22日 09:00–10:20 | 80 | 平台自身缺陷 | 否 | 保留在分子侧 |
| D | 监控误报，人工核实服务正常 | 第26日 14:00–14:10 | 10 | 误报 | 核实后不计入 | — |
剔除前：原始不可用时长 = 60 + 150 + 80 = 290分钟（D经核实不计入）。剔除前可用性 = 1 − 290 ÷ 43200 ≈ 99.33%。
剔除后：可剔除时长 = 60 + 150 = 210分钟。剔除后可用性 = 1 − （290 − 210）÷ （43200 − 210） = 1 − 80 ÷ 42990 ≈ 99.81%。
两个数值并列披露，同时注明：剔除时长210分钟，剔除比例约0.49%；自身缺陷导致的不可用80分钟，已单列供复盘。易错点有三处：把C也剔除会让剔除后数值虚高到接近100%；D若不核实直接计入会多算10分钟；若A与B在时间上重叠而未合并，会重复扣减。算例中的阈值和数值均为演示假设，实际目标值应结合历史基线与业务影响另行设定。
解读与限制：剔除后的指标怎么用、不能怎么用
剔除后指标反映平台可控范围内的表现，适合用于平台团队的改进跟踪和内部承诺。它不能替代全口径披露：对外报告或管理层汇报应同时给出剔除前数值，让读者看到用户实际经历的整体可用性。只报剔除后数值，等于隐藏了外部依赖和自身缺陷的真实影响。
剔除比例本身应作为治理指标持续监控。若某月剔除比例明显高于历史水平，需要核查是外部环境确实恶化，还是分类认定变宽。建议按月记录剔除时长、剔除比例和各类异常占比，形成趋势线，异常抬升时触发规则复核。
可用性只是运行质量的一个维度，不宜作为唯一绩效依据。建议配合平均恢复时间（MTTR）、故障次数、自身缺陷占比等指标一起看：可用性高但故障频发、恢复缓慢，说明稳定性依赖运气而非机制。目标值应结合平台历史基线、业务高峰时段和用户影响面设定，不同平台、不同部署方式的基线差异较大，套用统一达标线容易失真。
在异常记录与审批留痕环节，可以用工作项和文档承载整套流程：每段异常建一条工作项，字段包括起止时间、影响模块、分类、证据附件和审批状态；剔除规则、分类准入表和月度统计报告存放在文档中，版本可追溯。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署可实现故障转移、数据容灾和零停机服务升级。这些部署与架构特性影响平台自身的故障形态和统计范围，规则设计时可一并纳入考虑。
常见问题
计划内维护没有提前公告，还能从分母剔除吗？
按本文口径不能。计划内维护从分母剔除的前提是提前公告并控制在约定窗口内，两者缺一不可。未公告的变更、超出窗口的维护，按普通故障处理，时长完整保留在不可用部分。
如果确实发生了未公告的停机，建议在复盘中记录原因，并在下一周期把公告流程纳入变更管理要求，而不是在当期临时补认定。
同一时段既有云厂商故障又有平台自身缺陷，怎么算？
先合并区间再判定，取并集后按“不可剔除优先”处理，即整段按平台自身缺陷对待，不从分子剔除。这样处理是为了避免同一分钟被两次扣减导致可用性虚高。
合并后的记录中仍应分别注明两类成因和各自的证据，便于复盘时区分外部影响与自身问题。
统计窗内没有任何请求，可用性记100%还是不计？
请求口径下分母为零，此时不计算可用性，标注“无流量”，不能记为100%。时间口径下统计总时长不会为零，但若整月处于维护状态，应单独说明，避免读者误读为正常运行。
剔除比例多少算正常？超过多少要复核规则？
没有通用数值。建议先积累3至6个月的历史数据形成基线，再设定触发复核的阈值，例如某月剔除比例明显高于历史区间上限时启动规则复核。
复核的重点是分类认定是否变宽、证据是否完整，而不是直接调整阈值去迁就结果。
异常记录和审批留痕放在哪里比较合适？
可以用工作项承载每段异常，字段包括起止时间、影响模块、分类、证据附件和审批状态；剔除规则、分类准入表和月度报告存放在文档中，保留版本记录。
ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署可实现故障转移、数据容灾和零停机服务升级。部署方式会影响平台自身的故障形态，规则设计时可一并考虑。
