我們生活在被軟件吞噬的世界，而在軟件構(gòu)建領(lǐng)域，幾乎每年就會(huì)出現(xiàn)一波浪潮。今年，平臺(tái)工程仿佛成為了一個(gè)“新貴”，Gartner 10月發(fā)布的2023年十大戰(zhàn)略技術(shù)趨勢(shì)中，平臺(tái)工程就位列其中，它的目的在于為負(fù)責(zé)構(gòu)建產(chǎn)品和服務(wù)的開發(fā)團(tuán)隊(duì)提供所依賴的通用共享服務(wù)，從而讓開發(fā)更聚焦于開發(fā)，運(yùn)維聚焦于運(yùn)維。

平臺(tái)工程不是第一次嘗試解決構(gòu)建和運(yùn)行軟件方面的普遍難題，也幾乎肯定不會(huì)是最后一次。之前就有敏捷、DevOps、站點(diǎn)可靠性工程（SRE）和數(shù)字化轉(zhuǎn)型，目標(biāo)宏偉，但結(jié)果好壞不一。軟件解決方案帶來了新問題，許多問題由急切的供應(yīng)商通過提供帶來新問題的解決方案來解決。平臺(tái)工程試圖駕馭創(chuàng)新、采用、碎片化和停滯這個(gè)無休止的循環(huán)，從而滿足不斷進(jìn)步的需求。

1.為什么開發(fā)不能DIY？

支持開發(fā)項(xiàng)目需要工具，同時(shí)保持工程師的高效工作。期望應(yīng)用程序開發(fā)團(tuán)隊(duì)運(yùn)行所有東西不切實(shí)際。因此，很多企業(yè)團(tuán)隊(duì)選擇組裝一套第三方服務(wù)和開源系統(tǒng)，并添加了其他非開發(fā)人員以保持系統(tǒng)運(yùn)行。無論構(gòu)建什么樣的應(yīng)用程序，都在一個(gè)平臺(tái)上編寫它們。

需要一個(gè)起點(diǎn)來構(gòu)建軟件。你可以采用數(shù)據(jù)庫、消息隊(duì)列、容器編排、操作系統(tǒng)和各種開發(fā)者工具等框架和工具來搭建應(yīng)用程序運(yùn)行的“堆?！被颦h(huán)境。但特例和偏好會(huì)破壞統(tǒng)一性，導(dǎo)致碎片化。因此需要在易維護(hù)性和靈活性之間保持微妙的平衡，從而在保持簡單易懂的整體環(huán)境的同時(shí)又能讓每個(gè)團(tuán)隊(duì)發(fā)揮所長。

2.DevOps

劃分構(gòu)建和維護(hù)軟件系統(tǒng)方面任務(wù)的簡單二分法是分為開發(fā)（Dev）和運(yùn)營（Ops）。開發(fā)為客戶構(gòu)建新的特性和功能，運(yùn)營確保它們?cè)诎l(fā)布后正確運(yùn)行。

DevOps試圖奉行“誰構(gòu)建，誰運(yùn)維”的理念，從而消除這種分裂。這種理念認(rèn)為，通過將運(yùn)營所有權(quán)交給帶來軟件錯(cuò)誤的人（開發(fā)者），自然激勵(lì)會(huì)迫使組織正視技術(shù)債務(wù)，一開始就構(gòu)建更好的軟件。

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

3.站點(diǎn)可靠性工程

SRE概念理論上聽起來不錯(cuò)，在適當(dāng)規(guī)模和類型的組織中非常有效。達(dá)到足夠的規(guī)模和復(fù)雜性后，確?？煽啃员旧砭统闪艘豁?xiàng)挑戰(zhàn)。這個(gè)角色常常處理重復(fù)的操作任務(wù)，并通過采用或構(gòu)建新的交付和生產(chǎn)力工具和流程來不斷識(shí)別和消除“臟活”，從而使公司的整體系統(tǒng)逐漸更具競(jìng)爭力。

實(shí)際上，許多組織在實(shí)現(xiàn)SRE的承諾時(shí)遇到了挫折。有時(shí)只是重新命名運(yùn)營團(tuán)隊(duì)，而不改變技能組合或?qū)嵤┛梢詼p少臟活的項(xiàng)目；或者給SRE團(tuán)隊(duì)進(jìn)行改變的余地太小。費(fèi)用上升（因?yàn)楦呒寄芎头峙漕A(yù)防性容量的成本高達(dá)四倍），而且投資回報(bào)多半值得懷疑。

