作者|趙云

作為一種圍繞開發團隊和 IT 運營團隊營造協作氛圍的文化，自誕生之日起，業界就有兩種聲音，擁護者和批評者。一方面，在勞動力成本上升、市場競爭日趨激烈、用戶需求變化頻繁的情況下，結合了一系列的理念、實踐和工具，提高了企業在產品和服務交付方面的效率。一定程度上。另一方面，被很多人譏諷為“系統集成”、“軟件拼湊”，實際上無法實現。有些人甚至認為運動失敗了。它在推動軟件交付方面確實發揮了重要作用。它為企業項目團隊帶來了高敏捷、減少勞動力、高效的跨職能團隊協作、持續創新和最小缺陷等優勢。工具的危險性已經不像過去了。

本意：打通部門墻

說起來，你得先從父親說起——。 2007年，參與法國某政府部門的小型數據中心遷移項目。在這個項目中，他分別負責測試和驗證。這意味著他有機會不僅與開發團隊（Dev）一起工作it運維，而且經常與運維團隊（Ops）一起工作。在開發團隊，他需要適應敏捷交付的節奏it運維，但在運營團隊，他必須遵循傳統模式，像消防員一樣維護系統。兩種工作氛圍的來回切換讓他很失望：不同的工作方式和思維方式必然會有巨大的差異，所以兩者之間的工作充滿了沖突。應用在實際生產中會遇到各種未知的、棘手的問題，很難及時處理。這使得運維等相關人員需要在軟件開發生命周期的前期介入。作為一個敏捷開發的愛好者，我果斷調整，試圖沖破這道開發運維的部門墻。而他的敏捷管理實踐是開發的第一個原型。

概念生成有兩個關鍵時刻，一個是在倫敦敏捷會議上與 Clay 的會面，另一個是 John 和 Paul 在 09 年的演講。經過分析，確切的定義是和的組合，它是一組流程、方法和系統的統稱，用于促進開發、技術運營和質量保證（QA）部門之間的溝通、協作和集成。當時的概念很簡單：修補文化。為了使“”成功，涉及分歧的所有各方都需要參與。時隔十余年，企業“工程師”的職位似乎多了起來，但這些初衷在大會上已經蕩然無存：大量的運維和運維人員參與其中，而開發人員卻少了。

無法登陸之謎

隨著火爆，很多企業都比較粗魯：合并Dev和Ops兩個團隊，或者將運維合并到開發中。這是一個概念性錯誤。據悉，客觀條件下也存在泥沙不足的情況。尤其是在微服務興起的明天，系統被劃分成幾十個甚至上百個服務組件。如果沒有敏捷的基礎設施服務作為前提，那基本上就是一句空話。這也是那幾年一直沒能落地的兩個主要原因。下面是一個真實的例子。李先生是云工程技術方面的資深專家和企業家，擁有 15 年的經驗。他曾經講過一個令人費解的經歷：一個負責開發產品的主管級學生在會議“Real”上談到了他的團隊，但從來沒有和他們談論過他們的運營需求甚至他們在做什么，只說他們正在使用 來部署應用程序。

這很令人不安：如果公司的運營團隊不參與，他們怎么可能是“真實的”？

與團隊的開發人員交談后，我明白了整個流程背后的含義：公司的開發人員接管了整個應用生命周期，一站式處理，不涉及運維——他們使用boto3和編寫部署腳本發布新版本，聘請精通AWS和前端業務的“全棧工程師”。其初衷純粹是為了讓開發者工作更輕松，其初衷是減少甚至消除他們在部署、部署管理等基礎設施生命周期中的各種復雜操作和混亂。現在，當他們嘴里說“真實”的時候，他們的意思是讓開發人員包括運維的工作。

開發運維全贏

目前，我們正在為開發人員提供未來運營商將熟悉的久經考驗的工具，包括 CI，這是一種用于 IT 基礎架構的手動編排工具，可以使用代碼管理和維護 IT 資源），事實上有它是這樣的：“嘿，你應該試試我們的平臺！我們已經修復了所有這些錯誤，它比原來的工具好得多。” “謝謝，但我們不感興趣。” “呃，為什么？？它更可靠，更快，并且使用行業標準工具。” “是的，但我們根本不認識他們。我們更熟悉我們的東西。” Ops 仍然相信他們的方式是好的 Make：盡管運營部門知道如何在云上運行軟件。但開發商通常不支付賬單。陳述了這段經歷 - “Ops 總是試圖說服開發人員參加會議。只需解釋他們構建的平臺的作用以及它將如何幫助他們。我仍在與開發人員的對話中辯論，拼命試圖帶來一個''對整個公司的態度，團隊對這些態度的回應是‘我們自己做，謝謝。’”

