2020DevOps狀態報告——平台模型：擴展DevOps的新方法

• 2021 年 1 月 8 日
• 筆記

平台模型是我們在這個領域看到越來越多的方法，它源於負責產品或服務的端到端交付的產品團隊的理念。

如果只應用於單一的產品，或者幾個產品，它的效果很好。 但如果有數百種產品或服務，把一個產品團隊用於這些產品，對每一個來說都是低效和昂貴的。

想像10個團隊，每個團隊都有自己的技術棧、工具鏈和流程。 會一直重複解決類似的問題、花太多的時間來評估技術、集成、維護基礎設施等等。 這些時間可以更好地花在建立和改進產品團隊負責的實際產品上。

缺乏標準化的技術和流程也造成其他問題：

●管理變得昂貴，幾乎不存在管理
●獨立的堆棧減少了整個組織的知識共享
●許多產品團隊實際上沒有能力來運行完整的基礎設施和應用程式。許多開發人員將基礎設施操作視為分散他們實際工作的注意力，因此他們從不真正關注它。

雖然擁有多個端到端產品團隊並不能很好地跨越大型複雜環境，但由清晰目標、邊界和責任定義的平台模型卻能做到 一個由用戶建立在心中的平台，可以大大減少單個產品團隊的辛苦和開銷。

廣義地說，平台團隊提供基礎設施、環境、部署管道和其他內部服務，使內部客戶（通常是應用程式開發團隊）能夠構建、部署和運行其應用程式。
Evan Bottcher定義的數字平台在這時可以起作用：「作為一種令人信服的內部產品的自助服務API、工具、服務、知識和支援的基礎。自主交付團隊可以利用該平台以更快的速度交付產品功能，同時減少協作。」

自助服務是「一個好平台的一個關鍵特徵。具體來說，它應該允許自助服務供應、自助服務配置、自助服務管理和平台功能和資產的運營。」

平台模型通常與本地雲環境相關聯，也適用於從古到今的許多其他類型的體系結構。主要優勢有：

●應用團隊可有更具效率。他們不必是基礎設施運維方面的專家，也不必對工具鏈中的每種工具都有深入的了解，因而他們能夠專註於產品。應用程式開發人員不再需要等待集中化的團隊來為他們提供測試環境或雲資源，而由此產生的自治性使他們能夠更快地工作。

●改善管理。如果您的所有應用程式都運行在完全不同的基礎架構堆棧上，使用不同的流程，那麼您就無法有效地管理成本、遵從性和審計。一個有效的平台能帶來高效的IT治理，同時授權應用程式團隊快速交付。

●結束環境切換。不斷地在應用程式和基礎設施操作之間切換注意力是對生產力和創造力的巨大消耗。當個體工人和團隊能夠專註於自己特定的環境時，他們的境況會更好。

●持續改善基礎設施。一個提供面向客戶解決方案的公共平台，而不僅僅是對基礎設施的原始訪問，使組織具有更大的靈活性。平台的消費者不與基礎設施堆棧的具體實現掛鉤，因此平台團隊可以迭代地替換和升級組件，並且只需要與應用程式團隊進行最小程度的交互。

內部平台的使用

在對平台的討論中，我們使用「內部平台」一詞來表示由組織和為組織構建的平台。我們將這些平台與外部供應商提供的平台區分開來——例如，許多人認為AWS或其他IaaS產品是
「平台」。在調查中，我們將平台團隊定義為那些負責維護其他團隊用於構建和交付應用程式或服務的自助服務平台的團隊。

我們提出了兩個問題來衡量一個組織對內部平台的使用：
• 您的開發人員使用自助服務平台的百分比是多少？

• 哪些服務可供自助服務？

我們發現平台的使用在調查受訪者中非常廣泛。百分之六十三的人說他們至少有一個自助內部平台。 在擁有內部平台的人中，60%的人在擁有二到四個平台之間。在擁有內部平台的公司中，幾乎有三分之一的公司有26%至50%的開發者使用該平台。