摘要： 阿里持續(xù)交付平臺已經(jīng)經(jīng)歷了 8 年的不斷迭代進化，成長為集團幾萬應用所依賴的最重要的研發(fā)工具，它的效率直接影響著幾萬研發(fā)日常工作。但平臺不能只是工具的堆砌，更需要針對互聯(lián)網(wǎng)時代的研發(fā)模式進行深度思考，不斷打磨，將工程師文化和工程師實踐不斷地融入其中。

阿里持續(xù)交付平臺已經(jīng)經(jīng)歷了 8 年的不斷迭代進化，成長為集團幾萬應用所依賴的最重要的研發(fā)工具，它的效率直接影響著幾萬研發(fā)日常工作。但平臺不能只是工具的堆砌，更需要針對互聯(lián)網(wǎng)時代的研發(fā)模式進行深度思考，不斷打磨，將工程師文化和工程師實踐不斷地融入其中。輕管控重技術(shù)，使用業(yè)界上最新工程實踐，用技術(shù)的演進去解決技術(shù)人的效率問題。本次演講將介紹阿里持續(xù)交付工具的演化歷程和對互聯(lián)網(wǎng)行業(yè)交付領(lǐng)域熱點問題的思考實踐。

注：本文整理自阿里巴巴高級技術(shù)專家陳鑫（神秀）在 ArchSummit 全球架構(gòu)師峰會 2017 深圳站上的演講，原題為《互聯(lián)網(wǎng)時代的持續(xù)交付》。

寫在前面

大家好，我來自阿里巴巴，花名神秀，今天給大家?guī)淼?topic 是互聯(lián)網(wǎng)時代的持續(xù)交付。為什么在持續(xù)交付前面要強調(diào)互聯(lián)網(wǎng)？阿里的持續(xù)交付實踐有什么特別之處？希望我在這里能夠拋磚引玉，給大家?guī)硪稽c點收獲。

我在阿里負責持續(xù)交付平臺和研發(fā)工具鏈建設(shè)，以及將對應的能力通過阿里云輸出，我們對外的版本叫云效，公有云上目前正在公測中。

首先給大家介紹下今天的幾個主要內(nèi)容。

首先著重介紹一下阿里這些年持續(xù)交付工具上的演進和我們的建設(shè)思路。
然后會和大家一起探討一下互聯(lián)網(wǎng)企業(yè)產(chǎn)品快速演進下的一個重要話題：質(zhì)量和效率，介紹我們怎么看待這兩者之間的關(guān)系，以及如何協(xié)調(diào)。
再一個是我們正在面對的問題：交付和 devops，傳統(tǒng)軟件企業(yè)對交付肯定不陌生，但對于阿里場景下我們會有一些新的挑戰(zhàn)。Devops 方面介紹下我們最近一年的進展和一個小創(chuàng)新。
發(fā)展：持續(xù)交付在阿里

時間線

首先介紹下阿里持續(xù)交付平臺的發(fā)展歷程：第一階段2009 年我們做了一個簡單的自動化發(fā)布工具，來解決 SCM 和 PE 同學單點問題。在這之前可能很多企業(yè)都經(jīng)歷過這樣的過程，固定時間提交發(fā)布申請，配管同學開始統(tǒng)一凍結(jié)代碼打包，然后交給運維同學進行發(fā)布。在小團隊小企業(yè)時也勉強夠用。應用規(guī)模越來越大，線上環(huán)境越來越復雜時，配管和運維同學的能力和效率開始阻礙我們產(chǎn)品的發(fā)展。當然其中也有一些腐敗，比如要搭車緊急發(fā)布要請配管同學喝咖啡什么的。開個玩笑。

沒過兩年，研發(fā)人員越來越多，各種復雜研發(fā)規(guī)范，線上各種復雜腳本，各種新同學挖坑，后人踩坑苦不堪言。這一切必須規(guī)范起來，后來到了 2013 年我們把從代碼變更到線上發(fā)布完全統(tǒng)一了起來，通過統(tǒng)一構(gòu)建部署平臺進行嚴管控。

顯然這還遠遠不夠，到了 2016 年，平臺再度升級。上線了從需求到代碼，從交付到反饋的一站式平臺。項目、需求、代碼、構(gòu)建、測試、發(fā)布、流水線、輿情反饋等等等等，產(chǎn)品大圖基本完備。

