去哪兒網核心領域DevOps落地實踐

本文根據張春芳

本文根據張春芳

老師在〖deeplus直播：逆襲生產力擔當，雲原生時代的運維新歸宿〗線上分享演講內容整理而成。

去哪兒網 系統運維總監

2014年加入去哪兒網，就職於基礎研發基礎平臺組，近來一直致力於整個公司研發體系的標準化及效率提升，涉及開發、測試、運維等多個領域。目前主要負責全公司的DevOps生態體系建設，為業務交付的速度和質量提供保障。

今天的分享主要包含以下幾個方面的內容：

老師在〖deeplus直播：逆襲生產力擔當，雲原生時代的運維新歸宿〗線上分享演講內容整理而成。

張春芳

看我們生態之前，大家先看一下我們的整個專案流程。

在整個專案流程中，首先是業務，我們做DevOps的時候一定要從業務目標出發，業務人員先去確定業務目標，然後進行產品的規劃，規劃完成之後進行產品的設計。

設計拆分成具體的功能，功能對應我們的需求。

在需求出來之後，我們進行敏捷開發。

開發完成後進行整合測試驗證，最終釋出運維上線。

我們DevOps其實主要是致力於為產品設計到釋出運維這一過程提供支援，完成服務目標。整個過程也是我們專案管理的過程。

一．Qunar devops生態概覽

基於整個專案流程，我們看一下我們DevOps的目標和方法。

這個目標和方法我借鑑了百度工程能力的定義：

工程能力是使用系統化的方法，在保證質量的前提下，更高效率地為客戶/使用者持續交付有價值的軟體和服務的能力。

其中有幾個關鍵詞，首先它是系統化的方法，對應去哪兒我們這麼拆解系統化的方法。

首先要有

1、專案流程

因為有了流程規範，具體的一些落地才有章可循，而不是做各種單獨的一些場景化支援。有了流程規範，我們去落地，先

2、目標和方法

這一層落地工具平臺都是先做一些普適性的工具。但普適性的工具雖然對所有的場景都支援，但也存在對真正具體的一個場景化支援不流暢的問題，因此我們

流程規範，

遵循這一閉環，我們來建立我們DevOps的生態。

有了方法之後，我們的目標是什麼呢？當然是提升交付速度。但是在提升交付速度的過程中，我們又必須保障質量，所以

落地到我們的工具平臺，

基於以上的目標和方法，我們落地了DevOps生態。

拆分出具體的場景化實踐。

首先看一下完整的流程。

貫穿全部流程的是專案管理。

在上層，我們根據不同的域進行了拆分，可拆分為開發、測試、上線和運維。

開發部分包括的內容就是應用註冊、程式碼管理、sonar、Cr等。

測試部分包括缺陷管理、case介面、測試效能、介面測試和程式碼覆蓋率。

上線包括髮布步驟編排、產物管理、回滾管理、負載均衡等。

運維包括監控、日誌、事件、報警等。

上圖右方是我們的一些公共服務，底層的資源是KVM跟k8s。整個過程我們也遵循雲原生的基本原則，開源與自建結合。圖中藍色部分是使用開源的，黃色部分在使用開源的基礎上進行了二次開發，紅色部分完全由我們自建。

生態是以是以唯一的管理單元——APPCODE串聯的，APPCODE是指應用的唯一標識，因為有了APPCODE，才會使我們整個過程可追蹤，資料可追溯，服務可運維。所以

我們的兩大核心目標就是提升交付速度和保證交付質量。

3、完整生態

建立生態之後，看一下我們現在基於生態實現的效果。

這幾個數字是基於月均的數字統計。

我們現在每月平均有3000＋專案釋出，15萬次＋部署，涉及到2000＋應用，1000＋開發測試運維。

由此來看，我們的體量還是相當龐大的。

值得一提的是，在這3000＋的專案釋出中，有很大一部分是開發自測自發，即完全沒有測試人員的參與。這完全依賴於我們 DevOps生態建設對開發測試進行賦能，也因此，我們的開發同學自測自發不僅保證了質量，同時也保證了我們的交付速度。

APPCODE是我們非常核心的要素，建立生態的關鍵。

在瞭解我們的生態之後，下面來具體地看一下我們在一些核心領域的落地實踐。

