使用清单管理资产并防止重复
随着组织的发展，你需要跟踪的内容量也是如此。组织通常会重复内部工作，因为一个团队不知道另一个团队的项目。 当人们在团队之间移动时，新人加入公司，其他人离开，项目可能会成为孤立项目。 清单有助于解决这些问题，是平台工程的关键部分。
清单是用于跟踪、管理和组织组织技术资产的工具或系统。 这些资产包括代码、API、容器、虚拟机（VM）、团队权限等。
不跟踪资产会导致技术蔓延和浪费，只是因为你不容易发现已经存在的东西。 失去对已经存在的东西的跟踪是一个共同的挑战。
我们运行了一吨容器或 [VM] 实例。 是否可以删除旧 VM？ 没人知道 我们需要想出一种方法来清理旧东西并使用适当的标记，以便我们知道谁是所有者或团队，谁可以通知我们做什么，什么是生命周期。。 我们不知道是否可以关闭特定 VM，因为我们不确定会发生什么。 - Martin，DevOps 工程师，大型物流公司
跟踪资产
你需要一个清单来跟踪你在生态系统中创建或构建的所有“内容”，内部客户可以通过可理解的方式可视化。
清单可以提高安全性、提升重用性，并通常使发现更容易。 不同的工具可用于跟踪不同类型的资产。 其中每个工具都提供了一个清单，可帮助你管理、跟踪和清理浪费。
可用的跟踪工具包括：
- 使用 Azure 部署环境可以跟踪通过基础结构即代码（IaC）创建的复杂基础结构作为抽象 环境。
- Azure API 中心 为开发人员提供了发现和使用 API 的方法。
- 包注册表（如 GitHub 包 或 Azure Artifacts 或其他已批准的包和 SDK 的清单）可提高供应链安全性。
在决定库存可见性时，请考虑最适合组织的方法。 某些组织允许所有开发人员查看软件资产，但只有少数组织可以修改它们，类似于开放式厨房。 其他（特别是在受管制行业）更严格地限制访问，有时甚至会由于敏感度限制项目名称的可见性。
增强可发现性、治理和重用性
拥有一个或多个清单系统，可帮助你跟踪对平台工程实践和避免技术蔓延至关重要的内容。 最初有一组平面清单列表可能足够。 但是，可以通过跨多个库存添加不同资产之间的关系来进一步提高可发现性。 无论所需的可见性级别如何，拥有集中式聚合点，团队都可以快速搜索和发现他们可用的所有资产。 这将促进重用、减少冗余，并建立一致的治理方法。
请考虑 API 定义与实现接口的已部署应用程序代码之间的关系。 此代码存储在存储库中并由团队管理，并提供有关其使用的文档。 创建开发、测试、生产甚至临时沙盒环境。 在云本机方案中，环境可能部署到共享的 Kubernetes 群集中。 构建 API 的开发团队及其任何内部使用者都需要能够获取有关其中每个内容的信息，但资源关联的方式并不明显。
首先，可以使用与 Wiki 页面一样简单的内容来帮助跟踪每个事物彼此的关系。 但是，文档的年龄很快，而且很难找到和分析。 理想情况下，你有一个具有关系 图的系统，该关系图 可让用户界面在清单中遍历这些关系。 若要真正提高可发现性，需要能够将存储在多种类型的库存或图形中的内容关联在一起。 你可能不需要直接使用库存，但你可能希望能够将其与 API 目录系统中的信息相关联。
将清单与关系图和目录链接
若要使用数字存储类比，还可以将目录中的项目（模板）与生成的清单内容相关联。 例如，如果意识到其中一个模板创建了不安全的配置，则需要快速查找使用模板创建的所有资源来修复它们。 开始正确的应用程序模板本质上是此目录中与其他类型的目录项（如 IaC 模板）绑定的初学者工具包捆绑包。 跟踪这些关联可让你主动查找引用错误的 IaC 模板的任何应用程序，即使尚未预配任何基础结构。
目前，可以在一些工具包和产品中找到这种概念性高级开发人员平台图的简化变体，尽管它所谓的变化。 例如，开源门户工具包 Backstage.io 将此称为软件目录，而其他产品则使用不同的术语。 但是，大多数这些产品和工具包都假定你正在使用其更广泛的功能集，并要求清单的内容在它们内部重复。 这种重复意味着目录数据库的内容不特定于用户，可能变得过时，并且不受实际源系统的用户授权机制控制。 但是，如果你遵循一种开放的厨房方法，这可能适用于你的组织。