隨著組織的發展，您需要追蹤的內容數量也會增加。組織經常重複內部工作，因為團隊不了解彼此的專案。 隨著人們在團隊之間調動、新人加入公司以及其他人離開，專案可能會成為無人負責的狀態。 庫存有助於解決這些問題，是平台工程的關鍵部分。
庫存是用於追蹤、管理和組織組織技術資產的工具或系統。 這些資產包括程式碼、API、容器、虛擬機器 （VM）、團隊權限等。
不追蹤資產會導致技術擴張和浪費，因為您無法輕易發現已經存在的內容。 忘記已經存在的東西是一個常見的挑戰。
我們有大量容器或 [VM] 執行個體在運行。 我們可以刪除舊的虛擬機嗎？ 沒有人知道。 我們需要想出一種方法來清理舊東西並使用適當的標籤，這樣我們就知道誰是所有者或團隊，他們可以告訴我們我們可以做什麼以及生命週期是什麼...... 我們不知道是否可以關閉特定的 VM，因為我們不確定會發生什麼。 - Martin，大型物流公司 DevOps 工程師
追蹤資產
您需要一個清單來追蹤您在生態系統中建立或建置的所有內容，並且內部客戶可以以易於理解的方式視覺化。
庫存可以提高安全性、促進重複使用，並且通常使發現更容易。 不同的工具可用於追蹤不同類型的資產。 這些工具中的每一個都提供了一個清單來幫助您管理、跟踪和清理廢物。
可用的追蹤工具包括：
- Azure 部署環境可讓您追蹤透過基礎結構即程式碼 （IaC） 建立的複雜基礎結構，做為抽象 環境。
- Azure API Center 提供開發人員探索和取用 API 的方法。
- GitHub Packages 或 Azure Artifacts 等套件登錄 （或已核准套件和 SDK 的其他清查） 可改善供應鏈安全性。
若要瞭解您的庫存，請考慮適合您組織的最佳方法。 有些組織允許所有開發人員查看軟體資產，但只有少數開發人員可以修改它們（類似於開放式廚房）。 其他人，特別是在受監管的行業中，更嚴格地限制訪問，有時甚至由於敏感性而限制了項目名稱的可見性。
增強可探索性、治理和重複使用
擁有一個或多個庫存系統來幫助您追蹤您擁有的東西對於平台工程實踐和避免技術蔓延至關重要。 最初，擁有一組平面庫存清單可能就足夠了。 不過，您可以透過在多個庫存中新增不同資產之間的關係來進一步提高發現性。 無論您需要何種可見度，擁有集中式彙總點都可讓團隊快速搜尋並探索所有可用的資產。 這促進了重複使用，減少了冗餘，並建立了一致的治理方法。
請考量 API 定義與實作介面的已部署應用程式程式碼之間的關係。 此程式碼儲存在儲存庫中並由團隊管理，並提供有關其使用的文檔。 建立開發、測試、生產環境，甚至臨時沙箱環境。 在雲端原生案例中，環境可能會部署至共用 Kubernetes 叢集。 建置 API 的開發團隊及其任何內部取用者都需要能夠取得有關這些事物的資訊，但資源之間的關聯並不明顯。
首先，您可以使用像 wiki 頁面這樣簡單的東西來幫助跟踪每個事物之間的關係。 但文件很快就會老化，並且很難找到和解析。 理想情況下，您應該有一個具有關係 圖表 的系統，該系統可以支援使用者介面遍歷庫存中的這些關係。 若要真正提高可探索性，您必須能夠將儲存在多種類型的清單或圖表中的專案關聯在一起。 您可能不需要直接取用庫存，但您可能希望能夠將其與 API 目錄系統中的資訊建立關聯。
將庫存與關聯式圖形和目錄連結
若要使用數位商店的類比，將目錄中的項目（範本）與產生的庫存內容相關聯也很有用。 例如，如果您意識到其中一個範本建立了不安全的組態，則需要快速尋找使用範本建立的所有資源來修正它們。 啟動正確的應用程式範本是此目錄中的入門套件組合，與其他類型的目錄項目（例如 IaC 範本）相關聯。 追蹤這些關聯可讓您主動尋找任何參考錯誤 IaC 範本的應用程式，即使尚未佈建基礎結構也一樣。
這種概念性的高級開發人員平台圖的簡化變體可以在當今的一些工具包和產品中找到，儘管它的名稱各不相同。 例如，開放原始碼入口網站工具組 Backstage.io 稱之為軟體目錄，而其他產品則使用不同的術語。 但是，這些產品和工具包中的大多數都假設您正在使用其更廣泛的功能集，並要求在其中複製您的庫存內容。 此重複表示目錄資料庫的內容不是使用者特定的，可能會變得過時，而且不受實際來源系統的使用者授權機制所控制。 但是，如果您遵循開放式廚房方法，這可能對您的組織有效。