4、效果

上述分享的方法論中有一步很關鍵，那就是規範流程。那麼規範流程有什麼意義呢？

二.核心領域實踐

下面我們來看一個具體的案例，看它如何助力我們的開發提效。

在我們公司，可能其他公司也相同，在開發專案過程中一個核心資源就是開發資源，我們的理想狀態就是要實現開發資源利用最大化，理想狀態就是開發人員只需專心投入寫程式碼即可。

但是現實情況是開發同學被各種角色干擾。主要有以下幾個問題。

1、規範化助力開發提效

頻繁的被打擾導致其時間碎片化，在各種任務之間切換導致效率無法保證。

1）背景

無法得知專案的實時進度，專案是在開發過程中，還是在測試過程中。因此只能去跟開發進行去人為溝通，這不僅導致了開發被打斷，也使專案經理無法掌控整個專案過程。

對開發來說，

QA最終要為質量負責，但是QA不知道專案的這次需求變更了什麼內容，這就會導致變更靠人為的梳理很容易被遺漏，從而導致上線出故障。我們有很多血淋淋的教訓，因為沒有更新DB，或者是一個配置忘記更新了，上線出現過很多次故障。

對專案經理來說，

PMO要收集整個專案過程的資料，透過資料去確定我們的改進最佳化分析，分析最佳化改進。但現在我們專案的所有資料全都依賴人工去填寫，很難保證資料的準確性，從而給改進最佳化帶來困難。

透過上述分析，我們可以發現，我們對於整個過程的跟蹤是基於專案去跟蹤的，但是這個專案變更的內容又是應用維度的，所以導致我們沒有辦法被跟蹤，人為操作多。核心問題就是我們的應用跟專案沒有建立關聯關係，所以我們要去建立這一關係，從而解決這個過程中的問題。

對QA來說，

那如何建立關係？

對PMO來說，

看看我們是怎麼做的。

2）方案

我們對分支進行了命名規範的要求，分支名必須包含一個PMO標識。這樣當分支被建立、被push的時候，就自動將其關聯到專案上面，建立了應用跟專案的關聯關係。

依靠規範化。

知道了專案變更了哪些內容，變更的時候每次提交都可以去自動的觸發一些相應的檢查，相應的檢查結果報告就可以展示在這個專案上面。對於QA人員來說，可以直觀的瞭解專案當前的質量狀況；對於專案經理來說，可以比較直觀地瞭解這個專案的狀況，從而去控制風險。

① 分支命名規範化

對於PMO來說，之前很多資料難以收集，有了關聯關係之後，我們會把這一次專案的釋出資料，包括髮布的次數，以及變更的行數等都自動回填，相當於獲取了這個專案整體的變更資料。

② 質量檢查視覺化

因為我的程式碼已經跟它關聯起來了，在開發中如果是提交到程式碼，可以自動從專案已排期狀態變成開發狀態。當我做了一些Beta驗證的時候，就可以自動地流轉到我現在是要提測了或是要釋出了，所以這個狀態的流轉實現了智慧化。

結

合完整的方案，我們就解決了各種開發被打斷，自動化手動操作過多的問題。

這個是我們的架構。

相當於開發與應用關聯的工具，我們內部把它叫做Qodin，底層是DB，Cache，其次是我們的資料儲存，然後各個工具平臺會把自己執行的一些結果透過傳送訊息推送到我們的訊息平臺。Qodin透過消費這些訊息，透過外部的HTTP介面觸發各種工具平臺去執行。上層是我們透過js一些頁面給使用者提供一些檢視入口、操作入口等等。

③ 資料回填自動化

下面再來看一下我們實現的效果。

上圖是我們的一個專案，我們可以看到這個專案中到底變更了哪些內容，首先是變更的一些質量的情況，以及它的釋出情況。其次是我們自動回填的資料，可以看到包括研發階段的市場自動計算，專案總市場等，線上釋出的次數，程式碼變更的一些資訊，同時我們在一些專案的關鍵節點，根據時間計算關鍵節點的狀態流轉以及是否delay，這些都會有一個及時的專案提醒，這樣保證了開發和專案經理等都可以及時地關注到整個專案過程，一旦有任何風險也可以及時地暴露出來。

