3. 证据收集原则：客观性、完整性、可追溯性、时效性要求

在变更申请的证据收集过程中，接口调试记录与日志数据必须遵循四项核心原则。这些原则不仅是证据法律效力的保障，也是后续影响评估与谈判的基础。任何偏离原则的证据收集行为，都可能导致变更申请被驳回或在审计中失效。

3.1 四项原则概述

3.2 原则详解与接口调试实践

3.2.1 客观性

客观性是证据的基石。在接口调试中，客观性要求收集的证据必须是系统直接产生的原始数据，而非经过人工加工或解释后的结果。

• 原始报文留存： 使用抓包工具（如 Wireshark、Fiddler）或 API 网关的请求/响应日志功能，保存未经任何修改的 HTTP/HTTPS 报文。
• 禁止后处理篡改： 不得对日志中的错误码、响应时间、返回数据做任何人为修正或美化。
• 时间戳来源： 统一使用 NTP 同步后的服务器时间，避免因本地时间偏差导致客观性受损。

// 客观性示例：记录原始请求与响应，不做任何数据清洗
// 正确做法：直接存储 JSON 原始字符串
log.info("原始请求报文: {}", requestBody);
log.info("原始响应报文: {}", responseBody);

// 错误做法：对响应数据进行格式化或错误码转换后再记录
// log.info("处理后的响应: {}", formatResponse(responseBody)); // 违反客观性

3.2.2 完整性

完整性要求证据链条不能出现断裂。在接口调试中，尤其需要关注跨系统、跨服务的调用链完整性。

• 全量参数记录： 记录接口请求的所有参数，包括 Header、Query String、Body，以及可能被忽略的默认值。
• 调用链追踪： 使用 Trace ID 串联上下游系统调用，确保从发起端到最终响应端的全路径可查。
• 异常分支覆盖： 不仅记录正常流程，超时、重试、熔断、降级等异常分支的日志同样需要完整保留。

3.2.3 可追溯性

可追溯性确保每一份证据都能找到其来源和责任人。这是影响评估与谈判中责任认定的关键。

• 身份标识： 在日志中记录调用方应用 ID、用户 或 ，明确谁发起了变更请求。
• 版本关联： 记录接口的版本号（如 /api/v2/order）、代码的 Git Commit ID、部署的 Release Tag。
• 环境标记： 明确区分开发、测试、预发布、生产环境，避免环境混淆导致追溯失败。

// 可追溯性示例：日志中携带完整的上下文信息
// 推荐格式：[时间] [TraceID] [调用方] [接口版本] [操作] [结果]
2025-03-21 14:30:22.456 [trace-abc123] [app-order-service] [v2.1.0] [createOrder] [SUCCESS]
2025-03-21 14:30:22.789 [trace-abc123] [app-payment-service] [v1.8.3] [deductBalance] [FAILED: insufficient_balance]

3.2.4 时效性

时效性要求证据必须在变更发生后的特定时间窗口内完成收集。超过时效的证据可能因系统状态变化而失去证明力。

• 实时采集： 使用日志采集工具（如 Filebeat、Fluentd）实时将日志发送至集中存储，避免日志积压。
• 快照机制： 在变更操作前后分别对关键接口的配置、缓存、数据库状态进行快照。
• 保留周期： 根据变更影响等级设定证据保留周期。高风险变更的证据至少保留至项目审计结束。

3.3 四项原则的关系模型

下图展示了四项原则在证据收集过程中的相互作用与依赖关系。客观性与完整性构成证据的“质量基础”，可追溯性提供“关联能力”，时效性则定义了“有效边界”。

3.4 原则检查清单

在每次接口调试证据收集完成后，建议使用以下清单进行自检，确保证据满足四项原则要求。

1. 客观性检查：
   • 是否使用了原始日志文件而非二次加工数据？
   • 时间戳是否来自 NTP 同步服务器？
   • 是否存在人为修改报文内容的操作？
2. 完整性检查：
   • 是否覆盖了请求/响应的全量参数？
   • 调用链 Trace ID 是否完整串联？
   • 异常分支（超时、重试、熔断）的日志是否已包含？
3. 可追溯性检查：
   • 每条日志是否包含调用方身份标识？
   • 接口版本、代码 Commit ID 是否已记录？
   • 环境标记是否明确（dev/test/staging/prod）？
4. 时效性检查：
   • 证据是否在变更窗口内完成采集？
   • 日志保留周期是否满足审计要求？
   • 是否在变更前后执行了快照？