在 2017 年，我們把這 8 年的平臺工具經(jīng)驗開放到了阿里云，也就是云效這個產(chǎn)品，希望通過阿里經(jīng)驗反哺云上生態(tài)，同時也依托廣大研發(fā)者的經(jīng)驗幫助我們工具成長。

工具與理念演進

說完了發(fā)展歷程，下面介紹下我們的工具和理念的演進過程，下面會針對這四點詳細展開。

第一是自動化，自動化是工具首先要完成的價值，也是效率提升的最直接的抓手。對于我們會先做好配置、代碼、測試、運維的自動化。
第二是標準化，標準化是工具平臺最大使命，比如亞馬遜經(jīng)常講到的Apollo環(huán)境部署工具就做的非常棒，阿里也有自己的研發(fā)標準和運維標準，研發(fā)標準中比如研發(fā)模式、技術(shù)棧、配置管理規(guī)范相對好做。運維域就相當困難，目前 web 應用、移動應用、搜索、系統(tǒng)基礎(chǔ)軟件等會自成體系，集團內(nèi)部和阿里云也會略有不同。但是隨著容器化和統(tǒng)一調(diào)度的推進，這些都有望統(tǒng)一。
第三是定制化，定制化應該是對平臺的更高要求，不同團隊，不同技能水平對工具天然就有不同的需求。我們不能因為管控而喪失靈活性，也不能因為照顧低水平技能而限制高水平。因此我們會首先按照團隊成熟度來推薦適合的交付過程和管理規(guī)范。
第四是一站式，當工具開始百花齊放時，對研發(fā)同學是有一定傷害的，不同的交互，不同的產(chǎn)品對接形態(tài)，不但會增加系統(tǒng)復雜度，也讓效率在平臺之間的流轉(zhuǎn)中降低。因此我們通過平臺工具融合，將需求到反饋的整條鏈路打通，在一個平臺完成基于價值的交付。

自動化一切

好，先看下我們的第一個理念：自動化一切。這張圖展示的是一個常見的研發(fā)過程，我們先從 master 拉出開發(fā)分支進行開發(fā)，合并成 release 分支進行發(fā)布，發(fā)布完成后合并到 master。應該每個研發(fā)團隊都有自己的一套規(guī)范來處理分支問題。當團隊規(guī)模越來越大，或者出現(xiàn)新人的時候，如何規(guī)范操作，提高協(xié)作效率，避免錯誤，那么就需要工具來承載這一切。

我們將常見的幾種研發(fā)模式：主干開發(fā)、分支開發(fā)、gitflow 等從拉分支開始，到 mergerequest、代碼合并、沖突解決全部白屏化解決，最終簡化成一個 pipeline，一個開發(fā)新手只需在平臺上操作就可以馬上融入研發(fā)工作而不會出現(xiàn)任何差錯。

標準化落地

再看關(guān)于標準化方面，工具層面主要完成了這幾個方面：應用創(chuàng)建、測試驗收、標準環(huán)境、上線卡點、部署過程。

一個應用對應一個代碼庫，一個服務單元，我們通過代碼推薦、技術(shù)棧模板對集團標準進行落地和迭代，比如 springboot 推廣。通過資源編排來快速完成基礎(chǔ)設(shè)施的申請搭建。

測試驗收方面集團規(guī)約和安全測試是這幾年主推的標準，已經(jīng)在全集團落地，代碼質(zhì)量得分則是通過數(shù)據(jù)度量的方式，客觀評測當前應用質(zhì)量情況。

標準環(huán)境是交付流水線和運維管控的基礎(chǔ)，通過容器化和統(tǒng)一調(diào)度現(xiàn)在可以比較容易的實現(xiàn)，第四點比較有意思。原來的工具思路往往是出現(xiàn)部署、資源問題，會引導用戶通過自動化工具自助解決，比如清理日志、重啟機器等。現(xiàn)在我們會更多的采用自愈的方式，把環(huán)境資源運維工作下沉到平臺無人干預式解決，用工具替代人。

上線卡點多是一些管控類需求，基于集團統(tǒng)一的管控策略來定，控制研發(fā)行為和質(zhì)量。

