企业应用集成清单用来回答三个问题：有哪些系统连在一起、数据怎么流动、出问题时找谁。清单需要逐条记录每个应用连接的身份与权限、数据方向与对象、触发方式与频率、字段映射、异常处理、责任人与验证证据。本文提供一张可直接复制填写的空白表格，逐字段说明填写口径与必填优先级，并给出一条完整示例和后续维护方法。清单建好后，可以放入ONES文档或工作项中随变更同步更新。
要点总览（TL;DR）
- 清单按“一条集成一行”组织，核心字段覆盖两端应用、数据方向与同步对象、触发方式与频率、字段映射、异常处理、责任人和验证证据。
- 集成名称、源应用、目标应用、数据方向、同步对象、触发方式、执行频率、技术责任人和状态为必填；认证权限与异常处理建议在上线前补齐。
- 暂时无法确认的字段填“待补”并写明补录责任人和时间，不留空白，也不批量臆填。
- 验证证据写到可复查的位置，如联调工单号、抽样比对记录、监控看板名称，避免只写“已测试”。
- 清单随集成新增、变更、下线同步更新，每季度由业务与技术责任人复核，并把更新清单作为集成类变更的完成条件。
企业应用集成清单空白模板（可直接复制）
下面这张表按“一条集成一行”组织。复制到表格工具或文档中即可使用，列名建议保持不变，便于不同团队横向汇总。每条记录对应一个明确的连接关系，例如“CRM同步客户到数据仓库”，而不是按系统笼统登记。
| 序号 | 集成名称 | 源应用 | 目标应用 | 连接方式 | 认证与权限 | 数据方向 | 同步对象 | 触发方式 | 执行频率 | 字段映射与转换规则 | 异常处理与重试 | 责任人 | 验证证据 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
使用时有两点约定：第一，一行只描述一个源到目标的连接，双向同步拆成两行或明确标注方向；第二，“验证证据”填写可复查的凭据位置，例如测试记录编号、日志截图存放路径、联调工单号，避免只写“已测试”。
每个字段记录什么：字段说明与口径
字段说明的作用是让不同人填写同一张表时口径一致。以下按字段分组解释含义与常见写法，填写时以“后来者能否据此复现或排查”为判断标准。
| 字段组 | 字段 | 记录内容与填写口径 | 常见写法示例 |
|---|---|---|---|
| 应用与连接对象 | 集成名称、源应用、目标应用、连接方式 | 写清两端系统的正式名称与版本环境；连接方式记录协议或中间件类型，如API、消息队列、文件传输、数据库直连 | 源应用“CRM生产环境”，连接方式“REST API，经集成平台转发” |
| 身份与权限 | 认证与权限 | 记录调用方身份、授权范围与最小权限说明，不记录明文密钥，只写密钥保管位置 | “服务账号 svc-crm-sync，仅客户读写权限，密钥存于配置中心” |
| 数据方向与同步对象 | 数据方向、同步对象 | 方向写单向或双向；同步对象写到业务实体级别，并注明范围过滤条件 | “单向，客户主数据，仅同步近两年有交易的客户” |
| 触发方式与频率 | 触发方式、执行频率 | 触发方式区分事件触发、定时调度、手动触发；频率写具体周期或实时 | “事件触发，客户状态变更时；每日02:00全量校对一次” |
| 字段映射与转换规则 | 字段映射与转换规则 | 记录关键字段对应关系、必填校验、枚举值转换、单位或格式转换；字段多时注明映射文档位置 | “客户等级A/B/C映射为1/2/3；手机号去除空格后写入” |
| 异常与重试处理 | 异常处理与重试 | 写清失败判定条件、重试次数与间隔、超限后的处理动作和通知对象 | “失败重试3次，间隔5分钟；仍失败则进入待处理队列并通知集成责任人” |
| 责任人与验证证据 | 责任人、验证证据 | 责任人写业务负责人和技术负责人各一名；验证证据写可复查的记录位置 | “业务：客户运营张三；技术：集成组李四；证据：联调工单 INT-1024” |
字段映射是最容易被简写的一项。建议至少记录主键字段、状态字段和时间字段的对应关系，因为这三类字段出问题最容易导致重复数据或状态错乱。转换规则涉及代码逻辑时，写明规则所在位置即可，不必在清单里粘贴完整脚本。
哪些必填、哪些选填：填写优先级
清单初建时不必追求一次填满，但影响排查和责任归属的字段必须先填。下表给出必填与选填的划分及理由，团队可在此基础上增加内部字段，不建议删减必填项。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 集成名称、源应用、目标应用 | 没有两端对象就无法定位连接，是所有排查的起点 |
| 必填 | 数据方向、同步对象 | 决定数据归属与冲突处理方式，缺失会导致重复写入或覆盖 |
| 必填 | 触发方式、执行频率 | 判断数据延迟和漏同步时直接依赖这两项 |
| 必填 | 责任人（技术） | 故障通知和变更评审需要明确到人 |
| 必填 | 状态 | 区分在用、停用、待上线，避免误操作已下线连接 |
| 建议必填 | 认证与权限、异常处理与重试 | 涉及安全与稳定性，上线前应补齐；初建期可先标注“待补” |
| 选填 | 连接方式 | 多套集成共用同一中间件时可统一在附录说明 |
| 选填 | 字段映射与转换规则 | 字段较少时可直接写在单元格；字段多时填写映射文档位置 |
| 选填 | 业务责任人 | 纯技术同步（如日志归集）可只保留技术责任人 |
| 选填 | 验证证据、备注 | 上线验收后补充；备注用于记录特殊约定或临时绕行方案 |
缺项处理遵循“标注而非留白”的规则：暂时无法确认的字段填“待补”，并在备注中写明补录责任人和计划时间；涉及认证、异常处理等建议必填项，应在上线评审前完成补录。定期复核时，把“待补”条目单独列出跟踪，避免长期悬空。
完整填写示例：一条应用集成记录
以下示例演示一条客户数据同步集成如何落到模板各字段。示例为演示情景，系统名称与人员均为虚构，填写结构可直接套用。
| 字段 | 填写内容 |
|---|---|
| 序号 | 007 |
| 集成名称 | CRM客户主数据同步至数据仓库 |
| 源应用 | CRM系统（生产环境） |
| 目标应用 | 数据仓库（分析层） |
| 连接方式 | REST API，经集成平台转发 |
| 认证与权限 | 服务账号 svc-crm-dw，仅客户实体只读权限；密钥存放于配置中心，每90天轮换 |
| 数据方向 | 单向（CRM→数据仓库） |
| 同步对象 | 客户主数据，含客户编号、名称、等级、所属区域、最近交易时间；仅同步近两年有交易记录的客户 |
| 触发方式 | 事件触发（客户新增或变更时）+ 每日02:00全量校对 |
| 执行频率 | 增量实时，全量每日一次 |
| 字段映射与转换规则 | 客户编号作为唯一主键；等级A/B/C转换为1/2/3；区域名称按区域编码表转换；时间统一为UTC+8；映射明细见《CRM-DW字段映射表 v2》 |
| 异常处理与重试 | 接口超时或返回5xx时重试3次，间隔5分钟；仍失败写入待处理队列，次日全量校对时补同步；连续两次失败通知技术责任人 |
| 责任人 | 业务：客户运营张三；技术：集成组李四 |
| 验证证据 | 联调工单 INT-1024；上线后抽样比对100条客户记录一致；监控看板“CRM-DW同步成功率” |
| 状态 | 在用 |
| 备注 | 客户合并场景暂不自动同步，由数据仓库侧手工处理 |
示例中异常处理写到了“失败后发生什么”这一层：重试、进入队列、补同步、通知，四个动作对应四种结果，排查时可以直接对照。验证证据同时包含工单、抽样比对和监控看板，分别对应上线验收、数据质量和日常运行三个环节。备注记录了已知的例外场景，避免后来者把“客户合并未同步”误判为故障。
清单的调整与维护方法
集成清单的价值取决于它是否与实际情况同步。建议把清单当作有责任人的活文档，而不是上线时填一次的项目文档。以下动作可以作为维护规则直接采用。
新增与下线集成
- 新增：集成方案评审通过时即创建清单行，状态填“待上线”；上线验收后补充验证证据并改为“在用”。
- 下线：先改为“停用”并注明停用日期与替代方案，观察一个约定周期确认无调用后再归档，保留历史行便于追溯。
- 变更：连接方式、同步对象、字段映射发生变化时，更新对应字段并在备注记录变更日期，重大变更同步通知下游使用方。
定期复核与责任人机制
建议每季度复核一次，由各集成的技术责任人确认状态、权限和异常处理仍然有效，业务责任人确认同步对象范围符合当前业务。复核结果记录复核日期，长期无人认领的条目列为清理对象。责任人离职或转岗时，交接动作中应包含清单条目的移交。
字段增删的调整原则
新增字段应说明用途并给出填写口径，避免同一信息出现两种写法；删除字段前确认没有下游报表或排查流程依赖它。必填项调整需要团队确认后统一生效，历史记录中的空值按缺项标注规则补齐，不做批量臆填。
与变更和上线流程的衔接
把“更新集成清单”作为集成类变更的完成条件之一：变更单关闭前，清单对应行已更新且验证证据可查。清单本身可以放在ONES文档中统一维护，集成的新增、变更和下线以工作项承载，状态流转与清单行同步，评审记录和验证证据关联到同一工作项，后续复核时按责任人筛选待确认条目即可。这样清单的更新动作就嵌入到已有的变更流程里，减少额外维护成本。
常见问题
集成清单里的“验证证据”具体应该放什么，放到什么程度算合格？
验证证据的目标是让另一个人不依赖口头说明就能复查这条集成确实按描述运行。可以放三类内容：上线验收阶段的联调工单号或测试记录编号；数据质量层面的抽样比对结果，例如抽取若干条记录核对字段一致；日常运行层面的监控看板名称或告警规则位置。合格的标准是证据可定位、可打开、能对应到具体时间点，只写“已测试”“运行正常”无法支撑后续排查。
双向同步的集成在清单里应该记一行还是两行？
建议按“一个源到目标的连接”拆开记录，双向同步写成两行，分别标注方向。这样做的原因是两个方向在触发方式、字段映射和异常处理上往往不同，例如A到B是事件触发、B到A是定时批量，合并成一行会丢失关键差异。如果两个方向完全对称，也可以在数据方向字段注明“双向”，并在备注中说明两个方向共用同一套映射规则，但排查时仍需能区分失败发生在哪个方向。
团队刚开始建清单，字段填不全，是先上线再补还是必须填完才能上线？
可以分阶段推进，但边界要清楚。影响定位和责任的字段必须先填：两端应用、数据方向、同步对象、触发方式、执行频率、技术责任人和状态。认证与权限、异常处理与重试涉及安全和稳定性，建议在上线评审前补齐；确实来不及的，在字段中标注“待补”，备注写明补录责任人和计划时间，并在复核时单独跟踪。字段映射在集成较简单时可以先写关键字段对应关系，复杂映射注明文档位置。
集成下线后，清单里的记录是删除还是保留？
建议保留并改为“停用”，注明停用日期和替代方案，观察一个约定周期确认没有调用后再归档。保留历史行的价值在于追溯：后续出现数据异常时，能查到某条连接曾经存在、何时停用、由谁处理。直接删除会让这段历史消失，也不利于审计。归档时可以移到单独的归档表或标记归档状态，保持在用清单的整洁。
清单放在文档里还是放进工作项管理，哪种更合适？
两种方式可以配合使用。清单主体适合放在文档中，便于整表查看、复制和横向汇总；集成的新增、变更、下线适合用工作项承载，因为这类动作有状态流转、评审记录和责任人。把清单放在ONES文档中维护，集成变更以工作项跟踪，状态与清单行同步，评审记录和验证证据关联到同一工作项，复核时按责任人筛选待确认条目即可。团队规模较小、变更不频繁时，单用文档也能运转。
