DEVOPS也是要有代價的

2016年我參加一個系統整合公司的年會的時候，大家讓我講點什麼，因為臨時叫到我，於是我沒加思考就講了一個盛世危言。我說雖然今年大家取得了十分豐碩的成果，只不過我們需要居安思危，隨著雲端計算,軟體定義資料中心，特別是DEVOPS的快速發展，系統整合的門檻會越來越低，與應用開發離得比較遠的系統整合企業日子會越來越難過，因此希望企業能夠加速業務的轉型升級。

在DEV和OPS兩個領域都幹過超過十年，這讓我對DEVOPS有著不同尋常的期許。隨著企業IT上雲的加速，甚至很多DBA都已經在為自己的前途感到十分悲觀了。透過自動化工具、管道化的流程工具，開發者就能夠敏捷交付應用系統，並且這些系統的運維成本是極低的，一旦系統存在問題，開發者也可以快速參與，對於企業來說是誘惑力十足的願景。

在2017年，我的一個客戶也和我談了他們對未來IT的規劃，他們希望透過微服務架構的應用改造，讓每個獨立的應用都變得足夠簡單，每個資料庫也足夠的小，同時透過在雲平臺上自研工具鏈實現DEVOPS。為此我還幫他們聯絡了一個做雲工具鏈的團隊，幫他們實現他們的目標。

數年過去了，這個客戶在一些小型系統上確實嚐到了DEVOPS的甜頭，認為DevOps是萬能的千金良方。直到最近的一件事，把他們搞得焦頭爛額。在一些小系統上獲得成功後，客戶把DevOps的實踐推廣到了大型的核心繫統。不過前陣子一套新上線不久大型的系統出現了一些問題，業務高峰期系統無比卡頓，大量資料積壓。在多方專家分析無果後，客戶找到了我們。我們發現分析這個問題與以前我們分析系統故障時完全不同了，IT基礎元件和應用都部署在一個K8S的容器雲環境中。出問題的資料庫和KAFKA都是容器化部署的，而在容器映象打包的時候，映象中並沒有包含任何可用於監控分析的工具。因此我們只能透過有限的日誌去尋找問題的蛛絲馬跡。

後來經過幾輪折騰，開始把日誌中看到的堆空間不足的問題做了調整後雖然有些效果，但是還不足以解決所有的問題。最後沒辦法，只能要求開發人員重新打了容器映象，又監控了一段時間，終於把系統中的問題都找出來了。最關鍵的問題是因為業務高峰期的併發訊息數量過大，KAFKA是採用JBOD三副本方式配置的，而底層的CEPH儲存也是三副本的。如此高的IO負載下，IO延時過大，導致系統全面出現問題。當我們把分析結果交給開發人員時，他們根本就無法理解為啥這種架構就會出問題，確實也是，開發人員並不是全棧專家。

事後我也在考慮，從這個使用者這些年的DEVOPS實踐來看，總體還是成功的，利用工具鏈，開發單位實現了敏捷交付。不過也暴露了一些問題，那就是當系統出問題的時候，解決起來比以前更為複雜了。而且從這個案例中，也發現了開發團隊釋出應用時的一些不專業的技能，給後續執行帶來了極大的問題。在我們與運維團隊的交流中，他們覺得研發部門釋出的東西對他們來說都是一些黑匣子，他們基本上沒有能力去幫助研發團隊解決問題。

我想這個案例暴露出來的問題還是有一定的代表性的，可能很多在實施DEVOPS的團隊都會面臨這個問題。無獨有偶，這個案例發生後不就，8月22日，INFOWORLD上釋出了一篇ComputeWorld的自身業務分析師Scott Carey的文章。

翻譯成中文就是開發者根本不想做運維。這篇文章引用了亞馬遜的Emily Freeman部落格裡的一段話作為開場白，描述了DevOps中的一些不盡如人意的問題。

從文字中可以看出她對於這個問題的一些無奈。當初實施DevOp是想透過開發與運維的高度融合解決敏捷交付的問題，同時將DEV/OPS兩支以前相對割裂的隊伍更好的整合起來，實現1+1>2的目標。不過現實往往比較骨感，這個目標的實現並不容易。最主要的問題是DEV/OPS是兩支擁有完全不同技術背景與技術能力的隊伍，甚至很多企業裡這兩支隊伍的上級管理部門還不同，甚至兩個部門之間存在較大的對立與爭議。DevOps的理念並沒有真正彌合這兩個隊伍之間的鴻溝，反而讓Dev隊伍更為膨脹，認為自己無所不能，運維部門僅僅是其從屬;而Ops隊伍則認為現在的應用是一個更黑的黑匣子，他們對此無能為力，因此他們只要把IT基礎設施，也就是伺服器、雲平臺管管好就可以了。資料庫、中介軟體之類的反正都和應用一起打包到容器裡了，乾脆就讓研發隊伍去管吧。

