Day30-19｜9.6.3 可靠性数据的收集：为评价、建模和改进建立可信证据

一、教材定位

软件可靠性评价、模型分析和故障改进都以数据为基础。没有连续、准确、可追溯的可靠性数据，所谓故障率、平均无故障时间和可用性只能是印象判断。可靠性数据的收集不仅是把错误日志保存下来，还要记录软件在什么条件下运行、处理了多少工作量、发生了什么故障、故障影响了哪些业务、如何被发现和修复，以及修复后是否真正恢复。

本节在考试中经常与可靠性测试、可靠性模型和运维监控结合出现。题目可能要求设计数据采集方案，也可能给出一组数据让考生判断为什么不能用于评价。答题时要注意数据的完整性、代表性、可比性和安全性，既要采集技术数据，也要采集业务结果和恢复过程。

二、可靠性数据的分类

1. 运行量数据

运行量是理解故障率分母的基础，包括运行时间、请求数、事务数、处理记录数、消息数、批次量和设备工作时长。对于不同系统，运行量尺度不同：实时接口可以使用请求数或服务时间，批处理可以使用批次数和记录数，嵌入式系统可以使用工作小时或任务周期。

如果只记录故障次数而不记录运行量，就无法比较不同时间段、不同版本或不同规模系统的表现。一个版本故障次数增加，可能只是因为请求量增长了十倍；一个版本故障次数减少，也可能是系统运行时间变短。

2. 故障事件数据

故障事件包括发生时间、发现时间、故障类型、影响对象、严重等级、触发条件、持续时间、恢复时间和最终状态。事件应有唯一编号，并能关联到日志、指标、链路、发布和工单。

故障类型应结合系统特点分类，例如进程崩溃、超时、数据错误、消息丢失、重复处理、切换失败、资源耗尽、配置错误和安全异常。分类规则要稳定，否则同类故障在不同版本中被归到不同类别，趋势分析就会失真。

3. 错误与缺陷数据

故障不一定马上表现为用户可见的失效，因此还要记录内部错误、异常堆栈、校验失败、断言失败、重试和降级事件。缺陷管理系统中的发现阶段、修复版本、严重程度、根因和回归结果，也属于可靠性数据。

4. 恢复与维修数据

包括告警延迟、人工响应、切换开始和完成时间、补偿时间、回滚时间、修复版本以及是否需要人工操作。对软件可靠性而言，恢复过程与故障本身同样重要。系统发生故障后迅速恢复且数据正确，和长时间不可用或恢复后数据错误，可靠性含义不同。

5. 业务影响数据

技术日志无法完整说明故障影响。应收集受影响用户数、失败订单数、金额差异、库存差异、消息积压、未完成任务和客户投诉等业务数据。业务影响数据有助于确定故障严重等级和改进优先级，也能避免“接口返回成功但业务实际错误”的盲区。

6. 环境与配置数据

故障数据必须与版本、配置、节点、区域、硬件规格、网络状态、依赖版本、流量和数据规模关联。相同故障在不同配置下表现不同，如果没有环境上下文，无法判断是代码缺陷还是配置问题，也无法复现。

三、数据采集点的设计

1. 入口层

在网关、接口和消息入口记录请求时间、请求标识、来源、版本、租户、输入摘要、响应状态和处理时长。入口层适合统计用户可感知的成功率和延迟，但不能单独判断内部数据是否正确。

2. 服务与组件层

在服务调用、状态转换、事务边界、缓存、线程池、连接池和异常处理处采集事件。关键是记录调用链和关联标识，让一次业务请求可以追踪到多个服务和依赖。对重试、降级和熔断要记录原因和次数，避免把最终成功误认为没有发生过故障。

3. 数据与消息层

记录数据库事务、提交与回滚、主备延迟、消息发送、确认、重试、死信、消费和幂等结果。数据和消息层常常决定最终一致性，不能只依赖应用日志。涉及敏感数据时应采集摘要、哈希或脱敏后的业务标识，不应把原始密钥和隐私内容写入普通日志。

