阿里巴巴DevOps文化淺談 | 云效

 近些年DevOps火遍全國，似乎不說DevOps研發效率就是低下的，技能就是落伍的，然而真是這樣么？為了讓大家更好的了解DevOps文化，3月27日《云效說碼》分享特別邀請了阿里巴巴資深技術專家陳鑫（花名：神秀）進行視頻直播分享，聊聊他對DevOps的理解以及阿里巴巴的DevOps文化落地要訣，

【以下內容為分享實錄，有刪節】

DevOps發展的三個階段

首先我們簡單看一下什么是DevOps，這個詞從何而來，我在這里把DevOps發展歷史分為三個階段：誕生期、定義期和落地期，

DevOps的“祖師爺”是比利時一名獨立IT咨詢師Patrick Debois，2007年，他負責一個大型專案的測驗和驗證作業，一邊和開發對接測驗代碼，一邊和運維對接“發版”，他發現專案組里的開發和運維兩個角色的思維方式差異巨大，一邊希望“快快快”，一邊希望“穩穩穩”，這讓他有點崩潰，

在2008 Agile Conference大會上，Patrick遇到了Andrew，兩個人一拍即合，開始琢磨如何改變這種Dev和Ops水火不容的現狀，

2009 年 10月，Patrick 通過 Twitter 召集開發工程師和運維工程師在比利時根特市舉辦了首屆“DevOpsDays”大會，開始大規模討論Dev和Ops的協作話題，后來為了便于傳播“DevOpsDays”被縮寫為“DevOps”，

在2009年以后，DevOps開始火遍全球，2010 年，The Agile Admin博客發表文章《What is DevOps 》 ，詳細闡述了DevOps的定義，包括一系列價值觀、原則、方法、實踐以及對應的工具，

同樣是2010 年，《持續交付》的作者Jez Humble出席第二屆的 DevOpsDays 大會，并做了 “持續交付”的演講，這是非常重要的里程碑，可以說《持續交付》這本書就是DevOps的最佳實踐，以至于國內搞研發效能的同學人手一本，也正是這本書，加速了業界對DevOps的理解以及落地，

但我認為業界真正開始大規模落地DevOps，還是不能離開容器化技術的功勞，“Docker”起到了決定性作用，通過撰寫Dockerfile，第一次可以讓開發者輕松定義軟體運行環境，并且能通過CI/CD標準化流程去交付它，不過這么多容器運維起來仍然麻煩，于是google在2014年開源“k8s”（Kubernetes）；2015年CNCF（Cloud Native Computing Foundation 云原生計算基金會）成立，正式將“k8s”作為核心，建立了一個巨大的生態系統，有了“docker”和“k8s”技術上助力，加速了開發和運維角色的融合，于是DevOps不再是空中樓閣，

我距離DevOps有多遠

回顧完歷史，我們對照下自身，通過三個小問題來看看自己的團隊是不是已經是“DevOps”了，
1、我每次寫完代碼都可以部署生產環境，不需要別人幫助，
2、有很多監控、運維工具可以任我使用，輕松處理線上各種問題和故障，
3、我直接為線上用戶的體驗負責，不管是代碼缺陷還是運維故障，自己搞的自己背鍋，

以上我三個問題，其實分別涉及到了DevOps最重要的三個方面，做法、工具、文化，這三者缺一不可，

什么是好的DevOps團隊

什么是高效能研發團隊呢？我們可以參考《2018 DevOps現狀報告》里這張表格：能做到每小時1次或者每天1次部署，1天或1周能夠上線1個版本，服務恢復時間小于1天，變更失敗率小于15%，不過這個數字其實并不好看，以我們自己舉例，阿里巴巴研發平臺團隊，可以輕松做到1天多次發布生產，可用性99.95%，變更失敗率小于5%，

這些要求在阿里巴巴看起來稀疏平常，那阿里是怎么一步一步走過來的，我們其他企業應該如何復制這些經驗，讓我們進入下一節，阿里巴巴的DevOps文化落地要訣，

阿里巴巴DevOps的發展階段

DevOps的發展永遠離不開技術的變革，在2008年的時候，淘寶啟動了服務化改造的歷程，創造了Dubbo、Apache Alibaba RocketMQ、TDDL（Taobao Distributed Data Layer）等業界知名的中間件，同時淘寶的巨型應用被拆分，變成了下單、會員、優惠等一系列應用，而圍繞各個子業務場景更是誕生了成百上千個前臺應用，大家可以想象一下當時的開發是怎樣的，每周一個固定發布視窗，幾百位工程師在臨近發布時提交代碼、修改bug、提交測驗，在發布日晚上開始按照順序進行逐個發布，如果發布后出現重大bug，要么當場Hotfix（修補程式），要么回滾，宣告發布失敗，所有人都被發布日搞的筋疲力盡，第一代自動化發布工具的出現，將發布能力交還給了開發者，同時也迫使開發者去解耦應用依賴，做到獨立發布，業務交付速度得到了質的提升，后來大家給它起了一個名字，就是“微服務”，

