Cortex、OpsLevel 与 Compass 到 DX：托管服务目录选型和迁移

高谷深陵大约 24 分钟约 7125 字

平台团队第一次做服务目录时，常把“能自动导入仓库”当成成功。两周后，目录里有一千多个组件，却有三套 Owner、两种服务标识和大量空关系；生产就绪 Scorecard 全绿，只因为规则检查了字段是否存在；更麻烦的是，原先计划继续使用 Compass 的团队发现目录与 Scorecard 正在转向 DX，迁移并不包含所有对象。真正的选型问题不是哪家页面更多，而是哪一种数据模型、权威策略、改进闭环和退出路径能被组织长期承担。

Cortex、OpsLevel 和 DX Fabric 都是商业专有产品，不存在可自由替换供应商控制面的开源许可。常见入口是供应商托管租户，但“商业平台”等于“只能多租户 SaaS”也是误判：Cortex 提供由厂商交付安装器的 on-premises 形态；OpsLevel 提供通过 Replicated 分发到客户 Kubernetes 的 Self Hosted 形态；DX 除多租户 SaaS 外还有厂商托管的单租户 Dedicated，以及部署在客户云账号、仍由 DX 运维的 Managed 形态。DX Managed 的详细部署指南当前给出 AWS 路径，GCP 仍标为 coming soon，不能把概览中的 GCP 目标当成已可交付基线。三家 SaaS 都没有供客户固定的统一稳定版本号，自托管版本则受合同发布通道、镜像或 Helm Chart 约束，升级前必须保存配置、固定制品并验证回滚。

启用动作通常从创建工作区、配置 SSO/用户、连接 SCM 与其他数据源、导入试点实体，再建立 Scorecard 开始。Compass 已经进入向 DX 迁移的阶段，不适合作为新的稳定基线；已有 Compass 组织应把它当源系统和迁移项目来管理。数据驻留、单租户、客户云、私网接入、SLA、备份恢复和支持责任都是合同能力，不能从产品演示或“self-hosted”字样自行推断。

托管服务目录的选择与迁移高清原图

先让部署、数据流和恢复责任对得上

选型会上最容易出现的误会是“自托管就没有供应商访问”和“单租户就没有数据出口”。Cortex on-premises 需要厂商安装器和商业授权；OpsLevel Self Hosted 需要 Kubernetes、Helm Registry 凭证以及 MySQL、Postgres、Redis、Elasticsearch 和对象存储，官方默认试用组件不建议用于生产；DX Managed 虽位于客户云账号，安装、升级、监控和 on-call 仍由 DX 承担，持续运维需要 DX 人员具备约定的网络访问。部署地点、运维主体和软件许可必须分三列记录。

灾备也不能只问“供应商有没有备份”。SaaS 或 Dedicated 要从合同取得数据区域、备份频率、跨区复制、RPO、RTO、恢复演练、支持升级和终止后删除证明；客户托管形态则要把责任落到具体存储。OpsLevel 官方明确说明 MySQL 丢失会丢全部应用数据，Postgres 丢失会丢历史报告，Redis 丢失会丢待处理任务且部分任务不会自动补回，因此生产必须使用受监控的外部数据存储并实际恢复备份。Cortex on-premises 与 DX Managed 同样要拿到组件清单、状态存储和升级回滚手册，不能只备份 GitOps 文件。

连接器决定真实攻击面和出口费用。Cortex Cloud 拉取内网 Git 时需要静态 IP、代理或 Relay；Kubernetes Agent 则以只读 get/list/watch 权限从集群主动向 Cortex 推送。OpsLevel SaaS 的 GitHub App 便于自动轮换，但 PAT 路径需要仓库、组织和 webhook 权限；Self Hosted 的 GitHub App 文档甚至包含 Contents、Checks、Pull Requests 的读写权限，若只做目录发现就必须删减并用失败实验确认哪些能力因此不可用。DX 支持静态 IP、网络代理和自托管 extractor，也提供单租户或客户云网络选项。每条连接都应记录方向、DNS/目标地址、端口、源身份、scope、读取的字段、峰值流量和撤销步骤，跨区 SCM、日志与代码内容扫描还要进入出口流量预算。

用同一组件样本建立比较基线

不同产品术语会诱导团队按页面做比较。先固定一个与产品无关的组件模型，才能看出导入和治理差异。样本 payment-api 是生产服务，稳定标识不随仓库改名变化；它由 payments 团队负责，属于 checkout 域，依赖 ledger-api，关联一个主仓库和一个 runbook。质量规则要求 Owner、仓库、值班和近期验证过的 runbook 都可用。

