研发平台可用性评估要先把“平台自身可服务”定义清楚，再按统一口径计算。核心公式是可用性=可服务时长÷应服务时长，同时结合故障次数与时长、MTTR、关键操作成功率和响应时延分位值判断。本文给出评估范围、指标用途、分母与时间窗规则、从取数到结论的步骤，并用一个月的示例演示计算，最后说明百分比之外需要留意的限制。
要点总览（TL;DR）
- 可用性评估先界定对象：登录、页面访问、核心操作、接口调用属于平台自身运行，交付流水线等业务环节单独统计。
- 核心公式为可用性=可服务时长÷应服务时长，需事先写明计划内维护是否剔除、时间窗长度与采样粒度，跨周期保持一致。
- 辅助指标包括故障次数与累计故障时长、MTTR、MTBF、关键操作成功率、响应时延P95/P99，各自回答不同问题，不宜互相替代。
- 分母为零或数据不足时标注为不可计算，不记为100%可用；相同百分比下需结合故障时段、单次最长中断和降级情形分层解读。
- 评估结果落到监控补点、应急预案、容量调整和复盘任务上，下一周期复查，形成从度量到改进的闭环。
评估目标：先界定“平台可用”指什么
可用性评估的第一步是确定评什么。研发平台承载需求、任务、代码、测试、文档等多种工作，但可用性评估的对象是平台自身能否正常提供服务，包括登录、页面访问、核心操作和接口调用。交付流水线的构建成功率、发布节奏等属于研发交付环节的指标，应单独统计，避免与平台可用性混在一个百分比里。
评估对象可以按服务面拆分。登录与身份认证决定用户能否进入平台；页面访问反映主要工作界面能否打开；核心操作指创建任务、更新状态、提交代码关联、查询报表等高频动作；接口调用面向集成系统和自动化脚本。四类对象的失败影响不同，评估时应分别记录，再决定是否合并为平台整体可用性。
评估视角同样需要事先约定。用户感知视角关注“我要做的事能不能做成”，适合收集工单和反馈；系统监控视角关注服务进程、接口返回码和响应时间，适合计算客观指标；运维值班视角关注告警、处置和恢复过程，适合统计故障时长与恢复效率。三条线各有盲区，评估方案应说明以哪条线为主、哪些数据用于交叉验证。
本次评估要回答的问题可以列成清单：评估覆盖哪些服务和用户群体；统计时间窗是哪一段；计划内维护如何处理；哪些故障计入不可用；关键操作的判定标准是什么；结果与哪个基线比较。问题清单确定后，后续指标和口径才有落点。
| 评估对象 | 判定内容 | 主要证据来源 | 边界说明 |
|---|---|---|---|
| 登录与身份认证 | 用户能否完成登录、单点登录是否正常 | 认证服务监控、登录失败工单 | 不包含用户密码错误等个人原因 |
| 页面访问 | 主要工作页面能否打开并完成加载 | 前端监控、可用性拨测 | 不包含用户本地网络问题 |
| 核心操作 | 创建、更新、查询等高频动作是否成功 | 接口成功率、操作日志、用户反馈 | 需预先列出核心操作清单 |
| 接口调用 | 开放接口和集成调用是否按约定返回 | 网关日志、调用方反馈 | 调用方参数错误不计入平台故障 |
指标与范围：可用性评估用哪些指标
可用性百分比回答“在应服务时间内有多大比例可正常使用”，是最直观的指标，但它只反映时长占比，不反映故障发生的频次和单次影响。评估时应把可用性与故障次数、累计故障时长并列，避免一次长故障和多次短故障得到相同百分比却对应不同的使用体验。
恢复类指标补充故障处置能力。MTTR（平均恢复时间）等于故障恢复总时长除以故障次数，反映从故障发生到服务恢复的平均耗时；MTBF（平均故障间隔时间）等于统计期内可服务时长除以故障次数，反映两次故障之间的平均稳定运行时间。两者结合可以看出平台是“偶发长故障”还是“频繁短抖动”。
体验类指标补充用户实际感受。关键操作成功率等于成功次数除以总尝试次数，适合按操作类型分别统计；响应时延分位值取P95或P99，表示95%或99%的请求在多少毫秒内完成，比平均值更能暴露长尾延迟。分位值需要标注统计的接口范围和采样时间窗，否则不同周期的数据不可直接比较。
| 指标 | 计算方式 | 回答的问题 | 使用注意 |
|---|---|---|---|
| 可用性百分比 | 可服务时长÷应服务时长×100% | 应服务时间内有多少比例可正常使用 | 需明确分母与故障判定 |
| 故障次数 | 统计期内计入的故障事件数 | 平台运行是否稳定 | 需去重并排除误报 |
| 累计故障时长 | 各次故障不可用时长之和 | 故障对使用时间的总影响 | 与可用性百分比互为印证 |
| MTTR | 故障恢复总时长÷故障次数 | 平均多久能恢复 | 分母为零时不可计算 |
| MTBF | 可服务时长÷故障次数 | 两次故障之间平均稳定多久 | 需与统计窗口一致 |
| 关键操作成功率 | 成功次数÷总尝试次数×100% | 高频动作能否顺利完成 | 按操作类型分别统计 |
| 响应时延P95/P99 | 按请求耗时排序取对应分位值 | 多数请求和长尾请求的响应速度 | 标注接口范围与采样窗口 |
数据口径：分母、时间窗与缺失值怎么定
应服务时长是可用性计算的分母，指平台按约定应当提供服务的分钟数。若平台承诺7×24小时服务，一个月按30天计，应服务时长为43200分钟；若只在工作时段提供服务，则按实际承诺时段累计。计划内维护是否剔除必须事先写明：剔除时，维护窗口从应服务时长和不可用时长中同时扣除；不剔除时，维护造成的不可用计入故障时长。同一评估体系内应保持规则一致，跨周期比较才有意义。
时间窗选择影响结果的敏感度和稳定性。月度窗口适合例行汇报，能较快反映变化；季度窗口平滑了单月波动，适合观察趋势；滚动窗口（如最近30天）让每次查看都覆盖相近长度的时间，适合持续监控。窗口越短，单次故障对百分比的影响越大，解读时应说明窗口长度，避免用不同窗口的数据直接比较。
采样频率和监控粒度决定数据能否支撑结论。分钟级拨测适合捕捉短时中断，小时级汇总可能漏掉短暂故障；接口成功率按请求统计与按分钟聚合，得到的数值也会有差异。评估方案应写明采样方式、聚合方式和统计单位，并在多个周期中保持一致。
缺失数据、重复告警和误报需要预先定义处理规则。监控中断期间没有数据，不能默认记为可用，应标注为数据缺失并说明覆盖比例；同一故障触发多条告警时按故障事件去重，避免故障次数虚高；经核实为误报的告警从故障记录中剔除，并保留剔除依据。多系统拼接数据时，统一使用同一时区和时钟源，明确每条记录归属哪个服务，防止同一段时间被重复计入或漏计。
| 口径要素 | 定义方式 | 处理规则 |
|---|---|---|
| 应服务时长 | 按服务承诺时段累计的分钟数 | 写明是否剔除计划内维护窗口 |
| 不可用时长 | 从故障影响到服务恢复的分钟数 | 与应服务时长使用同一时间单位 |
| 时间窗 | 月度、季度或滚动30天 | 同一对比组使用相同窗口 |
| 采样粒度 | 拨测频率、日志聚合粒度 | 跨周期保持一致并记录变更 |
| 缺失数据 | 监控中断或日志缺失的时段 | 标注缺失，不默认计为可用 |
| 重复与误报 | 同一故障的多条告警 | 按故障事件去重，误报留痕剔除 |
| 时钟与归属 | 统一时区与时钟源 | 每条记录标明所属服务 |
计算与评估步骤：从取数到结论
第一步确定范围与时间窗。列出参与评估的服务、用户群体和核心操作，选定统计起止时间，并确认计划内维护窗口清单。范围一旦确定，本期评估内不再调整，若中途新增服务，应单独统计或在报告中注明。
第二步采集监控、工单与故障记录。监控数据提供接口成功率和响应时延，工单和用户反馈提供用户感知侧的故障线索，运维值班记录提供故障起止时间和处置过程。三类数据按统一时间轴对齐，形成故障事件清单，每条记录包含影响服务、开始时间、恢复时间、影响范围和判定依据。
第三步按公式计算。先汇总不可用时长，再用应服务时长减去不可用时长得到可服务时长，计算可用性百分比；用故障恢复总时长除以故障次数得到MTTR；用可服务时长除以故障次数得到MTBF；按操作类型统计关键操作成功率；按接口范围计算响应时延P95和P99。所有结果标注单位、时间窗和样本量。
第四步按场景与用户群体分层。可以按服务面（登录、页面、核心操作、接口）、用户群体（如不同部门或地区）、故障类型（服务中断、性能下降、部分功能不可用）分别计算。分层后常会发现整体百分比掩盖了某一类操作的集中问题。
第五步与历史基线或目标值对比并形成结论。基线可以选上一周期、上季度同期或近几个周期的均值；目标值应来自服务承诺或团队约定，没有依据时不设通用达标线。结论要说明本期可用性水平、主要故障来源、恢复效率变化，以及需要跟进的运维动作。
分母为零或数据不足时，应标注为不可计算，不记为100%可用。例如统计期内没有发生故障，MTTR的分母为零，此时报告“本期无故障，MTTR不适用”；监控覆盖不足的时段单独列出覆盖率，结论中说明数据对整体的代表性有限。
例子：一个月的可用性怎么算出来
以下为演示情景，数字均为假设，用于说明计算过程。某研发平台承诺7×24小时服务，统计窗口为某月30天，应服务时长为30×24×60=43200分钟。该月计划内维护两次，每次30分钟，按约定从应服务时长中剔除，调整后应服务时长为43200−60=43140分钟。
当月记录到三次故障：第一次核心操作接口异常持续45分钟；第二次页面加载缓慢，判定为性能下降但服务可用，不计入不可用时长，仅记录事件；第三次登录服务中断20分钟。计入不可用的故障时长为45+20=65分钟，可服务时长为43140−65=43075分钟，可用性为43075÷43140×100%≈99.85%。故障次数按事件计为3次，其中计入不可用的为2次。
MTTR按计入不可用的故障计算：（45+20）÷2=32.5分钟。若把性能下降事件也纳入恢复统计，则需另行说明口径，两种算法不能混用。MTBF按可服务时长除以故障次数：43075÷3≈14358分钟，约合239.3小时。
分层后结论会不同。整体可用性99.85%看起来较高，但登录服务中断20分钟集中在上班高峰，受影响用户集中；核心操作接口异常45分钟影响了下游集成调用。若只看整体百分比，容易忽略这两类故障的集中影响。响应时延方面，假设核心查询接口P95为800毫秒、P99为2600毫秒，说明多数请求响应正常，但长尾请求明显偏慢，需要单独排查。
| 计算项 | 数值 | 说明 |
|---|---|---|
| 日历时长 | 43200分钟 | 30天×24小时×60分钟 |
| 计划内维护 | 60分钟 | 两次各30分钟，按约定剔除 |
| 应服务时长 | 43140分钟 | 43200−60 |
| 不可用时长 | 65分钟 | 45分钟接口异常+20分钟登录中断 |
| 可服务时长 | 43075分钟 | 43140−65 |
| 可用性 | 约99.85% | 43075÷43140×100% |
| MTTR | 32.5分钟 | 65÷2 |
| MTBF | 约14358分钟 | 43075÷3，按3次故障事件计 |
解读与限制：百分比之外还要看什么
相同的可用性百分比可能对应不同体验。两次30分钟中断与一次60分钟中断，在月度窗口下算出的可用性相同，但对用户的影响不同：前者可能两次打断工作节奏，后者可能让一个上午无法使用。解读时应同时看故障次数、单次最长中断和故障发生时段，必要时按高峰时段单独统计。
可用性高不直接等于用户满意。平台可用但响应缓慢、部分功能降级、报表数据延迟，都会让用户感到不好用。降级运行需要预先定义计入方式：核心功能仍可用、仅非关键功能受限时，可记为可用但标注降级；核心操作无法完成时，应计入不可用。部分功能不可用的时长若单独统计，应在报告中与整体可用性并列呈现。
指标反映的是观测结果，不能直接说明因果。可用性下降可能与发布变更、容量不足、外部依赖异常等多种因素相关，需要结合变更记录和故障复盘判断原因。把可用性百分比直接用于个人绩效考核，容易导致故障记录被少报或延迟上报，评估结果反而失真。
评估结果应转化为运维动作。常见做法包括：对高频故障补充监控和告警；对恢复时间长的故障梳理应急预案和值班交接；对长尾延迟明显的接口安排容量调整或查询优化；把每次故障的复盘结论落到具体工作项，明确负责人和完成时间，并在下一周期复查改进效果。这样可用性评估才形成从度量到改进的闭环。
在故障记录、复盘结论和改进任务的沉淀上，ONES 可以承接相关管理动作：故障和复盘可以作为工作项记录状态与负责人，复盘文档与关联任务保存在同一平台，便于下一周期对照检查。若团队关注平台运行稳定性，ONES 高可用集群部署方式提供故障转移、数据容灾和零停机服务升级的架构支持，具体实施条件需结合部署环境确认。评估指标本身仍需团队按本文口径自行定义和计算。
常见问题
计划内维护到底算不算进不可用时长？
两种做法都可以，关键是事先写明并在同一评估体系内保持一致。剔除时，维护窗口从应服务时长和不可用时长中同时扣除，可用性只反映非计划中断；不剔除时，维护造成的不可用计入故障时长，结果更接近用户实际遇到的中断。跨周期比较时，若中途改变规则，应在报告中注明变更点和影响，否则前后数据不可直接对比。
统计期内一次故障都没发生，可用性写100%合适吗？
没有故障时，可用性按公式计算确实接近100%，但需要同时说明样本条件：统计窗口多长、监控覆盖率多少、核心操作是否都有数据。MTTR的分母为零，应写“本期无故障，MTTR不适用”，不能填0分钟。若监控覆盖不足，结论中要说明数据对整体的代表性有限，避免把“没监测到”当成“没发生”。
监控数据和用户工单对不上时以哪个为准？
建议以故障事件清单为汇总口径，两类数据分别作为判定依据。监控数据用于确定起止时间和影响范围，工单和反馈用于发现监控未覆盖的问题，例如页面卡顿、部分功能异常。出现冲突时回到原始记录核对：检查时钟是否统一、告警是否重复、工单描述的时间是否准确。核实后把判定依据写入事件记录，后续周期沿用同一规则。
短时抖动很频繁，月度可用性看起来还不错，怎么呈现？
在可用性百分比之外并列故障次数、单次最长中断和故障发生时段。频繁短抖动会拉高故障次数、压低MTBF，即使总不可用时长不大，也会反复打断工作节奏。可以按高峰时段单独统计，或对核心操作按操作类型计算成功率，让集中出现的问题显现出来。呈现时说明各指标的统计窗口，避免用不同窗口的数据互相比较。
评估结果要不要和团队或个人绩效挂钩？
需要谨慎。把可用性百分比直接用于个人考核，容易让故障记录被少报或延迟上报，数据质量下降后评估反而失真。更稳妥的做法是把结果用于改进：对高频故障补监控、对恢复慢的故障梳理预案、对长尾延迟安排优化，把复盘结论转成有负责人和完成时间的工作项，下一周期复查效果。若确需与考核关联，应同时看数据完整性和改进完成情况。
