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

一.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、服務可觀測平臺

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

• 系統技術先進性，系統當前使用的是不是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是囊括運維領域的。