component:
  id: payment-api
  name: Payment API
  type: service
  lifecycle: production
  tier: tier-1
  owner: payments
  domain: checkout
  repository: https://example.com/your-org/payment-api
  dependsOn:
    - ledger-api
  runbook: https://example.com/runbooks/payment-api
  evidence:
    runbookLastVerified: T-30d

统一模型的核心不在字段拼写，而在不变量。id 必须全局唯一且不可复用；Owner 引用团队标识而不是显示名；依赖引用目标组件 ID；生命周期枚举有退出语义；证据带来源和年龄。导入到各平台后，应能反向导出并重建这些不变量。若某个产品只保留显示名、把 Owner 降成邮箱文本、或者关系导出后只剩 URL，迁移成本已经在第一天产生。

验证采用同一组样本：payment-api 是完整实体，ledger-api 故意缺 Owner，old-worker 标记 deprecated，另放一个同名不同 ID 的错误仓库。正向结果应导入两个有效组件并保持关系；反向结果应暴露缺 Owner、重复候选和过期组件，而不是静默合并。产品内置推荐可以辅助判断，但最终合并规则必须由稳定 ID 和权威表决定。

Cortex：Entity Descriptor、Scorecard 与 Initiative

Cortex 的目录核心是 Entity。Entity Descriptor 是兼容 OpenAPI 3 的 YAML，并通过 x-cortex-* 扩展表示类型、唯一 tag、Owner、组、依赖和自定义数据。x-cortex-tag 是稳定标识；x-cortex-type 决定实体类型。目录页面本身更像实体集合过滤器，Catalog 需要在 UI 创建，不能仅靠 GitOps 创建。

启用时先由工作区管理员创建 Cortex 工作区和最小角色，连接一个试点 Git 组织，然后在 Catalogs 中选择发现结果导入。也可以通过 UI 手工创建、API 写入或 GitOps 解析 cortex.yaml。导入向导应显式设置 Entity type、tag、Owner、仓库和 on-call，不要接受所有自动推荐。完成后在 All entities 搜索稳定 tag，查看来源文件、最近 GitOps 日志和 Owner。

openapi: 3.0.0
info:
  title: Payment API
  description: Handles payment authorization.
  x-cortex-tag: payment-api
  x-cortex-type: service
  x-cortex-groups:
    - tag: checkout
  x-cortex-owners:
    - type: group
      provider: CORTEX
      name: payments
  x-cortex-link:
    - name: Runbook
      type: RUNBOOK
      url: https://example.com/runbooks/payment-api

x-cortex-owners 可以引用 Cortex 团队、IdP 或 SCM 组，也可以使用邮箱；团队 Owner 比个人邮箱更能承受人员变化。父域或关系可以设置 Owner 继承，APPEND、FALLBACK、NONE 会分别追加、仅在子实体无 Owner 时回退、完全不继承。配置错误会造成 Owner 过多或无人负责：正向实验让子服务无显式 Owner 并设置 FALLBACK，预期得到域 Owner；反向实验给子服务错误 Owner 再使用 APPEND，若页面同时出现两队，就证明继承不是覆盖，必须明确责任规则。

GitOps 会在默认分支寻找 cortex.yaml/cortex.yml，也支持集中仓库中的 .cortex/catalog、.cortex/teams、.cortex/domains 和 .cortex/scorecards。删除描述文件是否归档实体取决于 auto-archival 配置；移动文件不等同删除。UI editing 与 GitOps importing 的组合尤其容易误解：GitOps 日志可能显示提交但处理了零实体，因为该类型允许 UI 编辑却禁用了 GitOps 导入。排障时先看 GitOps log 的 processed/omitted 数量，再看文件格式和默认分支。

Cortex Scorecard 先要求目录中已有 Entity 和所需集成。规则可以用表单或 CQL，采用等级递进或积分；evaluation window 决定重评周期，过短会撞到第三方 API 限流，过长会扩大陈旧窗口。规则应给出失败消息和修复入口。Scorecard 负责持续基准，Initiative 则把已发布 Scorecard 的某个等级或规则变成有目标、期限、适用实体、Owner 通知和行动项的改进计划。草稿 Initiative 不通知，正式启动后实体 Owner 才收到待办。