4. 基础设施层

采集主机、容器、网络、存储、数据库、缓存和消息平台的资源与状态。基础设施指标要与应用和业务事件关联，否则只能知道“某时 CPU 很高”，无法知道它是否导致订单失败或消息积压。

5. 运维与变更层

发布、配置修改、扩容、缩容、证书更新、权限变更和人工操作都应形成审计事件。很多故障并非自然发生，而是由版本或配置变化触发。没有变更数据，就很难进行时间线关联和变更影响分析。

四、可靠性数据的核心字段

一条高质量故障记录至少应包含：事件编号、发生时间、发现时间、恢复时间、软件版本、配置版本、环境和节点、业务和请求标识、故障类型、严重等级、触发条件、影响范围、用户影响、临时处置、根因、永久修复和验证结果。

时间字段必须统一时区和时钟来源。发生时间、发现时间和恢复时间不能混为一谈，因为它们分别用于计算故障暴露时间、检测时间和恢复时间。业务时间和技术时间也可能不同，要明确口径。

对于正常运行样本，也要记录运行时间、请求量、事务量和没有发生故障的观察区间。只收集失败记录会造成严重偏差，无法知道系统到底运行了多久、处理了多少请求。

五、采集方式与工具协同

1. 日志

日志适合记录离散事件和上下文，必须采用结构化格式，包含时间、级别、服务、实例、关联标识和错误分类。日志级别和采样策略要平衡完整性与成本。关键故障不能被采样丢失，普通成功请求则可以按比例采样。

2. 指标

指标适合观察数量、比例、延迟和资源趋势。要区分计数器、仪表盘、直方图和摘要等类型，合理设置标签，避免高基数标签造成监控系统压力。指标名称和单位应纳入字典，版本变更时保持兼容或记录迁移。

3. 链路追踪

链路追踪能够把跨服务调用连接起来，适合分析超时、重试、降级和级联故障。采样不能完全替代日志，关键失败和异常链路应强制保留。链路标识还应与业务订单号、消息号或任务号关联，但敏感标识必须脱敏。

4. 业务对账

对账是发现技术监控无法发现的数据错误的重要手段。通过比较订单、支付、库存、消息和账务记录，可以发现丢失、重复、状态不一致和金额差异。对账结果本身也要纳入可靠性数据，记录差异数量、发现时间和补偿完成时间。

5. 故障注入和测试平台

故障注入平台应记录注入目标、参数、开始结束时间和预期影响。测试平台还要保存运行剖面版本、数据集、用例版本、随机种子和执行结果，使可靠性数据可复现、可审计。

六、数据质量管理

1. 完整性

检查是否同时有成功和失败样本，是否覆盖关键服务、时间窗口和业务路径，是否存在日志丢失或监控中断。缺少数据的区间要被标记，不能当作无故障区间。

2. 准确性

检查时间、状态、错误分类和业务结果是否正确。日志中的“成功”应与业务最终状态交叉验证，避免技术层提前返回成功而业务随后失败。

3. 一致性

不同系统对故障、成功、重试和取消的定义应统一。一个系统记录“请求失败”，另一个系统记录“业务成功”，需要建立状态映射和事件关联，不能直接相加。

4. 可比性

版本、配置、负载、运行剖面和故障口径发生变化时，数据不一定可直接比较。比较前要分组、归一化或说明差异。尤其不能把测试环境与生产环境的指标无条件放在一张排行榜上。

5. 时效性与可追溯性

告警和数据应及时进入分析系统；原始数据、清洗规则、聚合过程和报告版本都应保留。评价结论需要能够追溯到原始事件，不能只保存最终平均值。

七、数据安全与隐私治理

可靠性数据可能包含用户标识、订单金额、访问地址、错误堆栈和配置内容。采集前要进行数据分类和最小化设计，只采集评价和定位所需的信息。用户标识可以使用不可逆摘要或脱敏映射，密钥、令牌和密码绝不能写入日志。

