【以下内容為分享實錄，有删節】
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平台，源于阿裡巴巴先進的研發理念和工程實踐，緻力于成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->釋出->運維->營運”端到端的線上協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續傳遞有效價值。