總結這一實踐，主要是透過規範化確定一個分支的命名規範來實現我們的應用跟專案的關聯，然後保證了我們專案整個流程的自動化與高效。

④ 狀態流轉智慧化

我們再來看一下速度有保證後如何保證質量，這就是我們的第二個實踐，透過多種手段和釋出門禁助力質量保證。

3）效果

我們先看一下理想，理想的狀態是開發修改完程式碼之後，透過測試，提交給QA，然後QA同學整合測試，最後愉快地上線。但實際中常常會出現開發跟測試同學的相互抱怨。

開發人員表示我測了。QA人員卻說你這提交的是什麼，你自己測了沒有？

QA人員常說為什麼我測試了，到上線還是會遇到問題，其實總結起來主要是以下問題：

2、多種手段+釋出門禁助力質量保證

首先測試條件是難保障的。開發人員做測試的時候，其實有環境的依賴，也有資料的依賴，有一些前提條件的準備。但是這些常常會特別耗時間，準備也非常困難，導致測試不足的問題。其次修復成本高，因為開發人員在前期的測試不足，提交給QA人員之後，透過QA人員發現了問題，然後再反饋給開發人員，反饋的週期就拉長了。開發人員這時可能已經進入到其他專案了，從而又有一個切換成本。

1）背景

沒有辦法讓開發保證提測的質量，更多的是依賴於自己的測試，對其來說非常不友好。還有上線的質量也難以保證，很多其實我測到了，但是可能依舊帶著問題上線了。

對開發人員來說，

所以該如何避免上述情況呢？來看一下我們的實踐。

對QA人員來說，

首先我們採用的第一個方法是先用多種手段保證效果。我們的手段包含以下幾種：

2）方案

即人工的review，現在我們公司已經建立起了較好的code review文化，大家都已經形成了這種習慣。

① 多種手段保證效果

這個地方sonar不只是sonar，在我們公司的話，主要技術棧是Java，所以我們會在 Sonar裡邊會做一些java規則的檢查，比如說非法的包名、重複類、然後依賴多版本等檢查，同時也會把一些原資料的資訊記錄下來，例如記錄變更的內容，變更的依賴等。除此之外也會做sonar本身的一些規則級檢查，我們這個規則也會定期做review。

程式碼review（code review），

介面自動化我們分了兩部分，第一部分是我們的線上迴歸測試，所用迴歸的工具我們叫滅霸，它會在每次開發提測時自動執行，把線上現在存量的一些介面做迴歸驗證。如果你是新增的業務介面的話，我們也會有一個自動化測試平臺叫Qunit，它是基於unit的，去做一個新的業務的驗證。

靜態程式碼檢查sonar，

我們sonarqube等各種的自動化工具，都可以看到當前的測試的覆蓋度。測試覆蓋度這塊大家其實一直有一個疑問，那就是我測試的時候就是程式碼百分百覆蓋，也不能保證上線完全沒有問題。但是反向也有另外一種說法，起碼百分之百覆蓋了，還是會增加一定程度信心的，所以覆蓋率是非常重要的。

介面自動化，

手段多樣是有前提保證的，尤其介面自動化有環境依賴，如果沒有環境做介面自動化或者沒有這個環境管理，介面自動化、執行介面自動化的可行性或速度都是沒有辦法保證的，所以我們又有一個環境管理平臺，透過這個環境管理，我們可以快速的交付一套環境，這個環境中包括了自己的應用以及它的依賴，為自動化的可行性提供了保障。

程式碼覆蓋率檢查，

自動化的可行性有了，多種手段也有了，最後的這些報告資訊怎麼通知給開發人員？我們做了多維度的報告展示，包括專案維度，個人維度，還有組織維度等，同時我們也會透過內部的Im訊息精準的通知到具體的開發人員，這樣方便他可以快速地解決問題，相當於質量阻力左移，降低了問題修復的成本。

② 環境管理提升測試速度

我們會結合我們的專案管理系統、釋出系統等去做質量卡點，如果不透過，我們就會去做一個攔截，然後避免帶著問題上線。

上面說了我們具體的方案，下面讓我們簡單地看一下多種手段，我覺得在現在這個階段，大部分公司都會有這幾方面的保證，我這個地方只簡單介紹我們公司的一些特色點。