访问应按职责分离，开发人员不应默认看到完整生产数据，分析人员只获得脱敏数据。传输和存储要加密，保留期限要符合合规要求，测试数据要有销毁和审计记录。安全治理不是可靠性数据的附加要求，数据泄露本身就是系统失效的一种表现。

八、可靠性数据的分析闭环

数据收集不是终点。应按“采集—校验—关联—分析—决策—改进—再采集”形成闭环。发现某类超时上升后，要关联版本、配置、流量和依赖；定位根因后，验证修复是否改变指标；修复后的数据再进入模型和评价。

可以建立故障知识库，保存故障模式、触发条件、影响、检测信号、处置方式和验证用例。这样新版本发布时可以自动检查历史高风险故障是否被回归覆盖，避免经验随着人员离开而丢失。

九、案例分析：支付平台可靠性数据方案

某支付平台已有访问日志和服务器监控，但发生过“用户显示支付成功、账务系统却没有入账”的问题。调查发现，日志只记录接口返回码，没有订单、支付流水和账务记录的关联；监控只关注 CPU 和响应时间，没有对账指标；故障工单也没有记录从发现到补偿完成的时间。

改造后的数据方案分为四层。入口层记录请求号、订单号摘要、渠道、版本和响应；业务层记录订单状态、支付流水、账务状态和状态转换；技术层记录调用链、重试、超时、消息确认和数据库事务；运维层记录发布、配置变更、告警、人工处置和回滚。每日对订单、支付、账务和消息进行对账，记录差异数量、金额、发现时间和补偿完成时间。

对可靠性评价，平台不再只报告接口成功率，而是同时报告最终支付成功率、账务一致率、重复入账数、未完成订单数、故障检测时间和补偿时间。所有指标与版本和渠道关联，并对敏感字段脱敏。这样既能发现用户可见的可靠性问题，也能为模型分析和论文案例提供可追溯证据。

十、综合知识练习

题1

为什么可靠性数据必须包含运行量？

参考答案：运行量提供故障率等指标的分母，用于比较不同时间、版本和负载下的表现。只有故障次数而没有运行时间、请求数或事务数，无法判断故障是变多了，还是系统处理量变大了。

题2

为什么只采集服务器 CPU、内存和接口返回码不够？

参考答案：这些数据只能反映部分技术状态，无法发现数据丢失、重复处理、状态不一致、业务补偿和账务差异。可靠性数据应同时包含应用、依赖、消息、基础设施和业务结果，并建立关联。

题3

如何处理监控缺失的一段时间？

参考答案：标记为数据不可用，检查是否能通过日志、业务对账、外部监控或重放补充；不能把缺失区间直接当作无故障运行。评价报告应说明缺失范围及其对结论的影响。

十一、论文写作素材

论文中可以这样描述可靠性数据建设：

“针对原系统只记录接口错误、缺少运行量和业务结果的问题，我建立了分层可靠性数据采集体系。入口层记录请求和事务标识，服务层记录调用、重试、降级和状态转换，数据层记录事务、消息、对账和补偿，基础设施层记录节点、网络、存储和资源趋势，运维层记录发布、配置和人工处置。所有事件统一时间和关联标识，指标采用统一口径，并对数据完整性、准确性、一致性和可比性进行校验。涉及用户和支付信息时采用脱敏、权限分离和加密存储，最终形成可追溯的数据—分析—改进闭环。”

十二、今日复盘

可靠性数据既包括故障，也包括运行量、正常样本、环境和恢复过程。
技术指标必须与业务结果、消息和对账数据关联。
数据要具备完整性、准确性、一致性、可比性、时效性和可追溯性。
发生时间、发现时间和恢复时间不能混淆。
可靠性数据采集必须兼顾安全、隐私、权限和保留期限。
数据最终要服务于评价、模型、故障定位和持续改进。