正向实验创建只适用于试点服务的“生产准备”Scorecard：Owner 存在、runbook 链接存在、值班集成返回有效对象；触发评估后 payment-api 通过，而另一个已有 Owner 但缺 runbook 的试点实体失败。再建立 Initiative，目标是补齐 runbook，预期行动项到达该实体的真实 Owner。ledger-api 缺 Owner 的样本单独验证未分派状态、平台兜底队列或 Initiative Owner 接管，不能期待系统把任务送给不存在的 Owner。反向实验撤销 on-call 集成权限；规则应显示错误或未知证据，不能继续沿用无时间戳的绿色结果。

API 可分页列出 Catalog Entities，返回稳定 tag、类型并按需包含 Owner、metadata 和 links；页大小有上限，大目录导出必须遍历全部页面并记录归档实体。GitOps 适合评审式变更，但官方建议不要用它做高频大批量更新，大规模同步使用 API。退出快照至少包含 Entity descriptor、团队、类型、关系、Scorecard、Initiative 定义、归档状态和外部集成映射；仅复制 cortex.yaml 不能重建 UI 创建的 Catalog 和所有租户设置。

OpsLevel：Component、Rubric、Scorecard 与 Campaign

OpsLevel 以 Component 为目录对象，Service 是常见组件类型。团队、层级、生命周期、系统和域共同组织组件；alias 是 API、YAML 和集成匹配的关键。Git、告警、部署或自定义事件集成会发现候选组件，团队也可以通过 GraphQL API、CLI、Terraform 或 opslevel.yml 写入。

启用时创建工作区后先配置身份源和团队，再连接一个 Git 提供方。Component Detection 会给出候选，不应把所有仓库立即确认成服务。对样本逐项核对组件名称、alias、type、owner、lifecycle、tier 和 repository。opslevel.yml 文件名只识别 .yml，并且顶层使用 component 或 repository；旧的 service 顶层已不应作为新配置基线。Owner、tier 和 lifecycle 使用人类可读 alias，因此 alias 改名或冲突会直接影响导入。

component:
  name: Payment API
  type: service
  owner: payments
  lifecycle: production
  tier: tier_1

正向实验先确保 payments team alias、production lifecycle 和 tier_1 已存在，再合并文件；预期同一 Repository 关联到 payment-api Component，Owner 和生命周期被解析。反向实验把 Owner 写成显示标题而非真实 alias，并把文件命名为 opslevel.yaml。预期自动检测不更新或报告无法解析，而不是创建一个同名新团队。修复后要在 Component activity 和集成日志中确认来源，不只刷新页面。

OpsLevel 的组织级 Rubric 决定持续成熟度模型，Category 和 Checks 逐级影响组件成熟度。独立 Scorecard 针对一组 Component 做专项检查，拥有单独的成熟度报告，但不影响服务总体 Service Level；这使它适合团队标准、上线前试验和阶段性行动。只有把检查正式纳入组织 Rubric，才会改变总体成熟度。上线前对同一试点分别查看 Scorecard 结果和整体 Rubric，确认专项试验没有被误接成组织级门槛。

Campaign 是与 Cortex Initiative 相近但语义不同的改进机制：它围绕一组检查、目标组件、负责人和期限推动一次组织变化，组件 Owner 处理未通过项；结束时可以把有长期价值的检查复制到 Rubric，形成持续标准。若把临时迁移检查一开始就放进 Rubric，会长期惩罚已不适用的组件；若 Campaign 结束后不沉淀关键检查，组织又会回退。比较时应把 Initiative/Campaign 都看成“从失败证据到责任行动”的层，而不是简单功能勾选。

OpsLevel GraphQL API 适合与工单、事件和内部自动化集成；Terraform Provider 可管理目录和成熟度对象。OpsLevel Terraform 文档还提供 opslevel export terraform，会生成 Terraform 配置和 import 脚本，但输出是某一时刻的快照，Provider schema 变化可能使 terraform plan 失败，弃用字段和关系块尤其需要人工检查。正确演练是导出到隔离仓库、固定 Provider、执行 terraform init 与只读 plan，确认无意外创建或删除后才接管 state。

Compass 的现实是迁移，不是继续加深绑定

Compass 的核心对象是 Component，包含类型、生命周期、Owner team、链接、依赖、事件、指标和 Scorecard。组件可由连接的 Bitbucket/GitHub 自动创建，也可经 UI、config-as-code 或 GraphQL API 管理。compass.yaml 中的唯一 ID 维持组件与文件的连接，文件在同一仓库内移动不应改变组件身份。对于存量组织，这些能力仍需稳定运行，但所有新自动化都要经过迁移价值审查。

