透過清查和關聯性追蹤改善探索並消除浪費

隨著組織成長，您需要追蹤的事物數量為何。 您可能需要追蹤程序代碼、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 將此稱為軟體類別目錄，而其他產品則使用不同的條款。 不過，大部分的產品和工具組都假設您使用其更廣泛的功能集，並要求清查的內容必須在其中重複。 此重複表示目錄資料庫的內容並非使用者特定、可能過時，而且不受實際來源系統的使用者授權機制所控制。 不過，如果您遵循開放式的廚房方法，這可能會對您的組織正常運作。

深入了解可協助的概念。

開始您的平臺工程旅程