我們生活在被軟件吞噬的世界，而在軟件構建領域，幾乎每年就會出現一波浪潮。今年，平臺工程仿佛成為了一個“新貴”，Gartner 10月發布的2023年十大戰略技術趨勢中，平臺工程就位列其中，它的目的在于為負責構建產品和服務的開發團隊提供所依賴的通用共享服務，從而讓開發更聚焦于開發，運維聚焦于運維。

平臺工程不是第一次嘗試解決構建和運行軟件方面的普遍難題，也幾乎肯定不會是最后一次。之前就有敏捷、DevOps、站點可靠性工程（SRE）和數字化轉型，目標宏偉，但結果好壞不一。軟件解決方案帶來了新問題，許多問題由急切的供應商通過提供帶來新問題的解決方案來解決。平臺工程試圖駕馭創新、采用、碎片化和停滯這個無休止的循環，從而滿足不斷進步的需求。

1.為什么開發不能DIY？

支持開發項目需要工具，同時保持工程師的高效工作。期望應用程序開發團隊運行所有東西不切實際。因此，很多企業團隊選擇組裝一套第三方服務和開源系統，并添加了其他非開發人員以保持系統運行。無論構建什么樣的應用程序，都在一個平臺上編寫它們。

需要一個起點來構建軟件。你可以采用數據庫、消息隊列、容器編排、操作系統和各種開發者工具等框架和工具來搭建應用程序運行的“堆棧”或環境。但特例和偏好會破壞統一性，導致碎片化。因此需要在易維護性和靈活性之間保持微妙的平衡，從而在保持簡單易懂的整體環境的同時又能讓每個團隊發揮所長。

2.DevOps

劃分構建和維護軟件系統方面任務的簡單二分法是分為開發（Dev）和運營（Ops）。開發為客戶構建新的特性和功能，運營確保它們在發布后正確運行。

DevOps試圖奉行“誰構建，誰運維”的理念，從而消除這種分裂。這種理念認為，通過將運營所有權交給帶來軟件錯誤的人（開發者），自然激勵會迫使組織正視技術債務，一開始就構建更好的軟件。

實踐上的挑戰在于，DevOps已成為介于Dev和Ops之間的第三個孤島，處理雙方都不想做或不能做的事情。盡管有觀點認為“DevOps工程師”一開始就不該存在，但這個角色還是迅速流行起來。它指代這類人：處理搭建持續集成/持續交付（CI/CD）系統、將基礎架構配置為代碼、為新應用程序配置云環境以及竭力跟上Dev和Ops任何一方面不斷出現的變化。

3.站點可靠性工程

SRE概念理論上聽起來不錯，在適當規模和類型的組織中非常有效。達到足夠的規模和復雜性后，確保可靠性本身就成了一項挑戰。這個角色常常處理重復的操作任務，并通過采用或構建新的交付和生產力工具和流程來不斷識別和消除“臟活”，從而使公司的整體系統逐漸更具競爭力。

實際上，許多組織在實現SRE的承諾時遇到了挫折。有時只是重新命名運營團隊，而不改變技能組合或實施可以減少臟活的項目；或者給SRE團隊進行改變的余地太小。費用上升（因為更高技能和分配預防性容量的成本高達四倍），而且投資回報多半值得懷疑。

4.數字化轉型

對于試圖在日益網絡化的環境下站穩腳跟的老企業來說，數字化轉型概念可能是個宏偉的目標，聽起來就像將舊的家庭視頻轉換成MPEG文件，或掃描紙質合同、改用DocuSign。管理顧問樂于領導這些昂貴、緩慢又痛苦的項目，將組織帶入云計算時代。代價高昂的數據泄露增添了暫時的動力，與全球系統集成商簽署的多年協議也是如此。不過，數字化轉型的最大外在驅動力是疫情，這最終迫使每個人都想方設法使用二維碼來點菜。

5.平臺來了

“平臺”這個詞幾乎意味著任何東西。首先，平臺意味著可以在其上面構建產品。平臺隨時可供使用。除非組織可以將平臺用于多種用途，否則它只是產品的一部分。平臺為應用程序、工作負載、租戶、運營商、開發者和客戶（間接）提供服務。

大多數軟件架構現在以“服務”為導向，這也意味著平臺必須為服務而存在。可以說平臺為在它上面構建產品的其他團隊提供服務。

每當我們試圖確定“平臺”的確切定義時，會開始聽起來像是營銷噱頭。我們可能談論“計算平臺”、“數字基礎設施平臺”，甚至是“云平臺”。我們談論的平臺涵蓋一些既模糊又具體的東西：人員、流程、工具、文檔、知識、升級路徑、供應商合同、SLA、期望、計劃和成本結構，這些使組織持續關注平臺。