Atlassian 已明确把 Compass 的目录和 Scorecard 转向 DX Fabric，并公布了计划中的支持结束节点。实施时应在 Compass 到 DX 迁移页面确认合同、支持节点和租户安排，不在内部路线图里假设 Compass 会无限期存在。更重要的是，DX 不是 Compass 数据库原样换壳：组件会重建为 Entity，依赖成为关系，团队映射规则变化，部分双向 Jira/JSM 连接仍存在缺口。

迁移工具执行一次组件目录同步，并可持续把 Atlassian Teams 同步到 DX。需要同时提供 Compass 与 DX API keys。团队模型有实质差异：DX 中用户只属于一个团队，并要求 Team Lead；Compass/Atlassian Teams 中的多团队成员必须选定一个归属，缺少 Team Lead 时迁移过程会推断负责人。这个转换会改变 Owner 语义，不能只比较组件总数。

明确不会自动迁移的对象更关键：Compass Scorecard 必须在 DX 重建；关联的部分 on-call 信息不会直接进入 DX Entity；告警和运维能力需要迁往 Jira Service Management。官方迁移流程会提供一段双系统并行期，但并行不是双向一致性保证。冻结窗口中若继续在两边改 Owner、关系和 Scorecard，最终很难判断哪边权威。

DX Fabric：以 Entity、API 和 Terraform 接住目录

DX Software Catalog 使用 Entity，可以连接 SCM 自动发现仓库。自动发现的仓库先进入 pending 状态并由用户批准，避免把每个实验仓库直接变成权威服务。Catalog 可以通过 API 从多个系统同步，关系模型能承载分组和纵向依赖。所有 DX 客户都有 Service Catalog 基础入口，但自定义 Entity Type、Property、Relation 和 Team Entity 属于 Fabric 能力，不能拿基础租户的 Service Entity 推断完整目录模型。Owner 与 Team 进入 Scorecard 和 Initiative 的责任链，因此身份源映射应先于质量计划上线。

启用流程从 DX 工作区、SSO/团队和 SCM 连接开始。先审批统一样本的仓库，给 Entity 选择稳定 identifier 和 type，再设置 Owner、关系与 JSM alias。用户、CLI 或代表用户运行的代理使用带过期时间和 scope 的 PAT，权限上限受签发者当前角色约束；后端和机器间流量应使用 organization token。只读验收先调用 Catalog 与 Scorecard API，确认分页、identifier、失败检查和审计归属。Terraform Provider 可管理 Catalog 与 Scorecards 配置，适合把模型、检查和关系配置纳入评审；Provider Registry 才是当前资源和字段的权威，升级前必须看 plan，不能把 Provider 支持推断为“租户所有数据均可导出”。

DX 的 Scorecard API 可按 Entity identifier 读取当前报告，并用 only_failing 筛选未通过检查。判据要区分 passed: false、豁免和没有证据。Initiative 把 Scorecard 失败项分配给 Owner 并推动整改。迁移 Compass Scorecard 时先导出旧定义和适用组件快照，再在 DX 建立草稿规则，对同一实体集合比较分布；结果一致后才启用通知。仅凭“Scorecard 数量相同”不能证明迁移完成。

用统一矩阵做选型而不是数功能

决策面	Cortex	OpsLevel	DX Fabric / Compass 迁移
目录对象	Entity descriptor，tag 与 type	Component、alias、type	DX Entity 与自定义类型；Compass Component 为迁移源
导入	UI、发现集成、GitOps、API	Detection、`opslevel.yml`、API、CLI、Terraform	SCM pending 审批、API、Terraform；Compass 一次迁移连接器
Owner	团队/用户与继承策略	Team alias 与目录关系	DX Team/Lead；Compass 团队需映射
标准	等级或积分 Scorecard、CQL	组织 Rubric 与独立 Scorecard	DX Scorecard；Compass Scorecard 需重建
改进计划	Initiative + action items	Campaign，可沉淀检查到 Rubric	DX Initiative；Compass 无自动迁移结果可依赖
配置即代码	Cortex YAML、Scorecard/Workflow GitOps、API	`opslevel.yml`、GraphQL、CLI、Terraform	DX API 与 Terraform；Compass config-as-code 为迁移输入
导出	API + GitOps 文件，API/UI 对象另盘点	Terraform 快照 + GraphQL/S3/CSV 补足	DX API + Provider 已支持配置；Compass 先做源快照
退出难点	Catalog/UI 设置、集成映射不全在 YAML	Terraform 快照需适配 Provider schema	产品迁移进行中，Scorecard、团队、运维能力分流

