DevOps 是一種將開發和運營結合起來的方法，在應用規劃、開發、交付和運營方面將人員、流程和技術結合起來。DevOps 使以前孤立的角色（如開發、IT運營、質量工程和安全）之間進行協調和合作。一直以來，DevOps 的採用都是以幫助企業更快地向客戶提供價值，更好地適應市場和競爭，並保持系統的穩定性和可靠性為目標。

然而，近兩年關於“DevOps 已死”的討論越來越多。該觀點持有者認為 DevOps 模糊性，實施起來的複雜性及高成本等問題，未能達到幫助企業實現其加快交付、提高質量和降低成本的目標。

在這篇文章中，我們將理性分析一些反對 DevOps 的常見論點，並一同探討在當下 DevOps 實施時所面臨的挑戰，以及 DevOps 未來演變與平臺工程的關聯。

反對 DevOps 的三大觀點

DevOps 的定義過於模糊

關於 DevOps 的批評之一是它 過於模糊，缺乏一個明確的定義。DevOps 對不同企業和團隊來說意味著不同的東西，而且對 DevOps 的實際內容也沒有達成共識。甚至有言論表示 DevOps 只是一個被供應商和行業顧問過度使用的流行詞。

DevOps 實際上並不是一套僵硬的框架或規則，而更是一種文化和思維方式，能夠適應不同的環境和目標。DevOps 並沒有規定團隊應該如何工作，而是提供了可以幫助團隊更好地合作的原則和實踐；也沒有規定團隊應該使用什麼工具，而是鼓勵團隊使用最適合他們需要的工具。因此 DevOps 的模糊性我們可以視為它的靈活性。DevOps 允許團隊根據他們的具體挑戰和機會來定製他們的方法，還允許團隊進行試驗並從經驗中學習。

DevOps 給企業造成成本負擔

反對 DevOps 的另一主要觀點就是， DevOps 的實施和維護成本過高。由於 DevOps 需要對企業的文化、組織架構和技術進行大幅度的改變，同時，還需要企業在時間、成本以及基礎設施方面進行大量投資。因此有部分企業中的 IT 主管或領導並不願意在此花費過多，因為他們無法保證 DevOps 實施後的實際效果。

不可否認，企業實施 DevOps 的確是個不小的工程。但客觀來說，DevOps 並不一定是一個全有或全無的主張。企業可以逐步和有選擇地採用 DevOps，根據自身需求和商業目標來選擇合適的工具和實施方式，企業中現有的資源和基礎設施也可以被利用起來。這樣企業可以將採用 DevOps 的前期成本和風險降到最低。

關於實施效果，DevOps 並不是一套即時的解決方案，需要從長期利益來看。DevOps 可以幫助企業減少交付過程中的浪費、錯誤、延遲和失敗，同時提高軟體交付的質量、效率、團隊間的協作以及客戶滿意度。從長遠來看，這些成果可以轉化為更低的成本、更高的收入和更好的競爭優勢。

DevOps 過於複雜

第三個反對 DevOps 的聲音來自於對其複雜程度的質疑，認為 DevOps 難以實施和管理。DevOps 通常涉及多項技術挑戰和較高的複雜性，因此導致開發團隊和運營團隊難以上手。同時還涉及跨多個團隊的大量協調和溝通，這在大型或分散式組織中可能是個極大的挑戰。

實際上 DevOps 是為了簡化和精簡軟體開發生命週期，而不是使其複雜化。DevOps 依賴自動化、標準化和整合，以減少人工任務、錯誤和依賴性。此外，DevOps 並不是一個適用於所有情況的解決方案。企業需要根據他們的具體環境和要求來定製 DevOps 方法，並利用各種工具和技術來促進 DevOps 的實施和管理。例如，使用版本控制來跟蹤和記錄變化；或使用告警管理來統一和優先處理緊急狀況。

DevOps 實際存在的問題

DevOps 自 2007 年隨著企業規模、行業以及現有的 IT 環境的變化，針對 DevOps 的反對聲音也並非空穴來風，DevOps 在概念上、流程和技術等方的確面臨著巨大的挑戰。

首先許多企業對 DevOps 的概念存在誤解， 未能採用 DevOps 的基本原則和文化，導致實施時存在偏差，即僅僅僱傭一個“DevOps 工程師”或使用一些 DevOps 友好的工具。這就導致了混亂、孤島和低效率等問題。因為 DevOps 並不是一個角色或一個工具，而是一種思維方式和一種實踐，需要企業變革和確保一致性。

DevOps 的核心理念是“you build it, you run it”，這 給開發人員增加了過多的壓力和認知負擔，開發人員不得不處理複雜且多樣的基礎設施、安全、合規和運維等問題，開發人員通常不擅長或缺乏處理這些任務的技能和工具，從而需要耗費大量時間和精力。而過多的精力花費在非開發任務上，導致開發人員無法將核心能力價值最大化利用。

此外，隨著分散式系統的廣泛應用，其複雜性越來越高， DevOps 變得更加難以實施和管理（當然問題的根本來自於現代軟體開發的複雜性增加而非 DevOps 本身）。企業需要對其基礎設施和環境有更多的控制和可見性，以及更多的敏捷性和速度來滿足業務需求。DevOps 也難以應對雲原生技術（如容器、Kubernetes、微服務和無伺服器）的多樣性和波動性。

平臺工程的崛起

為了解決上述問題，一些企業正在嘗試將 DevOps 演變到下一階段，透過建立可重用、自助式平臺的實踐，使開發人員能夠以最小的摩擦構建、部署和執行其應用程式，這就是平臺工程逐漸崛起的契機。

平臺工程相比 DevOps 有以下幾個優勢：

賦能開發人員：平臺工程為開發人員提供了一個“黃金路徑”，為他們的應用程式提供合適的工具、實踐和安全措施。開發人員可以自助獲取他們需要的資源，而不用擔心底層的細節或依賴關係。平臺工程還透過降低複雜性、提高生產力、增強質量和加速反饋迴圈，改善了開發人員的體驗。
啟用平臺工程團隊：平臺工程擁有專門的平臺工程師團隊，負責構建、維護和改進支援開發人員的平臺，平臺工程師充當促進者和協調者。同時，平臺工程師可以利用雲原生技術（如容器、Kubernetes、微服務和無伺服器）建立可擴充套件、彈性、可移植和成本效益良好的平臺。
利用平臺編排：平臺工程使用平臺編排工具，自動化跨不同環境的平臺的配置、部署和管理。平臺編排工具還提供對平臺及其使用情況的可見性、監控和治理。平臺編排工具幫助平臺工程師為開發人員提供一致、可靠和安全的平臺。
改善業務成果：平臺工程透過實現更快更好的軟體交付，幫助組織實現其業務目標。平臺工程能夠培養開發人員和平臺工程師之間的協作、創新和學習文化，並幫助組織以可靠、高成本效益和安全的方式進行擴充套件。

結論

DevOps 並沒有死，而是在革新和進化，平臺工程則是 DevOps 的下一個演變階段，相較於 DevOps，其優勢是以可持續的方式賦能和助力開發人員。平臺工程能夠幫助企業組織應對雲原生環境的複雜性和增長，同時實現更快更好的軟體交付。

從 DevOps 到平臺工程：軟體開發的新正規化