最后部署過程，發(fā)布策略、監(jiān)控、基線、回滾都是必備功能，我這里就不再贅述了。

定制化解決方案

要實現(xiàn)定制化，先看下解決方案的幾個因素：

團隊成熟度：規(guī)模如何，1-2 人，7 人，10 人以上？全棧還是有獨立測試運維團隊？質(zhì)量如何，是否有技術(shù)債務？團隊內(nèi)部有什么特別的規(guī)范約定？
迭代速度：每日隨時發(fā)？還是周期性交付？是否有窗口限制，從我們持續(xù)交付的角度，我們并不想對上線行為做過多約束，符合卡點應該即可上線，阿里現(xiàn)在核心應用基本都做到隨時發(fā)布，甚至一日多次發(fā)布。
BU 技術(shù)棧：各自 BU 的一些私貨規(guī)范，和個性化差異。雖然我們一直在建設(shè)統(tǒng)一基礎(chǔ)設(shè)施和研發(fā)運維平臺，仍然無法做到 100% 統(tǒng)一，是我們一直努力的方向
最后是集成交付：是否有產(chǎn)品集成需求，項目交付？或者專有云交付。比較典型的就是電商、移動端、阿里云三種形態(tài)。
由這四點因素我們推導出了幾種定制化方向：

研發(fā)模式：根據(jù)應用小規(guī)模團隊采用分支研發(fā)，共建型大團隊采用 gitflow，更加龐大的團隊采用主干開發(fā)模式。因為微服務設(shè)計的流行，現(xiàn)在應用的團隊規(guī)模越來越小，所以在阿里分支研發(fā)模式會更受歡迎。
技術(shù)棧：java、C++、腳本類等等，我們會采用代碼推薦和模板化的方式，幫助用戶一鍵創(chuàng)建代碼框架和編譯環(huán)境。
部署模板：常見的做法是軟件包模板和 Dockerfile。在阿里，很多 BU 架構(gòu)負責人和 PE 都會提供各種技術(shù)棧基礎(chǔ)鏡像，幫助普通研發(fā)者快速部署環(huán)境，類似這種的技術(shù)棧管控也同樣依靠工具來承載。
最后依靠多級 pipeline 來實現(xiàn)多種類型的交付過程，來滿足集成交付需求。

一站式平臺

大家現(xiàn)在看到的是目前阿里云效研發(fā)協(xié)同平臺的全貌，總體可以分為項目協(xié)作和持續(xù)交付兩大部分，交付部分形成了從需求到反饋的完整閉環(huán)，其中反饋部分不單單只有效能度量，還有針對業(yè)務本身的輿情分析和問卷調(diào)查，以及智能化客服工具。

工程師文化落地平臺

最后說一下我們建立平臺工具的最終目的，就是將工程師文化落地平臺。當然工程師文化是一個很虛的東西，每個企業(yè)都有自己的文化。包括阿里自己內(nèi)部淘系、B2B、阿里云等 BU 都有各自特點。不過總結(jié)下來會有以下四點：

質(zhì)量文化：質(zhì)量是持續(xù)交付的核心所在，團隊成長的必經(jīng)之路。沒有質(zhì)量的文化傳承，效率無從談起，代碼會很快腐爛，無人敢動，成為技術(shù)債務。更不要說快速迭代和持續(xù)交付了。
創(chuàng)新文化：作為研發(fā)中臺的我們，不可能也不必要成為所有工具創(chuàng)新、效率創(chuàng)新的來源。在阿里本身也有濃厚的創(chuàng)新文化，今天我們碰撞出一個 idea，明天就有一幫哥們把他變?yōu)橐粋€工具或者小產(chǎn)品。創(chuàng)新被人發(fā)現(xiàn)后還會快速的發(fā)展成一系列生態(tài)。這些事情每天都在發(fā)生，對于我們工具平臺來說，應該成為一個載體，將最優(yōu)秀的創(chuàng)新落地在平臺之上，促進相似產(chǎn)品的融合避免重復造輪子，也可以推廣引流，做強做大，形成正向循環(huán)。
全棧文化：現(xiàn)在都在講 devops，但沒有工具承載的 devops 基本上是空談，當我們平臺可以幫助 dev 自動完成 ops 工作，或者引導促進知識學習時，才能做到研發(fā)、測試、運維協(xié)作的無死角。
精益文化：這個才是我們一站式平臺的理念所在：基于價值的交付，基于數(shù)據(jù)的準確度量，幫助開發(fā)或者領(lǐng)導者評估產(chǎn)品價值和優(yōu)化團隊效率。
好，以上就是我們對阿里內(nèi)部研發(fā)工具建設(shè)上的一些實踐，希望能夠拋磚引玉，共同探討。