适合 Cortex 的信号是团队希望以实体描述文件和丰富查询规则管理多类型目录，并把 Scorecard 失败显式变成 Initiative；代价是 GitOps/UI 模式、CQL、集成配额和大规模更新需要治理。OpsLevel 更强调组件成熟度 Rubric、专项 Scorecard 和 Campaign 的组织改进路径，适合愿意维护 alias 与成熟度模型的团队；代价是要清楚哪些检查影响总体等级。深度使用 Atlassian 生态且能接受 DX 数据模型与迁移流程的组织，应直接评估 DX，不应新增长期 Compass 依赖。

三个产品都不能替代权威设计。若 HR、IdP、Git、PagerDuty 和门户都能改 Owner，自动导入越强，冲突越快。建立字段权威表：Team membership 来自 IdP，Repository 来自 SCM，lifecycle 由服务 Owner 经 Git 审批，on-call 来自值班系统，门户只聚合并记录来源。产品差异主要决定怎样实现这张表，而不是取消它。

项目接入要经过正反实验和证据门槛

试点仓库中放入对应描述文件或连接发现集成，先只读导入统一样本。每个平台都做四轮检查：首次导入、显示名修改、Owner 转移、描述文件删除或归档。稳定 ID 不应变化；显示名修改应更新原实体；Owner 转移应留下来源和审计；删除应进入明确的 archive/delete 语义，不得因 SCM 暂时不可见就消失。

Scorecard 试点使用同一条“生产服务必须有有效 runbook”规则。正向样本链接可达且证据新鲜，反向样本包括空 URL、404、属于其他服务的页面和证据源超时。预期至少能区分通过、语义失败与未知。平台若只能检查 URL 非空，就把探测结果作为外部证据写入目录，并记录最后成功时间；不要把字符串存在误写成可运维。

Initiative/Campaign 试点选择一个低风险规则，限定两个服务和一个团队，启用通知前先预览受影响对象。验收看行动项是否到达真实 Owner、完成证据是否自动关闭、Owner 变更后任务是否转移、到期状态是否可解释。离线样本只能证明配置结构、稳定身份和规则输入；SaaS 权限、企业 SSO、真实通知和生产集成必须在目标租户生成运行记录与下游审计证据。

按故障层次排查导入、Owner 和评分漂移

目录缺实体时，先看数据源连接是否成功，再看发现候选、过滤器、默认分支、文件名和解析日志。Cortex 要检查 GitOps processed/omitted；OpsLevel 要检查 .yml 文件名、alias 和 Detection 建议；DX 要检查仓库是否停在 pending；Compass 存量则检查 SCM 应用和 config-as-code 同步状态。

出现重复实体时比较稳定 ID、仓库 canonical URL、来源和创建顺序。不要凭显示名直接合并；先导出两者关系和 Scorecard 结果，选定权威 ID，把引用迁到目标后再归档副本。Owner 错误时沿 Team identifier 回查 IdP 映射、继承策略和自动推荐。个人邮箱看似准确，却会在离职后形成悬空 Owner。

Scorecard 突然全红或全绿，先检查外部集成和规则版本。大面积同步变化通常不是所有服务同时变好或变坏，而是 Token、限流、evaluation window、查询语义或未知状态处理变化。抽样读取原始证据、最后同步时间和规则计算结果；修复后手动重评少量试点，再恢复批量调度。

API 返回 401 时检查 Token 是否来自正确工作区、是否过期或撤销；403 表示已认证但缺 scope/角色；429 表示分页并发或评估频率超过边界。客户端要有退避、游标持久化和可恢复导出，不用无限重试。日志严禁输出 Authorization header、完整 Entity payload 和人员邮箱集合。

权限、容量、成本与敏感数据共同进入采购门槛

工作区管理员、目录编辑者、Scorecard 管理者、Initiative/Campaign Owner 和普通成员应分离。Cortex API Key 可绑定默认或自定义角色，创建者还要有 Edit API keys 权限；多个角色叠加时权限取最宽，不能靠再加一个只读角色降权。OpsLevel 只有 Admin 能签发 GraphQL 写 Token，其他角色签发的 Token 只读；Standards Admin 管成熟度对象，Team Member 只应改自己团队拥有或未归属的 Component。DX 则把 Catalog、Scorecard、Self-Service 和 Data Connector 管理拆到 Workspace Admin 与 Elevated Roles，PAT 的有效权限是所选 scope 与用户当前角色的交集。API Key 按自动化用途创建，目录导出只给读权限，写入集成限制到必要对象；个人 Token 不进入 CI。

