接口巡检按业务分级
核心闭环的接口每小时探活，非核心按天。探活不只看通不通，还要看返回条数与关键字段是否为空。只探连通性会出现接口正常但数据为空的情况，业务侧仍拿到错误结果，且难以察觉。
字段变更要监控
源系统升级常改字段名或含义，聚合层不会主动报错，只会静默错位。做法是对关键字段做基线采样，定期比对取值分布，异常波动即触发核查。这比等业务发现数字不对要早得多。
日对账与差异台账
每天抽少量样本做双入口比对，差异记入台账并跟踪到关闭。样本不必多，但要覆盖金额、状态与时间三类字段。台账积累后能看出哪些系统最不稳定，运维资源据此分配更有依据。
权限复核与退役
账号与权限按季度复核，离职与转岗同步要验证到聚合层。退役台账记录每套系统的使用率与替代方案，达到条件即启动下线。只加不减的聚合层，三五年后会变成新的历史包袱。
适用与不适用
适合谁
- 聚合层已上线、需要长期运维的企业
- 源系统升级频繁、字段经常变化的集团
不适合谁
- 尚在建设阶段、接口尚未稳定的项目
- 没有运维岗、也不打算设置的企业组织
典型场景
某集团的聚合入口上线半年后，财务发现两张单据状态不一致。排查发现源系统升级改了状态字段取值，聚合层仍按旧值映射。团队补了字段基线采样与日对账，把差异台账纳入周会，并按季度复核账号与退役条件。
可执行步骤
- 按业务影响分级，为每类接口设置探活频率与告警接收人
- 对关键字段做基线采样，定期比对取值分布的变化并留档
- 每天抽少量样本做双入口对账，并把差异登记进台账跟踪关闭
- 按季度复核账号与权限，并验证离职账号在聚合层已停用
- 维护退役台账，达到约定条件即启动下线，并留存过程记录
常见坑
- 只探接口连通性，不校验返回内容，数据为空也算健康，业务侧长时间拿到空结果。
- 源系统改字段后无人比对，聚合层静默错位，等业务发现时已积累数月错误数据，回算困难。
- 权限只在原系统复核，聚合层残留离职账号，形成不易察觉的访问缺口，审计时才会暴露。
自检与验收清单
- 接口探活频率与告警接收人是否按业务分级
- 关键字段是否做基线采样并定期比对
- 是否每日对账并把差异登记为可跟踪台账
- 权限是否按季度复核并覆盖聚合层账号
常见问题
巡检要自动化到什么程度？
探活、条数与关键字段为空这三类可以全自动；取值分布比对可半自动，异常时人工确认。全自动判断业务正确性不现实，也没必要，关键是把发现时间从月结提前到当天。
退役一套系统难吗？
技术上不难，难在确认没人还在用。做法是把访问日志统计与业务方确认并行，先只读保留一段时间再停。缺少使用率数据就下线，容易在停服后才发现有部门仍在依赖。
聚合层要不要做容灾？
按业务影响分级：核心闭环应能在单套源系统故障时降级展示并明确提示，非核心可接受短时不可用。降级策略要写进运维手册并演练，否则故障时没人知道哪些功能还能用。