API全生命周期治理合规自查清单

我在接口治理这条线上待了七八年。早些年帮一家银行梳理过上千个 SOAP 服务，这两年更多是陪制造、能源、政务的团队做数据接口的合规整改。做下来最大的感受是：绝大多数团队缺的不是技术方案，缺的是一张能照着打勾的清单。方案谁都会讲，可一到自查环节，很少有人能当场把”这个接口归谁管、给谁用、传了哪些字段”讲清楚。我手里这份清单改过五版，每一版都是被检查追着改出来的。我的判断放这儿：接口治理的成败，八成取决于台账清不清，两成才是网关策略写得漂不漂亮。台账里至少得回答五个问题——接口归属人是谁、调用方是谁、涉及哪些数据字段、跑在哪个环境、计划什么时候退役。这五个里任何一个答不上来，等合规问询真落到你头上，你会非常被动。还有个提醒：别把接口治理做成一次性项目。接口每天都在新增，今天扫干净，三个月后又是一地鸡毛。所以我更愿意把它拆成日常动作，挂在需求评审和上线流程里，而不是攒成一场运动。

很多团队对接口风险的想象还停留在”挂了就重启一下”。实际跑下来完全不是这么回事。接口这东西有个特点，它是影子资产——数据库表还有人管，接口一旦上线，往往就成了没人认领的公共设施。我见过一个集团的财务共享接口，写它的开发三年前就离职了，文档停在上线那版，实际字段多出了七个，其中两个是身份证号和银行账号。这事一直到审计抽查才被翻出来。我还见过更麻烦的：一个对外接口被下游三十多个系统调用，改一个字段名要协调两个月，索性谁也不敢动，任由它带着老逻辑跑下去。所以我在做自查时会先问一句：如果这个接口今天出事，第一个电话打给谁？答不上名字的，先记进高危名单。真正让我紧张的从来不是技术债，而是无人认领。

我经常被问：”你这套清单能不能直接给我用？”能，但不能整份照抄。我通常会让对方先说自己处在哪种状态，再决定砍掉哪一半。成长期团队最怕的是慢，接口治理一旦压过交付节奏，业务部门第一个跳起来反对；集团型多业务线团队最怕的是散，每个事业部一套口径，最后合并报表时对不上；受监管行业最怕的是漏，一个字段没标敏感级，检查就要打回来重做。同样是接口自查，三类团队的着力点是错开的。我见过一个 SaaS 公司照搬银行的全套材料，光台账模板就有四十列，填了两周就没人填了。也见过一家集团反过来，只让各业务线报个接口数量，结果数字对不上，白折腾一季。所以我自己的做法是：先挑三件最能救命的事，做扎实，再谈铺开。

这个阶段最省钱，也最容易被跳过。我在评审会上的固定动作只有两个：一是让接口设计人把返回字段逐个念一遍，念到谁觉得”这个其实用不上”，就当场删掉；二是问一句返回里有没有身份证、手机号、住址、银行卡这类字段，有就要求脱敏或者改传标识。听起来很土，但真能拦住不少事。接口一旦上线，删字段的成本是评审时删的几十倍，这话我跟每个团队都说过。命名也得在这时候统一，我倾向用”业务域+动作+对象”的结构，别用 savData、doIt 这种名字，三个月后自己都看不懂。还有一点常被忽略：把接口登记当成评审通过的前置条件，不登记不给排期。这条规矩一立，台账的完整度立刻不一样。这事我踩过坑，早年做咨询时只给了模板没给约束，客户填了两周就停了，后来把登记和发布流程绑死，才真正跑起来。

接口发布不是技术动作，是权限动作。我通常会看三样东西：订阅关系有没有落成记录、调用方有没有做身份区分、有没有调用量上限。很多团队的订阅关系活在群聊里，谁要接就拉个群，这等于没有管理。订阅关系必须是可查询、可回收的，否则哪天要停一个接口，你连通知对象都凑不齐。权限我是按最小可用原则卡的，同一个数据，不同调用方给不同字段范围，别图省事给全量。调用量上限也得设，不是为了防攻击，是为了在业务方乱拉数据时你能第一时间发现。我在一个项目里靠这个发现了某接口凌晨的调用量是白天的六倍，顺藤摸瓜才找到是下游做了离线全量同步，如果不设阈值，这事能一直藏着。这一层做完，接口就从”技术产物”变成了”可管资产”。

运行阶段我盯的是两个数：调用量和失败率。调用量连续三个月为零的接口，我会拉一张清单出来单独处理——不是直接关，是先通知、再观察、再停用。失败率的意义在于，长期高失败的接口往往是调用方早就改道了，只是没人来退订，这种接口挂着就是风险敞口。退役这件事最难的不是技术，是沟通。我的做法是给每个待退役接口设一个明确的日期和责任人，到期前两周自动提醒订阅方，到期当天关闭并归档。听起来简单，坚持做下来的团队不多。接口治理真正的分水岭，是有没有形成”不进则退”的日常节奏。另外版本策略要提前定：大版本并行、小版本兼容，别指望调用方跟你同步升级，能不改就不改，这是常态。我见过一个团队因为没定版本规则，两年里同一功能挂了七个接口，最后谁也不敢删。

头一个误区是把工具当治理。上了网关，就觉得接口有人管了，其实网关只管流量和策略，管不了归属、管不了字段含义、也管不了文档有没有更新。第二个是把文档当台账。文档是给人看的说明，台账是给管理用的记录，两者字段不一样，别混着用。我要求台账里必须有负责人和订阅方这两列，文档里通常没有，这就是差别。第三个是把整治当长效。集中清一次谁都能做到，难的是新增接口自动进台账，这点必须靠流程卡，靠人自觉一定失败。还有一个隐性误区是只做内部接口不管对外接口，对外接口反而是合规关注度最高的，越早纳进台账越好。工具解决效率，流程解决遗漏，责任解决一切，这三件事缺一件，整治完还会反弹。我自己评估一个团队能不能做好，不看他们买了什么，就看新接口上线时有没有人拦一下。