③ 報告訊息反饋結果

我們是基於開源工具phabricator實現的，我們會做到分支建立後自動同步倉庫，同時代碼push的時候自動去建立更新diff，這樣就避免了人工去建立以及後續操作。同時我們支援兩次提交diff的變更，這是為了解決發現問題並修改重複提交後的全量diff問題。不需要全量的再次diff，只需要看這兩側的一個變更。當然如果影響範圍較大的話，還是建議全量的再diff一次。

④ 質量門徑預防蔓延

我們使用業界通用的sonarqube，但我們的特色點是程式碼push的時候它會自動執行，然後訊息反饋。同時我們有增量跟全量的報告。我們有很多歷史在的基礎上，如果你要求它去全量的解決問題，這在業務非常繁忙的時候是不現實的，所以我們做了增量，只去檢查當前這次變更引入的問題，只要解決了這些問題並能夠保證不新增，後續再去慢慢地解決全量問題。

在CodeReview方面，

介面自動化這裡我講的是滅霸即介面迴歸問題，介面自動化大家最頭疼的就是要自己去寫case，業務變動又比較頻繁。我們的時間點是怎麼做的？我們會基於檢查點的case自動生成補全清理。例如航司，航空公司是有很多公司的，比如說南航、國航、川航等，相當於每一個航空公司對應一個業務，我可能就要對這一個型別去進行驗證，所以我們需要使用者先定義一個檢查點維度，然後業務在線上執行的時候，會去生成日誌，我們透過日誌去採集這些具體的case，再生成補全。當過了一段時間，如果檢查點沒有這種業務的case請求了，我們就可以自動清理，這就解決了我們人工維護case的一個痛點。

靜態程式碼檢查方面，

是基於Jacoco實現的，也是增量跟全量的一個報告，可以看這次變更的一個覆蓋率情況。

上述是多種手段，

介面自動化方面，

我們對環境的定義是什麼？這個環境肯定不是單應用的環境，這種單應用的環境是對於整個業務的測試，它起到的作用是非常薄弱的。所以我們對環境的定義是支援一種業務測試，能支援一種業務測試的應用去依賴以及它所用的資源的一個組合。所以我們環境的組成就包括AppCode、資料儲存、中介軟體、網路配置、環境變數等。

環境有了，但是不可能每次進行一個業務測試或專案測試的時候，都去重新搭建一套環境，這樣成本是非常高的。我們之前去做專案覆盤時，對於delay專案大家吐槽最多的是為什麼delay？是因為環境問題。所以我們把環境的這些資訊做成了模板可配置，這樣就實現了資源與資訊的積累沉澱。

其次是業務巡檢。開發同學、測試同學只是去使用提供的環境，服務提供方要保證可用性，讓開發同學只是去用它，而不是再去為它的可靠性分擔精力，所以我們有業務巡檢。

我們之前建立一套環境後就實現了完全的資源隔離，相當於有一套環境給全部的應用分配資源，這是對於資源的極大浪費，同時建立速度也很低，所以我們又做了一個軟路由環境，基準環境跟專案環境。

下面我們透過下圖來詳細解說。

程式碼覆蓋率

上圖中我們可以看到我們包含了環境，即應用及其依賴，所以我們會先鎖定資源，包括Kvm、 DB這些東西，然後再進行採集編排，然後去觸發任務執行，排程執行。

下面看一下我們的測試環境。

我們會定期去呼叫業務線提供的一些全鏈路測試case，定期去執行，驗證這個環境的可靠性。同時我們也會去消費一些變更訊息，包括配置變更、程式碼變更、資料變更，去同步這個環境，這樣就保證了我們基礎環境的自運維。

首先是環境建立的流程，

我們會有一套基準環境，是全鏈路的，包含了全部的應用，但是對於專案來說，只需要建環境值，包含自己變更的這些應用以及它的一些DB依賴。在真正業務測試的時候，從閘道器進來，如果在軟路由，即自己這個專案環境裡邊有，我就會走到自己專案環境，如果沒有就會請求到基準環境。從這個層面來看，專案對應的環境它只包含自己本次變革的應用，對資源的節約是非常大的。同時因為應用少了，我們建立的速度也提升了，這樣就會保證在我們的測試過程跟開發過程中，環境不會成為瓶頸了。

