【以下內容為分享實錄，有刪節】
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）中聯繫我們，申請試用，謝謝大家。
【下期直播預告】
直播時間：4 月 10 日 19:00—20:00
直播主題：中小企業如何實現在家研發軟件
直播簡介：通過阿里云云效產品，演示多人多角色如何在線研發軟件，包括持續集成、持續交付等過程
講師介紹：焦霸，阿里巴巴研發協同平臺持續交付負責人，長期投入在CI/CD、DevOps領域建設
觀看方式：釘群直播（掃碼加入釘釘群：23362009）
【關於雲效】
雲效，企業級一站式DevOps平臺，源於阿里巴巴先進的研發理念和工程實踐，致力於成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->發佈->運維->運營”端到端的在線協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續交付有效價值。