分享實錄 | 阿里巴巴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」了。
一、我每次寫完代碼均可以部署生產環境，不須要別人幫助。
二、有不少監控、運維工具能夠任我使用，輕鬆處理線上各類問題和故障。
三、我直接爲線上用戶的體驗負責，無論是代碼缺陷仍是運維故障，本身搞的本身背鍋。

以上我三個問題，其實分別涉及到了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）中聯繫咱們，申請試用，謝謝你們。

---

【下期直播預告】
直播時間：4 月 10 日 19:00—20:00
直播主題：中小企業如何實如今家研發軟件
直播簡介：經過阿里云云效產品，演示多人多角色如何在線研發軟件，包括持續集成、持續交付等過程
講師介紹：焦霸，阿里巴巴研發協同平臺持續交付負責人，長期投入在CI/CD、DevOps領域建設
觀看方式：釘羣直播（掃碼加入釘釘羣：23362009）

---

【關於雲效】 雲效，企業級一站式DevOps平臺，源於阿里巴巴先進的研發理念和工程實踐，致力於成爲數字企業的研發效能引擎！雲效提供從「需求 ->開發->測試->發佈->運維->運營」端到端的在線協同服務和研發工具，經過人工智能、雲原生技術的應用助力開發者提高研發效能，持續交付有效價值。