其次是業務巡檢，

我們的質量檔案叫Cable，它會消費各種自動檢查手段、自動化工具執行的一些結果，把他們推送的一些訊息推送到 IC中，然後我們的質量檔案在消費這些訊息的同時提供介面給Qodin、釋出系統進行攔截跟結果展示。

自動化工具我剛才介紹了4種，我們內部還會有一些專案流程、慢查詢等自動化工具。這些工具並不全部都是我們來提供的，有很多是業務線來提供的。這是因為我們在實現Cable的時候，採用了一個通用的方式，即定義了一個通用的接入標準——業務線各種檢查手段，你只要把你的結果推送IC訊息即可，這樣的話如果你某個業務線有自己的一些檢查工具，你只要按照這個標準去推送訊息，我就可以快速地接入，在你的業務線去落地，這樣能極大的發揮整個業務對自己質量負責的積極性，同時也會更有利於我們整個公司的質量保證。

然後是軟路由，

下面看如何解決帶著問題上線這一問題。

這個是基於之前環境不隔離即完全資源獨立的情況下做的方案，可以看到我們有應用83個，資料庫23個，中介軟體7個，我們能保證10分鐘之內交付，每一次變更都會有一些變更記錄。這是基於資源完全隔離的情況，基於上述新方案，我們應用精簡後，環境交通速度就更快了。

3）效果

這是質量門禁現在的狀況。

我們上述說到，業務線也可以提供各種各樣的檢查手段。我們現在有豐富的檢查手段，業務線根據自己的配置去選擇需要的一些手段。這是我們組織維度暫時的質量情況，最終我們做的各發布系統整合的釋出攔截。

總結這一部分的話就是質量，我們透過多種手段加發布門禁，確保了我們的質量。

有了流程，保證了質量，我們現在要去釋出上線了。

① 環境效果

② 質量門禁效果

理想是測試完了，直接一鍵點擊發布按鈕上線。但是現實往往不是如此。

QA人員釋出時，先要去OPS那邊申請機器，再去配置釋出步驟，即釋出的一些相關的資訊，配置非常複雜，前期需要許多準備工作。

對於開發人員來說，開始運維，如果線上出現了一個問題，要先找到它這個機器的資源，然後再去找應用，找程式碼，這是非常割裂的。

還有一個問題，一旦遇到問題的網路，還要去各個地方找這些資訊，定位也十分困難。

所以總結起來是什麼問題？

我們會各種工具平臺，雖然大家現在強調一站式的，但是在背後的話，各種資源服務還是不同的Team提供。因為不同的Team提供的時候只關注自己管理的領域，所以它的管理維度是不一樣的，這樣就會導致管理維度不一樣，這些資料資訊無法串聯起來。

3、應用畫像助力釋出運維

1）背景

基於這個問題，我們可以思考一下，我們真正釋出運維的到底是什麼東西，它最小單元是什麼？我們確定了我們最小的管理單元，其實就是我們的應用，那麼我們應用有哪些屬性呢？我們就猜出了我們的應用畫像，包括基本屬性、環境屬性、釋出引數和依賴資訊。

基本屬性是身份，Appcode就是它的唯一標識。

這裡強調一下

2）方案

，之前也有人問我等級有什麼用，等級是非常有用的，我舉個例子，有了等級，你才知道你這個服務的重要程度，你在運維的時候你才能知道優先把資源傾斜給哪些應用，先去運維哪些。

環境屬性，包括應用要執行的軟硬體環境配置等。

釋出引數，包括編譯引數、打包引數、釋出策略等。

依賴資訊，包括我有哪些網路依賴，例如我們的域名owner，資料庫依賴，以及服務之間的呼叫關係。

① 應用畫像

只有真正拆分出來我們管理的最小的單元是什麼，我們才可以對它進行運維，進行釋出，所以我們基於應用畫像拆分出應用。下圖是我們的一個釋出流程。

首先是應用確定了自己的應用畫像，然後使應用畫像存在一個配置系統中，然後排程系統去從配置系統拿到一些配置，完了出發到我們Jenkins，部署到各種的排程資源中。

