通过库存和关系跟踪改进发现并消除浪费

随着组织的发展，需要跟踪的内容量也会随之增加。 可能需要跟踪代码、API、容器、虚拟机 (VM) 、消息主题、团队成员身份、项目所有权等。 随着规模扩展，经常发现重复工作的情况并不少见，因为一个团队不知道另一个团队。 当人员在团队之间移动，新人加入公司，而其他人离开时，项目可能会成为孤儿。 如果不进行管理，这可能会导致技术蔓延和浪费，只是因为你无法轻松发现已经存在的内容。 这是一个常见的挑战。 例如，请考虑以下引号：

我们已运行大量容器或 [VM] 实例。 是否可以删除旧 VM？ 没人知道 我们需要想出一种方法来清理旧内容并使用适当的标记，以便我们知道谁是所有者或团队谁可以告诉我们我们可以做什么，生命周期是什么...。 我们不知道是否可以关闭特定的 VM，因为我们不确定会发生什么。 - Martin，大型物流公司的 DevOps 工程师

通过定制清单改进跟踪、安全性和重用

你需要的一部分是一个清单，该清单可帮助跟踪在生态系统中创建或构建的所有“内容”，内部客户可以通过易于理解的方式进行可视化。

清单可以提高安全性、促进重用，并且通常使发现更容易。 例如，Azure 部署环境将通过基础结构即代码 (IaC) 描述和跟踪通过基础结构即代码创建的复杂基础结构，并将其描述为抽象 环境 ，该环境处于开发和运营都可以理解的级别。 同样， Azure API 中心 为开发人员提供了一种发现和使用 API 的方法。 GitHub Packages 或 Azure Artifacts 等包注册表 (或其他已批准包和 SDK 清单) 提高供应链安全性。 其中每个工具都提供了一个清单，可帮助你管理、跟踪和清理浪费。

在评估如何创建或应用这些清单时，一个重要决策是确定其内容应具有多大的可见性。 请记住，这里没有正确或错误的答案。 一些公司采取开放式厨房的方法，“每个人都可以看到正在准备的食物，但只有少数人可以做饭。使用开放式厨房，开发人员可以完全了解软件资产，但只能修改他们负责的资产。 相反，受监管的公司可能有更严格的规则，即使项目名称的可见性也被视为敏感。

通过关系改进发现和跟踪

拥有一个或多个有助于跟踪你拥有的库存系统对于平台工程实践和避免技术蔓延至关重要。 最初拥有一组平面清单列表可能就足够了。 但是，虽然不需要启动，但也可以通过跨多个清单添加不同资产之间的关系来提高可发现性。 无论所需的可见性级别如何，拥有集中式聚合点使团队能够快速搜索和发现可用的所有资产。 这可以促进重用、减少冗余，并建立一致的治理方法。

请考虑 API 定义与实现 接口的已部署应用程序代码之间的关系。 此代码存储在存储库中并由团队管理，并提供有关其使用的文档。 创建开发、测试、生产甚至临时沙盒环境。 在云原生方案中，环境可能会部署到共享 Kubernetes 群集中。 生成 API 的开发团队及其任何内部使用者都需要能够获取有关其中每个内容的信息，但资源之间的关系并不明显。

首先，可以使用像 Wiki 页面这样简单的内容来帮助跟踪每个内容之间的关系。 但是文档的老化速度很快，并且可能很难找到和分析文档。 理想情况下，你会有一个具有关系图的系统，该 关系图 可让用户界面遍历清单中的这些关系。 若要真正提高可发现性，需要能够将存储在多种类型的清单或图形中的内容关联在一起。 你可能不需要直接使用库存，但你可能希望能够将其与 API 目录系统中的信息相关联。

若要使用数字商店的类比，将目录中) 的项 (模板与生成的库存内容相关联也很有用。 例如，如果你意识到其中一个模板创建了不安全的配置，则需要快速找到创建该模板的所有资源来修复它们。 此目录中的入门工具包捆绑包实际上与其他类型的目录项 (（如 IaC 模板) ）关联。 跟踪这些关联可让你主动查找引用错误 IaC 模板的任何应用程序，即使尚未预配任何基础结构。

此概念性的高级开发人员平台图的简化变体可以在当今的一些工具包和产品中找到，尽管它所称的有所不同。 例如，开源门户工具包 Backstage.io 将此称为软件目录，而其他产品使用不同的术语。 但是，其中大多数产品和工具包都假定你正在使用其更广泛的功能集，并要求在它们内部复制清单的内容。 这种重复意味着目录数据库的内容不是特定于用户的内容，可能会变得过时，并且不受实际源系统的用户授权机制控制。 但是，如果你遵循开放式厨房方法，这可能适用于你的组织。

详细了解可以提供帮助的概念。

开始平台工程之旅