兩大挑戰(zhàn)：質(zhì)量和效率

接下來我們探討一個話題，質(zhì)量與效率，這可能是工程領(lǐng)域一個永恒的話題，我們今天就聚焦在互聯(lián)網(wǎng)場景下，我們的軟件怎么來解決既要又要還要的問題。

先看下在互聯(lián)網(wǎng)時代我們的一些挑戰(zhàn)：

當交付速度決定市場：我們 CTO 曾說過，研發(fā)工具要保障一個 idea 從誕生到上線在 2 周內(nèi)完成，快速試錯，不行就干掉，好了就拉一幫人做大做強。對于傳統(tǒng)研發(fā)方式來說，這似乎非常困難，但是卻真實發(fā)生了。

在這個前提下，我們的質(zhì)量效率將如何選擇？

開著飛機換引擎會成為常態(tài)？基于我們前面的假設(shè)，先占領(lǐng)市場，再不斷迭代優(yōu)化，基本已經(jīng)成為我們軟件研發(fā)的共識。現(xiàn)在如果有人說，我們是開著飛機換飛機，我可能都只能“呵呵”一聲，因為我們自己就經(jīng)常這么干，對吧。

持續(xù)集成面臨挑戰(zhàn)

再來看我們持續(xù)集成面臨的挑戰(zhàn)：

缺少測試覆蓋的持續(xù)集成成為負擔。當我們單測、API 測試做的不好的時候，通過流程強加的持續(xù)集成基本上是自欺欺人，要不就是不穩(wěn)定，要不就是沒效果。
測試團隊轉(zhuǎn)型，開發(fā)全棧導致的質(zhì)量下降。有這么多需求，沒時間寫測試，或者保姆式服務享受慣了，自己沒這個意識，等等等等。
測試環(huán)境互相依賴產(chǎn)生不穩(wěn)定因素，在阿里集成環(huán)境問題應該是研發(fā)過程中的一大痛點。
看了這么多問題，我們需要思考，除了推動完善測試，我們還能做什么？

從工具要效率

好，我今天要講的是，從工具要效率，質(zhì)量與效率并重。首先我們看下我們從哪里能獲得效率？

第一個快速反饋，我想對于效率我們首先能想到的詞是快，也就是快速反饋。加快構(gòu)建速度，加快回歸速度。
第二個是協(xié)作，因為往往溝通成本是程序員的一大開銷，而且咱們還不太擅長，對吧，經(jīng)常會發(fā)現(xiàn) IQ 和 EQ 成反比。因此降低協(xié)作成本，可以有效提升效率，比如分支開發(fā)模式，在線審核，移動辦公等等
第三個是創(chuàng)新，原有粗放型，人力型無法延續(xù)的時候，創(chuàng)新可能是唯一出路。比如雙引擎測試、mock 測試等等。
以上三點我會一一舉例來介紹。

協(xié)作成本

先來看一個協(xié)作的例子，分支開發(fā)和主干開發(fā)這兩種研發(fā)模式的對比。

所謂分支開發(fā)，就是所有人都在分支上進行編碼，比如需求，bug 等等，需要集成時合并到一個臨時 release 分支上進行打包發(fā)布，發(fā)布完成后合并到主干。

所謂主干開發(fā)，即開發(fā)者直接在主干上進行編碼，開發(fā)完成后立即提交主干，發(fā)布時采用最新主干代碼進行打包發(fā)布。

好，接下來我們看下兩種研發(fā)模式的對比：