這裡要強調的是我們這個地方有一些自定義的階段，透過這些自定義我們可以把那些非標準的過程納入進來，業務線就可以在這裡去做自己的適配。

等級

運維也是基於一個應用的，當一個應用的某些指標報警，我就可以去快速地找到應用對應的Trace鏈路、日誌、事件系統。

根據這三板斧，我就可以去定位到我的問題，最後對應我們的運維繫統去做對應的運維操作。

② 釋出流程

這是我們的應用畫像效果。其中有應用形式配置，包括它的一些服務依賴屬性，服務呼叫屬性。

上述是我們釋出的過程，可以看到在釋出過程中我們可以知道當前的釋出進度，還會對接我們的異常日誌，以及報警資訊。還有我們的監控，變更的事件，Trace鏈路，這三板斧實現了我們對應用的可運維。

③ 運維流程

最後是流水線。我們剛才說的是對單應用的管理，但是其實真正專案的時候是多應用的釋出，多應用的交付，所以我們拆分了兩種型別的流水線，第一個就是單應用的流水線，包括拆開發、測試、整合和線上。

流水線的好處我想大家應該都知道，我這邊總結兩點：

使整個流程更加的自動化；

使一些上游的資料向下遊傳遞。

我舉個例子，我們開發測試的流水線在這個過程中會產生一些資料，例如DB變更，DB的配置變更，定時任務監控等，這些都可以自動的識別出來，這樣的話就可以在線上的時候自動把這些資訊拿到，然後業務線只需要改一下Beta和線上的一些不同配置以及具體的值即可，這樣我就可以不用人工地去各個地方資訊搬運，線上也可以快速地交付。

單應用的交付完成之後，其實是更多的不是專案維度，專案維度我們可以組織讓業務線去做人工地編排，編排應用之間流水線以及它的一些前置依賴。

在一般情況下交付到了釋出就完成，其實我們在釋出完成之後還可以做一些服務治理健康保障，例如我們有觸發的壓測，以及強弱依賴等。

這就是我們具體的實踐。我再總結一下，具體實踐第一是規範化，保證我們整個流程的順暢與自動化。第二是多種手段保證質量，質量門禁保證問題的蔓延。第三是拆分應用畫像，使畫像確定我們的運維最小單元，實現可釋出可運維。第四是透過流水線使我們整個流程更順暢。

3）效果

最後再來看一下我們近期的一些規劃。

4、流水線助力持續交付

第一部分是開發平臺。在整個開發活動過程中，所佔比例最大的還是寫程式碼，我們怎麼能讓寫程式碼效率更高，所以我們計劃做一個開發平臺，其實也是一個開發外掛。這個外掛主要有哪些功能呢？

它可以介面呼叫自動生成，我們會有原資料資訊中心，去採集我們現在整個公司提供的介面資訊，然後業務在開發程式碼的時候就可以自動拿到這些依賴，然後自動地生成程式碼。

生成程式碼的同時，它還可以進行一些服務治理的配置，後續我們希望聯動其他的工具，例如我們聯動qconfig（配置中心）配置自動生成以及聯動我們的服務治理，然後自動生效等。

開發平臺，極大地提升我們的開發效率。開發平臺最終要達到的效果就是讓我們程式碼編寫更簡單，規範落地有載體，服務治理更有效。

三、未來規劃

第二部分混沌工程，《

又一宕機事故！都怪當初沒做好故障演練系統……

》

有詳細的介紹。

1、開發平臺

第三部分是服務可觀測平臺，剛才我們說了基於應用畫像讓我們應用做到可觀測，可釋出，可運維，但是其實對於它整體的狀態，我們還需要有一個可觀測平臺。基於雲原生的思想，讓我們的應用服務可觀測，它主要分為三個領域的實踐。

2、混沌工程

系統當前使用的是不是TC元件，TC元件是不是最新的，TC元件它其實是所有服務的一個基石，後續的Trace鏈路，各種的治理全都依賴於它。技術先進性可觀測之後，尤其是團隊維度，在整個公司技術演進的時候，我就可以先著力地去改進它，去發力去做一些感性的應用。

3、服務可觀測平臺

系統健康度是指我當前的系統是不是有報警，它是不是多機房災備，質量保障手段是不是足夠健全等，我可以據此瞭解應用的健康度。