這種DevOps實踐中讓開發人員承擔大量運維人員的工作，開發人員可以肆無忌憚的寫程式碼和釋出系統，從表面上看，少了運維部門得干預，反而提高了系統交付的速度，也節約了成本。

不過這種模式存在兩個問題，一個是研發人員不僅僅成為開發領域的全棧工程師，而且依然要成為運維領域的全棧工程師，才能把這件事幹好。這種期望往往是虛妄的，也是導致研發人員發出“我不想做運維”的吶喊的主因。也有一些研發人員十分願意接受這樣的挑戰，不過他們很快會發現拉網線和裝水管需要的是兩種完全不同的技能的時候，也會放棄這種追求了。這就引發了第二個問題，那就是當Dev在某個與運維相關的領域知識與能力不足的時候，釋出的產品裡可能會包含很多低階錯誤，一旦系統出問題，運維部門又缺乏技術手段去定位與分析。那麼就只能請出十分高水平的專家，使用終極分析武器來定位與解決問題了。

出現這些問題實際上並不是DevOps的理念出現了問題，而是我們在實現DevOps的路上走了彎路，讓我們陷入了一些烏托邦似的陷阱。事實可能與某些IT部門得領導的願景完全不同，那就是無論如何透過DEV來簡化OPS，我們都無法完全避開運維的問題，在目前的技術條件下，可以完全自動駕駛的IT系統是不存在的。

我們的工具鏈開發過程中缺乏運維專家的參與，只注重功能的實現而缺乏運維知識，這導致了我們的DevOps流程走的很順利，但是一旦出現問題，DEV人員不明白系統，因此無從下手。OPS人員面對應用系統的黑匣子，空有一身本領也無從下手。而當每次系統出問題，運維團隊都無法解決問題，必須請來十分強大的專家，用上核心跟蹤，火焰圖這樣的終極武器來定位問題的時候，我們的DevOps可能已經走向邪路了。

更有甚者，還有一些組織的領導和某些研發團隊的負責人認為DevOps可以最終演進為更高的目標-NoOps，從而可以大大節約運維的成本，並把運維的費用全部或者大部分轉移到研發一端。最近在我與一些企業IT負責人交流的時候，有不少都流露出了這種願望。這些研發出身的IT主管都認為，只要研發時設計到位，NoOps是能夠實現的。以我目前的認知能力來看，這是一種十分可怕的觀點。

實際上，DevOps不是要培養更為全棧的工程師而是要讓DEV/OPS兩個工作結合的更為緊密，從而變得更高效。目前DevOps存在的問題從最根本上還是組織對於DevOps的認知錯誤導致的。為了節約成本而把運維責任推給了開發人員並不是解決DevOps問題的良藥。

透過應用架構的改造，以及系統上雲，確實可以大大節約企業的IT運營成本，只不過開發與運維這兩個體系的建設並不能夠去做簡化或者弱化運維。讓運維人員必須深入瞭解開發與讓開發人員成為運維專家都不是DevOps中正確的手段。透過研發與運維的專家共同構建標準化的規範體系，工具鏈，智慧化運維工具，透過不斷提升的底層平臺的能力來支撐DevOps，才能讓這個工作做的更好。

如果說DevOps並不是為了讓Dev都成為Ops專家，Ops都成Dev專家，那麼這部分互相跨越邊界的工作就必然需要一種自動化的手段來實現。因此和作者Scott的觀點類似的是，我也認為平臺工程可能是可以解決DevOps目前存在的問題的一種方法，只不過平臺工程本身就是個大工程。需要更高水平的研發與運維專家參與，並且投入足夠的資金才能夠做好。不過目前我們的大部分組織都只希望從DevOps中獲得實惠，而並不想為DevOps投入平臺工程的成本。如果真的這樣，這個問題就很難解決了。平臺工程裡的一個十分關鍵的問題就是運維專家的經驗如何成為工具鏈的一部分，這裡就涉及到了專家知識自動化的問題，如果不解決這個基礎問題，那麼運維專家就要全程參與DevOps的每個活動，這也是極為高成本的，因此工具鏈中的運維知識生態化也是十分關鍵的，也值得認真探討，只是今天的篇幅有限，我們就不展開討論了。

最後要說的是，今天我的觀點僅僅是認知與解決DevOps問題的一個方法，並不是放之四海皆準的原則，不同的企業，不同的IT發展階段，不同的技術團隊，在DevOps的實踐中會有不同的選擇。不管如何，組織的IT主管真正看明白DevOps才是這個組織的DevOps走上康莊大道的第一步。