SSO、SCIM、审计日志、细粒度角色、数据驻留与保留能力可能受部署形态、租户配置或合同影响，必须在目标环境逐项验证。正向实验让只读导出 Token 完成全量分页；反向实验用它创建实体和修改 Scorecard，预期得到 403 且审计记录主体正确。再撤销 IdP 用户、SCM App 和机器 Token，预期 UI 登录、API 和连接器分别失效。只验证 SSO 退出而不撤销 API Token，会留下机器身份绕过离职流程。

目录中的组织图谱高度敏感：Owner、依赖、生产等级、仓库、值班、漏洞和技术栈组合后能暴露攻击路径。字段分级和最小展示优先于“全部导入”。SCM 集成若被允许读取文件内容，需限制组织和仓库；导出文件放在受控存储并设置短保留；支持工单和截图先脱敏。Scorecard 失败细节对普通开发者可见，不代表应对全公司公开漏洞原文。

容量模型包括实体数量、关系边、外部集成数、同步频率、规则数、评估窗口、API 分页、通知和历史保留。Cortex GitOps 不适合高频批量更新；OpsLevel Terraform 全量导出会随账号规模增大；DX/Compass 迁移还要计算双系统同步和人工重建 Scorecard 的吞吐。用试点测量一次完整同步和评估耗时，确保不会持续超过调度间隔，并观察第三方 API 限流。

总成本由席位或合同费用、平台团队人力、Owner 维护时间、集成运行、API 配额、数据出口、迁移咨询、双系统并行和退出演练组成。Cortex 公开入口采用定制报价；OpsLevel 按开发者数量计价，Standard 公开限制为至多五十名用户，Enterprise、单租户和 self-hosted 另行报价；DX 按 developer license 计价，MCP 访问另有使用量档位，合同从年度期限起。采购评审不写死金额，而要记录可验证的计费单位、谁算活跃用户、机器人是否占席位、超量行为、自托管附加费、数据导出条件、支持责任和续约退出窗口。一个功能丰富但无法导出规则或稳定标识的平台，会把未来迁移费提前藏进当前采用率。

用可恢复的退出演练结束选型

退出演练应在签约和大规模导入前完成。Cortex 通过 API 分页导出全部 Entity，并保留 GitOps descriptors、Scorecards、Initiatives、teams、types 和 UI Catalog 配置清单；openapi descriptor 接口明确不会包含经 API 创建的 custom data、dependencies 等对象，因此必须再读取完整 Entity 数据，不能只收 YAML。OpsLevel 运行 Terraform 导出后在隔离 state 中验证 plan，同时用 GraphQL 补足 Provider 未表达的对象；CSV 单次导出上限为二万五千条，大账号应分片，若合同启用 S3 Data Export，还可用周期性 full 与 incremental 快照校验删除标记。DX 分别使用 Web API 与 Terraform Provider 已支持的 Catalog/Scorecard 配置建立清单；Provider 文档只承诺管理 Fabric 的 Catalog 和 Scorecards，Entity 数据、Team、Initiative、权限和连接器要按当前 API 与合同逐项证明可导出。Compass 则先做完整源快照，再执行官方迁移连接器和差异对账。

对账至少包含实体总数、按类型数量、稳定 ID 集合、无 Owner 数、关系闭合率、归档数、Scorecard 定义数、规则数和行动计划状态。Compass 到 DX 还要单列团队多归属冲突、Team Lead 推断、未迁移 Scorecard、on-call 缺口、JSM 分流和 Forge/自定义扩展替代。一次迁移同步成功只证明连接器跑完，不证明这些语义完整。

真正切换时冻结旧平台写入，完成最终导出，导入新平台并让 Owner 抽样签认；双读期间所有变更只回到一个权威源。验证目录搜索、关系、权限、Scorecard 和行动项后，撤销旧平台 API Key、SCM App、Webhook 和 SSO，停止通知与自动化，再按合同和保留政策删除数据。保留脱敏审计证据，避免保留可继续调用生产系统的 Secret。

长期每季度重跑小型退出演练，并把结果作为平台健康指标：导出是否仍可解析、Provider 是否仍能 plan、关系是否闭合、未知评分是否被正确表达、Owner 是否回应。托管目录最容易制造“供应商替团队维护数据”的错觉；实际上供应商维护运行平台，组织仍要维护身份、权威、规则、整改和退出。能持续证明这五件事，选型才从产品试用变成工程能力。