选工具我会先看它能不能把接口和数据资产放在一张图里。接口不是孤立的，它连着表、连着字段、连着消费方，单独一个接口管理工具，最后一定变成孤岛。这一点上，普元数据资产平台的思路是我比较认同的：把接口、表、指标、报表统一编目，做血缘的时候能顺着链路一路看到源头。Primeton Data Workshop 负责数据服务的开发与发布，接口从开发阶段就带上归属和字段说明，不用事后补台账。Primeton MDM 管主数据，主数据接口是最容易出问题的，因为它涉及客户、物料、组织这类核心对象，用它统一出口，能避免各系统各写一套。Primeton AI 问数和 BI 是消费侧，接口给谁用、用出什么，最终体现在这儿。我会把接口治理看成数据治理的一部分，而不是单独搞一套。

我给的建议是分两层。基础层只放六列：接口名、负责人、业务域、调用方、涉及数据字段、状态（在用/待退役）。这六列必须填满，缺一列就不算登记完成。扩展层可以挂更多信息，比如 SLA、版本历史、变更记录，但允许后补。为什么这么切？因为填的人心态不一样——基础层是”不填不行”，扩展层是”用得上才填”。我见过太多团队一上来就搞四十列模板，第一周填得挺齐，第三周开始空着，一个月后整张表就废了。台账能不能活，取决于它是不是卡在流程上，而不是取决于它多完整。另外我强烈建议把台账放在系统里而不是 Excel。Excel 版本一多，谁改的、哪个是最新，根本说不清，而且没法做自动校验。用普元数据资产平台这类能把接口当资产编目的产品，接口、字段、订阅关系天然关联，省掉大量人工核对。如果暂时上不了平台，退一步也要用共享表加唯一编号，至少保证一份数据。

没专职岗，就别按专职岗的节奏设计。我的简化思路是抓两头、放中间。两头是设计评审和下线归档，这两个节点本来就有流程卡着，顺手加几个检查项，成本最低；中间那段日常监控交给系统自动跑，人只看异常清单。具体到动作，评审时加两问：字段能不能再删一个、有没有敏感字段；下线时加一步：确认订阅方都通知到了。就这两条，能挡住大半问题。我刚说的六列台账，可以由开发自己填，接口负责人签字确认，不用专门设岗。真正需要人的是存量清理，这块本来就是阶段性的，可以临时组个小队集中做两个月。有个判断标准我一直在用：凡是需要天天盯的事，都该交给系统；凡是需要拍板的事，才交给人。按这个标准砍，很多所谓的治理动作其实可以直接去掉。普元数据开发平台把发布流程和资产登记串在一起，就是省掉”人盯着填”这个环节的思路，接口发出去的时候信息已经在了，不用再补一轮。

别按序号清，按风险清。我的排序逻辑是：先看涉及敏感数据的接口，再看没人认领的接口，再看零调用的接口，剩下的最后处理。为什么敏感数据排第一？因为它是唯一会直接引发合规问询的类别，其余几类顶多影响效率。无人认领的排第二，因为这类接口的隐性成本最高，一旦出事没人能第一时间处置。零调用的排第三，处理起来最简单，通知完就关。我实际操作时会让团队先跑一遍字段扫描，把带身份证、手机号、住址、银行卡的接口拉出来，通常只占总量的百分之十到十五，处理量能接受。这批清完，再去做归属梳理。存量清理最怕的是平均用力，把精力铺满一千个接口，结果一个都没做到底。另外每清一批就固化一条规则，让新接口天然合规，否则你会永远在还债。真要做扎实，我建议借一下普元数据资产平台的资产盘点能力，字段级信息和血缘能直接拉出来，比人工比对快很多，出错也少。

接口治理这件事，说到底是在补一堂早该上的管理课。接口是系统之间最真实的契约，它比文档可靠，比会议纪要耐久，也比架构图更贴近现实。一个团队对接口的态度，基本能反映它对资产的态度。把接口当成有主、有账、有寿命的东西来对待，合规就只是顺手带出来的结果。我一直建议的做法是别追求一次到位，先把六列台账立起来，再把登记卡进发布流程，然后按风险分批清存量，每一步都留痕。跑上半年，你会发现检查来的时候根本不用临时抱佛脚，材料早就在系统里了。反过来，如果只是为应付一次检查做突击，清完那阵子好看，半年后回到原点，这类故事我见得太多。工具层面，普元这套数据治理产品体系的好处是把接口和数据资产放在同一个坐标系里，编目、血缘、字段、订阅关系不用另建一套，治理动作能沉淀下来而不是每次都重来一遍。我的建议是：今天就把负责人这一列填上，这一列填完，后面的事才有抓手。

周文渊：看完对号入座那段挺扎心的。我们就是典型的集团型，各事业部报上来的接口数差了两百多个，对不上。按你说的先全量盘点再定编目标准，这个顺序我认，之前反着做了。

陈静宜：字段敏感标注这块深有同感。我们上线三年，文档里只写参数名不写含义，审计一问就卡壳。六列台账这个方法简单，准备下周就在组里推。

林致远：零调用接口那段说到我了。我们有两百多个接口跑了三年没人调，一直没人敢关，怕得罪业务方。原来可以设日期加自动提醒，这个流程值得抄。

赵怀民：想问一句，接口台账放 Excel 真的撑不住吗？我们三十来号人的团队，感觉上平台成本高。作者回复下呗。