埋点与功能同期
日志埋点要和功能开发同期做，不能等上线后补；补埋点只能记录未来行为，试运行期的操作永远缺证据。怎么排：需求评审时就确定事件清单与字段，开发任务里为埋点单列工作量，联调时一并验证，避免被当作收尾。
存储依赖平台
集中存储、检索与容量规划通常依赖客户既有平台或一次采购，属于外部依赖。为什么容易卡：平台选型走采购流程需要时间，容量要按业务峰值估算，若按平均值规划，上线首月就可能写满，采集中断数天。
时间同步与标识
各服务器时间不同步会让链路还原失效，统一主体标识又依赖身份源对接。怎么做：把时间同步与账号映射放在联调前置项，先用手工映射跑通链路，再替换为自动同步，避免两个依赖互相等待而拖住验收。
留存策略需法务
留存期限与到期销毁要经法务确认，涉及个人信息处理的还要说明销毁方式。边界：留存策略由客户方法务与合规负责人决定，我方提供配置项与执行记录，不代替判断合规期限，也不擅自延长保存时间。
依赖清单提前交
集中存储采购、法务确认留存期限、通知与审计平台账号开通，都不是一周能办完的事。做法：开工时提交外部依赖清单，写明接口人、办理环节与预计周期，给采购与审批留出余量；依赖未到位时先用手工台账与临时存储过渡，并在周报里标注对上线范围的影响，避免最后一周才发现卡在流程上。
适用与不适用
适合谁
- 正在排期日志改造的项目与部门及其实施团队
- 依赖客户既有日志平台的系统与部门
- 涉及个人信息需定留存期的应用与部门
不适合谁
- 无业务数据、仅做演示的原型或演示原型
典型场景
某建筑集团的投标文件助手计划五周上线。第一周定事件清单与字段，第二至三周随功能开发同步埋点，第四周接入客户既有日志平台并做容量评估，第五周做删除测试与还原演练。平台采购延迟两周，是主要影响交付的依赖。
可执行步骤
- 需求评审时确定事件清单与字段，并在开发任务中单列埋点工作量。
- 联调阶段一并验证埋点，确保多段日志能靠链路标识拼接完整，完成后归档。
- 接入客户既有日志平台，按业务峰值而不是平均值评估存储容量，并留存记录。
- 与身份源完成账号映射，统一主体标识之后，再做一次完整的链路还原验证。
常见坑
- 上线之后才补埋点，试运行期的操作没有任何记录，第一起争议就没有证据可用，事后难以补救。
- 容量按平均值规划，业务高峰写满磁盘，采集静默中断数天也没人发现，排查成本明显上升。
- 留存期限由技术团队随手定，合规评审时被质疑依据不足，历史日志只能重跑清理，合规评审时很难解释。
自检与验收清单
- 事件清单与字段是否在需求评审阶段就已确定
- 埋点是否随功能开发同步完成并通过联调验证
- 存储容量是否按业务峰值而非平均值评估，并有记录
- 主体标识是否已与身份源完成映射并验证，可现场抽查
常见问题
能不能上线后再补日志？
可以补，但补不回历史。试运行期的问题往往正是最需要证据的阶段，缺失就只能靠人证。若确实来不及，至少先记登录与关键操作，后续再补字段，并把这段缺口写进交接说明。
日志平台一定要新建吗？
不必。客户已有日志或安全平台时优先复用，减少一次采购与运维负担；只有容量或检索能力不足时才考虑扩展。复用时要确认字段可扩展、保留期可配置，否则后期改造成本更高。
留存期谁说了算？
由客户方法务与合规负责人按适用法规与行业惯例确定，我方提供可配置项与执行记录。涉及个人信息处理的还要说明到期销毁方式，这类判断不属于实施方权限，也不应默认延长保存。