一条日志必须能回答六个问题
“管理员修改了订单”不是可审计日志。记录应能说明：是谁、什么时候、从什么终端、对哪个订单或配置、做了什么、结果怎样。跨系统操作还要携带统一追踪号，把后台、API、支付、消息和闸机记录串起来。
票务业务的高风险事件清单
| 类别 | 必须记录的动作 | 建议告警 |
|---|---|---|
| 账号与权限 | 登录失败、角色变更、授权、停用、高权限操作 | 短时大量失败、非工作时段提权 |
| 票与价格 | 新建票种、改价、配额、优惠、停售 | 临近开售改价、超范围折扣 |
| 订单与退款 | 补票、作废、改期、退款审批、人工放行 | 同账号连续退款、绕过审批 |
| 数据操作 | 批量查询、导出、删除、脱敏配置 | 异常大批量导出 |
| 接口与密钥 | 渠道参数、回调地址、密钥轮换、白名单 | 回调地址突变、密钥读取异常 |
推荐的最小字段集合
事件 ID、发生时间、接收时间、用户 ID、角色、来源 IP 或设备、会话 ID、业务对象类型和 ID、动作、变更前后摘要、结果码、失败原因、审批单号、追踪号和应用版本。时间应统一时区并同步时钟；变更前后只记录审计所需字段，避免整条游客资料进入日志。
日志越多不等于越安全
密码、短信验证码、完整身份证号、银行卡号、支付密钥和访问令牌不应明文写入日志。手机号、证件号等按用途脱敏；必要的关联可保存不可逆摘要或受控标识。日志查看和导出本身也要记录审计日志，形成“谁查看了审计数据”的二级留痕。
让日志可查、可信且不影响交易
- 业务系统异步发送日志，避免审计平台故障拖垮售票主链路。
- 集中存储并限制修改权限，关键日志使用哈希链、签名或不可变存储增强完整性。
- 按用户、订单、票码、设备、追踪号和时间范围快速检索。
- 设置留存、归档和合法删除流程，定期验证日志可恢复与可解析。
- 用规则识别异常退款、批量导出、越权和接口配置变化。
验收要用真实场景反向验证
选择一笔改价、一笔审批退款、一次权限变更、一次批量导出和一次闸机人工放行，要求审计人员在限定时间内还原完整链路。若只能在多台服务器逐个查文件，或无法定位唯一操作人，就还没有达到可运营状态。
留存边界：日志留存周期和字段范围应结合系统等级、适用规范、合同与个人信息保护要求确定；本文不提供统一法定期限。