我建議進行以下測試以確定我們是否到底在談論平臺：

• 平臺提供有價值的服務
• 平臺符合可重用接口
• 平臺需要工作負載才有價值
• 平臺間接支持最終用戶
• 平臺提高生產力
• 平臺得到資助和維護
• 平臺為可靠性、安全性和性能設定了標準
• 平臺使得做一些事情變得容易，做其他事情更困難（有意或無意）
• 平臺必須謹慎改變，以避免連鎖反應
• 平臺可能包括手動任務、工單、運行手冊和知識

平臺通常包括的幾類組件如下：

• 基礎計算、網絡和存儲
• 處理定制或隨機請求的工單系統
• 身份、身份驗證和授權服務
• 準備就緒核對清單
• 安全掃描
• 監控、可觀測性和報告
• SLA
• 各種數據庫
• 消息隊列
• 災難恢復和故障切換
• 郵件服務器（這有多方便？）
• Kubernetes

如果你的公司沒有一個平臺團隊，那么你們就還沒有平臺意識。也許你期望供應商為你做一切工作，或者數字化轉型顧問集成這些系統，以便無縫地運行，以降低風險、獲得很高的投資回報。

值得注意的是，平臺工程師已挺身而出。他們試圖將文檔編寫糟糕的工具、服務、開源項目、巧妙的改動、待辦列表和技術債務變成類似產品的東西。目標不是虛幻的（“生產力”或“可靠性”），而是務實的（“不妨構建人們想要使用的產品”）。

6.平臺即產品

貴公司內部的平臺好比推向市場的產品。你想構建貴組織想要使用的東西，因此用戶會游說管理層，以確保資源持續不斷。所以你需要關注負責重大任務的大型團隊，你可以幫助他們加快行動、減少失敗并高效運行。你必須了解內部客戶的優先事項、痛點、建立規模經濟的機會以及可持續的商業模式。你需要使平臺易于采用，同時還考慮當前情況的實際限制。

平臺采用產品理念可帶來與采用 DevOps、SRE、數字化轉型或敏捷全然不同的結果。現在有了人們想要使用的東西：平臺，它可以減輕他們的負擔，并讓他們專心致志。他們不必擔心云提供的所有細節，他們有一個基于平臺的限制和決定的受限菜單。當然，沒有人會純粹為了平臺而使用平臺；團隊必須贏得客戶的信任和認可，否則他們只能將工作量帶回家。

7.所有權理念

所有權可能根植于人類心理學，也可能是層次化管理結構的產物。在現實世界中，當你嘗試運作重大項目時，就要知道誰在做什么，并相信他們會繼續做下去。否則，整個組織會分崩離析。一旦沒人知道組織結構圖，紛爭、指責、冷漠和跳槽很快接踵而來。

谷歌的SRE并不負責可靠性，他們大多將自己視為內部可靠性顧問。谷歌SRE試圖幫助產品團隊在設計系統時做出正確的選擇。他們幫助設定服務水平目標（SLO），以確保可靠性目標已明確定義。也許最重要的是，他們推動團隊一貫采用來自整個谷歌技術基礎架構（可以稱之為平臺）的標準服務。SRE是平臺即產品的客戶成功團隊。

8、下一步是什么？

平臺工程潮流越來越盛。LinkedIn和Twitter上將“平臺”添加到頭銜中的人越來越多。CEO們將平臺工程師視為主要客戶。

當我試圖更好地了解當下的形勢時，我問了所有的SRE朋友他們對平臺工程有何看法。每個人都會懷疑這是新瓶裝舊酒，只是營銷噱頭。

不止一個SRE告訴我“實際上，我們是平臺團隊，而不是SRE團隊。”我認識的以前在性能工程、安全和數據管理方面工作的朋友和同事都已經向平臺工程轉型。

我最喜歡平臺工程的是所有權，最不喜歡的是平臺工程在定義方面的模糊性，諸如在“平臺是什么、不是什么”方面缺乏明確性。我對DevOps窮途末路和SRE一敗涂地的說法持保留態度。DevOps工程師的工作仍然需要完成，即使換了新名字。想象一下平臺團隊在你的公司聚在一起，接管其他產品、應用程序和IT團隊面臨的常見問題，結果會如何。

平臺不是一艘更快的船，而是上漲的潮水。

原文鏈接：

??https://dzone.com/articles/the-rising-tide-of-platform-engineering???