4.數(shù)字化轉(zhuǎn)型

對(duì)于試圖在日益網(wǎng)絡(luò)化的環(huán)境下站穩(wěn)腳跟的老企業(yè)來說，數(shù)字化轉(zhuǎn)型概念可能是個(gè)宏偉的目標(biāo)，聽起來就像將舊的家庭視頻轉(zhuǎn)換成MPEG文件，或掃描紙質(zhì)合同、改用DocuSign。管理顧問樂于領(lǐng)導(dǎo)這些昂貴、緩慢又痛苦的項(xiàng)目，將組織帶入云計(jì)算時(shí)代。代價(jià)高昂的數(shù)據(jù)泄露增添了暫時(shí)的動(dòng)力，與全球系統(tǒng)集成商簽署的多年協(xié)議也是如此。不過，數(shù)字化轉(zhuǎn)型的最大外在驅(qū)動(dòng)力是疫情，這最終迫使每個(gè)人都想方設(shè)法使用二維碼來點(diǎn)菜。

5.平臺(tái)來了

“平臺(tái)”這個(gè)詞幾乎意味著任何東西。首先，平臺(tái)意味著可以在其上面構(gòu)建產(chǎn)品。平臺(tái)隨時(shí)可供使用。除非組織可以將平臺(tái)用于多種用途，否則它只是產(chǎn)品的一部分。平臺(tái)為應(yīng)用程序、工作負(fù)載、租戶、運(yùn)營商、開發(fā)者和客戶（間接）提供服務(wù)。

大多數(shù)軟件架構(gòu)現(xiàn)在以“服務(wù)”為導(dǎo)向，這也意味著平臺(tái)必須為服務(wù)而存在。可以說平臺(tái)為在它上面構(gòu)建產(chǎn)品的其他團(tuán)隊(duì)提供服務(wù)。

每當(dāng)我們?cè)噲D確定“平臺(tái)”的確切定義時(shí)，會(huì)開始聽起來像是營銷噱頭。我們可能談?wù)摗坝?jì)算平臺(tái)”、“數(shù)字基礎(chǔ)設(shè)施平臺(tái)”，甚至是“云平臺(tái)”。我們談?wù)摰钠脚_(tái)涵蓋一些既模糊又具體的東西：人員、流程、工具、文檔、知識(shí)、升級(jí)路徑、供應(yīng)商合同、SLA、期望、計(jì)劃和成本結(jié)構(gòu)，這些使組織持續(xù)關(guān)注平臺(tái)。

我建議進(jìn)行以下測(cè)試以確定我們是否到底在談?wù)撈脚_(tái)：

• 平臺(tái)提供有價(jià)值的服務(wù)
• 平臺(tái)符合可重用接口
• 平臺(tái)需要工作負(fù)載才有價(jià)值
• 平臺(tái)間接支持最終用戶
• 平臺(tái)提高生產(chǎn)力
• 平臺(tái)得到資助和維護(hù)
• 平臺(tái)為可靠性、安全性和性能設(shè)定了標(biāo)準(zhǔn)
• 平臺(tái)使得做一些事情變得容易，做其他事情更困難（有意或無意）
• 平臺(tái)必須謹(jǐn)慎改變，以避免連鎖反應(yīng)
• 平臺(tái)可能包括手動(dòng)任務(wù)、工單、運(yùn)行手冊(cè)和知識(shí)

平臺(tái)通常包括的幾類組件如下：

• 基礎(chǔ)計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)
• 處理定制或隨機(jī)請(qǐng)求的工單系統(tǒng)
• 身份、身份驗(yàn)證和授權(quán)服務(wù)
• 準(zhǔn)備就緒核對(duì)清單
• 安全掃描
• 監(jiān)控、可觀測(cè)性和報(bào)告
• SLA
• 各種數(shù)據(jù)庫
• 消息隊(duì)列
• 災(zāi)難恢復(fù)和故障切換
• 郵件服務(wù)器（這有多方便？）
• Kubernetes

如果你的公司沒有一個(gè)平臺(tái)團(tuán)隊(duì)，那么你們就還沒有平臺(tái)意識(shí)。也許你期望供應(yīng)商為你做一切工作，或者數(shù)字化轉(zhuǎn)型顧問集成這些系統(tǒng)，以便無縫地運(yùn)行，以降低風(fēng)險(xiǎn)、獲得很高的投資回報(bào)。

