📚 课程目录第4章迁移前的风险评估。

4. 迁移前的风险评估

审计日志迁移，说穿了最怕什么？丢数据。第二怕什么？系统崩了。第三怕什么？改完发现性能还不如老版。这些都不是靠运气躲过去的，而是靠迁移前一轮扎实的风险评估。

我接触过好几个团队，上来就撸代码写迁移工具，风险想都不想。等出问题了再回头排查，成本翻十倍不止。所以我个人习惯：迁移前的风险评估，至少要占整个项目 20% 的时间。这不是浪费，是买保险。

4.1 风险到底从哪儿来？

先画出风险地图。审计日志迁移涉及 4 个核心域：数据、代码、运行环境、上下游依赖。每个域都能炸坑。

数据域：历史日志格式差异、字段映射丢失、时间戳精度截断、大字段截断、敏感信息泄漏。
代码域：新 SDK 接口语义变化、线程模型不兼容、无同步锁写入、异常处理链断裂。
运行环境：JDK 版本不匹配、第三方依赖冲突、内存/磁盘配额不足、网络超时重试机制缺失。
上下游依赖：日志消费端（ES、Kafka、Splunk）预期字段变化、告警规则未同步、审计报表生成中断。

我踩过的坑： 有一次只改了 SDK，忘了检查下游的日志解析正则——结果新日志都带了一层 JSON 转义，下游全部解析失败。调了一个通宵才定位到。

4.2 风险评估的三个实用方法

方法不在多，管用就行。我总结了一套 『三遍扫描法』：

第一遍：快照扫描——把所有接入点列出来，给每个点贴风险标签。
第二遍：深度扫描——对 High 风险点做代码走读、接口对比、压力测试。
第三遍：回滚扫描——假设迁移出问题，回滚需要哪些步骤？哪些数据不可逆？

针对每个风险点，我习惯用一个简单的表格做登记，而不是拍脑袋。下面是我常用的模板：

风险编号	风险描述	影响域	可能性	严重度	等级	缓解措施
R001	旧 SDK 日志格式为逗号分隔，新 SDK 改为 KV 对	数据	高	严重	P0	对齐格式并做前向兼容
R002	新 SDK 使用异步批量 flush，可能丢失最后一批日志	数据	中	高	P1	增加 JVM Shutdown Hook 强制 flush
R003	新 SDK 依赖的 netty 版本与现有服务冲突	环境	中	高	P1	使用 shade 插件隔离版本
R004	日志字段中新增了加密标识，审计消费方无法识别	上下游	低	中	P2	输出变更文档并提前通知消费方

特别注意： P0 等级的风险必须满足 “不改代码不迁移” 的原则。我曾经因为赶进度跳过 P0 的格式兼容处理，上线后日志解析大面积报错，3 小时内丢了约 5 万条审计记录。谁也不想背这种锅。

4.3 数据完整性风险评估——最难啃的骨头

审计日志的核心是不可篡改、不丢失、按序存储。迁移时最容易踩的雷就是——你以为数据完整，但实际上少了一条或多了一条。

我常用的校验思路：双写校验 + 行数对比 + 哈希校验。具体来说：

双写：在迁移灰度期间，同时往新旧两套 SDK 写日志，并记录每条日志的唯一 ID。
行数对比：按相同时间段统计新旧两个存储中的日志条数，差值超过 0.1% 立刻报警。
哈希校验：选取关键字段（时间戳 + 用户 ID + 操作类型）拼接后算 MD5，对比两边的哈希值是否一致。

这里给一个我手写的伪代码校验逻辑，虽然简单但非常实用：

// 双写校验伪代码
for each log entry:
    id = entry.getUniqueId()
    oldSDK.write(entry)
    newSDK.write(entry)

// 对比线程
while(true):
    oldCount = queryCount("old_table", timeRange)
    newCount = queryCount("new_table", timeRange)
    if Math.abs(oldCount - newCount) > threshold:
        alert("数据条数不一致！")
    sleep(interval)

4.4 性能影响风险评估——别让日志变成瓶颈

很多人觉得日志嘛，写个文件能有多慢？其实不然。新 SDK 可能做了更多序列化、加签名、异步队列，这些都会引入延迟。

我建议做一次 全链路的压测，至少覆盖：

单线程写入 TPS（每秒日志条数）
多线程并发写入下的 P99 延迟
日志磁盘 I/O 占用率（不超 60%）
异步队列积压阈值（满队列时策略是阻塞还是丢弃）

压测结果结合生产环境的峰值流量，算出 余量系数。我个人要求余量至少 3 倍，也就是说生产峰值 1000 TPS，压测需稳定在 3000 TPS 以上才能上线。

4.5 回滚风险评估——留好退路

迁移最怕没有回头路。记得有一次我在客户现场做 SDK 升级，改了数据库的日志存储结构，结果新 SDK 有 Bug，数据全写乱了。要回滚发现老 SDK 已经读不了新格式的数据……那个下午真是度日如年。

从那以后，我定了一条铁律：任何迁移方案都必须附带回滚方案，且回滚方案必须经过测试。评估回滚风险时主要看三点：

数据结构变化是否可逆——如果改了字段类型，回滚时能否无损转换回来？
灰度开关是否独立——能否通过配置中心一键切回旧 SDK？
回滚的数据丢失窗口——回滚期间写进去的日志，怎么补？

我自己的习惯： 每个版本迭代都保留一个“回滚检查清单”。里面写清楚回滚步骤、预审人、超时时间、降级策略。不仅写给自己看，也要同步给运维值班的同学。

4.6 风险评估可视化——一张图说清楚

你想想看，把上面这些风险项和评估流程画成一张图，团队沟通效率能提高多少？下面这张 SVG 就是我常用的风险评估结构图。

4.7 风险登记与跟进——把评估落地

光评估不跟进，等于白做。我建议每个风险点指定一位 负责人 和一个 deadline，贴在项目看板上。每周复盘中逐一过堂。

我自己经历过的最深刻的教训是：有一项风险被标记为“低概率”，所有人都没当回事。结果上线那天触发了，虽然只影响了 20 条日志，但因为它是一条关键的合规审计记录，被内部审计抓出来了……那感觉，不用我说你也懂。

所以记住一句话：没有不重要的风险，只有还没暴露的风险。把你评估出来的每一项，都当作定时炸弹去对待。