平臺工程不是為了取代DevOps，而是DevOps的進一步演進和發展。本文介紹了DevOps和平臺工程，以及對于安全的意義。原文: Platform Engineering and Security: A Very Short Introduction

我是一名 DevOps 工程師，個人還是希望 DevOps 仍然有其意義，因為很顯然，如今已是"DevOps 已死，平臺工程萬歲"的時代了。

不可否認，自 2022 年以來，我們更頻繁的看到"平臺工程(platform engineering)"、"開發者門戶(developer portal)"以及"后臺(Backstage)"等術語。

本文將回答幾個基本問題：DevOps 真的死了嗎？什么是平臺工程？區別是什么？平臺工程如何處理 DevSecOps/安全問題？

DevOps 已死？

簡單來說，并沒有。

如果我這么多年來在技術領域學到了什么，那就是技術、框架和方法論從未真正消亡，而是會成長、適應和發展。

例如，想想敏捷開發。你第一次聽說敏捷開發是什么時候？現在死了嗎？這就是問題所在。

但某種程度上，DevOps 確實"死"了。雖然從傳統意義上講，DevOps 并沒有從科技界消失，但確實"死"了，因為許多嘗試 DevOps 的公司和團隊都沒有達到預期。

不過這并不是什么新聞，因為早在多年前，技術研究和咨詢公司 Gartner 的一位數據分析師就已經預測，在整個 2022 年，75% 的 DevOps 計劃將無法達到預期目標，而到 2023 年，這一數字可能會增長到 90%。

但需要指出的是，這些 DevOps 計劃的失敗并不是因為技術上的挑戰，而是因為信任、所有權和團隊合作等被忽視的人為因素。

DevOps 本應是解決傳統運營孤島中所有問題的銀彈，讓一切重新變得美好。然而不幸的是，許多團隊并沒有達到最初預期，而且開發人員似乎并不想從事運維工作：

開發人員不想從事運維？

公平的說，這取決于你問的是誰。有些開發人員認為 DevOps "誰構建，誰運維"的模式肯定是有益的，甚至有時是必要的，而有些開發人員則根本不想接觸運維。

Twitter 上有一項關于此問題的民意調查^[1]，330 名開發人員參與了調查，調查結果顯示，41.8% 的受訪者表示支持運維任務，42.1% 的受訪者表示不支持，16.1% 的受訪者表示無所謂。

因此，開發人員更愿意避免與基礎架構和運維打交道，這對 DevOps 來說是個壞兆頭。在這種情況下，平臺工程變得前所未有的熱門。

平臺工程

如今，非專業的最終用戶經常被要求運維一系列復雜的服務，這幾乎是不可能的。平臺工程與 DevOps 一樣，都是為應對日益復雜的現代軟件架構而出現的。

DevOps 試圖從文化角度解決軟件開發生命周期(SDLC)中的協作和速度問題，即重視責任分擔模式、持續成長和學習心態，鼓勵團隊合作、最佳實踐和現代工具鏈，而平臺工程則試圖從另一個角度來解決問題：自助服務。

我們來看一個具體例子：

團隊中的開發人員需要為新創建的應用創建數據庫，但他們可能并不完全了解如何使用正確的自動化工具(比如Terraform)在特定云服務商(比如AWS)中創建關系數據庫(RDS)，并非所有開發人員都知道基礎架構在哪里運行以及如何協調。

解決這個問題的 DevOps 方法是使團隊具有足夠的跨職能知識，讓團隊中的某個人掌握 AWS 服務和基礎設施即代碼的專業知識，更重要的是擁有適當權限，通過編寫 Terraform 模塊和在 AWS 中部署 RDS 來自動化配置云資源。

而對于平臺工程，應該有一個作為"內部開發人員門戶"的集成產品，這樣開發人員就可以通過它以自助服務的方式請求 AWS 中的 RDS，平臺將自動創建 RDS。

請注意，這只是一個例子。如果設計得當，內部開發人員門戶網站可以實現更多功能。

簡而言之，平臺工程是一門設計和構建工具鏈和工作流集成產品的學科，涵蓋了整個 SDLC 的操作需求，實現適度的開發人員自助服務，并為云原生時代的各個組織和團隊找到合適的抽象層次。

平臺工程 V.S. DevOps

