为什么现在要做一轮部署自检
超凡国际的部署往往不是一次完成就静止不变：接入的系统在增减、使用的人在轮换、依赖的外部条件在调整。如果只在上线时核对过一遍，后续的变更很容易留下没人注意的缺口。现在做一轮自检，目的不是重新选型，而是把当前实际运行状态与当初的设计假设逐项对照，找出已经偏离却未被记录的地方。
自检的时机可以选在变更集中发生之后，例如新增了对接系统、调整了权限范围、更换了值班安排，或者距离上次完整核对已经过去较长时间。把自检当成一次有范围的审计，而不是一次全面重来，才能在有限时间内得到可整改的结论。
自检范围与记录方式
先划定范围，再开始逐项核对。范围不清会导致清单越拉越长，最后无法收口。建议用一张表记录每个核对项的状态：通过、待确认、不通过，并附上证据位置或观察方式。
- 明确本次自检覆盖的系统、环境与时间段，写进记录表抬头。
- 为每个核对项指定一名观察人，避免自己核对自己。
- 核对项只记录可观察的事实，不写主观评价。
- 对“待确认”项标注需要谁提供信息、最晚何时补齐。
- 自检结束后保留记录表，作为下一轮核对的基线。
边界与依赖核对
边界与依赖是超凡国际部署中最容易被默认“一直没变”的部分。核对时重点看实际调用关系是否与记录一致，以及外部依赖是否仍在约定范围内。 超凡国际实用指南
- 列出当前所有对接系统，与部署记录中的清单逐项比对，标出新增和已停用的条目。
- 确认每个对接方向的调用频率与数据量是否仍在当初约定的范围内。
- 检查外部依赖的可用性是否被单独监控，而不是靠业务侧发现异常后再排查。
- 确认边界变化是否有变更记录，没有记录的变更视为待确认项。
- 核对依赖方联系方式是否仍然有效，避免异常时找不到对接人。
数据与权限核对
数据与权限的核对重点是“谁还能访问什么”，而不是“当初设计了什么”。随着人员轮换，权限往往只增不减，这是自检中最常见的偏差来源。
- 导出当前权限清单，与在岗人员名单逐一对照，标出已离岗或已转岗但仍有权限的账号。
- 检查是否存在多人共用同一账号的情况，共用账号无法追溯操作来源。
- 确认数据保留周期是否仍按约定执行，过期数据是否已被清理或归档。
- 核对敏感数据的访问是否有独立记录，记录是否可读、可查。
- 确认权限变更是否有审批痕迹，无痕迹的变更列为不通过项。
告警与回退核对
告警与回退是部署自检中最需要实际验证的部分。只看配置页面不足以判断是否有效，应至少做一次可回退的验证，并记录观察结果。
- 逐条核对告警规则对应的接收人是否仍在岗，通知渠道是否仍然可达。
- 确认告警触发后是否有明确的处置入口，而不是只发出一条通知。
- 检查回退步骤是否仍然可执行，回退所需的权限和依赖是否齐备。
- 在非高峰时段做一次回退演练，记录实际耗时与遇到的阻碍。
- 确认回退演练结果是否写回部署记录，未写回的视为待确认项。
交接与整改顺序
自检的价值在于整改。把核对结果按影响面和修复成本排序，先处理会影响运行连续性且修复成本低的项，再处理需要协调外部依赖的项。交接时确保下一轮值班人员知道哪些项仍处于待确认状态。
- 把不通过项按“影响运行连续性”和“修复所需协调量”两个维度排序。
- 优先处理权限遗留和告警接收人失效这类修复成本低、影响直接的项。
- 对需要外部依赖方配合的项，指定跟进人并设定补齐期限。
- 整改完成后更新部署记录，并在记录表上标注关闭日期。
- 把本轮遗留的待确认项写进交接说明，避免下一轮重复排查。