互聯網研發效能之去哪兒網(Qunar)核心領域DevOps落地實踐
本文從業務目標角度出發，確定了開源+自建模式搭建 Qunar 研發工具鏈整體生態；通過 APPCODE 打通工具鏈，流程規範化自動化；多種手段+發布門禁助力品質提升；建立應用畫像確定運維最小單元，可發布可運維；最後通過流水線加速整個流程更順暢高效。
本文根據張春芳老師在〖deeplus直播：逆襲生產力擔當，雲原生時代的運維新歸宿〗線上分享演講內容整理而成。我自己為了消化裡邊的內容，整理了一個腦圖，各位可以把圖片列印下來對照著看，這樣幫助更大，另外以後翻到這篇文章通過這個腦圖也能大概了解主要內容。原文標題《去哪兒網核心領域DevOps落地實踐》
張春芳，去哪兒網 系統運維總監，2014年加入去哪兒網，就職於基礎研發基礎平台組，近來一直致力於整個公司研發體系的標準化及效率提升，涉及開發、測試、運維等多個領域。目前主要負責全公司的DevOps生態體系建設，為業務交付的速度和品質提供保障。
今天的分享主要包含以下幾個方面的內容：
一．Qunar devops生態概覽
1、項目流程
看我們生態之前，大家先看一下我們的整個項目流程。
在整個項目流程中，首先是業務，我們做DevOps的時候一定要從業務目標出發，業務人員先去確定業務目標，然後進行產品的規劃，規劃完成之後進行產品的設計。設計拆分成具體的功能，功能對應我們的需求。在需求出來之後，我們進行敏捷開發。開發完成後進行集成測試驗證，最終發布運維上線。我們DevOps其實主要是致力於為產品設計到發布運維這一過程提供支援，完成服務目標。整個過程也是我們項目管理的過程。
2、目標和方法
基於整個項目流程，我們看一下我們DevOps的目標和方法。
這個目標和方法我借鑒了百度工程能力的定義：工程能力是使用系統化的方法，在保證品質的前提下，更高效率地為客戶/用戶持續交付有價值的軟體和服務的能力。其中有幾個關鍵詞，首先它是系統化的方法，對應去哪兒我們這麼拆解系統化的方法。
首先要有流程規範，因為有了流程規範，具體的一些落地才有章可循，而不是做各種單獨的一些場景化支援。有了流程規範，我們去落地，先落地到我們的工具平台，這一層落地工具平台都是先做一些普適性的工具。但普適性的工具雖然對所有的場景都支援，但也存在對真正具體的一個場景化支援不流暢的問題，因此我們拆分出具體的場景化實踐。遵循這一閉環，我們來建立我們DevOps的生態。
有了方法之後，我們的目標是什麼呢？當然是提升交付速度。但是在提升交付速度的過程中，我們又必須保障品質，所以我們的兩大核心目標就是提升交付速度和保證交付品質。
基於以上的目標和方法，我們落地了DevOps生態。
3、完整生態
首先看一下完整的流程。
貫穿全部流程的是項目管理。在上層，我們根據不同的域進行了拆分，可拆分為開發、測試、上線和運維。
- 開發部分包括的內容就是應用註冊、程式碼管理、sonar、Cr等。
- 測試部分包括缺陷管理、case介面、測試性能、介面測試和程式碼覆蓋率。
- 上線包括發布步驟編排、產物管理、回滾管理、負載均衡等。
- 運維包括監控、日誌、事件、報警等。
上圖右方是我們的一些公共服務，底層的資源是KVM跟k8s。整個過程我們也遵循雲原生的基本原則，開源與自建結合。圖中藍色部分是使用開源的，黃色部分在使用開源的基礎上進行了二次開發，紅色部分完全由我們自建。
生態是以是以唯一的管理單元——APPCODE串聯的，APPCODE是指應用的唯一標識，因為有了APPCODE，才會使我們整個過程可追蹤，數據可追溯，服務可運維。所以APPCODE是我們非常核心的要素，建立生態的關鍵。
4、效果
建立生態之後，看一下我們現在基於生態實現的效果。
這幾個數字是基於月均的數字統計。我們現在每月平均有3000＋項目發布，15萬次＋部署，涉及到2000＋應用，1000＋開發測試運維。由此來看，我們的體量還是相當龐大的。
值得一提的是，在這3000＋的項目發布中，有很大一部分是開發自測自發，即完全沒有測試人員的參與。這完全依賴於我們 DevOps生態建設對開發測試進行賦能，也因此，我們的開發同學自測自發不僅保證了品質，同時也保證了我們的交付速度。
二.核心領域實踐
在了解我們的生態之後，下面來具體地看一下我們在一些核心領域的落地實踐。
1、規範化助力開發提效
上述分享的方法論中有一步很關鍵，那就是規範流程。那麼規範流程有什麼意義呢？
1）背景
下面我們來看一個具體的案例，看它如何助力我們的開發提效。
在我們公司，可能其他公司也相同，在開發項目過程中一個核心資源就是開發資源，我們的理想狀態就是要實現開發資源利用最大化，理想狀態就是開發人員只需專心投入寫程式碼即可。
但是現實情況是開發同學被各種角色干擾。主要有以下幾個問題。
- 對開發來說，頻繁的被打擾導致其時間碎片化，在各種任務之間切換導致效率無法保證。
- 對項目經理來說，無法得知項目的實時進度，項目是在開發過程中，還是在測試過程中。因此只能去跟開發進行去人為溝通，這不僅導致了開發被打斷，也使項目經理無法掌控整個項目過程。
- 對QA來說， QA最終要為品質負責，但是QA不知道項目的這次需求變更了什麼內容，這就會導致變更靠人為的梳理很容易被遺漏，從而導致上線出故障。我們有很多血淋淋的教訓，因為沒有更新DB，或者是一個配置忘記更新了，上線出現過很多次故障。
- 對PMO來說，PMO要收集整個項目過程的數據，通過數據去確定我們的改進優化分析，分析優化改進。但現在我們項目的所有數據全都依賴人工去填寫，很難保證數據的準確性，從而給改進優化帶來困難。
通過上述分析，我們可以發現，我們對於整個過程的跟蹤是基於項目去跟蹤的，但是這個項目變更的內容又是應用維度的，所以導致我們沒有辦法被跟蹤，人為操作多。核心問題就是我們的應用跟項目沒有建立關聯關係，所以我們要去建立這一關係，從而解決這個過程中的問題。
2）方案
那如何建立關係？依靠規範化。看看我們是怎麼做的。
① 分支命名規範化
我們對分支進行了命名規範的要求，分支名必須包含一個PMO標識。這樣當分支被創建、被push的時候，就自動將其關聯到項目上面，建立了應用跟項目的關聯關係。
② 品質檢查可視化
知道了項目變更了哪些內容，變更的時候每次提交都可以去自動的觸發一些相應的檢查，相應的檢查結果報告就可以展示在這個項目上面。對於QA人員來說，可以直觀的了解項目當前的品質狀況；對於項目經理來說，可以比較直觀地了解這個項目的狀況，從而去控制風險。
③ 數據回填自動化
對於PMO來說，之前很多數據難以收集，有了關聯關係之後，我們會把這一次項目的發布數據，包括發布的次數，以及變更的行數等都自動回填，相當於獲取了這個項目整體的變更數據。
④ 狀態流轉智慧化
因為我的程式碼已經跟它關聯起來了，在開發中如果是提交到程式碼，可以自動從項目已排期狀態變成開發狀態。當我做了一些Beta驗證的時候，就可以自動地流轉到我現在是要提測了或是要發布了，所以這個狀態的流轉實現了智慧化。結合完整的方案，我們就解決了各種開發被打斷，自動化手動操作過多的問題。
這個是我們的架構。
相當於開發與應用關聯的工具，我們內部把它叫做Qodin，底層是DB，Cache，其次是我們的數據存儲，然後各個工具平台會把自己執行的一些結果通過發送消息推送到我們的消息平台。Qodin通過消費這些消息，通過外部的HTTP介面觸發各種工具平台去執行。上層是我們通過js一些頁面給用戶提供一些查看入口、操作入口等等。
3）效果
下面再來看一下我們實現的效果。
上圖是我們的一個項目，我們可以看到這個項目中到底變更了哪些內容，首先是變更的一些品質的情況，以及它的發布情況。其次是我們自動回填的數據，可以看到包括研發階段的市場自動計算，項目總市場等，線上發布的次數，程式碼變更的一些資訊，同時我們在一些項目的關鍵節點，根據時間計算關鍵節點的狀態流轉以及是否delay，這些都會有一個及時的項目提醒，這樣保證了開發和項目經理等都可以及時地關注到整個項目過程，一旦有任何風險也可以及時地暴露出來。
總結這一實踐，主要是通過規範化確定一個分支的命名規範來實現我們的應用跟項目的關聯，然後保證了我們項目整個流程的自動化與高效。
2、多種手段+發布門禁助力品質保證
我們再來看一下速度有保證後如何保證品質，這就是我們的第二個實踐，通過多種手段和發布門禁助力品質保證。
1）背景
我們先看一下理想，理想的狀態是開發修改完程式碼之後，通過測試，提交給QA，然後QA同學集成測試，最後愉快地上線。但實際中常常會出現開發跟測試同學的相互抱怨。
開發人員表示我測了。QA人員卻說你這提交的是什麼，你自己測了沒有？
QA人員常說為什麼我測試了，到上線還是會遇到問題，其實總結起來主要是以下問題：
- 對開發人員來說，首先測試條件是難保障的。開發人員做測試的時候，其實有環境的依賴，也有數據的依賴，有一些前提條件的準備。但是這些常常會特別耗時間，準備也非常困難，導致測試不足的問題。其次修復成本高，因為開發人員在前期的測試不足，提交給QA人員之後，通過QA人員發現了問題，然後再回饋給開發人員，回饋的周期就拉長了。開發人員這時可能已經進入到其他項目了，從而又有一個切換成本。
- 對QA人員來說，沒有辦法讓開發保證提測的品質，更多的是依賴於自己的測試，對其來說非常不友好。還有上線的品質也難以保證，很多其實我測到了，但是可能依舊帶著問題上線了。
2）方案
所以該如何避免上述情況呢？來看一下我們的實踐。
① 多種手段保證效果
首先我們採用的第一個方法是先用多種手段保證效果。我們的手段包含以下幾種：
- 程式碼review（code review），即人工的review，現在我們公司已經建立起了較好的code review文化，大家都已經形成了這種習慣。
- 靜態程式碼檢查sonar，這個地方sonar不只是sonar，在我們公司的話，主要技術棧是Java，所以我們會在 Sonar裡邊會做一些java規則的檢查，比如說非法的包名、重複類、然後依賴多版本等檢查，同時也會把一些原數據的資訊記錄下來，例如記錄變更的內容，變更的依賴等。除此之外也會做sonar本身的一些規則級檢查，我們這個規則也會定期做review。
- 介面自動化，介面自動化我們分了兩部分，第一部分是我們的線上回歸測試，所用回歸的工具我們叫滅霸，它會在每次開發提測時自動執行，把線上現在存量的一些介面做回歸驗證。如果你是新增的業務介面的話，我們也會有一個自動化測試平台叫Qunit，它是基於unit的，去做一個新的業務的驗證。
- 程式碼覆蓋率檢查，我們sonarqube等各種的自動化工具，都可以看到當前的測試的覆蓋度。測試覆蓋度這塊大家其實一直有一個疑問，那就是我測試的時候就是程式碼百分百覆蓋，也不能保證上線完全沒有問題。但是反向也有另外一種說法，起碼百分之百覆蓋了，還是會增加一定程度信心的，所以覆蓋率是非常重要的。
② 環境管理提升測試速度
手段多樣是有前提保證的，尤其介面自動化有環境依賴，如果沒有環境做介面自動化或者沒有這個環境管理，介面自動化、執行介面自動化的可行性或速度都是沒有辦法保證的，所以我們又有一個環境管理平台，通過這個環境管理，我們可以快速的交付一套環境，這個環境中包括了自己的應用以及它的依賴，為自動化的可行性提供了保障。
③ 報告消息回饋結果
自動化的可行性有了，多種手段也有了，最後的這些報告資訊怎麼通知給開發人員？我們做了多維度的報告展示，包括項目維度，個人維度，還有組織維度等，同時我們也會通過內部的Im消息精準的通知到具體的開發人員，這樣方便他可以快速地解決問題，相當於品質阻力左移，降低了問題修復的成本。
④ 品質門徑預防蔓延
我們會結合我們的項目管理系統、發布系統等去做品質卡點，如果不通過，我們就會去做一個攔截，然後避免帶著問題上線。
上面說了我們具體的方案，下面讓我們簡單地看一下多種手段，我覺得在現在這個階段，大部分公司都會有這幾方面的保證，我這個地方只簡單介紹我們公司的一些特色點。
- 在CodeReview方面，我們是基於開源工具phabricator實現的，我們會做到分支創建後自動同步倉庫，同時程式碼push的時候自動去創建更新diff，這樣就避免了人工去創建以及後續操作。同時我們支援兩次提交diff的變更，這是為了解決發現問題並修改重複提交後的全量diff問題。不需要全量的再次diff，只需要看這兩側的一個變更。當然如果影響範圍較大的話，還是建議全量的再diff一次。
- 靜態程式碼檢查方面，我們使用業界通用的sonarqube，但我們的特色點是程式碼push的時候它會自動執行，然後消息回饋。同時我們有增量跟全量的報告。我們有很多歷史在的基礎上，如果你要求它去全量的解決問題，這在業務非常繁忙的時候是不現實的，所以我們做了增量，只去檢查當前這次變更引入的問題，只要解決了這些問題並能夠保證不新增，後續再去慢慢地解決全量問題。
- 介面自動化方面，介面自動化這裡我講的是滅霸即介面回歸問題，介面自動化大家最頭疼的就是要自己去寫case，業務變動又比較頻繁。我們的時間點是怎麼做的？我們會基於檢查點的case自動生成補全清理。例如航司，航空公司是有很多公司的，比如說南航、國航、川航等，相當於每一個航空公司對應一個業務，我可能就要對這一個類型去進行驗證，所以我們需要用戶先定義一個檢查點維度，然後業務在線上執行的時候，會去生成日誌，我們通過日誌去採集這些具體的case，再生成補全。當過了一段時間，如果檢查點沒有這種業務的case請求了，我們就可以自動清理，這就解決了我們人工維護case的一個痛點。
- 程式碼覆蓋率是基於Jacoco實現的，也是增量跟全量的一個報告，可以看這次變更的一個覆蓋率情況。
上述是多種手段，下面看一下我們的測試環境。
我們對環境的定義是什麼？這個環境肯定不是單應用的環境，這種單應用的環境是對於整個業務的測試，它起到的作用是非常薄弱的。所以我們對環境的定義是支援一種業務測試，能支援一種業務測試的應用去依賴以及它所用的資源的一個組合。所以我們環境的組成就包括AppCode、數據存儲、中間件、網路配置、環境變數等。
環境有了，但是不可能每次進行一個業務測試或項目測試的時候，都去重新搭建一套環境，這樣成本是非常高的。我們之前去做項目復盤時，對於delay項目大家吐槽最多的是為什麼delay？是因為環境問題。所以我們把環境的這些資訊做成了模板可配置，這樣就實現了資源與資訊的積累沉澱。
其次是業務巡檢。開發同學、測試同學只是去使用提供的環境，服務提供方要保證可用性，讓開發同學只是去用它，而不是再去為它的可靠性分擔精力，所以我們有業務巡檢。
我們之前創建一套環境後就實現了完全的資源隔離，相當於有一套環境給全部的應用分配資源，這是對於資源的極大浪費，同時創建速度也很低，所以我們又做了一個軟路由環境，基準環境跟項目環境。
下面我們通過下圖來詳細解說。
- 首先是環境創建的流程，上圖中我們可以看到我們包含了環境，即應用及其依賴，所以我們會先鎖定資源，包括Kvm、 DB這些東西，然後再進行採集編排，然後去觸發任務執行，調度執行。
- 其次是業務巡檢，我們會定期去調用業務線提供的一些全鏈路測試case，定期去執行，驗證這個環境的可靠性。同時我們也會去消費一些變更消息，包括配置變更、程式碼變更、數據變更，去同步這個環境，這樣就保證了我們基礎環境的自運維。
- 然後是軟路由，我們會有一套基準環境，是全鏈路的，包含了全部的應用，但是對於項目來說，只需要建環境值，包含自己變更的這些應用以及它的一些DB依賴。在真正業務測試的時候，從網關進來，如果在軟路由，即自己這個項目環境裡邊有，我就會走到自己項目環境，如果沒有就會請求到基準環境。從這個層面來看，項目對應的環境它只包含自己本次變革的應用，對資源的節約是非常大的。同時因為應用少了，我們創建的速度也提升了，這樣就會保證在我們的測試過程跟開發過程中，環境不會成為瓶頸了。
下面看如何解決帶著問題上線這一問題。
我們的品質文件叫Cable，它會消費各種自動檢查手段、自動化工具執行的一些結果，把他們推送的一些消息推送到 IC中，然後我們的品質文件在消費這些消息的同時提供介面給Qodin、發布系統進行攔截跟結果展示。
自動化工具我剛才介紹了4種，我們內部還會有一些項目流程、慢查詢等自動化工具。這些工具並不全部都是我們來提供的，有很多是業務線來提供的。這是因為我們在實現Cable的時候，採用了一個通用的方式，即定義了一個通用的接入標準——業務線各種檢查手段，你只要把你的結果推送IC消息即可，這樣的話如果你某個業務線有自己的一些檢查工具，你只要按照這個標準去推送消息，我就可以快速地接入，在你的業務線去落地，這樣能極大的發揮整個業務對自己品質負責的積極性，同時也會更有利於我們整個公司的品質保證。
3）效果
① 環境效果
這個是基於之前環境不隔離即完全資源獨立的情況下做的方案，可以看到我們有應用83個，資料庫23個，中間件7個，我們能保證10分鐘之內交付，每一次變更都會有一些變更記錄。這是基於資源完全隔離的情況，基於上述新方案，我們應用精簡後，環境交通速度就更快了。
② 品質門禁效果
這是品質門禁現在的狀況。
我們上述說到，業務線也可以提供各種各樣的檢查手段。我們現在有豐富的檢查手段，業務線根據自己的配置去選擇需要的一些手段。這是我們組織維度暫時的品質情況，最終我們做的各發布系統集成的發布攔截。
總結這一部分的話就是品質，我們通過多種手段加發布門禁，確保了我們的品質。有了流程，保證了品質，我們現在要去發布上線了。
3、應用畫像助力發布運維
1）背景
理想是測試完了，直接一鍵點擊發布按鈕上線。但是現實往往不是如此。
QA人員發布時，先要去OPS那邊申請機器，再去配置發布步驟，即發布的一些相關的資訊，配置非常複雜，前期需要許多準備工作。
對於開發人員來說，開始運維，如果線上出現了一個問題，要先找到它這個機器的資源，然後再去找應用，找程式碼，這是非常割裂的。
還有一個問題，一旦遇到問題的網路，還要去各個地方找這些資訊，定位也十分困難。
所以總結起來是什麼問題？
我們會各種工具平台，雖然大家現在強調一站式的，但是在背後的話，各種資源服務還是不同的Team提供。因為不同的Team提供的時候只關注自己管理的領域，所以它的管理維度是不一樣的，這樣就會導致管理維度不一樣，這些數據資訊無法串聯起來。
2）方案
① 應用畫像
基於這個問題，我們可以思考一下，我們真正發布運維的到底是什麼東西，它最小單元是什麼？我們確定了我們最小的管理單元，其實就是我們的應用，那麼我們應用有哪些屬性呢？我們就猜出了我們的應用畫像，包括基本屬性、環境屬性、發布參數和依賴資訊。
- 基本屬性是身份，Appcode就是它的唯一標識。
這裡強調一下等級，之前也有人問我等級有什麼用，等級是非常有用的，我舉個例子，有了等級，你才知道你這個服務的重要程度，你在運維的時候你才能知道優先把資源傾斜給哪些應用，先去運維哪些。
- 環境屬性，包括應用要運行的軟硬體環境配置等。
- 發布參數，包括編譯參數、打包參數、發布策略等。
- 依賴資訊，包括我有哪些網路依賴，例如我們的域名owner，資料庫依賴，以及服務之間的調用關係。
② 發布流程
只有真正拆分出來我們管理的最小的單元是什麼，我們才可以對它進行運維，進行發布，所以我們基於應用畫像拆分出應用。下圖是我們的一個發布流程。
首先是應用確定了自己的應用畫像，然後使應用畫像存在一個配置系統中，然後調度系統去從配置系統拿到一些配置，完了出發到我們Jenkins，部署到各種的調度資源中。
這裡要強調的是我們這個地方有一些自定義的階段，通過這些自定義我們可以把那些非標準的過程納入進來，業務線就可以在這裡去做自己的適配。
③ 運維流程
運維也是基於一個應用的，當一個應用的某些指標報警，我就可以去快速地找到應用對應的Trace鏈路、日誌、事件系統。
根據這三板斧，我就可以去定位到我的問題，最後對應我們的運維繫統去做對應的運維操作。
3）效果
這是我們的應用畫像效果。其中有應用形式配置，包括它的一些服務依賴屬性，服務調用屬性。
上述是我們發布的過程，可以看到在發布過程中我們可以知道當前的發布進度，還會對接我們的異常日誌，以及報警資訊。還有我們的監控，變更的事件，Trace鏈路，這三板斧實現了我們對應用的可運維。
4、流水線助力持續交付
最後是流水線。我們剛才說的是對單應用的管理，但是其實真正項目的時候是多應用的發布，多應用的交付，所以我們拆分了兩種類型的流水線，第一個就是單應用的流水線，包括拆開發、測試、集成和線上。
流水線的好處我想大家應該都知道，我這邊總結兩點：
- 使整個流程更加的自動化；
- 使一些上游的數據向下游傳遞。
我舉個例子，我們開發測試的流水線在這個過程中會產生一些數據，例如DB變更，DB的配置變更，定時任務監控等，這些都可以自動的識別出來，這樣的話就可以在線上的時候自動把這些資訊拿到，然後業務線只需要改一下Beta和線上的一些不同配置以及具體的值即可，這樣我就可以不用人工地去各個地方資訊搬運，線上也可以快速地交付。
單應用的交付完成之後，其實是更多的不是項目維度，項目維度我們可以組織讓業務線去做人工地編排，編排應用之間流水線以及它的一些前置依賴。
在一般情況下交付到了發布就完成，其實我們在發布完成之後還可以做一些服務治理健康保障，例如我們有觸發的壓測，以及強弱依賴等。
這就是我們具體的實踐。我再總結一下，具體實踐第一是規範化，保證我們整個流程的順暢與自動化。第二是多種手段保證品質，品質門禁保證問題的蔓延。第三是拆分應用畫像，使畫像確定我們的運維最小單元，實現可發布可運維。第四是通過流水線使我們整個流程更順暢。
三、未來規劃
最後再來看一下我們近期的一些規劃。
1、開發平台
第一部分是開發平台。在整個開發活動過程中，所佔比例最大的還是寫程式碼，我們怎麼能讓寫程式碼效率更高，所以我們計劃做一個開發平台，其實也是一個開發插件。這個插件主要有哪些功能呢？
它可以介面調用自動生成，我們會有原數據資訊中心，去採集我們現在整個公司提供的介面資訊，然後業務在開發程式碼的時候就可以自動拿到這些依賴，然後自動地生成程式碼。
生成程式碼的同時，它還可以進行一些服務治理的配置，後續我們希望聯動其他的工具，例如我們聯動qconfig(配置中心)配置自動生成以及聯動我們的服務治理，然後自動生效等。
開發平台，極大地提升我們的開發效率。開發平台最終要達到的效果就是讓我們程式碼編寫更簡單，規範落地有載體，服務治理更有效。
2、混沌工程
第二部分混沌工程，《又一宕機事故！都怪當初沒做好故障演練系統……》有詳細的介紹。
3、服務可觀測平台
第三部分是服務可觀測平台，剛才我們說了基於應用畫像讓我們應用做到可觀測，可發布，可運維，但是其實對於它整體的狀態，我們還需要有一個可觀測平台。基於雲原生的思想，讓我們的應用服務可觀測，它主要分為三個領域的實踐。
- 系統技術先進性，系統當前使用的是不是TC組件，TC組件是不是最新的，TC組件它其實是所有服務的一個基石，後續的Trace鏈路，各種的治理全都依賴於它。技術先進性可觀測之後，尤其是團隊維度，在整個公司技術演進的時候，我就可以先著力地去改進它，去發力去做一些感性的應用。
- 健康度，系統健康度是指我當前的系統是不是有報警，它是不是多機房災備，品質保障手段是不是足夠健全等，我可以據此了解應用的健康度。
- 一旦遇到了問題，我們可以快速定位，像上述我們說的日誌、Trace以及監控等。
已上是分享的全部內容，大家如果有什麼想法，歡迎在評論區提出~
>>>>
Q&A
Q1:在CI/CD流水線執行通過後才可以進行test測試流水線執行。怎樣控制兩個流水線的執行順序？建立兩者的關聯?
A1：我有三點建議。第一是流水線的出發儘可能的做到自動化，自動化的話就相當於避免人工的處罰，這樣你的順序基本上就可控了；第二是設置卡點，流水線需要有一些前置的卡點，就是達到什麼標準，然後才能去執行這條流水線，這樣就解決了這一問題，CI/CD不通過是不允許執行測試流水線的；第三是在一個項目階段，流水線其實是對同一個應用來說，或者是同一個應用同一次提交來說，它其實不是說同一次提交。同一個應用來說的話，流水線是區分開發，測試，集成，最終到線上的，所以我們可以確定一個唯一的標識，然後每一個流水線裡邊都會有一個唯一標識，可以把這個過程給串聯起來。
Q2：怎麼建立度量體系？
A2：我有幾點建議，首先度量一定是為了解決問題的，我們做度量的時候，先要確定我們需要解決的問題的痛點是什麼。根據我的理解，度量不是面向一線工程師的，所以在做度量的時候，一定要與TL一層的管理對齊目標，對齊目標需求，再建立對應的指標體系，進行指標的採集，度量。度量其實分為過程指標和結果指標。我們一般做度量的話，度量格就涉及到考核了。我覺得做度量這件事情，你首先要確定你為了做這件事情，可能需要獲得更多的支援，我們要先去拿結果指標跟上層對齊目標，然後獲得更多的資源，再去根據具體問題看過程指標。最後一個原則就是MARI原則(度量分析回滾改進原則)，我們遵循這個原則，讓數據說話，用數據去解決問題。
Q3：如何進行需求的分層管理？
A3：我說一下我們公司的一個具體實踐。我們公司是採用OKR的管理機制，首先我們確定了整個公司的業務目標，然後各個團隊去制定自己的O目標，之後根據目標去設立對應的一些結果指標，然後結果指標再去拆分成具體的一些產品需求，再去對這個需求進行跟蹤管理。所以就是分了三級，對於上級來說，我們關注的是整個目標的情況；對於中層來說，關注的是結果指標這一層，看這一個點我是不是要達標；對於一線來說，關注的是需求的交付。
Q4：DevOps是不是一定要基於一些方法論？
A4：比如說項目管理，我們一般與敏捷相結合的話，有了敏捷方法論，然後我們去落地這個項目管理，例如現在最常用的是看板管理，它使用這些方法論會讓我們解決問題更快捷，更高效，但是它不是必須的，比如說TDD，我們在建立DevOps體系，當初並沒有TDD，TDD測試驅動開發其實是在最近幾年體系比較完善的時候才要做的事情。所以在沒有這些方法論之前，我們做的是一些單點的提效，當然有這些方法論的時候，我們去做參考，然後把這些單點的流程做場景化的落地實踐。理論跟實踐結合起來，我覺得會達到更好的效果。前兩天看一些大佬們分享，DevOps實踐其實是重在道法器術，道當然指的方法論，所以在一些方法論的指導下我們去落地實踐可能會更好一點。
Q5：DevOps跟SRE有什麼區別？
A5：下面是我的一些理解，可能有些偏頗，然後大家如果覺得不合適，我們可以再探討。從內容方面，我覺得是DevOps是一套方法論，它最終的體現是落地到一套工具，平台，它包含了項目管理、開發、測試、運維等多個領域，而SRE主要還是在運維領域；從目標層面來看，DevOps是保證項目過程的品質和目標，當然它也對最終服務的健壯性負有責任。但是SRE主要還是為服務的可靠性提供保障；從執行人員來看，DevOps發起方一般可以是PM，品質保障運維或者工具等團隊，而SRE主要還是運維人員。所以從我的理解層面來說，DevOps是囊括運維領域的。
相關閱讀
第三篇：去哪兒網(Qunar) DevOps 實踐分享 – 王曉翔