沒過兩年，隨著研發人員越來越多，出現了各種復雜研發規范、各種復雜腳本、各種 “挖坑”“踩坑”等情況，讓研發工程師苦不堪言，“這一切必須規范起來”， 2013年時我們建立了統一構建部署平臺，將阿里巴巴集團從代碼變更到線上發布環節完全統一起來，進行嚴管控，

在2016年我們又遇到了新問題，當時線上操作需要運維同學統一來做，而運維同學天然不想去做變更，可以理解，什么都不改的情況下服務是最穩定的，可這在某種程度上限制了開發者的創新，而且明確的職責分工也限制了開發者去關注自己應用的線上狀態，這種情況，導致研發程序中出現明顯瓶頸，這也是為什么阿里巴巴要做DevOps的根本原因，隨著“容器化”的浪潮來臨，我們研發平臺再一次升級，將線上容器定義、運維監控責任全部交給了開發者，應用運維崗位不復存在，

而今天隨著云原生技術的逐步成熟，上云已經變成企業標配，圍繞云原生去定義下一代研發平臺成為必然，

綜上，技術的推動、組織的變化和研發工具的建設，這三者的有機結合才促成了我們阿里巴巴DevOps一步步走向成熟，

阿里巴巴DevOps落地的工具

前面介紹了宏觀上技術和平臺的發展，具體來看有以下幾個工具對阿里巴巴DevOps落地以及研發效能提升發揮了重大作用，

首先是DevOps平臺“云效”，大家常見的開源軟體Gitlab、Jenkins、Jira這些平臺也曾經是阿里巴巴的一個選擇，但是后來我們發現，純工具型別的軟體只能解決一些單點自動化問題，比如代碼管理、構建打包等等，其實在實際開發程序中還有很多作業無法自動化，比如需求流轉的規則，分支管理的規則，開發、測驗、運維溝通的模式等，這些作業我們可以統稱為“協作”，

要做好“協作能力”需要的是對人和流程以及效率有深刻的理解，并且將這些理解抽象成方法，最終做成產品，阿里巴巴通過數年積累，產出了眾多獨特的研發管理方法，比如Aone-flow代碼管理模式、測驗環境管理模式、 AGit-Flow代碼管理模式、雙十一分層專案管理模式等等，我們把這些研發管理方法都落地在云效平臺上，最后作用在人身上，潛移默化的影響著開發者協作的文化，也可以說是DevOps文化，

第二個是流量回放測驗技術，這項技術的創新給測驗團隊帶來了很大影響，通過線上流量復制到線下，低成本的解決了測驗回歸的問題，將傳統通過撰寫用例進行測驗，簡化為編排資料進行測驗，第二層是Mock技術的應用，將一個分布式系統問題，轉化為單機問題，可以在幾秒鐘完成上千個用例運行，有了這兩個基礎技術后，在上層可以發展測驗平臺，通過演算法的手段去識別有效流量，去自動化處理資料，去識別例外流量背后的缺陷，通過這三層面的變革，可以說讓阿里巴巴測驗效率有了質的變化，

第三個是全鏈路壓測技術（對應阿里云上的產品叫PTS），雙11大家之所以能放心剁手，一年比一年順滑，核心就是這項技術在每次大促前幫助開發者發現風險，發現以后就需要快速的回應，通過DevOps工具去解決線上問題，每次壓測都是一次練兵，有點類似于軍事演習，快速發現問題，快速解決，不斷錘煉團隊DevOps能力，也可以這樣說阿里巴巴的DevOps能力正是一次一次“雙11”給練出來的，

阿里巴巴DevOps核心理念：松管控和強卡點

當開發開始定義運維，接手運維的時候，我們管理者會不會有些擔憂，比如會不會開發任意操作導致線上故障，隨意發布導致穩定性問題等等，

阿里巴巴DevOps有一個核心理念是松管控和強卡點，

先看“松”在哪里？“松”是指我們有多種流水線可以供開發選擇，應用Owner可以完整定義這個應用的各種規則，比如如何發布，如何測驗，如何進行資源、環境配置等，我們有通用構建和自定義構建，可以給用戶最大自由度，最后是“輕發布，重恢復”，在每一個應用維度，開發可以隨時使用流水線來交付代碼，而并不需要特別的限制，僅僅需要思考的是如果出問題，我們應該如何快速恢復，