終于意識到：這些改變文化的嘗試都失敗了。

現狀：淪為運維工具

最后對2022年做如下總結：今天更多是從運維的角度出發，試圖說服開發者按照運維的形式做事。原因一目了然，目前市場上幾乎所有被稱為“”的工具都集中在運維層面。如果您瀏覽 /r/，您將看到一篇又一篇關于操作或工具的文章。如果你看一下工程師的工作描述，它看起來與 2013 年的系統管理員角色非常相似，只是它不是舊的機架和服務器堆棧，而是由一些容器或云提供商管理。因此，如果它旨在改變整體文化，它就不能被認為是一場成功的運動。看好這場運動的人可能會高興地說：“我們正在努力！”但也許他們明白，他們只是在做一種僅限于行動的單方面努力——這實際上與最初指出的“單向道”相反。值得記住的是，在任何給定項目或組織中，運營人員通常至少占 1/5。試圖以“運維”和“使用運維工具”的形式說服每個開發者進行開發，最終將是一件可笑的差事。

問題

在一天結束的時候，“”這個詞可能已經變得有點陳舊了。如果今天還有人賣你，那可能就太落伍了。我們真正想聽到的是人們對日常角色的看法發生了根本性的轉變。我們經常忽略以下兩點：一、以人為本就是以運營為中心，角色是幫助開發者向客戶交付功能（或者幫助開發者實現其他業務目標）。 二、向開發人員交付產品和功能時要小心：找到阻力最小的路徑是保持速度的關鍵，讓開發人員學習和維護所有操作實踐既不可擴展也不可行。回顧原來的觀點，關鍵是要消除開發者與運維團隊之間的摩擦：讓運維人員不再盲目對開發者說“不”，讓開發者不再強求運維維修人員上線。這樣的認知和目標永遠是崇高的，企業明天仍然應該追求它們，但世界是什么樣的？如果我們接受“”是一種將開發人員帶入運維世界的嘗試，但我們也同意這些嘗試在很大程度上都失敗了，那么今天我們需要一個新術語。

提出了一個新名詞：“”。

：軟件開發人員的運維

這聽起來很俗氣，但這個概念是新的。其理念是，重點是讓開發人員更好地工作。運維人員不會告訴他們要做什么，而是會詢問他們在運維方面想做什么，然后讓他們盡可能輕松。這個詞受益于加入的經驗，他通過不同的視角看待世界：以開發人員為中心。這是一種將開發人員作為主要客戶放在首位的觀點。建立面向開發人員的運營實踐（理論上）應該讓開發人員參與并促進協作工作。事實上，如果我們只專注于這個目標，2009 年我們將最終解決我們仍在努力解決的問題。在這個新理念下，“下載這個工具，閱讀這個 48 頁的指南頁面，告訴你的 PM 截止日期你錯過了”將永遠消失；開發人員贏得運維工作的日子已經一去不復返了，我會為你做的。

寫在最后

去年3月，《2022年全球平臺市場調查報告》發布。報告預測，到 2028 年，全球平臺市場規模將從 2021 年的 67.376 億港元降至 263.70 億港元，看起來 20.7% 的 CAGR 2022-2028 年。從這張圖中我們可以看出，作為提高企業技術可靠性、保障業務穩定下滑的神器，全球企業工具的需求量正在增加。從文化上講，它是一種讓開發人員使用新的操作工具的運動。然而，這些運動無疑有“偏離”的跡象，這也是它們無法實施的根本原因：文化的缺失。如果觀念不能改變，即使把員工放在一起，也只會減少兩個團隊之間的糾紛。也就是說，考驗的不僅僅是一個企業的技術，還有管理水平和企業文化。提出的“”概念改變了“開發、運維”的現狀，希望重新組織開發和運維流程的規范，讓開發者可以在運維初期對系統部署給出優化建議，維護。 盡管名詞變了，但 TS 的初衷是一樣的：減少開發團隊和運維團隊的摩擦，而不是一方獲勝，拒絕溝通，甚至干脆成為一個新工具.

參考資料：

更多精彩技術文章可見51CTO技術精選刊物，下載鏈接：???????