随着组织的发展，你需要跟踪的内容量也是如此。组织通常会重复内部工作，因为团队不知道彼此的项目。 当人员在团队之间流动、新人员加入公司、而其他人离开时，某些项目可能会因无人管理而被搁置。 清单有助于解决这些问题，是平台工程的关键部分。
清单是用于跟踪、管理和组织组织技术资产的工具或系统。 这些资产包括代码、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 将此称为软件目录，而其他产品则使用不同的术语。 但是，大多数这些产品和工具包都假定你正在使用其更广泛的功能集，并要求清单的内容在它们内部重复。 这种重复意味着目录数据库的内容不特定于用户，可能变得过时，并且不受实际源系统的用户授权机制控制。 但是，如果你遵循开放式厨房方法，这可能适用于你的组织。