首先看是否建立分支的區(qū)別。分支開發(fā)模式每個 feature 都建立分支，利于管控，看到分支馬上明白是做什么事情。主干模式直接提交主干，通過 commit 來區(qū)分。
第二點，分支研發(fā)需要多次集成合并 release，必然會產(chǎn)生重復沖突，集成后測試會導致測試反饋滯后。而主干開發(fā)則只需解決一次沖突可以做到提交后即集成。
第三點，當某個分支功能不想發(fā)布了，分支模式可以直接退出集成，需要發(fā)布的分支重新合并 release 即可。而主干開發(fā)往往采用特性開關(guān)方式 off 掉相應功能，因為代碼剝離比較困難。
第四點，當線上某次發(fā)布被回滾掉了，分支模式我們可以把主干進行回滾，下次 release 分支合并時即可自動回滾，防止錯誤代碼被重復發(fā)上線。而主干模式需要進行 hotfix，在此之前可能會 block 后續(xù)發(fā)布。
通過以上四個場景的對比，我們把相對利于協(xié)作的標為黑色，不利于的標為白色。可以看出分支模式似乎略勝，尤其是在第三點，基于功能分支的任意集成給研發(fā)同學提供了很高的自由度。我們實踐下來，通過工具化支持，在微服務人員分工明確，耦合較少和快速迭代的場景下，大大減輕了分支開發(fā)集成反饋滯后的弊端。

快速反饋

好，我們看下一個效率點：快速反饋。研發(fā)過程中，隨著測試用例逐漸積累，測試時間也隨之增長，執(zhí)行時間到 30 分鐘時我想應該都忍不了吧，幾杯咖啡都下肚了，測試還在跑好抓狂。這里我要介紹一個做的比較有意思的工具來達成快速的這個目標，我們叫他精準回歸。他有幾個特性：借助中間件全鏈路 trace 技術(shù)，建立測試用例與業(yè)務方法的關(guān)聯(lián)關(guān)系，當代碼變更時推薦需要執(zhí)行的用例，精準回歸，快速反饋。

架構(gòu)圖

來看下這張圖。首先我們通過 eagleeye，我們用于 tracing 的中間件插件，來對測試代碼和應用代碼進行打樁，注入 taceid。當測試用例執(zhí)行時，我們記錄測試用例到應用代碼的完整鏈路日志，也就是 eagleeye log，通過日志采集送入實時計算引擎，計算出測試代碼和應用方法之間的關(guān)聯(lián)關(guān)系。

打個比方，當我們掌握了一個測試用例覆蓋了哪些應用代碼后，當代碼發(fā)生變化后，自然知道有哪些用例可以覆蓋到他，這樣只要執(zhí)行這些用例就好了，幾十分鐘的測試時間縮短到幾分鐘甚至數(shù)秒，對于效率提升會非常巨大。

當然這個方案也不是一點瑕疵也沒有，在集成階段我們推薦運行完整用例集，不過這個沒關(guān)系，畢竟在開發(fā)階段測試運行的頻度要大于集成階段。

測試創(chuàng)新

先看三個問題：測試覆蓋不全怎么辦，寫測試用例尤其是好的用例需要大量時間。beta 測試會產(chǎn)生資損故障怎么處理，真實流量進入后，如果有 bug，肯定會導致一些問題，雖然影響小，但是也會導致一些不可彌補的問題。測試數(shù)據(jù)難以維護，經(jīng)常被污染怎么辦，這是一個復雜而頭疼的問題。

為了解決以上問題，天貓業(yè)務團隊誕生了一個叫雙引擎測試的平臺，通過線上數(shù)據(jù)采集，線下服務隔離，執(zhí)行重放和對比，自動完成回歸工作，輔助我們提高覆蓋率，大大提高效率。

架構(gòu)圖

大家可以看這張架構(gòu)圖，左邊是線上服務，首先通過 client 對線上請求進行采集，其中包括 request 和 response，以及下游系統(tǒng)，緩存、db 等等的調(diào)用鏈路快照。通過 mq 消息發(fā)送給 beta 環(huán)境的 client 進行回放。

這里就簡單進行回放請求就完成了么？顯然不是，該工具最核心的是對應用所有的下游依賴進行了隔離和 mock，比如應用發(fā)送給 db 一條 sql 查詢數(shù)據(jù)，雙引擎測試平臺會將這個請求阻斷，并返回線上同樣查詢的快照數(shù)據(jù)。最終拿到應用的 response 進行實時對比，存儲不一致結(jié)果。