值得注意的是，平臺(tái)工程師已挺身而出。他們?cè)噲D將文檔編寫糟糕的工具、服務(wù)、開源項(xiàng)目、巧妙的改動(dòng)、待辦列表和技術(shù)債務(wù)變成類似產(chǎn)品的東西。目標(biāo)不是虛幻的（“生產(chǎn)力”或“可靠性”），而是務(wù)實(shí)的（“不妨構(gòu)建人們想要使用的產(chǎn)品”）。

6.平臺(tái)即產(chǎn)品

貴公司內(nèi)部的平臺(tái)好比推向市場(chǎng)的產(chǎn)品。你想構(gòu)建貴組織想要使用的東西，因此用戶會(huì)游說管理層，以確保資源持續(xù)不斷。所以你需要關(guān)注負(fù)責(zé)重大任務(wù)的大型團(tuán)隊(duì)，你可以幫助他們加快行動(dòng)、減少失敗并高效運(yùn)行。你必須了解內(nèi)部客戶的優(yōu)先事項(xiàng)、痛點(diǎn)、建立規(guī)模經(jīng)濟(jì)的機(jī)會(huì)以及可持續(xù)的商業(yè)模式。你需要使平臺(tái)易于采用，同時(shí)還考慮當(dāng)前情況的實(shí)際限制。

平臺(tái)采用產(chǎn)品理念可帶來與采用 DevOps、SRE、數(shù)字化轉(zhuǎn)型或敏捷全然不同的結(jié)果?，F(xiàn)在有了人們想要使用的東西：平臺(tái)，它可以減輕他們的負(fù)擔(dān)，并讓他們專心致志。他們不必?fù)?dān)心云提供的所有細(xì)節(jié)，他們有一個(gè)基于平臺(tái)的限制和決定的受限菜單。當(dāng)然，沒有人會(huì)純粹為了平臺(tái)而使用平臺(tái)；團(tuán)隊(duì)必須贏得客戶的信任和認(rèn)可，否則他們只能將工作量帶回家。

7.所有權(quán)理念

所有權(quán)可能根植于人類心理學(xué)，也可能是層次化管理結(jié)構(gòu)的產(chǎn)物。在現(xiàn)實(shí)世界中，當(dāng)你嘗試運(yùn)作重大項(xiàng)目時(shí)，就要知道誰在做什么，并相信他們會(huì)繼續(xù)做下去。否則，整個(gè)組織會(huì)分崩離析。一旦沒人知道組織結(jié)構(gòu)圖，紛爭、指責(zé)、冷漠和跳槽很快接踵而來。

谷歌的SRE并不負(fù)責(zé)可靠性，他們大多將自己視為內(nèi)部可靠性顧問。谷歌SRE試圖幫助產(chǎn)品團(tuán)隊(duì)在設(shè)計(jì)系統(tǒng)時(shí)做出正確的選擇。他們幫助設(shè)定服務(wù)水平目標(biāo)（SLO），以確?？煽啃阅繕?biāo)已明確定義。也許最重要的是，他們推動(dòng)團(tuán)隊(duì)一貫采用來自整個(gè)谷歌技術(shù)基礎(chǔ)架構(gòu)（可以稱之為平臺(tái)）的標(biāo)準(zhǔn)服務(wù)。SRE是平臺(tái)即產(chǎn)品的客戶成功團(tuán)隊(duì)。

8、下一步是什么？

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

當(dāng)我試圖更好地了解當(dāng)下的形勢(shì)時(shí)，我問了所有的SRE朋友他們對(duì)平臺(tái)工程有何看法。每個(gè)人都會(huì)懷疑這是新瓶裝舊酒，只是營銷噱頭。

不止一個(gè)SRE告訴我“實(shí)際上，我們是平臺(tái)團(tuán)隊(duì)，而不是SRE團(tuán)隊(duì)?！蔽艺J(rèn)識(shí)的以前在性能工程、安全和數(shù)據(jù)管理方面工作的朋友和同事都已經(jīng)向平臺(tái)工程轉(zhuǎn)型。

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

平臺(tái)不是一艘更快的船，而是上漲的潮水。

原文鏈接：

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