日志记录的重要性：审计、合规、故障排查
做密码迁移，很多人第一反应是「把数据搬过去就行」。我一开始也这么想。
结果第一次上线就出了岔子。某个批次迁移失败，密码哈希写了一半，用户登录不上去了。
翻日志？发现根本没开详细记录。谁跑的、什么时候跑的、跑成啥样——全是黑盒。那感觉，就像在深夜修一台没有仪表盘的服务器。
从那以后我彻底明白：日志不是附属品，是安全绳。
这一章，我们就来拆开它。审计、合规、故障排查，这三个角度，缺一个都不行。
审计——每一步都要有据可查
审计说白了就是：谁、在什么时间、对哪条密码记录、做了什么操作。迁移过程中，你可能涉及批量读取、解密、重新哈希、写入新库。每一步如果没记下来，事后根本没法自证清白。
我遇到过最典型的场景：合规部门突然要求追溯三个月前的迁移记录。如果日志只记了「迁移完成」四个字，你拿什么交代？
所以，审计日志至少要包含这些字段：
| 字段 | 含义 | 示例 |
|---|---|---|
timestamp | 操作发生时间，精确到毫秒 | 2025-03-18T10:23:45.123Z |
operator | 执行人/服务ID | migration-service-v2 |
action | 具体操作类型 | READ_HASH / WRITE_HASH |
user_id | 被操作的密码所属用户 | u-abc123 |
source | 来源系统 | legacy_ldap |
status | 成功/失败/部分成功 | SUCCESS |
trace_id，方便把多个步骤串起来。
比如一次密码迁移会生成多个日志条目，trace_id相同，查起来省太多时间。
合规——不是摆设，是防火墙
合规要求五花八门。GDPR、SOX、PCI DSS，每个都对日志保留周期、不可篡改性有硬性规定。
举个例子，PCI DSS要求密码相关的审计日志保存至少12个月，并且要能检测到日志被修改。如果没有签名或防篡改机制，合规检查直接判不通过。
下面是一份常见的合规要求对照表：
| 标准 | 日志保留期限 | 特殊要求 |
|---|---|---|
| GDPR | 至少6个月（依处理目的） | 用户可要求删除日志中的个人标识 |
| PCI DSS | 至少12个月 | 日志必须防篡改，定期审查 |
| SOX | 7年 | 需要第三方审计日志的可追溯性 |
我曾经接过一个客户，他们之前用明文日志存本地，结果被合规巡检要求整改。改日志架构花了一周，不如一开始就设计好。
password: 'welcome123'的案例，那家公司第二天就被通报了。
故障排查——日志是事故现场的监控录像
迁移总会出问题。网络抖一下、格式对不上、并发写冲突——你没法预判所有隐患。但你可以确保：故障发生时，日志能告诉你它为什么发生。
我习惯把日志分为三个级别：
- DEBUG —— 开发调试用的详细上下文，上线后一般关掉。
- INFO —— 正常的迁移步骤，比如「已处理用户1000人」。
- ERROR —— 异常信息，必须包含
stack trace和失败原因。
一个典型的故障排查流程：
- 先看ERROR日志：找到哪个用户、哪个步骤出错了。
- 再查INFO日志：确认前后上下文，看是不是连续失败。
- 如果需要更细的线索，才打开DEBUG。不过千万别在生产环境常开DEBUG，否则日志量会让你崩溃。
下面是一段我常用的日志记录格式（JSON结构化）：
{
"time": "2025-03-18T10:23:45.123Z",
"level": "INFO",
"trace_id": "mig-20250318-a1b2c3",
"service": "pwd-migrator",
"action": "WRITE_HASH",
"user_id": "u-abc123",
"status": "SUCCESS",
"latency_ms": 12.4,
"message": "密码哈希写入目标库完成"
}latency_ms字段，以后做性能瓶颈分析时特别有用。
我发现很多故障跟超时有关，没有这个字段你根本不知道哪个操作慢。
三者之间的关联
审计、合规、故障排查不是孤立的。一条好的日志，在审计上能当证据，在合规上能通过检查，在故障排查时能直接定位问题。我画个简单的图，你一看就明白：
写在最后（这一节的心得）
日志记录看似简单，但真正做好的人不多。要么记不全，要么记太多导致成本爆炸。你得把握一个度。
我个人经验：先满足合规硬性条款，再把排查常用的字段加进去，最后用trace_id把审计路径穿起来。这三步走完，基本就不会漏。
记住：日志不是写给别人看的，是写给未来出了问题的自己看的。