2020DevOps狀態報告——平臺模型：擴充套件DevOps的新方法

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

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

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

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

●管理變得昂貴，幾乎不存在管理

●獨立的堆疊減少了整個組織的知識共享

●許多產品團隊實際上沒有能力來執行完整的基礎設施和應用程式。許多開發人員將基礎設施操作視為分散他們實際工作的注意力，因此他們從不真正關注它。

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

廣義地說，平臺團隊提供基礎設施、環境、部署管道和其他內部服務，使內部客戶（通常是應用程式開發團隊）能夠構建、部署和執行其應用程式。

Evan Bottcher定義的數字平臺在這時可以起作用：“作為一種令人信服的內部產品的自助服務API、工具、服務、知識和支援的基礎。自主交付團隊可以利用該平臺以更快的速度交付產品功能，同時減少協作。”

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

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

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

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

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

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

內部平臺的使用

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

我們提出了兩個問題來衡量一個組織對內部平臺的使用：

• 您的開發人員使用自助服務平臺的百分比是多少？

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

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