崔立強：Dev無感Ops，如何作到高效軟件交付

在2018第二屆研發效能嘉年華上，阿里巴巴雲效技術專家崔力強帶來了如何作到高效軟件交付的精彩演講，首先介紹了阿里巴巴在近幾年在交付平臺上的技術經驗，以及目前雲上工具平臺交易的趨勢，其次分享了阿里巴巴內部交付平臺如何幫助咱們統一步調、並行工做，最後詳細講述了Dev無感Ops能夠解決DevOps遇到的一些問題。
數十款阿里雲產品限時折扣中，趕快點擊這裏，領券開始雲上實踐吧！
視頻觀看請點這
PPT下載請點這
如下爲精彩視頻內容整理：

阻礙開發者前進的問題
對於一個普通的工程師而言，第一要務是完成需求交付，咱們的最終訴求是保障編碼、測試、部署的高效。但實際發現咱們在交付的過程當中並不暢，研發流程的混亂常常出現代碼錯合，漏和，丟代碼的現象；質量化降低最主要是代碼有bug，線上環境交付不穩定，會有嚴重問題出現，測試環境不穩定指的是在作集成測試時需有一套環境，若環境不穩定，開發測試工做會被block；團隊之間溝通不順暢，開發和開發之間，開發和測試之間，沒有統一規則或流程約定；一堆開源工具攢出來的開發工具鏈，不但提升了學習成本，還致使過程數據沒法統一存儲。幾年前，幾乎都使用開源工具模式作持續交付，後續發現存在許多問題，因而開始作自建平臺過程。

上圖爲知名公司的一份統計數據，統計持續交付是否能幫助咱們提高研發效率，分別是瀑布模式、敏捷模式和持續交付模式，能夠看出在持續交付模式下，開發在設計、測試、部署上的時間比重大大減小，在真正作開發上的時間達到了80%。也便是說咱們更專一，更高效的在進行開發，從Waterfall到Agile的模式在研發階段效率高，主要是由於有更少的時間作設計、coding,而coding時產生核心價值的一個環節；從2-3餅圖開發時間更長，是由於咱們把交付時間壓縮。

如何作到持續交付有如下五點：
 1.需求的小批量流轉，經過拆分讓價值能夠快速的交付，減小集成成本，通常單個需求咱們不會超過1周。
 2.自動化一切，不單是測試和部署，運維也須要自動化。
 3.內建質量，儘早的測試能夠顯著下降測試成本，保障交付流水線通暢，加強環境穩定性。
 4.每一個人都爲交付過程負責，不僅僅編碼完成交給測試就ok了，要負責代碼上線，而且各項功能數據都正常纔算完成。
 5.研發過程數據，用戶反饋數據，對咱們有很是大的價值，能夠看到目前還有哪些坑阻礙着咱們前進。

團隊不一樣階段面臨的問題 
最初咱們團隊只有1-7人時，是在最敏捷的狀態，相似Jeff Bezos所說的two pizza team。按照目前微服務化的規模，應該有2-3個應用。這樣的團隊首先應該具有基本的CI能力和質量保障，確保本身的代碼在必定質量下持續迭代。至於發佈、運維並不必定是立刻須要面對的問題，一些紙面上的流程和腳本，足夠應付一陣子。

當團隊成長到7-20人時，咱們應該有了一個比較大的產品，有複雜的架構和持續成長的業務。10多個應用之間互相影響，互相阻塞會致使咱們線下開發和線上SLA面臨挑戰。此時一個統一的研發流程能夠幫助咱們規範開發行爲，再加上統一的質量標準，不會讓咱們集成環境和線上環境面臨較大風險。隨着應用增多，咱們也須要一些契約測試來確保服務兼容性。

當團隊成長到20-100人時，已是一個至關大的規模，咱們掌握着一個企業核心的產品，業務壓力和穩定性壓力像兩個小人不斷PK。如何在質量和效率上達到最佳平衡，是咱們要考慮的核心問題。應用規模達到了幾十個，已經不是簡單研發自動化能解決的了，此時須要一個統一的研發平臺，幫助解決從CI到CD的全鏈路問題，甚至包含全自動化的運維工具。產品、開發、測試、運維等角色能夠在一個平臺上高效協做。在2017年，已經有83%的企業開始使用雲計算來解決企業基礎設施問題和軟件交付問題。相比2016年出現爆發式增加，不難理解利用現成的通過驗證的可靠方案，能夠大大縮短企業達成高效率目標的路徑。幫助企業在市場競爭中得到先發優點。

