隨著組織的發展，您需要追蹤的內容數量也會增加。組織經常重複內部工作，因為團隊不了解彼此的專案。 隨著人們在團隊之間調動、新人加入公司以及其他人離開，專案可能會成為無人負責的狀態。 庫存管理有助於解決這些問題，也是平台工程的關鍵部分。
庫存是一種用來追蹤、管理和組織組織技術資產的工具或系統。 這些資產包括程式碼、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 稱之為軟體目錄，而其他產品則使用不同的術語。 但是，這些產品和工具包中的大多數都假設您正在使用其更廣泛的功能集，並要求在其中複製您的庫存內容。 此重複表示目錄資料庫的內容不是使用者特定的，可能會變得過時，而且不受實際來源系統的使用者授權機制所控制。 不過，如果你採用透明優先的做法，讓所有開發者都能查看資產，這對你的組織來說可能相當可行。