企业官网建设流程全解析

GitHub为仓库指定可靠所有者

GitHub拥有超过14,000个仓库，但其中只有不到一半有明确的所有者。在不到45天的时间内，GitHub为每个活跃仓库指定了经过验证的所有者，将其余仓库存档，并使所有权成为后续工作的基础。

原有所有权模型的困境

GitHub在主要的内部GitHub组织中拥有超14,000个仓库。截至2025年初，超11,000个非存档仓库中绝大多数无明确所有者。对于与生产服务相关的仓库，历来有可靠的持久所有权，但对于无关联服务的仓库，却无可靠方法确定所有者。在密钥扫描修复工作中，此问题反复出现，不知道仓库所有者时轮换密钥风险大、干扰多，且无明确方法分配修复工作。

多年来，GitHub通过内部服务目录跟踪已部署服务的所有权，服务条目记录元数据，可建立从服务到仓库的映射，还记录所属团队、执行发起人及支持信息。但这种关系是多对一的，从服务入手可找仓库及其所有者，从仓库出发找所有者需反向查找，且仅适用于映射到服务目录中服务的仓库，留下巨大所有权缺口，包括团队仓库、文档仓库等。每次联系“无主”仓库所有者都需手动操作，对于重复性安全工作流程带来真正风险，在密钥扫描清理工作中，寻找合适所有者花费大量时间。

设计新所有权模型

GitHub需要将仓库所有权作为首要属性，考虑过将所有权存储在每个仓库内的专用文件中或维护在一个集中的仓库中，最终选择了GitHub自定义属性，这种方法提供原生、结构化且可在整个组织范围内查询的方式管理所有权，还能根据所有权类型有选择地执行企业和组织政策及规则集。

GitHub创建了两个自定义属性：“ownership - type”和“ownership - name”。“ownership - type”接受“Service Catalog”“Hubber Handle”“Team”三个值，涵盖了GitHub仓库所有权的实际范围；“ownership - name”是经过轻度验证的文本字段，GitHub应用程序会验证每个值，在格式方面有意放宽要求，希望让添加所有权轻松无压力，并依靠强大的验证捕捉无效条目。

首日覆盖情况

在要求任何人采取行动之前，GitHub建立了一个从服务目录到仓库自定义属性的定期同步机制。每个支持已知服务的仓库都会将其“ownership - type”设置为“Service Catalog”，并自动填充“ownership - name”，处理了约1,500个由服务支持的仓库，剩下团队仓库、文档仓库、一次性项目和个人仓库。

推广过程

为推广新模型，GitHub构建了一个由Kubernetes CronJob支持的GitHub应用程序，因执行逻辑需访问服务目录、GitHub API和一些内部系统，简单的GitHub Actions工作流不够。

仓库所有权执行流程从最初的所有权扫描到创建警告问题，再到自动关闭，或在30天后进行存档。GitHub将CronJob的首次运行安排在周六早上，但问题开始出现在整个组织的仓库中，人们在Slack上询问仓库中说要被存档的新问题。经过30天宽限期后，将仍未设置所有权的仓库进行存档，存档可逆且非破坏性，若有人再次需要可取消存档、设置所有权并继续使用。初始宽限期过后，将执行周期从30天缩短到一小时，新仓库若绕过创建时所有权要求会立即被标记。

遇到的问题及解决办法

此过程总体顺利，但有两起轻微内部事件暴露出有趣的边缘情况。第一起事件因存档未设置所有权的仓库，Datadog被配置为在该仓库中创建问题，仓库被存档后无法创建问题，内部监控服务注意到并向所属团队发送警报，问题升级。这暴露出通知方式漏洞，通过在所有权问题上@提及仓库管理员，并将所有具有写入权限的用户作为后备分配解决问题。

第二起事件是数据可靠性问题，未考虑服务目录可能返回过时或损坏的数据，若错误数据导致应用程序认为一批仓库失去服务目录条目，会大规模存档拥有有效所有者的仓库。为降低存档合法仓库的风险，设置了下限，每次运行前应用程序统计即将进行的存档数量和即将创建的问题数量，若超过保守阈值，将停止操作并触发Datadog监控；若无法访问服务目录，作业将跳过服务目录验证，只检查能独立验证的内容。

数据结果

最终，GitHub有大约3,000个活跃仓库和11,000个存档仓库（最初存档约3,000个）。从第一次运行到稳定状态，整个过程不到45天。现在每个活跃仓库都有经过验证的所有者，否则就会被存档。许多新存档的仓库多年未提交代码，存档减少了管理范围，使活跃仓库清单更符合实际情况。

确保所有权持续有效

实现100%的覆盖只有在能够保持的情况下才有意义，因此GitHub在每个仓库创建工作流程中都强制执行所有权属性，包括仓库创建页面、内部工具和自动化流程，使这些属性对所有新仓库都是必需的。同时，收紧了执行周期，失去所有权的仓库会在一小时内被标记出来。

每种所有权类型都有其自身的持久性特点，服务目录条目遵循服务生命周期，服务被弃用时，其仓库通常也会被存档；团队会被验证是否至少有两名成员，团队的存在和成员资格往往相当稳定；个人Hubber用户名只有在有人离开公司时才会失效，此时个人仓库通常应被存档。对于重要到能超越个人的仓库，所有权应该是团队或服务，而不是个人。

对您的启示

您现在可以使用GitHub自定义属性实现类似的所有权模型，推荐方法如下：定义您的所有权分类，确定适合组织的所有者类型；在组织级别创建自定义属性，设置“ownership - type”属性作为单选框，包含允许的值，以及“ownership - name”属性作为文本字段；如果有服务目录或资产清单，进行同步，为已跟踪的仓库填充所有权；在仓库创建时强制执行所有权，使这些属性成为必需；为现有仓库构建宽限期工作流程，创建带有合理截止日期的问题，然后存档无人认领的仓库；不要在周六进行第一次强制执行；在大规模信任自动化之前构建防护措施，假设数据源偶尔会出错，通知有时会丢失，从一开始就为此进行设计。