在足夠的自由度下，我們必須要設定一些“卡點”，比如代碼審核和質量紅線；代碼安全檢查、規約檢查；發布、封網視窗等，還有所謂“變更三板斧”：可灰度、可監控、可回滾，這些卡點是為了保障阿里巴巴集團所有開發工程師步調統一，交付合格的產品，

總結：DevOps核心是快速交付價值，給與開發最大自由度，負責開發和運維全部程序，在監控、故障防控工具，功能開關的配合下，可以在保障用戶體驗和快速交付價值之間找到平衡點，

阿里巴巴DevOps核心理念：以應用為中心

阿里巴巴是怎樣快速落地DevOps的？這里我要重點提的是：以應用為中心的DevOps理念，應用資訊其實可以歸納為CMDB中的一種資料，它對于研發人員天然是親切的，它可以直接對應一個服務，一個代碼庫，以代碼為起點，我們又可以串聯流水線、環境、測驗、資源，最外圍是工具鏈：監控、DB、運維、中間件等等，

用應用串聯整個工具鏈，可以讓開發人員很好的理解和打通DevOps整體程序，不會存在“開發說代碼、服務，運維說機器、機房”，這種雞同鴨講的情況出現，

當工具通過應用打通后，開發人員就可以順理成章的在平臺上定義它的應用，同時也在定義運維規則，比如，規劃環境、創建資源、設定發布策略等等，這些都可以由開發人員完成，

完成應用和運維定義后，“誰定義就要誰負責”，因此在阿里巴巴，開發人員需要為應用全生命周期負責，通過類似理念和運維工具自動化的推進，“Dev”潛移默化的接手了“Ops”的作業，這時，你會發現原來“DevOps”并沒有那么復雜，

享受DevOps紅利，成為精英交付團隊

通過我們前面提到的阿里巴巴在實踐中錘煉的DevOps工具，“松管控、強卡點”和“以應用為中心”的DevOps理念，阿里巴巴的DevOps得以落地，并獲取實實在在的效率紅利，它消除對個人的依賴，降低團隊之間的損耗，降低測驗成本提升質量，降低發布軟體風險，最終加快企業創新速度，讓阿里巴巴在一場一場機會中可以快速回應，

上圖是2018年我們發布的一些資料，首次提出了“211” 概念：85%以上的需求可以在兩周內交付；85%以上的需求可以在一周內開發完成；提交代碼后可以在1小時內完成發布，我也建議大家能夠以“211”來作為自己企業的效能目標，通過先進的DevOps工具、實踐和文化，三管齊下，帶來紅利，而不要為了做而做，

云時代帶來的新機會

通過前面對阿里巴巴DevOps發展的介紹，我們不難發現這樣一個回圈：我們在軟體研發程序中不斷的遇到新的問題，從而催生出新的技術（比如微服務、容器化）；然后新的技術又帶來了架構的變革（比如服務化、技術中臺）；最終形成了軟體研發的新模式，現在云原生技術來了，這項新技術能給我們帶來哪些機會呢？

云原生是什么？業界有各種各樣的解讀，有觀點認為：完全使用云來構建應用系統就是云原生，而從軟體研發的角度來看，我認為云原生帶來最大的變化是開發者僅需關注業務邏輯，從而帶來極大地效能提升，這是怎么做到的呢？我們對比下傳統應用和云原生應用，

在傳統軟體研發程序中，開發者的代碼會深度耦合中間件，需要關注服務發現、分庫分表、訊息處理等多方面，往下也同樣需要關注軟體部署在哪，需要多少容量，甚至還需要關注作業系統、存盤等問題，

在云原生時代會很不一樣，中間件核心能力會下沉到云基礎設施之中，一些常見的限流、降級、鑒權等能力都不需要關心了，資料庫、運行環境等都是動態伸縮的，常見的運維問題也不需要關心，只需要開發好代碼，通過軟體交付平臺自動化的發布到云端，

軟體開發的復雜度其實不會消失，而是換一種方式存在，云原生技術下這種復雜度會下沉到云基礎設施層，通過云去屏蔽這種復雜性，

那這種復雜性怎么解決，其中一個核心就是用資料去解決，在云原生下我們擁有業界統一的技術標準，比如中間件標準、容器標準等，擁有規范的資料和強大的基礎設施，也可以輕松獲取到這些資料，有了這些資料，我們就有機會去創造出各種智能工具，去解決我們軟體開發的復雜度，或者是通過工具幫助開發者作業，降低這種復雜度，

因此在云原生技術下，我們擁有了前所未有的智能的機會和貧訓的機會，

云原生時代影響開發者的三大技術體系