統一步調、並行工做
阿里巴巴內部端到端的研發平臺包括項目協做、持續交付、應用運維、測試度量如下幾方面。用雲效首先能夠得到研發模式的標準化，咱們將其命名爲AoneFlow，這是目前應用最廣最適合阿里巴巴的分支管理模式，不但具備高度自由，快速迭代的特性，還能夠與CD流水線結合，讓整個公司具備統一的軟件交付規範。

上圖爲研發模式標準化-AoneFlow，將分支管理模式落地到產品層面，開發只要經過平臺新建特性分支，checkout push代碼，後續合併上線全過程所有由平臺接管，不但可讓開發者協做變的很是簡單，高效，永不出錯，並且在研發流程中能夠加入自由配置的預設規則，好比何時合併代碼，須要達到什麼樣的標準，codereview 安全是否經過，發佈分支怎麼處理，等等像樂高積木通常定義本身的研發流程。

將繁瑣的易出錯的事情留給平臺，實現研發模式全自動化。真正的作到了研發過程全上平臺，全部數據可追蹤，而且完全杜絕了漏發、錯合、管理混亂的狀況。讓開發專心價值交付，是雲效首先要解決的問題。
持續交付核心是快速交付價值，給與開發最大自由度，負責開發和運維所有過程。在監控、故障防控工具，功能開關的配合下，能夠在保障用戶體驗和快速交付價值之間找到平衡點。

Dev無感Ops
Ops自身複雜由繁雜重複性的工做，Dev能夠很輕易作Ops，是Dev感受不到Ops的存在，Ops真正出現問題時，平臺會通知Dev處理問題，最後幫助團隊作度量。首先介紹阿里巴巴內部是以應用爲中心DevOps理念使用來應用串聯整個DevOps工具鏈、開發定義應用，同時定義運維、開發爲應用全生命週期負責、系統自動完成應用運維配置。

所以咱們一直在推進標準化，智能化，無感的Ops體系建設。目前在研發端咱們的三個實踐第一個是無人值守發佈，衆作周知絕大部分的故障來自於變動，變動的絕大部分又來自於發佈，如何保障每次發佈都是對用戶無影響的，如何用系統代替人來關注龐雜繁瑣的運維指標。去年咱們應用運維產品推出了無人值守發佈功能，它使用人工智能的方法，計算髮布過程當中監控指標、日誌數據、用戶數據等等多重維度的變化，預判可能出現的風險，警告用戶或者觸發回滾，保障發佈過程無人蔘與。最終避免了90%的發佈故障。第二個是應用健康檢查，一樣咱們用大數據，人工智能的辦法，獲取多重運維數據，來幫助開發同窗發現目前應用存在的風險，進行一鍵修復，有點相似你們電腦裏的360管家。不須要有多少經驗，人人均可以成爲運維專家。最後是應用自愈，咱們將運維工具和經驗沉澱到了這個產品，對一些場景和問題進行自動修復和調整，達到無人蔘與的目的。這就是咱們無感Ops的目標。

截圖來自阿里云云效研發的某過程
上圖爲全雲端構建，加速研發過程，雲效徹底自研的全雲化構建調度系統，已經能夠支持全部語言構建，擁有通過阿里雲安全團隊承認的安全加固機制。而且根據不一樣技術棧提供了自適應的構建緩存策略，避免依賴的重複下載，大大節約構建時間，提升開發過程效率。開發在使用雲效只須要選擇他的技術棧和構建命令，其餘均可以交給平臺自動化完成。

雲效目前支持阿里雲容器服務、edas、ecs三種部署方式，對每一個應用的每一個環境均可單獨定義它的部署方式，而且實現任意切換。好比咱們生產環境使用edas保障穩定，測試環境使用ecs混合部署節省資源都是能夠實現的，很是方便。

在咱們作運維棧轉型升級的時候，能夠經過修改部署配置進行平滑升級，若是有問題，咱們還能夠實現一鍵回滾。雲效保存着歷史全部軟件發佈升級的基線數據隨時可查，隨時可rollback，這些都是阿里巴巴內部多年經驗的積累實踐。

在運維方面，咱們支持了經過ECS模板快速擴容，而且在雲市場也上線了雲效推薦鏡像，直接能夠得到和阿里巴巴一致的運維標準。最後是基於特性分支的測試環境管理功能，支持環境隔離能力，具備生命週期管理功能，讓每一個開發均可以享受到獨立的研發環境，並行工做，高效交付。以上功能均可以在阿里云云效幫助中得到詳細操做指南。

原文連接