Cortex 构建自动推荐服务负责人的系统

凌晨两点，一次事故爆发，值班工程师被呼叫。经过一番排查，他们定位到了一个服务，但不确定如何修复。于是他们去找服务负责人升级处理，结果……没人知道该呼叫谁。构建该服务的团队去年经历了重组，README 里列出的人已经离职，运行手册里的 Slack 频道也已归档。现在已经是凌晨 2：45，事故仍在持续。到了这个地步，他们只能即兴发挥了（懂这个梗吧？）。

这是戏剧化的版本，但你大概能想到很多规模较小但类似的情况。一个安全漏洞躺在待办列表里，因为没人觉得那是自己的事。一次迁移卡在 80%，因为最后 20% 的服务找不到人去跟进。一个依赖被弃用了，直到它出问题才有人知道。所有权缺口导致问责不力，而问责不力又给工程组织带来更差的结果。在这篇文章里，我们将介绍我们在 Cortex 如何构建一个系统，来自动为服务推荐负责人。这样，当下一次告警响起时，就不用慌忙搞清楚该打给谁了。

对于 Cortex 的用户来说，所有权是一切的基础。记分卡、倡议、通知和值班路由都依赖于每个服务有人负责。良好的所有权数据意味着平台的其余部分可以正常运转。糟糕的所有权数据意味着构建在其上的每个功能都会继承这个问题。

既然所有权如此重要，为什么不是每个人都把它搞清楚了？它变得混乱的原因有很多，而大多数都归结为一个事实：组织的变化速度远快于描述它们的元数据。

重组和团队更名。一个团队拆分、两个团队合并，或者一个团队只是换了个名字。服务本身不会自己移动，所以所有权数据会慢慢偏离现实。

人员离职。某个服务的核心联系人离开了公司，但他们的名字还在上面挂了好几个月。

单体仓库。许多双手触碰同一个仓库的许多不同部分，所以“谁拥有这个仓库”已经不是正确的问题了。

真相来源太多。所有权可以存在于目录、CODEOWNERS 文件、PagerDuty 排班表、电子表格，或者某人的脑子里。当它们互相矛盾时，该信哪个？

好消息是，最难的部分是起步。一旦所有权从 0 到 1，维护起来就不那么令人望而生畏了。一个团队拆成两个子团队？重新分配服务即可。创建了新服务？第一天就给它指定负责人。保持所有权准确主要靠小的增量变更。真正让人觉得不可能的是，第一次要处理数百甚至数千个无主服务。不过，随着情况变化，所有权仍然需要定期维护和关注。随着时间的推移，数据腐化同样可能让所有权陷入糟糕的状态。

所有权本身也比乍看起来更复杂。一个服务可以由一个团队拥有，也可以由一个人拥有，或者两者兼有。团队可以有父团队，实体（Cortex 目录中的任何东西，比如服务或域）可以有父实体，所以所有权可以是传递的。例如，我拥有一个服务，因为我是某个团队的成员，我的团队拥有一个域，而该域包含这个服务。大致是这样的：

父级 的 成员 拥有 包含 包含 拥有 Platform Eng父团队 Search team团队 Jordan工程师 Search域 search-api服务 indexer服务 团队 人员 实体 所有权流经团队、人员和父实体

那么谁拥有 search-api？Jordan 拥有，通过 Search 团队和 Search 域。Platform Eng 也拥有它吗？取决于你怎么问，也许是。而 indexer 有两条路径通向 Jordan，一条直接，一条通过团队。每一个这样的问题都会变成一次图遍历，我们花了大量时间投资于核心数据模型，让这些遍历变得很快。

更广泛地说，可以把这看作我们系统中任意关系的上下文图。像团队或实体这样的节点由边连接，边就是它们之间的关系。再进一步，实体可以有一个 Slack 频道。那是另一种关系。当你枚举所有可能的类型和关系时，你可以想象事情会变成一团乱麻。

回到所有权，为了让这个图成功运作，我们关心的是创建了哪些边。看看从 Jordan 到 indexer 的那条直接连线。它是图中最脆弱的边。如果我们没有团队负责人的边，而 Jordan 离开了公司，indexer 就没人管了，这正是本文开头的问题。从 Search 团队到 Search 域的边则要稳固得多。人员可以来来去去，只要团队还在，它下面的一切仍然有负责人，团队的每个成员仍然继承它。

这就是为什么当我们推荐负责人时，我们推荐的是团队而不是个人。棘手的地方在于，大多数关于谁在某个服务上工作的线索都指向个人，而不是团队。上下文图正是连接两者的东西。如果 Jordan 经常在某个服务上工作，而 Jordan 是 Search 团队的成员，那么 Search 团队就是一个很好的负责人猜测。所以我们真正解决的问题是，填补这个图中缺失的边，并且在团队层面填补，这样它们就不会过时。

成员 提交 拥有 代码 在 聊天 在 跟踪 告警 依赖 拥有？ Priya工程师 payments仓库 #paymentsSlack 频道 Payments团队 pay-gateway服务，无负责人 PAYJira 项目 pay-ledger服务 pay-oncallPagerDuty 服务 团队 人员 服务 集成 某个租户上下文图的一个切片。虚线边是我们预测的那条。 预测框架

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）