通過這種機制，我們可以輕松實現(xiàn)線上請求，線下回放測試，debug，專注測試業(yè)務代碼本身，隔離依賴避免干擾。

在這個工具上面，我們還可以長出很多比如用例管理、失敗分析，離線回放等等產(chǎn)品，目前該平臺在阿里已經(jīng)形成了自己的生態(tài)圈，落地核心應用，并且保障了多次核心代碼的重構(gòu)升級工作。

交付挑戰(zhàn)與 DevOps 實踐

前面我們介紹了阿里持續(xù)交付過去的一些實踐，現(xiàn)在的質(zhì)量與效率挑戰(zhàn)，下面我會講一下我們當前正在做的和正在探索的兩個方向，交付和 devops。

國際化和私有云的轉(zhuǎn)變

說到交付這個話題，傳統(tǒng)企業(yè)一定不陌生，而且可以說是絕對的專家。現(xiàn)在阿里這樣的互聯(lián)網(wǎng)公司面臨著新的交付問題。當我們要把電商體系附能給合資公司怎么辦，我們要把基礎(chǔ)設(shè)施和完整阿里技術(shù)體系輸出該怎么辦，當我們應用巨多，形成網(wǎng)狀依賴以后怎么辦？聽著就是一個很龐大的事情是不是？

目前我們的兩個交付變化，從統(tǒng)一交付變?yōu)榉峙桓?#xff0c;比如我們先輸出電商中臺，再輸出電商上層業(yè)務應用。從整體交付變?yōu)榉謮K交付，當全部輸出后，要進行版本迭代，如此大的應用規(guī)模無法在做整體交付，此時就需要進行分塊交付。而且這個塊可能每次都會存在差異。這無疑對工具帶來了新的挑戰(zhàn)。

交付效率挑戰(zhàn)

我們接著說效率，我這里列了三點：

快速搭建：我們需要低成本的一鍵創(chuàng)建環(huán)境，復現(xiàn)問題，或者創(chuàng)建交付版本的集成測試環(huán)境。
測試回歸：當環(huán)境中存在多個版本服務怎么搞，而且怎么做到足夠得快
鏈路管理：交付的過程能不能做成一鍵式，交付的版本能否可視可控，避免交付風險。
下面我們針對以上三點舉例說明。

交付過程探索

在這里我把交付過程寫到了這個 pipeline 里，依賴識別，對比回歸，快速搭建，精準回歸，一鍵交付。

首先看依賴識別，為什么要做依賴識別，剛才提到了，當我的應用數(shù)量非常大，并且網(wǎng)狀依賴非常復雜時，讓人來識別依賴關(guān)系已經(jīng)不靠譜了。而且我要交付一個功能，如果牽一發(fā)動全身的讓所有關(guān)聯(lián)應用來次整體輸出，涉及的團隊太多基本也不可持續(xù)。因此一定要工具來完成自動的依賴識別。借助全鏈路調(diào)用數(shù)據(jù)完全可以做到這一點。

比如我修改了 A1 這個版本，通過鏈路數(shù)據(jù)結(jié)合交付端鏈路快照，發(fā)現(xiàn)必須順帶著交付 B1 和 C1 兩個版本，此時系統(tǒng)幫我圈定了一個交付集，后續(xù)的測試工作可以基于此來開展。

集成測試開始前，我們可以借助剛介紹的雙引擎測試平臺進行數(shù)據(jù)回放，對比測試，確認對交付端數(shù)據(jù)的影響。

集成測試

接下來我們將進入集成測試階段，首先是快速搭建，通過應用容器編排，基于中間件隔離，我們可以很輕松的將 A1、B1、C1 進行隔離，形成一個小的集成鏈路。通過精準回歸技術(shù)，對變更功能進行快速反饋。

一鍵交付

最后是一鍵交付，除了基本的版本管理能力以外，我還可以在集團環(huán)境直接管理交付端的環(huán)境，讓研發(fā)人員交付過程成本降到最低。同時在交付端，支持灰度發(fā)布能力，進一步減少交付風險。