雖然平臺工程通過提供自動化基礎架構操作的自助服務功能改善了開發人員的體驗和工作效率，但并不適合所有人，尤其不適合小型團隊/公司。即使團隊決定購買內部開發人員門戶網站作為服務，而不是從頭開始構建，仍然需要在幕后維護自動化和模板。想想之前在云上創建 RDS 的例子，團隊需要具備維護 Terraform 模板的知識，以生成在 AWS 中創建 RDS 的模塊。

如果團隊和公司規模太小，不適合開展平臺工程，DevOps 可以更好的發揮作用。一般來說，在規模較小的環境中，協作更緊密，節奏更敏捷，組織摩擦更少。

關于平臺工程和 DevOps，還有一點至關重要，那就是平臺工程不會"取代"DevOps，它的出現不會讓 DevOps 被遺忘。

盡管很多人說，隨著平臺工程的興起，DevOps 已死，但這并不是一種方法取代另一種方法的情況，而是兩種方法可以結合在一起。我們可以將平臺工程稱為 DevOps 的"進化"，兩者仍在促進相同的目標，并能幫助 DevOps 提高效率。我們很可能仍然會經常看到 DevOps 文化，而且許多軟件工程組織也很可能會建立平臺團隊，從而將軟件開發人員和 IT 運維人員凝聚在一起。

安全在新范式中的定位

說到 DevOps，就不能不提到安全(或 DevSecOps)，畢竟安全是頭等大事。

DevOps通過"左移"來解決安全問題。在傳統軟件開發方法中，與安全相關的任務只在SDLC的最后處理，而這可能會導致項目延遲并且不可擴展，DevOps/DevSecOps使用自動化工具盡可能早的在SDLC的每個階段"嵌入"安全。

例如，在編寫代碼時，開發人員會考慮潛在的安全問題，如在哪里存儲secrets和憑證，以及如何從代碼中安全的獲取(而不是在將所有secrets推向生產之前進行最終審計/審查）。另外，在構建虛擬機鏡像或容器鏡像時，每次構建都會自動進行漏洞掃描，并在發現任何漏洞時進行修復(而不是在交付生產之前進行一次性掃描)。

這就是"左移"。

所有這些以更敏捷、反應更快、更自動化的"左移"方式處理secrets的方法，在平臺工程中仍然被堅持繼承了下來，DevOps 和平臺工程在這里并不矛盾。

只是在平臺工程的幫助下，內部開發人員門戶網站可以將整個過程的自動化提升到另一個層次。我們來看兩個具體的例子：

想象一下，當你想創建一個新的微服務時，內部開發人員門戶網站可以使用現有模板引導創建整個存儲庫，而不只是編寫一些模板代碼。然后通過技術手段構造 CI/CD 流水線、Dockerfiles 和 Kubernetes 清單，這不僅能為應用程序提供腳手架代碼，還能提供 CI/CD 流水線、Dockerfiles、Helm charts和 Kubernetes YAML，其中預配置的流水線遵循 DevSecOps 最佳實踐，能掃描源代碼中的硬編碼secrets，并對 YAML 等進行校驗。

想象一下，你想存儲一些secrets。與其去弄清團隊正在使用哪個secrets管理器，部署在哪里，以及是否有權限創建secrets，還不如訪問與secrets管理器集成的內部開發人員門戶，以自助服務的方式創建secrets，而不必過多擔心任何底層細節，這正是平臺工程所能提供的抽象程度。

想象一下，你想在云上啟動一個新的虛擬機。與其從頭開始編寫自動化代碼(或從現有代碼庫中復制粘貼)，然后在部署前審查安全組設置，還不如簡單的訪問內部開發人員門戶網站，點擊一個按鈕，然后使用由平臺工程團隊維護和保護的模板來完成所有工作。

所有這些都是平臺工程的魅力所在：

• 自助服務
• 適度抽象
• 最佳實踐和自動化

總結

本文探討了 DevOps 和平臺工程，它們之間的區別，以及新范式如何解決安全問題。

你好，我是俞凡，在Motorola做過研發，現在在Mavenir做技術工作，對通信、網絡、后端架構、云原生、DevOps、CICD、區塊鏈、AI等技術始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續學習、終身成長，歡迎一起交流學習。為了方便大家以后能第一時間看到文章，請朋友們關注公眾號"DeepNoMind"，并設個星標吧，如果能一鍵三連(轉發、點贊、在看)，則能給我帶來更多的支持和動力，激勵我持續寫下去，和大家共同成長進步！