與許多流行的技術術語一樣，DevOps 已從樂觀的頂峰跌落到疲憊的深淵。
其失敗的原因在於對軟體難以編寫的原因存在嚴重誤解。
誤解：透過消除部署障礙，可以部署更多軟體，事情會變得更簡單、更好。
真正原因：問題在於開發人員和運營團隊被荒謬的流程和協調所阻礙。
什麼是 DevOps？
DevOps 於 2007 年左右推出，這是一個相當激進的概念，旨在消除執行硬體的人和編寫軟體的人之間的分歧。
當我當時在一家老牌公司工作時，釋出軟體的流程如下。
- 開發團隊通常會與前端團隊一起，將伺服器軟體打包成一個完整的實體，然後剪下出一個帶有版本號的版本。他們會在自己的機器上進行本地測試，然後交由質量保證部門進行測試，最後在質量保證部門的檢查合格後交付給客戶。
- 運營團隊會收到一份操作手冊，有效說明軟體正在發生哪些變化，以及如果軟體崩潰了該怎麼辦。其中包括軟體的安裝方式、是否會對資料庫造成影響等，是一份完整的活文件。這樣做的目的是，管理伺服器、網路裝置和 SAN 的人員根本不知道軟體是做什麼的，也不知道如何修復，因此他們需要的實際上是一步一步的指導。有時，你甚至會得到一份紙質文件。
- 由於這些問題經常發生在資料中心內，因此你沒有無限增長的彈性。因此，如果可能的話，你會慢慢地推出更新，並每隔一段時間停止監控。但你不能像現在人們看到的那樣進行藍/綠部署，因為你很少有足夠的多餘伺服器容量為所有使用者同時執行兩個版本。有些組織確實會在不同時間使用不同的資料中心，並在它們之間進行切換（這被認為是最高階別的安全措施）。
- 你會選擇一個部署日，通常是一週的中間，當地時間上午 10 點左右，然後監控你所掌握的任何指標，看看釋出是否成功。這些通常都是非常基本的成功指標，包括一些令人瞠目結舌的指標，如 "支援部門是否收到了更多的服務單 "和 "我們的正常執行時間網站是否獲得了更多的點選率"。實際上就是 "負載平衡器是否滿意 "和 "客戶是否主動向我們抱怨"。
- 您將完成部署，然後待命團隊將在您進行部署的過程中監控進度。
為什麼這個方法不管用
部分問題在於這種設計非常耗費人力。你需要足夠多的開發人員一起協作才能釋出。然後你需要一個配備人員的 QA 團隊來實際使用該軟體，並在剛剛開始成為一種事物的自動化測試的基礎上確保該軟體確實有效。最後，你需要一名技術作家與開發團隊合作，講解發布手冊是什麼樣子的，然後最終讓運營團隊接收、審查該手冊，然後實施該計劃。
它也非常緩慢。即使功能已經完成，也經常要花幾個月的時間才能推出，因為必須先推出更重要的功能。或者這次更新會對資料庫進行重大更改，我們不想將六件事與一個可能造成災難性的變化捆綁在一起。這實際上是敏捷與瀑布設計分解為實際步驟。
當時，很多關於組織變革的空談都是廢話。企業如此迫切地想要變革的真正原因如下：
- 有很多技術員工是必須的，他們不能輕易替換，這讓人很無奈
- 招聘難度大、成本高。
- 銷售人員不能輕易地將他們最後一刻提出的交易要求注入釋出週期，因為這往往是板上釘釘的事。
- 這為 SaaS 供應商提供了一個絕佳的機會，他們可以將複雜性解除安裝到自己的堆疊中，從而將自己注入到流程中。
- 在雲平臺開始吞噬市場份額的時候，這一變化也強調了雲平臺的優勢。你不需要大量的規範，只需分配更多的伺服器即可。
- 錢（實際上）是免費的，所以不管每月賬單如何，提高速度才是上策。
- 開發人員可以理解地感到沮喪，因為微小的改動可能需要數週時間才能完成，而他們卻因客戶投訴而受到指責。
DevOps 與 Agile
DevOps 與 Agile 的結合最終產生了一種非常不同的程式設計哲學，其具有以下特點：
- 使用者就是測試者
- 每個系統都是你的專長
- 運輸速度高於一切
- 透過指標來掌握
- 正常執行時間免費，SSO 需要花錢（免費功能是付費功能，昂貴的可用性不收費）
- 日誌是商業智慧
這種模式的漏洞很早就出現了。開發人員在本地 Mac 和 Windows 機器上進行測試，然後將程式碼部署到根據 Ansible 劇本配置的 Linux 伺服器上，並執行數月甚至數年。執行中的生產伺服器群不可避免地會出現細微差異，要麼是出於安全原因的軟體包升級，要麼只是隨機配置事件。
很快你就會看到類似這樣的資訊：“它在 1、2、4、5 號機器上執行良好，但 3 號機器似乎有問題”。在 DevOps 模型中，誰應該去弄清楚發生了什麼或如何發生並不明確。
很快，開發人員的反饋開始堆積如山。他們不想花費這麼多時間來弄清楚他們想要哪個 Debian 軟體包來滿足這個或那個依賴關係。這不是他們感興趣的工作，而且他們也不會因為這項工作而得到獎勵，因為他們幾乎完全是根據他們釋出的軟體來衡量晉升的。
此時，您會看到非常奇怪的工作流程：在部署期間，按小時付費的生產伺服器數量增加一倍，然後慢慢縮減，所有這些都依賴於相同的 AMI（伺服器映像）來確保某種基本一致性。但是，由於對 AMI 的任何更新都需要進行完整的開發階段生產檢查，因此安全升級等工作需要很長時間。
進入容器
升級 Kubernetes、升級主機作業系統、制定防火牆規則、設定服務網格、執行網路策略、執行堡壘主機、配置 SSH 金鑰等。組織很快發現，這些事情非常耗時，而且通常需要比他們之前擺脫的角色更多的專業化。
以前，您需要一名 DBA、一名系統管理員、一名網路工程師和一些一般的運營人員。現在，您需要的人員不僅要了解資料庫，還要了解特定雲提供商版本的資料庫。您仍然需要具備系統管理員技能的人員，但此外，他們還需要是您的雲平臺專家，以確保您不會將資料庫暴露給網際網路。
平臺工程
由於沒有新的想法，只有新術語，王位的繼任者已經出現。開發團隊不再需要了解和排除執行其軟體的平臺的故障，相反，整個過程完全從他們身上抽象出來。他們提供容器，這就是關係的結束。
將平臺運營的所有權交給了從一開始就應該擁有它的人。這也消除了一些關於誰的問題的模糊性。開發團隊仍然需要隨時處理特定的應用程式錯誤，但平臺團隊可以執行更多的全域性規則。
結論
我們現在看到基礎設施領域正在大幅萎縮。團隊越來越多地尋求簡單、更少平臺特定性工具。在我的個人圈子裡，這感覺就像是真正的迴歸本源，因為中小型組織放棄了 Kubernetes 之類的技術，並採用了更簡單、更易於故障排除的工作流程，例如“拉取新容器的 bash 指令碼”。
從某些方面來看，這是一個積極的變化，因為組織不再假裝他們需要“全球規模”，而是可以專注於實際服務其擁有的使用者和開發人員。
然而，平臺工程並不是解決問題的靈丹妙藥。相反，它只是雲提供商急於顯示月度增長的另一種行業杜撰，他們知道團隊缺乏建立此類實踐所描述的工具的專業知識。在現實中，企業需要更加坦誠地瞭解自己的實際需求，而不是被引導去相信自己需要什麼。