最重要的還是有通暢的反饋渠道，依靠在前面介紹的平臺產(chǎn)品大圖上反饋模塊的豐富功能比如輿情、問答，我可以快速掌握交付端情況，采取必要措施。

好，以上就是我們針對目前新的交付問題的一些做法，歡迎各位與我深入探討。

DevOps 之路關(guān)鍵是工具

最后一個話題 devops，在這里我并不會詳細展開，只是講下我們這一年多來 devops 轉(zhuǎn)型的一些心得和一個小創(chuàng)新。

從 15 年開始提轉(zhuǎn)型，阿里集團去掉了大部分業(yè)務的 PE 團隊，交給開發(fā)，16 年我們建設(shè)統(tǒng)一調(diào)度平臺和落地 docker 容器技術(shù)，并完成了核心應用升級。17 年可能會是 devops 在阿里最輝煌的一年，今年我們會完成所有活躍應用的容器化和上下游完整工具鏈建設(shè)。

在這里我列了三點，首先對研發(fā)來說最基本的 ops 是什么，應用配置、環(huán)境、軟件基線，線上變更再加上流水線的管控。這是天天在用的。

這么復雜的一套在容器化之前我們做的并不好，當容器化開始落地后，我們的環(huán)境進一步標準化，實現(xiàn)了代碼驅(qū)動變更，管理工具大幅簡化。以前的基線工具，軟件包校驗工具，批量執(zhí)行工具都不需要了。并且通過配套調(diào)度系統(tǒng)，將環(huán)境資源真正交到了研發(fā)同學手里。

運維系統(tǒng)開始化繁為簡，服務下沉，自助型操作轉(zhuǎn)為自愈型，并且開始嘗試智能化解決方案。比如大促彈性調(diào)度。

DevOps 在阿里

看起來很美好是吧，實際上呢？不可否認，Ops 對開發(fā)者是有相當大挑戰(zhàn)的，尤其是相關(guān)運維基礎(chǔ)知識的缺失，解決問題能力的缺失。簡單地將 Ops 交給 Dev 就是 DevOps 了么？顯然不是，這不但對開發(fā)是一種傷害，還是一種效率低下的做法，以前 1000 個人能做的事情，現(xiàn)在需要 10000 個人來完成。

因此我們不能讓 DevOps 成為負擔，DevOps 機器人在路上。

DevOps 機器人

Devops 機器人實際上是基于數(shù)據(jù)的主動服務機器人，來隨時幫助開發(fā)者補充知識，解決問題，并且我們有一個機制來確保知識獲取的自閉環(huán)。

首先數(shù)據(jù)來自哪里？常見的，構(gòu)建錯誤，機器上錯誤日志，部署相關(guān)的，容器相關(guān)的等等。我們首先通過將這些收集起來，再配合用戶的行為，比如代碼變更 Diff，配置變更等等，保存在數(shù)據(jù)平臺中。

當我們有了數(shù)據(jù)以后，通過機器學習分析相關(guān)性配合人的積累，比如來自專家，工具運營，普通開發(fā)者的知識庫，形成規(guī)則。

當再次產(chǎn)生同樣問題時，系統(tǒng)會自動推薦相關(guān)解決方案，幫助開發(fā)者解決問題，同時收集反饋訓練模型。

通過我們的數(shù)據(jù)積累和問題廣場這樣的產(chǎn)品建設(shè)，形成問題出現(xiàn) =》方案推送 =》用戶反饋 =》知識貢獻的閉環(huán)。目前通過我們簡單的積累就已經(jīng)達到了 70% 以上的匹配率，未來通過閉環(huán)的知識訓練相信 devops 機器人會更加智能。

作者介紹

陳鑫（神秀），負責阿里云云效持續(xù)交付平臺和研發(fā)工具建設(shè)，致力于企業(yè)研發(fā)效率、產(chǎn)品質(zhì)量、DevOps 方向研究和探索。在阿里 6 年帶領(lǐng)過大數(shù)據(jù)測試團隊、測試工具研發(fā)團隊、持續(xù)交付平臺團隊。對研發(fā)協(xié)同、測試、交付、運維領(lǐng)域都有很深的見解。

總結(jié)

以上是生活随笔為你收集整理的承担集团数万应用、研发人员日常工作，阿里持续交付平台的设计、迭代之道...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。