最近某位大神在推特上發了一個貼文，結果引來了國內眾多賣課機構、培訓機構的狂歡，開始販賣焦慮，其實「平臺工程」也不是什麼特別高深莫測的東西。閒得無聊，把這位大神的幾個貼文薅了下來，你看過之後就會覺得沒啥，都是熟悉的東西。

Sid Palas & 平臺工程

這位大神的名字叫 Sid Palas，一位專門做 DevOps 和 Cloud infra 相關工作的小夥伴。為了讓大家瞭解他，他的 github 我附在最後了。下面就是這個非常有意思的貼文。原帖可以到推特上去圍觀。共有六部分，第一部分我貼了原圖，後面的五部分我把文字複製了過來。

 

DevOps is dead , long live Platform Engineering! 1) Developers don't like dealing with infra 2) Companies need control of their infra as they grow. Platform Engineering (and Internal Developer Platforms) enable these two facts to coexist.

DevOps 已死，平臺工程永存。1) 開發人員不喜歡與基礎設施打交道 2) 公司在發展時需要控制他們的基礎設施。平臺工程（以及內部開發者平臺）可以同時滿足這兩個訴求。

Fact 1: Most developers don't like dealing with infrastructure. They want to write code and run it somewhere but don't care much where that is. Functions as a Service (e.g. Lambda) or Platforms as a Service (e.g. Vercel) provide this experience.

事實 1：大多數開發人員不喜歡處理基礎設施。他們想編寫程式碼並在某個地方執行它，但不太關心執行在哪裡。函數即服務（例如 Lambda）或平臺即服務（例如 Vercel）提供了這種體驗。

 

Fact 2: As a company/organization grows, its needs may "outgrow" the constraints imposed by the FaaS and PaaS offerings. The challenge then becomes moving up the control axis without exiting the Developer Comfort Zone. This is where platform engineering comes into play!

事實 2：隨著公司/組織的發展，其需求可能會「超出」由 FaaS 和 PaaS 產品施加的限制。然後挑戰變成在不離開開發者舒適區的情況下向上移動控制軸。這就是平臺工程發揮作用的地方！

 

Platform engineers build the tooling and abstractions around the complex infrastructure configurations such that most software engineers don't need to worry about those aspects as much. The resulting system is what is known as an "Internal Developer Platform" (IDP)

平臺工程師圍繞複雜的基礎架構設定構建工具和抽象，這樣大多數軟體工程師就不必擔心這些方面。由此產生的系統就是所謂的「內部開發者平臺」（IDP）

 

The exact form of an IDP will vary greatly from one organization to the next. At a small company, it could be a set of helm charts that prescribe best practices for deploying services. At a large company, it might be a fully automated Infrastructure as Code solution.

IDP 的形式因組織而異。在一家小公司，它可能是一組說明部署服務最佳實踐的 helm charts 。在一家大公司，它可能是一個完全自動化的基礎設施即程式碼的解決方案。

The key is that it provides the control the company needs while keeping the DevOps effort within the Developer Comfort Zone!

關鍵是它提供了公司所需的控制，同時將 DevOps 工作保持在開發人員舒適區內！

 

平臺工程價值觀

Sid Palas 的觀點非常簡單、直接、好理解：平臺工程團隊以及他們負責的內部開發者平臺，向下維護底層基礎設施，向上給開發人員提供服務。開發人員自助式使用這個平臺，避免直接與底層基礎設施打交道。

其實目前很多公司已經這麼做了，這不是什麼新鮮東西。只不過不同規模的公司，這個開發者平臺的成熟度不一樣。這一點 Sid Palas 自己也提到了。而在我瞭解到的公司一般分為三種情況。1）在公司規模比較小的時候，業務也比較少，誰來負責維護開發者平臺是可以商量的。找幾個開源工具就能滿足需求，讓開發團隊或者運維團隊哪個團隊維護都可以。我見過研發實力強，讓研發團隊維護的，也見過運維實力強，讓運維團隊維護的；2）中等規模的公司，這個時候都會有專門的研發效能團隊，或輕或重，也都會有自己的 IDP 平臺了，哪怕是幾個開源工具「粘合」到一起組裝而成；3）大的公司則不必說，不但有專門平臺，甚至每個專項都會有專門的團隊來支撐。

另外就是國內研發效能團隊的業務邊界是比平臺工程範圍廣的。不僅僅負責底層基礎設施IaaS、k8s、PaaS、FaaS這些，所有和產研相關的平臺都有涉及，比如測試相關、專案協同等。

優化開發者體驗

平臺工程是一套用來構建和運營支援軟體交付和生命週期管理的自助式內部開發者平臺的機制和架構。平臺工程的目標是優化開發者體驗並加快產品團隊為客戶創造價值的速度。

對我個人而言，我更喜歡《Gartner釋出2023年十大戰略技術趨勢》這篇文章中給出的平臺工程的解釋(如上）。因為相對於之前的很多概念和實踐，這裡不但提到了交付價值，更是首次提到了「優化開發者體驗」。這一點是非常難能可貴的。之前很多公司都沒有注意到這一點。

內部開發者平臺反例

現在很多公司都開始做內部開發者平臺，有的叫釋出系統，有的叫專案管理平臺，叫什麼無所謂，但都有一個共同點就是做得太「爛」了。這些平臺沒有聚焦到導致開發進度放緩的開發痛點和阻力的解決方案上，反而是拍腦門想了很多看上去「高大上」實際上對一線產研工作沒有毛作用反而加重了一線產研工作量讓大家怨聲載道的功能上。讓一線產研小夥伴苦不堪言，內網罵完外網罵。這就是內部開發者平臺的典型反例。

相關文章

二三線網際網路公司怎麼做好研發效能

https://mp.weixin.qq.com/s/x9N-xWv8fenj7_xHxnif3Q

DevOps 已死，平臺工程才是未來

https://www.infoq.cn/article/7porVp7qVF03BVc2tDd6

Gartner釋出2023年十大戰略技術趨勢

https://mp.weixin.qq.com/s/x9N-xWv8fenj7_xHxnif3Q

聊聊 「DevOps 已死」
https://my.oschina.net/jianmu/blog/5582494

扯淡的DevOps，我們開發者根本不想做運維

https://mp.weixin.qq.com/s/ZLIdcZOAAKHRl2KvRsxkGA