OpsLevel：Component、Rubric 与 Campaign 治理

OpsLevel 用 Component 和 Alias 连接仓库、团队与外部集成，用组织 Rubric 表达持续成熟度，再用专项 Scorecard 和 Campaign 推动阶段性变化。三层对象不能互相替代：发现候选不等于权威服务，专项评分不自动改变总体成熟度，Campaign 结束也不保证长期标准已经沉淀。

OpsLevel Component、Rubric 与 Campaign 责任链高清原图

从小样本确认 Alias 与 Owner 解析

试点使用 payment-api 和 ledger-api，预先创建 payments Team Alias、生命周期和 Tier。首次导入验证 Repository 只关联一个 Component；修改显示名后 Alias 和稳定关系不变；将 Owner 写成不存在的显示标题时，导入必须报错或保持待处理，不能悄悄创建同名团队。

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

托管与 Self Hosted 的责任不能只看部署位置

托管工作区由供应商运行控制面；Self Hosted 通过 Kubernetes 分发后，团队还要负责集群、网络和外部状态组件，并根据合同明确升级与支持责任。恢复演练不能只保存 Helm Values：目录主数据、历史报告、待处理任务和对象存储分别对应不同状态，任何依赖丢失都要验证可恢复范围。

GitHub App、PAT、Webhook 和内部连接器按用途拆 Token。目录发现使用只读仓库与组织元数据，写 Checks 或 Pull Request 的能力只有在明确启用对应动作时才开放。反向实验撤销试点凭据后，Detection 与 Check 应呈现权限失败，不得把最近一次成功结果无限沿用。

Component、Alias 与 opslevel.yml 构成目录身份

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 和集成日志中确认来源，不只刷新页面。

Rubric 与独立 Scorecard 不承担同一语义

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

Campaign 把一次组织变化交给真实 Owner

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

GraphQL、Terraform 快照与退出

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

用正反实验验证成熟度与行动闭环

先创建不影响总体等级的专项 Scorecard，检查 Owner、Runbook 和近期部署证据。完整样本通过，缺 Owner 或证据源超时的样本分别显示失败与未知。随后创建只覆盖两个 Component 的 Campaign，预览通知对象再启动；Owner 变化后任务应转移，完成证据应重新评估，结束时只把长期有效检查复制到 Rubric。

opslevel --version
opslevel list services --format json | ConvertFrom-Json |
  Select-Object -First 5 alias,owner
opslevel export terraform --output ./opslevel-export

排障、权限和容量按控制面分层

缺实体先检查 Detection、.yml 文件名、默认分支、Alias 和集成日志；重复 Component 比较 Alias、Repository 与来源，不按显示名直接合并。全红或全绿先看集成 Token、Check 版本、外部限流和未知状态处理。GraphQL 的 401、403、429 分别对应认证、授权和容量问题，客户端需要游标、退避与可恢复导出。

Admin、Standards Admin、Team Member、Campaign Owner 与只读身份分开。目录导出 Token 不得修改 Component 或 Rubric；个人 Token 不进入流水线。容量模型覆盖 Component、Alias、关系、Check、同步频率、Campaign 通知、Terraform 导出与报告保留。退出时固定 Provider，导出到隔离仓库并执行只读 Plan，再用 GraphQL 或合同数据导出补齐 Provider 没有表达的对象，最后撤销应用、Token、Webhook、SSO 和存量备份访问。