离开上一段工作前，我花了一段时间整理交接材料。最后汇总下来，正文接近三万字。
这个数字本身没有什么值得炫耀的。文档写得长，不代表交接做得好。真正让我反复修改的，是另一个问题：如果接手的人在两周以后遇到一个我没有预料到的线上问题，他能不能靠这些材料继续往下走？
如果答案只是“能找到某个操作步骤”，那还不够。系统不会只在文档覆盖过的场景里出问题。一个人离开团队后，真正需要留下的不是他的工作回忆，而是足够清楚的判断路径。
我当时负责和参与过多套内部数字化系统。有的是 Java 和 Spring Boot，有的是 .NET Core，有的是 Vue 前端加后端服务，有的还连着 Oracle、SQL Server、Nginx、IIS、Tomcat、ETL 任务、外部接口、证书、防火墙和定时任务。单独看每个系统都能写一份说明，但交接时最容易出问题的地方，往往出现在系统之间。
工单完结之后，之前填写的工单内容竟然发生了变化。
我们在内部工单系统里发现了这个BUG。模板设计者可以给下拉框、表格列等字段配置动态数据源。工单填写时，用户看到的是当时的数据；流程完结后，页面仍会沿着原来的配置再次读取数据源。源数据有更新后，几个月前已经完成的工单也会跟着变。
这不是简单的显示不一致。已完结工单应该能还原当时的申请内容和审批依据。若历史页面展示的是后来变化过的数据，审计和追溯就失去了一个基本前提。
这篇记录的是一次修复过程。代码和日志均做了脱敏，但保留了当时的处理顺序、失败路径和判断依据。
这次问题最早不是从数据库指标开始的，而是流程专家找我说：有一张表查询一次要等很久。
我第一反应其实很常规：是不是查的数据量太大了？流程类系统里有些历史表一跑就是几年数据，如果查询条件再松一点，慢也不奇怪。结果他补了一句：这张表总共才几千行。
这就不太对了。几千行的表，哪怕 SQL 写得不算好，也不应该慢到让业务侧明显感知。我还是抱着质疑的态度自己执行了一下
SELECT COUNT(*)
FROM table_a;
这次问题发生在一个 Oracle 查询上。业务页面要展示一批物料在仓储流程里的状态，数据来自本地表，也来自一张通过 DB Link 访问的远程明细表。页面慢，用户看到的是转圈，开发看到的是一段很长的 SQL。
我第一次看这段 SQL 的反应很直接：太乱了，先整理一下。
它里面有 CTE，有远程表，有 CONCAT(CREATION_DATE, CREATION_TIME)，有 SUBSTR 截取库位号后 10 位，有 TO_CHAR(rm_tag, 'hh24miss') 判断班次，还有一堆状态 CASE WHEN。从代码可读性上看，确实有很多可以改的地方。问题是，数据库不按人的阅读体验执行。
这次问题发生在一次工单系统的版本升级里。
系统本身是公司内部流程工单系统。普通用户在里面填写、提交工单；模板设计者可以在前台配置表单字段、字段联动和流程等。对普通用户来说，一个下拉框只是一个下拉框。对模板设计者和系统管理员来说，它背后可能连着一份外部数据。
旧版本允许模板里的下拉框直接引用外部 JDBC 数据源。新版本准备把这条路收掉，改成由 API 提供数据。这个改动不是为了换一种写法。JDBC 直连数据库会牵涉账号、网络连通性、权限范围、审计日志和数据暴露边界。
根据公司对于系统安全的合规审计，这些要求不能靠模板设计者配置时“注意一下”来解决。
我一开始对数据平台的理解很直接：把数据接进来，存到库里，再提供页面、报表或者接口给别人用。
做过以后，发现这个理解太简单了。
报表和页面在很靠后的位置。麻烦的事情在前面：数据从哪里来，字段是谁定义的，谁负责解释口径，多久刷新一次，谁可以消费，接口申请有没有审批，质量规则失败以后谁处理，整个数据量越来越大以后如何管理。
这些问题如果只靠文档和人工沟通，平台很快就会变成一个更大的“查数入口”。页面很多，表很多，数据很多，但每一次字段变化、规则失败、接口异常，还是靠人去问、靠日志去翻。
这篇文章不是讲完整的数据治理理论。我只记录自己在内部数据平台项目里碰到过的几个具体问题，以及后来为什么会觉得：数据平台要管理的不是页面，而是数据关系。
Smart Quotation (SQ) ，一个公司内部的报价系统。它不是面向互联网用户的产品，是在公司内部流程里承接报价、项目、主数据、计算这些事情。这个系统一开始不是为 global 场景设计的。
它最早只是给 local 本地工厂使用。后来 global 团队发现，这套系统在其他区域也有复用价值。前面的业务讨论大部分都已经推进得差不多了，大家要确认的是：这套中国已经跑成熟的系统，能不能作为 global 方案继续往前走。
事情卡住的地方，反而不是业务流程。
德国中央总部有一位并不直接负责技术的同事看完之后，粗糙的评论了一句：C# 这个语言太老了，这个系统技术不行。