评估研发平台可用性，需要的不只是几个百分比，而是一条能相互印证的证据链：服务目录和关键用户旅程界定评估范围，监控与日志给出请求量、失败量和时延，工单与事件记录核对影响面和恢复过程，变更、容量与演练记录解释波动原因。本文限定在研发管理平台自身运行，给出指标口径、数据来源、计算步骤和算例；评估记录可用ONES文档与工作项留存，具体能力以官方资料为准。
要点总览（TL;DR）
- 评估研发平台可用性，先界定范围：只看研发管理平台自身运行（登录、页面与接口访问、核心工作项与文档操作、通知与集成回调），交付流水线可用性另作统计。
- 需要的数据分四类：监控与日志给出请求量、失败量和时延；工单与事件记录给出不可用起止时间与影响面；变更、容量与演练记录解释波动原因；服务目录与关键旅程界定分母。
- 可用率、错误率、时延、MTTR 都要写明分子、分母、时间窗、统计粒度和单位；无流量时段标记为不适用，监控盲区显式标注，不能默认为可用。
- 结论按五步形成：定时间窗、汇总请求与失败、提取不可用起止时间、与变更和容量对齐、写明覆盖范围与证据等级；单一时段或单一指标只作线索。
- 评估口径与结论沉淀为版本化文档，故障事件、变更与演练记录关联到同一工作项，下一周期直接调取对比。
评估目标：把“平台可用”拆成可验证的问题
研发平台可用性评估的对象，是研发管理平台自身的运行状态，包括用户登录、页面与接口访问、核心工作项与文档操作、通知送达以及集成回调等环节。评估前先列出服务目录：哪些模块、哪些接口、哪些集成通道属于本次范围，哪些依赖外部系统。范围写清楚，后续的分母才有意义。
需要与交付流水线的可用性区分开。代码构建、制品发布、流水线执行的成功率属于持续交付主题，反映的是交付链路，不直接说明研发管理平台本身是否可用。两者可以共用监控体系，但统计对象、分母和结论应分开表述，避免把流水线失败计入平台不可用。
围绕评估目标，需要回答三类问题：平台在评估期内是否可用，用可用率和错误率回答；不可用时影响多大，用不可用时长、影响用户数和受影响的关键旅程回答；波动原因是否可解释，用变更、容量、演练和事件记录回答。三类问题对应不同证据，缺一类，结论就只剩一个孤立数字。
指标与范围：可用率、时延、错误与恢复各自管什么
可用性评估常用一组互相补充的指标，每个指标回答不同问题，单独使用都容易误判。可用率回答“大部分时间能不能用”，错误率回答“请求失败有多频繁”，时延回答“能用的时候快不快”，恢复类指标回答“出问题后多快能回来”。
| 指标 | 回答的问题 | 统计对象 | 注意事项 |
|---|---|---|---|
| 可用率与不可用时长 | 评估期内平台可用的时间占比 | 按服务或关键用户旅程统计 | 需明确不可用的判定条件与起止时间 |
| 请求错误率与失败分布 | 失败请求占多大比例、集中在哪类接口 | 接口、页面、集成回调分类统计 | 区分客户端错误与服务端错误 |
| 响应时延 | 正常请求的处理速度与体验 | 服务端处理时延与端到端时延分开 | 注明统计分位值，不用单一平均值代替 |
| MTTD、MTTR、故障次数、影响用户数 | 发现和恢复的速度、故障规模 | 按事件记录统计 | 起止时间以事件记录为准，口径统一 |
可用率与不可用时长通常按服务或关键用户旅程统计。关键旅程指登录、打开工作项、保存文档、接收通知这类高频且影响面大的操作路径。按旅程统计的好处是能反映用户实际感受，代价是需要把多个接口的请求聚合起来，聚合规则要事先写定。
错误率需要按接口、页面和集成回调分类。集成回调失败可能由外部系统引起，与平台自身可用性相关但归因不同，应单列一类并注明外部依赖。响应时延要区分服务端处理时延与端到端体验时延，前者用于定位性能问题，后者用于判断用户感受，两者混用会让结论失真。
范围声明是指标可比的前提。评估报告应写明纳入哪些服务、覆盖哪些用户群、采用哪个时间窗和统计粒度。同一平台在不同时间窗、不同用户群下算出的可用率不能直接比较，跨周期对比时必须保持范围一致，范围调整要单独说明。
数据口径与证据：每类指标从哪里取、怎么保证可比
指标能否复算，取决于数据来源和口径是否写清楚。建议为每个指标建立一行口径记录：指标名称、数据来源、分子、分母、时间窗、统计粒度、单位、缺失值处理方式。不同团队按同一张表取数，结果才具备可比性。
| 指标 | 数据来源 | 公式要素 | 缺失或特殊情况处理 |
|---|---|---|---|
| 可用率 | 监控告警系统、可用性探测记录 | 可用分钟数 ÷ 统计总分钟数，按分钟粒度 | 探测缺失时段标注为未覆盖，不计入可用 |
| 错误率 | 访问日志、网关日志 | 失败请求数 ÷ 总请求数，按小时或天汇总 | 无流量时段分母为零，标记为不适用 |
| 响应时延 | 访问日志、链路追踪数据 | 按分位值统计，注明统计粒度与单位（毫秒） | 采样数据注明采样率与误差范围 |
| MTTR | 工单与事件记录 | 故障恢复总时长 ÷ 故障次数，单位分钟 | 未闭环事件单列，不并入已恢复统计 |
公式要素中最容易被忽略的是分母和时间窗。可用率的分母是统计总分钟数，错误率的分母是总请求数，MTTR 的分母是故障次数，三者不能互换。统计粒度决定精度：按分钟统计适合判断短时中断，按天统计适合看趋势，同一报告内应保持一致，跨粒度换算要说明方法。
分母为零和无流量时段需要专门规则。夜间或节假日没有请求时，错误率没有意义，应标记为“不适用”，不能记为 0% 错误率，否则会拉低整体错误率。监控盲区、日志缺失和采样误差要显式标注，不能默认为可用。证据分级上，系统自动采集的监控与日志数据优先于人工工单记录，人工记录优先于口头描述；结论引用哪一级证据，应在报告中注明。
计算与评估步骤：从原始数据到可用性结论
评估过程按固定顺序执行，其他人才能按同样步骤复现结果。以下五步适用于单服务、单旅程或整体平台，范围不同，取数范围随之调整。
- 确定评估时间窗与统计粒度。写明起止日期、是否包含节假日、按分钟还是按天统计，并固定下来供后续步骤共用。
- 按服务或关键旅程汇总请求量与失败量，计算可用率和错误率。先按接口分类汇总，再按旅程聚合，聚合规则写入口径表。
- 从事件记录中提取每次不可用的起止时间，计算不可用时长、故障次数和 MTTR。起止时间以事件记录中的确认时间为准，口径统一。
- 将指标曲线与变更记录、容量数据、演练记录对齐，标注异常时段。异常时段对应的变更或容量事件作为解释波动的证据。
- 形成结论，写明时间窗、覆盖范围、证据等级和未覆盖部分。结论中区分单次故障与长期趋势，分别给出判断。
第三步的起止时间口径直接影响 MTTR。以监控告警触发为起点、以服务恢复确认为终点，是较常见的做法；若以用户报障为起点，MTTR 会偏长，反映的是发现加恢复的总时长。两种口径都可以用，但同一报告内必须统一，并在结论中注明。
算例：一个月的可用率与故障恢复怎么算
以下为演示情景，数字用于说明公式和单位，不代表任何真实平台的表现。设定评估时间窗为某月 1 日至 30 日，共 30 天，按分钟统计，统计总分钟数为 30 × 24 × 60 = 43200 分钟。该月记录到两次不可用事件：第一次持续 40 分钟，第二次持续 20 分钟，合计不可用 60 分钟。
可用率 = 可用分钟数 ÷ 统计总分钟数 = (43200 − 60) ÷ 43200 ≈ 99.86%。分子是可用分钟数 43140，分母是统计总分钟数 43200，单位为分钟，结果以百分比表示。若按天统计，则需先把每天的不可用分钟数汇总，再除以当天总分钟数，粒度不同结果精度不同。
错误率方面，假设该月总请求数为 1200 万次，失败请求 3600 次，错误率 = 3600 ÷ 12000000 = 0.03%。失败请求中，接口错误 2400 次、页面错误 900 次、集成回调失败 300 次，回调失败需单独注明外部依赖。MTTR = 故障恢复总时长 ÷ 故障次数 = 60 分钟 ÷ 2 次 = 30 分钟。
解读这组结果时，可用率 99.86% 主要由两次短时中断拉低，中断集中在工作时段，影响面需要结合影响用户数判断。错误率 0.03% 看似很低，但若失败集中在核心工作项保存接口，用户体验损失会高于比例所显示的程度。证据是否充分，取决于监控是否覆盖了这两次中断的全过程、事件记录是否完整、变更记录能否解释触发原因。缺少其中任何一项，结论都应标注为证据不足。
解读与限制：指标能说明什么、不能保证什么
可用率高不等于用户体验好。平台大部分时间可访问，但核心操作时延偏高或错误集中在高频接口，用户感受仍然会差。评估时应把可用率、时延和错误率放在一起看，三者指向不同问题，合并解读才能形成完整判断。
监控覆盖不到的部分不能推断为可用。未接入探测的模块、未采集日志的接口、依赖外部系统且无回调记录的集成通道，都属于证据空白。报告中应列出未覆盖范围，说明其对结论的影响，不能把空白默认为正常。
不设通用达标线。可用率目标应结合业务影响、用户规模和历史基线确定：核心工作项操作中断的影响大于通知延迟，目标就应更严；历史基线稳定在某一水平时，突然下降比绝对值更值得关注。单次故障与长期趋势要分开看，单次故障用于复盘恢复过程，长期趋势用于判断平台稳定性是否在改善。
评估结论应写明时间窗、覆盖范围和证据等级。单一时段或单一指标只能作为线索，不能直接作为可用性结论，也不宜直接转化为团队绩效结论。结论表述建议采用“在某一时间窗、某一范围内，依据某一级证据，可用率为多少，主要影响因素是什么”的结构，便于复查和对比。
把证据沉淀成可复查的评估记录
评估做完一次，价值有限；能按周期复查、与上一期对比，才有持续参考意义。建议把指标口径、数据来源、算例和结论写入文档并版本化，每次评估新增一个版本，保留历史口径，范围调整时单独记录变更原因。
故障事件、变更记录和演练记录应关联到同一工作项或知识条目，形成从事件到原因、从原因到改进项的链路。评估结论经评审后归档，下一周期评估时直接调取上一期口径和结论做对比，减少重复定义口径的工作。
ONES 可承载文档协作、工作项状态流转与评审记录，适合把评估口径文档、故障事件工作项和评审结论放在同一处管理，便于交接与复查。ONES 支持私有部署和公有云部署，高可用集群部署方式提供故障转移、数据容灾和零停机服务升级等特性，可作为平台运行方式的背景信息；具体能力与适用条件以官方资料为准。
常见问题
平台刚上线、历史数据不足一个完整周期，可用性评估怎么做？
可以先缩短评估时间窗，例如按周或按发布周期统计，并在结论中写明时间窗较短、样本有限。此时重点放在证据完整性上：监控是否覆盖核心旅程、事件记录是否闭环、变更记录是否齐全。历史基线不足时，可用率目标先参考同类服务的运行情况，等积累两三个周期后再调整。跨周期对比时保持时间窗和统计粒度一致，避免用周数据与月数据直接比较。
监控数据和工单记录对同一次故障的时长说法不一致，以哪个为准？
先看两者定义的时间点是否相同。监控通常记录告警触发到恢复确认，工单记录的是报障到关闭，后者包含发现和沟通时间，通常更长。建议在口径表中固定一种起止定义用于 MTTR 计算，另一种作为补充说明。若差异较大，应回到原始日志核对，并在报告中注明差异原因，不能简单取平均值。
集成回调失败算不算平台不可用？
要看失败归因。回调由平台发出但失败原因在外部系统时，属于平台可用性相关但归因不同的事件，应单列一类并注明外部依赖；若平台自身未能发出回调或回调处理逻辑异常，则计入平台不可用。分类规则要在评估前写定，同一报告内保持一致，否则错误率会被高估或低估。
评估结论能不能直接用于团队绩效考核？
不建议直接使用。可用性指标受范围、时间窗、分母口径和外部依赖影响，同一数字在不同口径下含义不同。用于绩效前，需要先固定口径、排除外部依赖造成的中断，并区分单次故障与长期趋势。更稳妥的做法是把评估结论作为复盘和改进项输入，绩效判断另行设计指标组合。
评估记录放在哪里，才能让下一周期直接对比？
把指标口径表、数据来源、算例和结论写入文档并版本化，每次评估新增版本、保留历史口径；故障事件、变更和演练记录关联到同一工作项或知识条目，形成从事件到改进项的链路。ONES 可承载文档协作、工作项状态流转与评审记录，适合把口径文档、事件工作项和评审结论放在同一处管理，具体能力以官方资料为准。