一旦遇到了問題，我們可以

系統技術先進性，

健康度，

像上述我們說的日誌、Trace以及監控等。

已上是分享的全部內容，大家如果有什麼想法，歡迎在評論區提出~

快速定

位，

>>>>

>

>

我有三點建議。第一是流水線的出發儘可能的做到自動化，自動化的話就相當於避免人工的處罰，這樣你的順序基本上就可控了；

第二是設定卡點，流水線需要有一些前置的卡點，就是達到什麼標準，然後才能去執行這條流水線，這樣就解決了這一問題，CI/CD不透過是不允許執行測試流水線的；第三是在一個專案階段，流水線其實是對同一個應用來說，或者是同一個應用同一次提交來說，它其實不是說同一次提交。同一個應用來說的話，流水線是區分開發，測試，整合，最終到線上的，所以我們可以確定一個唯一的標識，然後每一個流水線裡邊都會有一個唯一標識，可以把這個過程給串聯起來。

>

>

Q&A

我有幾點建議，首先度量一定是為了解決問題的，我們做度量的時候，先要確定我們需要解決的問題的痛點是什麼。根據我的理解，度量不是面向一線工程師的，所以在做度量的時候，一定要與TL一層的管理對齊目標，對齊目標需求，再建立對應的指標體系，進行指標的採集，度量。

度量其實分為過程指標和結果指標。我們一般做度量的話，度量格就涉及到考核了。我覺得做度量這件事情，你首先要確定你為了做這件事情，可能需要獲得更多的支援，我們要先去拿結果指標跟上層對齊目標，然後獲得更多的資源，再去根據具體問題看過程指標。最後一個原則就是MARI原則（度量分析回滾改進原則），我們遵循這個原則，讓資料說話，用資料去解決問題。

Q1:

在CI/CD流水線執行通過後才可以進行test測試流水線執行。怎樣控制兩個流水線的執行順序？建立兩者的關聯?

A1：

我說一下我們公司的一個具體實踐。我們公司是採用OKR的管理機制，首先我們確定了整個公司的業務目標，然後各個團隊去制定自己的O目標，之後根據目標去設立對應的一些結果指標，然後結果指標再去拆分成具體的一些產品需求，再去對這個需求進行跟蹤管理。

所以就是分了三級，對於上級來說，我們關注的是整個目標的情況；對於中層來說，關注的是結果指標這一層，看這一個點我是不是要達標；對於一線來說，關注的是需求的交付。

Q2：

怎麼建立度量體系？

A2：

比如說專案管理，我們一般與敏捷相結合的話，有了敏捷方法論，然後我們去落地這個專案管理，例如現在最常用的是看板管理，它使用這些方法論會讓我們解決問題更快捷，更高效，但是它不是必須的，比如說TDD，我們在建立DevOps體系，當初並沒有TDD，TDD測試驅動開發其實是在最近幾年體系比較完善的時候才要做的事情。

所以在沒有這些方法論之前，我們做的是一些單點的提效，當然有這些方法論的時

候，我們去做參考，然後把這些單點的流程做場景化的落地實踐。理論跟實踐結合起來，我覺得會達到更好的效果。前兩天看一些大佬們分享，DevOps實踐其實是重在道法器術，道當然指的方法論，所以在一些方法論的指導下我們去落地實踐可能會更好一點。

Q3：

如何進行需求的分層管理？

A3：

下面是我的一些理解，可能有些偏頗，然後大家如果覺得不合適，我們可以再探討。從內容方面，我覺得是DevOps是一套方法論，它最終的體現是落地到一套工具，平臺，它包含了專案管理、開發、測試、運維等多個領域，而SRE主要還是在運維領域；從目標層面來看，DevOps是保證專案過程的質量和目標，當然它也對最終服務的健壯性負有責任。但是SRE主要還是為服務的可靠性提供保障；從執行人員來看，DevOps發起方一般可以是PM，質量保障運維或者工具等團隊，而SRE主要還是運維人員。所以從我的理解層面來說，DevOps是囊括運維領域的。

想了解更多精彩內容，快來關注dbaplus社群

Q4：

是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術乾貨，每天精品原創文章推送，每週線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。