日志审计与系统集成 P31 · 权限与系统管理
日志的价值在出事时才体现：能不能回答"谁、什么时候、把什么改成了什么"。 集成的价值则在于：让数据只录入一次，其他地方自动流转。
三类日志与审计要素、典型审计场景、系统集成的四种方式与幂等设计、集成常见故障与对账。
操作日志、审计追踪 Audit Trail、业务变更日志、接口日志、幂等、重试与补偿、EDI、API、消息队列。
只记录"谁登录了"，不记录"改了什么字段、改前改后是什么值"。 真出问题时，这类日志完全无法用于追溯。
1. 三类日志：用途完全不同
点击查看记录内容与保留策略用途：安全审计（谁导出了全量客户资料）、行为分析（哪些功能没人用）。
关键点：导出与打印必须记录，这是数据泄露的主要出口。
保留：通常 6 个月–2 年，敏感操作（导出、权限变更）单独长期留存。
用途：争议追溯（价格是谁改的、交期是谁推的）、合规审计。
关键点：这是最有价值也最常被省略的一类日志。审批意见、变更原因也要一并留存。
保留：与业务单据同周期，通常 5–10 年（财务相关按法定年限）。
用途：排查集成故障（是没收到、收到了没处理、还是处理失败）。
关键点：要有全局流水号（Trace ID）把一次业务跨多个系统的调用串起来， 否则排查时要挨个系统翻日志。
保留：通常 1–3 个月（量大，需注意存储成本）。
2. 五个典型审计场景：系统必须答得上来
| 审计问题 | 需要的数据 | 依赖的日志/记录 |
|---|---|---|
| 这张采购单的价格是谁改的？ | 改前价、改后价、操作人、时间、审批记录 | 业务变更日志 + 审批流记录 |
| 为什么这笔超预算还批了？ | 审批链、每级审批人、意见、附件 | 审批流记录 + 附件留存 |
| 这批货是谁放行入库的？ | 质检单、检验人、判定结论 | IQC 记录 + 操作日志 |
| 全量客户资料被谁导出了？ | 导出人、时间、导出行数 | 操作日志（导出专项记录） |
| 供应商银行账号何时被修改？ | 改前账号、改后账号、审批与回拨确认记录 | 业务变更日志 + 变更审批单 |
日志要只增不改不删（append-only），且业务数据库的删除操作也不能连带删除日志。 管理员账号本身的操作同样要记录——否则"管理员删了日志"这件事本身就无从追溯。
3. 系统集成：供应链系统的边界在哪里
四种集成方式对比
| 方式 | 特点 | 优点 | 缺点 | 适用 |
|---|---|---|---|---|
| 数据库直连 | 直接读写对方库表 | 简单、实时 | 耦合极深，对方改表就崩 | 仅临时方案，不推荐 |
| 文件交换 | 定时生成/读取 CSV、XML | 实现简单、易排查 | 实时性差、易丢文件 | 批量场景（对账、主数据） |
| API 接口 | HTTP 实时调用 | 实时、标准化、易管控 | 需要对方配合开发 | 主流方式 |
| 消息队列 | 发布/订阅异步传递 | 解耦、削峰、可靠 | 运维复杂度高 | 高频数据（订单、库存变动） |
4. 集成必须解决的四个问题
① 幂等
同一条消息重复到达时，结果必须一致。做法：用唯一业务号（如单据号+行号）做去重，
重复请求直接返回成功而不重复处理。
没有幂等 = 重复入库/重复扣款
② 重试与补偿
失败后要能自动重试（带退避策略），多次失败转入死信队列并告警人工处理， 而不是静默丢弃。
③ 对账机制
定期比对两边数据条数与金额（如订单数、库存数、账单金额）， 不一致自动告警。集成系统"看起来正常但对不上"是最危险的状态。
④ 监控与告警
接口成功率、耗时、积压量要有看板与阈值告警。 业务方往往比技术方先发现问题（客户投诉"查不到物流"），这是监控缺位的信号。
① 时区与日期格式（UTC vs 本地、YYYY-MM-DD vs DD/MM/YYYY）； ② 编码问题（UTF-8 vs GBK，中文乱码）； ③ 数量单位不一致（一方发"箱"、一方收"件"）； ④ 枚举值不统一（订单状态 1/2/3 各表各的含义）—— 这类问题不报错，但数据悄悄就错了，且极难发现。