研发平台可用性指标的关键在口径先行：先界定服务对象、核心操作和统计时间窗，再确定分子分母、故障判定与剔除规则，最后按业务影响分级设定目标值。本文给出一套可复算的指标清单、口径规则表、五步统计流程、目标值设定方法和月度算例，适用于研发管理平台自身的运行评估，不含交付流水线的执行可用性。
要点总览（TL;DR）
- 可用性主指标定义为约定服务时段内平台可正常提供核心操作的时间占比，公式为可用时长÷约定服务时长×100%，时间统一按分钟计，百分比保留两位小数。
- 统计前需先确认核心操作清单（如登录、工作项读写、文档访问、权限变更）和服务时段（7×24或工作日时段），并明确平台整体与按模块两级统计的取舍。
- 计划内维护窗口从分母扣除需有提前公告和可查记录；上游依赖故障、单用户或单项目局部异常是否剔除，须在口径规则表中事先约定并留存证据。
- 目标值按业务影响分级设定，结合历史基线、业务容忍度和投入成本三者平衡，并换算为年度允许不可用时长（故障预算）便于月度校验；新平台可设过渡目标。
- 可用性高不等于体验好，需结合响应时延和故障影响面解读；口径变更须留版本记录，指标宜用于团队改进而非个人绩效。
评估目标：可用性要回答哪个管理问题
可用性指标先要回答“给谁看、用来做什么决策”。同一组数字，面向业务方的服务承诺和面向运维团队的改进目标，口径宽严和目标值高低都不同。开篇先把评估目标写清楚，后续的口径争议会少很多。
常见的两类目标需要分开：
- 对外承诺型目标：面向平台使用方（研发团队、业务部门）承诺服务时段与可用水平，用于服务协议、季度通报。口径偏保守，剔除规则要事先书面约定，避免事后解释。
- 内部改进型目标：面向运维和平台团队自身，用于发现薄弱环节、安排投入。口径可以更细，允许按模块拆分，重点在趋势和归因。
评估对象是研发管理平台自身，包括登录认证、工作项读写、文档访问、权限与配置变更等核心操作。交付流水线的构建执行、发布成功率属于另一类指标，不纳入本文的可用性统计，否则故障归因会混在一起。
指标用途通常有三类：服务承诺的兑现核对、运维改进的优先级排序、容量与投入决策的依据。建议在评估目标说明中写明使用者、决策场景和不纳入范围，例如：
| 项目 | 内容示例 |
|---|---|
| 指标使用者 | 平台负责人、运维值班组、研发团队代表 |
| 决策场景 | 月度运行通报、季度服务承诺核对、故障后投入申请 |
| 不纳入范围 | 交付流水线执行、单机服务器与网络运维、终端设备问题 |
| 输出节奏 | 月度统计，季度汇总，年度回顾 |
指标与范围：可用性、核心操作与统计边界
主指标建议定义为：在约定服务时段内，平台可正常提供核心操作的时间占约定服务时长的比例。围绕主指标配三个辅助指标，避免只看一个百分比。
| 指标名 | 定义 | 单位 | 统计层级 |
|---|---|---|---|
| 可用性 | 可用时长 ÷ 约定服务时长 × 100% | 百分比，保留两位小数 | 平台整体、按模块 |
| 故障次数 | 统计周期内判定为故障的事件数，同一根因合并计一次 | 次 | 平台整体、按模块 |
| 平均恢复时长 | 故障总不可用时长 ÷ 故障次数 | 分钟 | 平台整体 |
| 受影响用户占比 | 受影响用户数 ÷ 统计周期内活跃用户数 | 百分比 | 平台整体 |
核心操作清单决定“什么算可用”。建议由平台负责人、运维和研发团队代表共同确认，覆盖登录、工作项读写、文档访问、权限变更等高频且影响面大的操作，并写明每项操作的验证方式（页面可打开、接口返回正常、数据可提交）。清单确定后一个统计周期内不随意增删，变更走版本记录。
统计时间窗建议以自然月为主、季度汇总，便于与运维排班和财务周期对齐。服务时段有两种选择：7×24 适合跨时区或夜间也有使用的平台；工作日时段（如工作日 9:00–21:00）适合使用集中在工作时间的团队。选择哪种要在口径中写明，因为它直接决定分母大小，同一故障在两种时段下的可用性数值差异明显。
统计层级上，平台整体口径用于对外承诺和趋势判断，按模块口径用于定位薄弱环节。两级同时统计时，模块口径的故障时长不能简单相加得到整体口径，因为一次故障可能同时影响多个模块，需按整体视角去重。
数据口径：分子分母、故障判定与剔除规则
可用性 = 可用时长 ÷ 约定服务时长 × 100%。时间统一以分钟为单位，故障起止时间精确到分钟，不足一分钟按一分钟计；最终百分比保留两位小数。分母为零的情形（如统计周期内无约定服务时段）不计算可用性，标注“不适用”，不能记为 100%。
故障起止时间的判定依据按优先级排列：监控告警记录优先，其次人工报障与用户工单，最后是值班日志。同一事件有多个来源时，以最早可确认的异常时间为起点、以核心操作恢复正常的验证时间为终点。同一根因引发的连续事件合并为一次故障，不可用时长不重复累加。
争议情形用规则表逐项写清，并留存证据：
| 情形 | 处理方式 | 记录证据 |
|---|---|---|
| 计划内维护窗口 | 提前公告且在约定窗口内执行的，从分母中扣除对应时长；超窗部分计入不可用 | 维护公告、执行记录、实际起止时间 |
| 上游依赖故障（网络、云资源、第三方登录） | 平台自身无责且无法规避的，单列说明；是否剔除由承诺口径事先约定，内部改进口径建议计入并单独归因 | 上游故障通告、影响链路说明 |
| 单用户或单项目局部异常 | 仅影响个别账号或单个项目、核心操作对其他用户正常时，不计入整体可用性，另记局部事件 | 影响范围说明、复现记录 |
| 单模块异常 | 影响核心操作且波及多用户时计入整体；仅影响辅助功能时计入模块口径 | 模块影响清单、用户反馈 |
| 数据缺失或监控盲区 | 无法确认起止时间的事件标注“数据不足”，不计入分子分母，但在报告中披露数量 | 缺失说明、补录尝试记录 |
剔除规则的核心原则是：剔除要有事先约定和可查证据，不能事后按结果调整。对外承诺口径建议从严，只剔除提前公告的计划内维护；内部改进口径可以把上游依赖计入并单独归因，以便推动依赖方改进。
计算与评估步骤：从原始记录到月度结论
把口径落到流程上，关键是让不同人按同一规则算出同一结果。建议固定五步，每步明确输入、输出和责任人。
- 确定统计周期与服务时长基数：责任人运维值班组。输入为服务时段定义和当月日历，输出为当月约定服务总分钟数，扣除已公告的计划内维护窗口。
- 归集故障事件并去重：责任人运维值班组。输入为监控告警、工单、值班日志，输出为事件清单，同一根因的连续事件合并，标注起止时间与影响范围。
- 按剔除规则计算有效不可用时长：责任人平台负责人复核。输入为事件清单和口径规则表，输出为每起事件计入或剔除的判断及有效不可用分钟数。
- 计算可用性并做同比环比：责任人运维值班组。输入为前两步结果，输出为平台整体与模块口径的可用性、故障次数、平均恢复时长，并与上月、去年同期对比。
- 输出结论与待改进项：责任人平台负责人。输入为计算结果和故障复盘记录，输出为月度运行结论、目标达成情况、下月改进项及责任人。
故障事件的归集和复盘记录如果散落在聊天工具和邮件里，跨月核对会非常费力。可以在 ONES 中用工作项记录每起故障的起止时间、影响范围、根因和处置动作，把月度统计结论沉淀为文档，让口径规则、事件记录和统计结果在同一处可追溯，复核时按同一份记录复算。
目标值设定：分级承诺与合理性校验
目标值不宜直接套用通用数字。合理做法是按业务影响分级，再结合历史基线、业务容忍度和投入成本三者平衡确定。
| 服务层级 | 目标可用性 | 对应年度允许不可用时长（按 7×24 计） | 依据 |
|---|---|---|---|
| 核心操作（登录、工作项读写） | 示例 99.9% | 约 8.76 小时 | 历史基线 + 业务容忍度 |
| 重要功能（文档访问、权限变更） | 示例 99.5% | 约 43.8 小时 | 历史基线 + 投入成本 |
| 辅助功能 | 示例 99.0% | 约 87.6 小时 | 影响面较小，容忍度较高 |
表中数值为演示情景，不代表任何平台的真实承诺。实际设定时先看历史基线：过去 6 到 12 个月的实际可用性是多少、主要故障来自哪里；再看业务容忍度：核心操作中断多久会影响交付节奏；最后看投入成本：提升一个千分点需要增加多少冗余和人力。三者平衡后确定目标，并换算为年度允许不可用时长（故障预算），便于月度校验是否超支。
新平台上线或架构调整期，建议设过渡目标，例如前三个月按改进型口径统计、不对外承诺，待基线稳定后再确定承诺值。过渡期要在口径文档中写明起止时间。
算例：一个月的可用性如何算出
以下为演示情景，数值仅用于说明计算方法。假设某月 30 天，服务时段为 7×24，约定服务总时长为 30 × 24 × 60 = 43,200 分钟。当月发生三起事件：
- 事件 A：核心操作中断 45 分钟，监控告警确认，计入不可用。
- 事件 B：计划内维护 120 分钟，提前三天公告且在窗口内完成，从分母扣除。
- 事件 C：单个项目权限配置异常 30 分钟，其他用户核心操作正常，不计入整体可用性，另记局部事件。
计算过程：分母 = 43,200 − 120 = 43,080 分钟；分子 = 43,080 − 45 = 43,035 分钟；可用性 = 43,035 ÷ 43,080 × 100% ≈ 99.90%。若事件 C 按计入处理，可用性约为 99.83%；若事件 B 不从分母扣除，可用性约为 99.62%。同一组原始数据在不同口径下差异接近 0.3 个百分点，这正是口径必须事先约定的原因。
解读与限制：指标能说明什么、不能说明什么
可用性高不等于体验好。平台在服务时段内可正常操作，但响应时延明显变长、页面加载缓慢时，可用性数字仍然好看。解读时应结合响应时延和故障影响面，受影响用户占比高的短时故障，业务感受往往比长时间但影响面小的故障更差。
几类失真情形需要提前防范：
- 统计周期过短，一次偶发故障就能让月度数字大幅波动，建议同时看季度趋势。
- 分母为零或服务时段定义变更，会导致跨期不可比，需在报告中注明。
- 口径变更必须留版本记录，写明变更内容、生效时间和原因，新旧口径数据分开呈现。
- 指标与个人绩效直接挂钩时，容易出现瞒报故障、拖延判定起点的倾向，建议指标用于团队改进而非个人考核，故障上报给予正向激励。
口径文档建议包含版本号、生效日期、变更记录和审批人，每次调整后重新基线化，确保跨期比较有据可依。
常见问题
计划内维护窗口从分母扣除，需要满足哪些条件？
从分母扣除计划内维护时长，通常需要同时满足三个条件：提前公告（如提前三个工作日以上）、在公告窗口内完成、有执行记录可查。超窗部分应计入不可用时长。对外承诺口径建议只剔除这类有公告和记录的计划内维护，内部改进口径可另行约定。
上游依赖故障（如网络、云资源、第三方登录）导致平台不可用，是否计入可用性？
是否计入取决于口径约定。对外承诺口径通常只剔除平台自身无责且无法规避的上游故障，并需有上游故障通告和影响链路说明作为证据；内部改进口径建议计入并单独归因，以便推动依赖方改进。两种口径应在规则表中事先写明，不能事后按结果调整。
单用户或单项目局部异常，什么情况下不计入整体可用性？
当异常仅影响个别账号或单个项目，核心操作对其他用户正常时，一般不计入整体可用性，另记局部事件。若异常波及多用户或影响核心操作，则应计入整体口径。判定时需留存影响范围说明和复现记录，避免口径随人变化。
新平台上线或架构调整期，目标值怎么设比较合理？
新平台或架构调整期可先设过渡目标，例如前三个月按内部改进型口径统计、不对外承诺，待历史基线稳定后再确定承诺值。过渡期起止时间应在口径文档中写明。目标值确定时仍需结合历史基线、业务容忍度和投入成本三者平衡，并换算为年度允许不可用时长便于校验。
统计周期内分母为零或监控数据缺失，可用性怎么处理？
分母为零（如统计周期内无约定服务时段）时不计算可用性，标注“不适用”，不能记为100%。监控数据缺失导致无法确认起止时间的事件，标注“数据不足”，不计入分子分母，但在报告中披露数量。这类情形应在口径规则表中提前写明处理方式。
