研发平台可用性指标建议以“可用时长÷应服务时长”为主指标，按平台核心入口、关键服务、单租户三个层级分别统计；应服务时长先扣除提前公告的计划维护窗口，非计划中断按分钟计入，数据缺失时段单独标注、不并入可用率。目标值按业务影响分级设定，例如核心入口月度不低于99.9%、一般服务不低于99.5%，再用连续多个周期的实测分布校准，避免把单一可用率当作全部绩效。
要点总览（TL;DR）
- 主指标用“可用率＝可用时长÷应服务时长”，按平台整体、核心服务、单租户三个层级分别统计，分母不同不能互相替代。
- 应服务时长先扣除提前公告的计划维护窗口，非计划中断按分钟全额计入；数据缺失时段单列标注，应服务时长为零时标注“不适用”，不记为100%。
- 目标值按业务影响分三级：核心入口月度不低于99.9%（约43分钟停机预算）、一般服务不低于99.5%（约216分钟）、非关键工具不低于99.0%（约432分钟），数值需用历史实测分布校准。
- 目标值要与恢复时长目标配套，新平台先设2–3个周期观察期，只统计不考核，积累分布后再定正式目标。
- 可用率只说明服务可访问的时间比例，需结合中断次数、MTTR、受影响用户比例和用户反馈综合判断，口径变更要留版本记录。
评估目标：先界定“平台可用”对谁意味着什么
可用性评估的第一步是把“平台可用”从一句笼统判断，收敛到具体的服务对象和用户动作。研发平台同时服务三类人：研发人员日常登录、查看工作项、编辑文档、调用接口；平台管理员负责部署、监控和故障处理；业务方在验收或季度评估时关注平台是否支撑了研发活动。三类人关心的“可用”并不相同，评估目标需要分别写清楚。
评估目标应当写成可判断的句子，而不是“保障平台稳定运行”这类无法验证的表述。例如：“核心入口在服务时段内可正常登录，并完成查看工作项、编辑文档两项主要操作”；“代码仓库接口在工作日9:00–21:00的请求成功率不低于设定目标”。判断句里包含对象、时间范围、动作和判定方式，后续的指标和口径才有落点。
本文讨论的是研发管理平台自身的运行可用性，包括登录入口、工作项、文档、接口等平台服务。交付流水线的构建、部署成功率属于持续交付与流水线管理主题，不在本文口径内。把两者混在一个可用率里，会让平台故障和流水线失败互相稀释，既看不清问题，也无法定出合理目标。
指标与范围：主指标、辅助指标和统计边界
可用率适合作为主指标，但它只回答“有多少时间可服务”，无法说明中断了几次、每次多长、影响了多少人。因此需要一组辅助指标共同构成评估清单，每个指标明确层级、定义和单位，避免把所有故障都塞进一个百分比。
| 指标 | 定义 | 统计层级 | 单位 |
|---|---|---|---|
| 可用率 | 可用时长÷应服务时长 | 平台整体、核心服务、单租户 | 百分比 |
| 中断次数 | 统计周期内非计划中断事件数，同一根因合并计一次 | 平台整体、核心服务 | 次 |
| 单次中断时长 | 从服务不可用到恢复可用的持续时间 | 事件级 | 分钟 |
| 恢复时长（MTTR） | 非计划中断时长合计÷中断次数 | 平台整体、核心服务 | 分钟 |
| 受影响用户比例 | 受影响用户数÷统计周期内活跃用户数 | 平台整体、单租户 | 百分比 |
| 误报/无效告警数 | 经确认未造成实际不可用的告警条数 | 平台整体 | 条 |
统计范围要在口径文档中一次写清。纳入的服务通常包括登录与统一认证、核心工作项读写、文档编辑与保存、对外接口；环境上一般只统计生产环境，预发和测试环境不计入正式可用率，若团队需要观察预发稳定性，可单列一套数据但不与生产合并。三个层级的关系是：平台整体看全部纳入服务的综合表现，核心服务按单个服务分别统计，单租户口径用于识别某个租户专属实例或专属配置下的可用性问题，三者分母不同，不能直接相加或互相替代。
数据口径：分子分母、时间窗与异常时段剔除规则
可用率要可复算，关键是固定时间窗、分子分母和异常时段的处理规则。建议按自然月统计，统一使用北京时间，起止时刻为当月1日00:00至次月1日00:00；需要滚动观察时可用滚动30天，但同一份报表内不混用两种时间窗。
公式为：可用率＝（应服务时长－非计划中断时长）÷应服务时长。应服务时长是分母，指平台按约定应当提供服务的总时长；非计划中断时长是分子中被扣减的部分，按分钟计。计划内维护窗口在提前公告后从分母中剔除，不计入中断；未提前公告的维护按非计划中断全额计入。这条规则需要在口径文档中写明公告提前量，例如提前24小时通知，避免事后把故障追认为维护。
取数来源建议明确优先级：优先使用真实请求日志计算请求成功率与不可用时段，其次用合成拨测验证入口可达性，告警事件作为中断识别的线索而非唯一依据。三种来源的覆盖范围不同，日志能反映真实用户请求，拨测能发现无人访问时段的故障，告警可能包含误报。口径文档应说明每种来源用于哪个指标，以及冲突时以哪个为准。
异常时段的处理需要单独规定：探测失败但无法确认服务不可用时，标注为“待确认”，确认前不计入中断也不计入可用；平台自身监控中断导致数据缺失的时段，标注为“数据缺失”，单列时长，不默认算作可用；统计周期内应服务时长为零时，不计算可用率，标注“不适用”，而不是记为100%。这些规则让报表在数据不完整时仍然可解释。
计算与评估步骤：从原始事件到可用率报表
同一套口径需要不同的人算出相同结果，计算流程应当固定为以下五步，并保留复核记录。
- 采集探测与事件数据，统一时间戳到同一时区，记录每条数据的来源和采集时间。
- 识别中断事件，按根因合并重复告警。同一数据库故障引发的多条告警合并为一次中断，起止时间取最早开始与最晚恢复。
- 判定计划内或非计划，套用剔除规则。核对维护公告记录，确认公告时间与维护窗口是否匹配。
- 按平台整体、核心服务、单租户三个层级汇总时长，计算可用率及中断次数、MTTR、受影响用户比例等辅助指标。
- 与目标值比对，输出达标或未达标结论，未达标时给出差距分钟数和主要中断事件清单。
复核环节建议每个周期抽取2–3个中断事件，核对起止时间、影响范围和根因归类是否与原始记录一致，复核人和复核日期记入报表。复核记录模板可包含事件编号、原始告警时间、确认开始时间、恢复时间、计入时长、复核结论六列，便于跨周期追溯。
当这些记录分散在告警系统、值班群和表格中时，口径落地容易走样。ONES 的工作项可用于登记每次中断事件，把开始时间、恢复时间、根因、影响范围作为字段固定下来；口径说明、目标值表和月度报表可以沉淀在 ONES 文档中，按版本留存。这样计算步骤中的“识别—判定—汇总—比对”有统一的记录载体，复核时能直接对照原始条目，而不是依赖个人记忆。
目标值设定：分级、依据与校准方法
目标值不宜全平台一个数字，也不宜凭印象拍板。建议按业务影响分三级设定：核心入口（登录、统一认证）关系所有人能否进入平台，目标最高；一般服务（工作项、文档等日常功能）次之；非关键工具（报表导出、辅助查询等）可适当放宽。以下数值为示例区间，需结合自身历史数据校准后使用。
| 服务级别 | 可用率目标（月度） | 对应停机预算 | 恢复时长目标 |
|---|---|---|---|
| 核心入口 | 不低于99.9% | 约43分钟/月 | 单次中断30分钟内恢复 |
| 一般服务 | 不低于99.5% | 约216分钟/月 | 单次中断2小时内恢复 |
| 非关键工具 | 不低于99.0% | 约432分钟/月 | 按排期修复 |
停机预算的换算方式是：（1－目标可用率）×应服务时长。以30天自然月、每天24小时计，应服务时长为43200分钟，99.9%对应约43分钟，99.5%对应约216分钟。把百分比换成分钟，团队才能判断一次故障是否已经用掉当月预算，也便于和恢复时长目标配套：只压可用率不压恢复速度，故障仍可能长时间挂着。
目标值的依据来自三处：历史实测分布，看过去6–12个月各月可用率的波动区间；用户可接受的中断时长，通过访谈或工单统计了解研发人员能容忍多长的登录中断；同类平台的常见区间，作为外部参照而非硬性标准。新平台或数据不足时，先设2–3个周期的观察期，只统计不考核，积累分布后再定正式目标。目标值还应每年或每半年复核一次，业务高峰、架构调整后及时调整。
例子：一个月的可用率如何算出来
假设某月为30天，平台按7×24小时提供服务，应服务总时长为30×24×60＝43200分钟。当月提前公告的计划维护窗口合计120分钟，非计划中断两次，分别为25分钟和35分钟，合计60分钟。
剔除维护后的应服务时长为43200－120＝43120分钟，可用时长为43120－60＝43060分钟，可用率＝43060÷43120≈99.86%。若核心入口目标为99.9%，当月停机预算约43分钟，实际非计划中断60分钟已超出预算，判定未达标，差距约17分钟。若把计划维护也计入分母，可用率变为（43200－60）÷43200≈99.86%，数值接近但含义不同：后一种算法把维护占用的时间也算作应服务时间，会低估维护窗口对分母的影响，在维护较多的月份差异更明显。两种口径不能混用于跨月比较。
这个算例同时说明辅助指标的必要性：可用率99.86%看似接近目标，但两次中断合计60分钟、MTTR为30分钟，恢复速度尚可，问题在于中断次数和单次时长需要进一步压缩。若只看百分比，容易忽略“差一点达标”背后的具体事件。
解读与限制：可用率能说明什么、不能说明什么
可用率回答的是“服务在多大比例的时间内可访问”，它不回答“访问后好不好用”。响应变慢、某个功能局部不可用、页面能打开但保存失败，这些情况可能不被计为中断，却直接影响研发人员的工作。因此可用率高不等于体验好，解读时要结合响应时间、功能成功率和用户反馈一起看。
探测点的位置和频率会改变结果。只从办公网拨测，可能漏掉外网或特定区域的访问问题；探测间隔5分钟，短于5分钟的中断可能被平滑掉。报表应说明探测覆盖范围、探测频率和判定阈值，让读者知道这个数字是在什么条件下得到的。指标用于发现问题和验收，不宜直接等同于团队绩效，否则容易诱发“缩短中断记录时间”而非真正缩短故障。
口径一旦确定，变更要留版本记录：改了什么规则、从哪个周期开始生效、新旧口径是否可比。跨周期比较时，若口径不同应注明，必要时按新口径重算历史数据再比较。综合判断时，把可用率、中断复盘结论、恢复时长和用户反馈放在一起看，才能形成对平台运行状况的完整认识。
常见问题
计划维护窗口没有提前公告，还能从分母里剔除吗？
不能。剔除的前提是提前公告，口径文档里要写明公告提前量，例如提前24小时通知。未按约定提前公告的维护，按非计划中断全额计入分子扣减，避免事后把故障追认为维护。实际操作中，维护公告记录应与维护窗口时间一一对应留存，复核时逐条核对公告时间是否满足提前量要求。
探测数据缺失的时段，应该算可用还是算不可用？
两种都不建议默认采用。平台自身监控中断导致数据缺失的时段，应标注为“数据缺失”并单列时长，不并入可用率计算；探测失败但无法确认服务不可用的，先标注“待确认”，确认前既不计入中断也不计入可用。这样报表在数据不完整时仍然可解释，也避免缺失时段被悄悄算成可用而虚高可用率。
新平台没有历史数据，目标值怎么定？
先设观察期，建议2–3个统计周期只统计不考核，积累各月可用率的实际分布后再定正式目标。观察期内可以参照同类平台的常见区间作为外部参照，但不作为硬性标准。正式目标确定后，每年或每半年复核一次，业务高峰、架构调整后及时调整，并把调整原因记入口径变更记录。
可用率达标了，为什么研发人员还是觉得平台不好用？
可用率只衡量服务可访问的时间比例，响应变慢、某个功能局部不可用、页面能打开但保存失败等情况可能不被计为中断，却直接影响使用。解读时应结合响应时间、功能成功率、中断复盘结论和用户反馈一起看。另外探测点位置和频率也会影响结果，只从办公网拨测可能漏掉外网访问问题，报表需说明探测覆盖范围和判定阈值。
跨月比较时口径改了，历史数据要不要重算？
口径变更要留版本记录，写清改了什么规则、从哪个周期开始生效。跨周期比较时若口径不同应注明；需要连续趋势判断时，建议按新口径重算历史数据再比较，否则数值波动可能来自规则变化而非实际运行状况。重算结果与原报表并存留存，便于追溯差异来源。