在云原生時代，我認為會有這三個技識訓給開發者帶全新的體驗，分別是開發態的CloudIDE、運行態的Service Mesh、以及運維態的Serverless技術，CloudIDE將開發環境搬到了云上，而且可以和研發平臺深度整合，為開發者提供極致的編程體驗，再也不用關心我在哪里開發，只要有瀏覽器，打開就可以編碼，

中間件在云時代會逐漸融入到Service Mesh技術下，服務路由、限流降級等開發者將不再關心，

Serverless技術，讓自動擴縮，容量評估變為歷史，開發者再也不關心機器在哪，

這三項技術將研發全鏈路云化，并且產生了大量研發資料、服務資料、運行時資料，阿里巴巴在最近幾年已經開始投入這些資料的挖掘和研究作業，并且和學界保持著密切的合作關系，

阿里巴巴正在探索的資料應用方向

簡單介紹一下我們目前正在探索的資料應用方向：在代碼方面，有代碼推薦、智能代碼評審、代碼搜索和優質代碼分享，在運維監控方面，我們投入了智能基線，能夠根據監控波動情況自動化報警，避免逐個配置規則，還有發布風險控制，通過識別變更前后監控異動來自動阻斷發布程序，還有自動化配置的業務全景監控，全鏈路洞察業務穩定性等，

下面我會通過兩個實體，深入細節，談一下我們在資料應用方面取得的成果，

代碼大資料的應用—PRECFIX缺陷監測技術

今年年初，PRECFIX代碼缺陷檢測技術(Patch Recommendation by Empirically Clustering)已經在阿里巴巴內部生產系統中上線，幫助開發者在代碼評審時發現缺陷，

智能化手段在缺陷檢測領域應用主要有三個難點：1）在沒有缺陷資料沉淀和公開資料集的情況下，如何標注資料？2）代碼是重邏輯形式語言，如何去表征代碼內容？3）如何通過非人工規則給出修復建議？

我們具體的做法是這樣的，首先通過資料挖掘手段標注疑似缺陷的commit，并提取相關統計特征進行學習，通過模型給出風險度評估，然后對缺陷commit的變更diff進行相似性代碼聚類，找出工程師常犯的錯誤，以及工程師常用的修復手段，當再次發生類似錯誤時，就可以給與開發者相對應的修復補丁，

運行時大資料的應用—無人值守發布

前面一個是“Dev”端的工具，下面介紹一個“Ops”端的工具：無人值守發布，

曾經，我們對所有線上故障做了分析，發現80%的故障都是由“變更”引起的，這也說明如果你不做“變更”，基本上不太會發生故障，因為代碼發布是線上變更的一個重要形式，所以要讓系統穩定、持續不斷地運行，就必須卡住發布這個口子，于是，我們做了 “無人值守發布”這個工具，它可以收集包括系統資料、日志資料、業務資料等，并對各種指標做檢查，通過演算法對比發布前后的指標異動，一旦發現問題，就可以對發布程序進行阻斷，甚至實作自動化回滾，有了這項技術，任何一個開發團隊，都可以安全的做好發布作業，運維團隊也不必擔心因為頻繁的線上變更而導致重大故障了，

阿里巴巴軟體研發平臺的未來：全新云效即將上市

綜上所述，“云”和“資料”是我們下一代軟體研發平臺最大的機會，這些資料智能工具雖好，但不能只給阿里巴巴來使用，更重要的是實作“云”的價值，也就是我們講的貧訓計算的價值，

因此今年我們會在阿里云上推出全新的DevOps工具平臺“阿里云·云效”，不但可以繼續為大家提供企業級一站式DevOps能力，還會將云原生能力、智能化能力融入其中，最近我們正在積極準備，敬請期待！有興趣的開發者也可以在云效用戶群（釘釘群號：23362009）中聯系我們，申請試用，謝謝大家，

【關于云效】

云效，企業級一站式DevOps平臺，源于阿里巴巴先進的研發理念和工程實踐，致力于成為數字企業的研發效能引擎！云效提供從“需求 ->開發->測驗->發布->運維->運營”端到端的在線協同服務和研發工具，通過人工智能、云原生技術的應用助力開發者提升研發效能，持續交付有效價值，

關于我們

了解更多關于云效DevOps的最新動態，可微信搜索關注【云效】公眾號；

福利：公眾號后臺回復【指南】，可獲得《阿里巴巴DevOps實踐指南》&《10倍研發效能提升案例集》；

看完覺得對您有所幫助別忘記點贊、收藏和關注呦；

原文鏈接：https://developer.aliyun.com/...

標籤：其他

上一篇：多分支集成發布各種坑怎么填？| 云效

下一篇：工業軟體技術的總結和開發方向