作者：王梓城
前言
在11月25日舉辦的中國 DevOps 社區廣州峯會上，小鵝通效能平臺負責人王梓城（Prince）分享了其團隊從 0 到 1 建設 DevOps 體系的實踐經驗，贏得了在場聽衆的廣泛共鳴。
一、背景：
疫情期間小鵝通響應“停課不停學”的號召，帶着使命咬牙完成了產品交付；後續小鵝通在各行各業中被使用，隨之而來的是幸福的煩惱——業務需求的爆炸式增長，打亂了原本產研規劃的所有節奏，同時產研交付效率的問題變得尤爲突出，被用戶和業務部門反覆提及。
這時，產研能力的建設得到了重視，成立了一個新的團隊，專項解決產研交付效率的問題。
團隊成立之初僅 3 人，一邊忙着交接原有手上的業務，一邊摸索能效提升的解法。在逐步解決一個個現實問題過程中，從不太瞭解 DevOps，漸漸深入瞭解並走上了 DevOps 實踐的道路。
二、三個階段
小鵝通的 DevOps 實踐分爲三個階段：
1.第一階段：深入產研，初識 DevOps
效能團隊從原本的業務中心成立，起初只有 3 人，對業務情況也不是很清楚。帶着使命花了近 2 個月時間完成原有業務交接的同時深入瞭解原有的全局產研狀態。在開發 > 測試 > 運維、需求規劃 > 開發迭代 > 最終測試 > 發佈上線的整個過程中，瞭解到研發團隊爲了支持業務的快速迭代、減少測試驗證輪次，在開發環境驗證通過後，直接上線至預發佈環境驗證後全網發版。在這種模式下各個角色之間相互吐槽，印象中被反饋最多的直觀感受是 2 個字 ——“累”、“慢”；在產研側聽到過最多的2個詞則是“項目延期”與“四大金剛”。
項目延期：當時有 100+ 系統，系統之間高度耦合，且只有一套可供灰度驗證的環境，導致出現一個項目延期，後續全部延期。
四大金剛：迭代發版全靠 4 個運維兄弟手動支持，雖然當時運維有使用工具平臺，將發佈收歸腳本操作，但不同業務線的部署腳本五花八門，導致運維仍需要做一些編排的工作。運維人員疲於應付頻繁的發佈操作。疫情期間開發可以輪班，但運維不行。
於是我們明確優先解決 2 個核心問題：一是讓運維從頻繁手動發佈中解放出來，二是支持多灰度能力，解決單一鏈路的系統高耦合導致的連鎖反應的問題，畢竟架構上的事情並不能馬上解決。
說幹就幹！
一方面，通過建設發佈平臺，讓開發提交變更清單，運維只需要在發佈平臺進行簡單編排即可完成發佈和回退操作。同時結合運維平臺（藍鯨）能力，將服務粒度的部署腳本細化拆分成步驟和作業的方式。這樣，一個類型的服務就可以通過組合指定的步驟形成一類的部署能力，發佈平臺只需進行綁定關聯。
另一方面，通過 Nginx+Lua 的方式和目錄形式，實現了業務的多灰度環境部署，同時結合多灰度的方式建立大小車的迭代模型。
在解決這兩個問題的過程中，我們逐步意識到我們在做的事情和 DevOps 息息相關，開始深入去了解 DevOps 到底是個什麼，同時也開啓了我們 Devops 的第二階段。
2.第二階段：引入平臺，嘗試 DevOps
實施第一階段的同時，公司業務保持快速增長，團隊進入快速擴張的階段，原本迭代慢的問題，隨着人員的擴張和發佈能力建設，短暫的平靜一段時間後，很快新的問題隨之而來。產研人員增長在達到 800+ 時，我們發現人員的增長不但沒能帶來預期的迭代增速，反而讓整個產研變更混亂——協調溝通的聲音蓋過了鼠標鍵盤的聲音。
我們從每個產研角色那都聽到了不同的聲音——起初所有的問題似乎都被人力不足所替代，但當人力上來後，其他的問題也就被推到了檯面。這也再次證明了人力的增加並不一定有效提高產研能效。
由於業務架構的高耦合在迭代的過程中存在衝突，即使已支持多灰度，仍涉及較多的代碼合併操作，最終導致業務溝通和測試驗證工作激增。因此，大家希望業務重視架構設計，對已有不合理的耦合進行拆分解耦；而拆分後新服務的重新部署調試仍然需要運維參與。新服務部署後問題較多，影響項目交付。
此外，產品規劃、方案評審、線上應急流程的缺失，都會加劇迭代過程中的問題。
這時，我們開始嘗試用 DevOps 的方式解決問題。結合當時現狀，我們梳理了一個完整的 DevOps 架構圖，確定從 5 個不同的階段，結合建立標準化、流程化、自動化來解決現有的問題：
聯合產研各部門，明確開發、測試、部署規範
聯合項管、應急、客滿團隊，建立迭代、應急、安燈流程
業務側開始對沖突嚴重的系統進行解耦拆分
結合工具逐步完善自動化能力
這樣，就初步搭起了小鵝的 DevOps 架子：
規劃階段，使用單品項目管理工具建立需求管理、規劃流程。
開發階段，結合 Git flow 以及 gitlab ci-runner 的能力進行構建管理和代碼質量的掃描，與原有的發佈流程打通。
雖然通過基礎能力的建設和流程機制的完善，讓迭代和質量的問題有所改善，但從最終的效果上並不好。主要體現在由於工具割裂，不同的角色使用不同的工具，跨部門溝通效率仍然不高；而且多工具維護成本高；數據割裂，無法整體度量改進。
3.第三階段：全面容器，深入 DevOps
隨着 DevOps 工具鏈的接入，我們發現維護的成本較高，尤其是在大量併發的場景下，缺少經驗豐富的人員工具鏈的問題解決效率低，與此同時，原本一些免費的平臺逐步走向收費模式，這時我們希望引入一些商業化的平臺，來加快我們效果的產出。因此我們開始深入產品的調研。
另一方面，在基於 CVM 的部署架構上，環境管理、發佈變更、應急維護以及成本方面都有較多的訴求問題，全面容器化事項正式拉起。容器化本身對於產研團隊來說是個較大的挑戰，研發團隊很多都不太瞭解容器、Kubernetes 相關的知識，而且容器申明式部署和以往CVM有很大的不同。但我們認爲這可能會是一個比較好的機會，我們可以通過平臺降低掉雲原生相關技術的學習成本，讓研發人員幾乎可以像之前一樣使用平臺，而無須關注底層技術的實現，同時也將我們的 Devops 落地實踐結合起來，完善整體的能力建設。
與此同時，我們也重新迴歸到價值流的關注上。通過流程、平臺的建設完善整個發佈迭代的閉環。同時結合小鵝“客戶第一”的宗旨，未來將客戶也納入到價值環中，通過客戶對於交付的迭代進行評估價值點，以期望讓整個假置換能夠進入到一個正向循環中，以不斷的解決客戶問題爲核心。
因此第三階段的目標也逐漸清晰——結合容器化，徹底解決標準化的問題；同時深入實踐 DevOps 價值流。在這個階段，我們全面開始使用騰訊雲 CODING DevOps：
整合原有小鵝社區、單品項目管理中的需求/缺陷，統一收口遷移至 CODING 項目協同，利用 CODING 項目協同進行業務需求管理。
基於CODING 項目協同、代碼倉庫、代碼掃描、持續集成、製品倉庫的產品能力與小鵝通內部存量 Gitlab 倉庫管理進行整合，融入 K8S 集羣、Prometheus、CMDB 等企業內原有發佈系統。
最終，初步實現需求全生命週期端到端的安全交付管理，極大提升研發交付效率。未來也計劃基於 CODING 生態和內部系統整合實現持續運營能力的建設。
三、談漸進式擁抱 DevOps
1.爲什麼說要漸進式擁抱？
很多時候並不能快速像大廠一樣，具備較爲完善的基礎建設以及專業人才。我們在與各大廠商之間的溝通中，發現一個問題，依賴自頂向下的方式進行推進落地，但往往這種方式會較爲強硬，容易與業務部門產生隔閡和衝突。
從組織和文化層面來看，其實 DevOps 是一種文化和流程的變革，如果直接在現有的流程框架下去推行，不能把相關團隊之間的協作調動起來、不將整個過程貫通，最終無法推行下去。而實踐推廣過程往往週期較長，並非能夠快速看到效果。
2.如何漸進式擁抱
（1）尋找切入點：
先解決單部門的問題，如需求、項目管理，是研發管理中最核心的場景之一。由此引入項目協同的實踐，完善工具、平臺的能力；代碼集成、構建，是日常開發接觸的核心場景之一，由此引入 CI 流水線管理能力。
（2）DevOps 也好，工具能力也好，核心都是要爲解決業務問題服務。與業務配合，給予實踐的解決方案。
（3）DevOps 由於涉及到不同部門的協作，以及一些所謂 “ 最佳實踐 ” 的引入，會帶來一些具體工作方法、工具、習慣規約的變化等等，必然和舊秩序有很多不同的點，可能在框架和細節上產生變化，但未必是顛覆。所以如何適配、拋棄哪些、保留哪些、採納哪些、都需要反覆的磨合。
（4）在考慮 DevOps 實踐時，很容易陷入拿着錘子找釘子的困境中。尤其在和很多服務商溝通時，很多理念並不一定適合我們當前的團隊綜合能力。團隊需要一個自主靈活的能力？還是需要不用過多思考的規範？都需要考量！這也是是一個動態變化的過程，需要不斷平衡調整。
（5）在日常解決各個團隊問題的過程中，需要建立信任感，合理宣導 DevOps 相關理念，例如告訴開發在 DevOps 的理念中是如何看或解決這個問題的。在推動解決的時候，要從全局層面觸發，自頂向下推動落地。團隊文化的建設是 DevOps 實踐中相當重要的一環，也是作爲開發程序員不太擅長的一點，但我們作爲 DevOps 工程師，應該重視。
（6）DevOps 的核心理念是要關注價值流動，通過不斷的實踐、調整、迭代、循環往復完善，需要不斷在踐行中總結。
最後，在 DevOps 實踐中沒有拿來主義的【最佳實踐】，我們要時刻關注業務，所有的實踐都是爲業務服務的。
四、一些思考
插拔式能力：DevOps 在國內發展的今天，也越來越被大家重視，特別是在這幾年大環境的挑戰下，降本增效一再被提及，行業內開始關注一站式的 DevOps 能力，漸漸的有同質化的競爭。但每個企業各具差異，很難統一，大團隊流程相對完善，牽一髮動全身，決策成本高，其中有研發能力的團隊，可能會做很多定製化；小團隊對於價格敏感，同時一站式的完整理念不一定在適配當前的團隊現狀。因此建議廠商對某些場景或問題深入挖掘，具備插拔式能力來提供服務，從而降低實踐 DevOps 的成本。
DevOps 的願景：最近在讀《埃隆馬斯克傳》，其中馬斯克的想法讓我也有一些思考，對於 DevOps 的理解希望不僅僅是在我們的企業、團隊去時間落地，同時也希望通過社區的傳播讓 DevOps 的理念在國內能夠更好的傳播。目前大家都覺得國內的環境很卷，而且在創造價值的過程中因爲各種問題產生大量的內耗，最終對整個社會的價值創造低於原有預期，DevOps 的普及是否能夠去影響整體的環境呢？
拭目以待！
共勉！
