使用清查來管理資產並防止重複
隨著組織成長，您需要追蹤的內容量也是如此。組織通常會重複內部工作，因為一個小組不知道另一個小組的專案。 隨著人員在團隊之間移動，新人加入公司，其他人離開，專案可能會成為孤兒。 清查有助於解決這些問題，而且是平臺工程的重要部分。
清查是用來追蹤、管理及組織組織組織組織技術資產的工具或系統。 這些資產包括程式代碼、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 將此稱為軟體類別目錄，而其他產品則使用不同的詞彙。 不過，大部分的產品和工具組都假設您使用其更廣泛的功能集，而且需要清查的內容在它們內重複。 這種重複表示目錄資料庫的內容並非用戶專屬、可能過時，而且不受實際來源系統的使用者授權機制所控制。 不過，如果您遵循開放式廚房方法，這可能適用於您的組織。