“你在團隊裡是做什麼的？”“DevOps。”
“DevOps是什麼呢？”
“DevOps是一種文化、一種實踐，目標是加快軟體迭代速度，讓團隊更快交付價值。”
“能不能具體點，你們日常工作的主要內容是什麼？”
“修Pipeline…”
作為一名開發，在剛涉足DevOps領域的時候，最難的就是和傳統運維撇清關係；等到DevOps不再被當成是運維，又容易被當成是專職修Pipeline的人。
DevOps在一遍遍被人們提及、一次次在專案中被實踐時，也在不斷地被重新定義，DevOps是什麼？這個問題可能到現在也比較難說清楚，但是專案中的“DevOps”做了些什麼，卻是清晰可見的。
本文就結合筆者的切身經歷，談一談關於DevOps交付的價值以及在企業轉型過程中遇到的一些問題。
背景介紹
客戶是一家澳洲大型金融保險企業，其IT部門總人數在千人以上，維護應用兩百餘個。在經歷了幾年的收購和合並之後，在業務上指定了“將收購來的多個品牌進行整合”的大方針，於是IT部門也開始面臨系統整合、業務線整合、網站合併的問題，同時客戶正在將他們的服務逐漸從自建資料中心向AWS公有云服務上遷移。
團隊概覽
在數字化轉型的漫漫長路中，該企業已經在內部搭建起了一套持續交付系統，以Jenkins為中心，有製品庫、依賴管理、程式碼管理、任務管理系統，敏捷實踐成熟。
我所在的團隊是在整個組織向DevOps轉型中的一個比較關鍵的團隊，肩負著CI/CD優化、持續交付改進、運維能力輸出的重任。類似的團隊應該在很多DevOps轉型的組織裡都有，負責維護CI/CD基礎設施、搭建應用開發腳手架、維護基礎設施變更、做各種自動化的工作（姑且就將這類團隊稱之為Platform團隊）。
比較特殊的是我在的這個團隊實行輪崗制，由產品團隊的成員（通常是開發人員）定期輪換到Platform團隊，帶著在產品團隊遇到但是沒能解決的問題，在這個團隊中尋求最佳實踐和解決方案，一段時間後（通常是三個月），開發人員從Platform團隊回到開發團隊，同時將DevOps技能和最佳實踐帶到產品開發團隊。
整個Platform團隊基本維持在3-5人的規模，有一個IM（Iteration Manager迭代經理），其餘全是開發人員。
取得的成就
回顧過去的五個月，Platform團隊一共經歷了10個迭代（每個迭代兩個星期），我梳理了一下每個迭代的工作內容，整理出主要成就如下：
- 圍繞CI/CD做了很多優化，比如簡化Jenkins slave建立流程、給自動化指令碼（基礎設施程式碼）貢獻了許多新功能。
- 新技術試點，比如嘗試將靜態檔案部署到AWS S3中代替Apache服務。
- 為應用設定監控，更新了基礎設施指令碼用於開啟監控，並協助應用團隊將配置指令碼應用到各個環境。
- 團隊之間的溝通，瞭解開發團隊痛點，幫助開發團隊找到能夠解決問題的團隊（許可權、責任劃分、知識傳遞），技能培訓等。
- 響應變化，解決技術難題（雖然我認為這更像是一個溝通+許可權的問題，但是其他所有團隊都認為是技術難題，那我也就這樣認為吧），以及修復一些類似於硬碟空間已滿、網路延遲、許可權的問題。
遇到的問題
當然在交付價值的同時，有很多痛點是非常折磨人的：
- 許可權分配：作為一個跨開發團隊工作的團隊，不但沒有擁有比開發團隊更多的許可權，甚至連開發團隊的一些許可權都沒有，比如不能向開發團隊的程式碼庫提交程式碼(修改基礎設施程式碼需要這個許可權)，比如缺少Linux許可權導致伺服器底層問題沒法直接修復，再比如 Jenkins 的問題追蹤到了服務層需要維護Jenkins的團隊支援，因為涉及到CI／CD的應用是由別的團隊在管理。
- 溝通效率：為了解決一個bug，有時候要花上兩週的時間發郵件，找關鍵人物，組織會議，跟不同的人解釋五遍以上的上下文（技術細節的上下文是很繁瑣的），最後解決問題的人還很有可能不是自己團隊的（沒有許可權）。因為大家平時都很忙，而且建卡工作的方式讓一部分人對團隊請求幫助的問題不是很熱心，這種情況在溝通的時候如果表現得情商不夠高，對方就會要你發郵件給他們團隊然後等 IM 建卡，規劃到迭代裡再說了，我遇到過一次這樣的情況，最後還是通過社工手段拿下了這個關鍵人物，過程不可謂不曲折。
- 明確需求：Platform團隊並不交付業務價值，因此沒有BA(Business analyst業務分析師，通常扮演梳理需求的角色)，建卡的事基本都由IM和Dev來做，雖然感覺上是合理的，但實施起來卻遇到很多問題，究其根本就是對需求的定義和劃分不夠明確，導致最後挪卡的時候大家都說不準這張卡算不算完成了，只能用拍腦袋的方式來決定。
- 質量分析：同上，團隊缺少QA(Quality Assurance，質量工程師，測試人員)，Dev們都是自己做卡自己測，有時候會結對測試，但也會因為對需求理解不充分，或者說拆卡拆得有問題，導致一些卡完成得質量不夠，直接影響受依賴的卡。舉個例子，部署監控需要自動化指令碼的兩個模組支援，兩個模組被分為兩張卡，在做第一張卡的時候遇到了諸多問題，好不容易把程式碼提交到別人的版本庫裡了，在做第二張卡的時候卻發現第一張卡程式碼裡多寫了一對引號，導致整個邏輯實現失敗，這個時候再回過頭來改之前的程式碼，又要重新解決之前遇到的各種問題（溝通、許可權，PS：這個時候做第一張卡的人還下了專案），週期和浪費的工時是可想而知的。
- 人員輪崗：這是 IM 一直很頭疼的一件事，Platform團隊大量的時間花在給新來的團隊成員輸入上下文、同時又有成員離開團隊要交接工作、尤其在溝通重要的工作中，成員的離開意味著需要新的人重新和干係人建立聯絡，再者，一些成員因為專案上的痛點，不是很有心思工作在團隊的事務上，而是更關心自己過段時間會被分配到那個團隊，如此種種都對團隊的價值交付造成了很大的困擾。舉一個例子，有一個端到端測試工具一直由Platform團隊維護，從我加入Platform團隊開始，這個測試工具就打算新增一個整合遠端瀏覽器引擎的功能，這是一個非常有價值的功能，因為開發團隊長期苦於瀏覽器版本支援過少，端到端測試不穩定；但是在實現過程中一直存在一個網路問題，這張卡先後被關閉、開啟、標記完成、又重新開啟，經歷了大概五六個人的手，困擾我們的網路問題直到Platform團隊解散，都沒能解決。
- 關鍵角色管理：做了什麼很重要，有時候讓別人知道你做了什麼比做了什麼更重要。這一點在 Platform 團隊體現的得尤為明顯；在交付團隊中，開發如果發現資源不足，需要和TL(Tech Lead 或是Team Lead，可以理解為專案組長)或者PM(Production Manager 產品經理)溝通，如果缺少合適的彙報物件，一方面在團隊需要外部支援或更多資源（比如許可權）的時候得不到及時的支援，另一方面意味著團隊缺少了更高的視角來實時回顧自己做的事情是否是正確的，方向有沒有走偏，或者是不是又在造別人造過的輪子。我在團隊解散後的回顧會議中，IM還堅持認為我們團隊被解散是因為沒有一個強有力的領導在背後支援，這也從側面反映了我們沒有找到合適的彙報人，告訴他，我們在做什麼，聽他說，我們下一步可以做什麼。
分析
問題背後的原因及可能的改進方案
團隊解散後經過一段時間的沉澱，我針對以上痛點與過往的成員一一交談，瞭解了他們的想法，總結分析出了以下原因，以及可能的解決方案。
原因1：團隊方向不清晰
不同於交付業務價值的產品團隊，Platform團隊不對某一個具體的產品負責，也不直接產出業務價值，加上Platform團隊對交付的價值缺乏有效的指標度量，造成了團隊方向不清晰的狀況。
可能的改進方案：Platform 團隊應該是屬於架構師的一個機動團隊，在團隊方向不清晰的時候應該立即與利益相關者(Stakeholder)溝通，即與架構師取得聯絡，取得高視角的資源，最好能建立交付價值指標，比如Platform團隊的目標是加快持續交付，提高交付質量，那就視覺化開發團隊釋出週期、質量報告，讓每個團隊成員看到Platform團隊交付價值的體現，從而明確團隊方向。
原因2：團隊角色缺失
在架構師不能全權參與團隊工作的情況下（甚至Platform團隊還可能沒有IM），一幫Dev就很容易失去對團隊整體的感知，每個Dev只關心自己手裡的工作，迭代開始初期容易考慮不到全域性影響、不能準確建卡，迭代進行時因為沒有合適的彙報人因而跨團隊交流困難，迭代結束時沒有優質的回顧。 在Micromanagement Culture（微觀管理文化）中有一個Alignment(校準)和Autonomy(自治)兩個互斥的指標，我們使用這兩個指標作為向量構成四個象限，如下圖所示：
圖片來源：Spotify Engineering Culture
- 高校準、低自治的團隊由領導決定做什麼以及怎麼做，團隊只需要執行，這樣會形成“領導說什麼就是什麼”的局面；
- 而高校準且高自治的團隊是由領導指出要解決的問題以及原因，然後由團隊成員相互合作共同找到問題的解決方案；
- 低校準、低自治的團隊則缺乏活力，只能循規蹈矩；
- 而高自治、低校準的團隊成員可以做任何他們想做的事情，領導則很無助因為沒有人關心真正需要解決的問題。
在敏捷團隊中，如果團隊成員只剩下Dev，情形則很有可能變成圖中左下象限（也有些許右下）的情況，要想達到右上象限的期望狀態，需要提高自治，更多的是校準。
可能的改進方案：在意識到這個問題的時候，團隊需要一個關鍵人物出面充當領導者的角色，扮演這個角色的人必須關注團隊交付價值、目標和方向，並且有強大的溝通能力讓團隊成員目標一致；和利益相關者加強溝通，保證團隊方向不會跑偏。
根本原因
Platform團隊成立初期被定義為一個立意高遠（DevOps轉型）的組織，但是在專案實施過程中變得越來越邊緣化，其中有“人”的原因，有組織架構的原因，當然還有一些客觀原因。但我突然意識到這背後有一個原因一直忽視了，那就是——我們在實踐DevOps反模式。
國內近年來一直在對DevOps如何落地爭論不休，DevOps提倡的是打破開發和運維的部門牆，將開發和運維（的能力）放在一個團隊。然而國內大部分專案的現狀是，開發不具備運維技能和意識，也不願意做“背鍋俠”（要求開發做運維一定程度上犧牲了開發的利益，比如亞馬遜的開發每隔一週會被要求24小時On-call）。
因此一些公司選擇了在專案中先成立一個 “DevOps團隊” 作為過渡，再慢慢將CI/CD的理念和技能擴散到其他團隊，但是這種方式稍不注意就會變成“換了個名字的Ops ”，因為工作內容相似，寫指令碼、做高可用，這些是傳統運維也會做的事情，這種形式非常不利於團隊思維的轉變，“團隊整體對最終交付物負責”才是DevOps的精要，而不是把團隊按職責劃分（只對流程負責）。
這樣的要求無異是給專案成員增加了工作量和責任，對他們提出了更高的要求。然而很多職員不願意無回報地多揹負一些責任，比如說開發，誰不願意每天寫點程式碼一提交就早早回家，DevOps要求他們得看著新功能上線，確保無誤之後才能離開；所以DevOps的推行在產品團隊中是有阻力的，因此DevOps的成功不光需要團隊內部努力，也需要得到高層支援並掃除障礙。
反思
在一個不確定性多發的時代，快速的從成敗經驗中學習比找尋正確的路徑更加重要。——ThoughtWorks高階諮詢師顧宇
- 儘早找到關鍵角色，並且管理好利益相關人。這一點在一個扁平化組織裡往往是最容易被忽視的，在意識到要和 Stackholders(利益相關者)建立聯絡之前，Platform 團隊走了很多彎路，也錯失了很多機會。
- 讓事情發生比如何發生更重要。應該說在這5個月的工作中，我認為最有價值的是最後兩個迭代開始真正蒐集來自應用團隊的需求，開始在兩地組織各個團隊的 TL 開會蒐集痛點和解決方案。作為 Platform 團隊的一員，這件事其實我早就意識到會是非常有價值的，但始終沒有去做，總是顧慮不知道怎麼去開始、去推動，擔心TL 們提出的問題不能得到真正解決。但是最後這件事終於發生了，才意識到真的是非常有價值，而且早該這麼做了。關於這點在我還在 ThoughtWorks 試用期的時候我的 Buddy(由公司安排負責伴隨新員工渡過試用期的人) 給了我一個非常好的建議，就是決定在講一個分享之前先把日程表（邀請郵件）發出來，這種看似是“Deadline driven(截止日期驅動)”的方式，背後暗含了“這件事情必須發生”的道理，這和 MVP(Minumum viable product，產品原型) 的原理也是一樣的，先上線，再蒐集反饋，迭代改進；就算它是一個錯誤的行為，這也是一次有價值的試錯。
我們是否還需要DevOps團隊
結合我自身的經歷，“DevOps 團隊”應該是一次有價值的試錯，讓我看到了這種方式的一些弊端，應用開發團隊自身如果不具備產品思維，要由一個獨立的團隊去影響它們是很難的，這種實踐下的 DevOps 團隊就像是披著 DevOps 外衣的 Ops 團隊，不能產生理想的價值。
相比之下如果有一種自上而下的方式讓開發團隊基於已有業務基礎之上去優化交付流程，並對每一個提交的最終價值負責，將產品思維真正植入到開發團隊，從而達到全域性優化的效果，這種做法才更符合真正的 DevOps 精神。
（文／ThoughtWorks杜屹東）