這是 2017 年王曉翔在 msup 全球軟件案例研究峰會上的分享，重點分享了提高工程效率過程中存在的問題、取得的成果和要做的事情。內容詳實，具有可操作性。我有幸看到了，所以在征得曉翔的同意下重新截圖、排版后發了出來。希望大家讀有所得。

 

可能和去哪兒有緣吧，認識好多去哪兒的朋友，包括董老師，曉翔，唐老板，張寧等好多小伙伴。曾經有次和曉翔團隊有過交流，團隊里的每個人都給我一種踏實的感覺，都是干事出活的。其實我們內部在做應用中心的時候，找到了網上唯一一篇應用中心的文章就是去哪兒網的。我一直覺得去哪兒的技術比較扎實，去哪兒網的很多技術文章都很干，干貨的干，他們有個技術公眾號「Qunar 技術沙龍」有很多不錯的文章，我也附在文章末尾了，歡迎大家訂閱。

 

我的老東家 IGT 之前就在蘇州街，之前我們那環境還可以，自從去哪兒搬過來啊，他們就把我們給卷的吃飯沒地啦，趕地鐵沒座，電梯上不去也下不來，有的時候趕點我要向上爬 18 層樓。但是每次看到樓里樓外的年輕人，讓我這種喜歡折騰的人莫名的感到一股活力。青春不就是應該這樣么，遇到值得做的事情，投入激情，一往無前的干它。我當時真覺得就憑去哪兒這股干勁肯定能把攜程薅下來，誰哪知道攜程不想一起玩兒了，直接掏出一沓美金甩給了百度把去哪兒合并了。

 

我自己為了消化里邊的內容，整理了一個腦圖，希望對大家有幫助。

 

 

原文題目《消滅低效的幕后黑手——Qunar DevOps 實踐分享》

 

2017 年 11 月 9-12 日，第六屆全球軟件案例研究峰會在北京國家會議中心盛大開幕，現場解讀 2017 年「壹佰案例榜單」。時任去哪兒工程效率部總監王曉翔帶來《消滅低效的幕后黑手——Qunar devops 實踐分享》的案例分享。王曉翔一直致力于軟件配置管理、軟件質量管理和軟件過程管理方面的工作和研究，擁有 10 多年的軟件配置管理領域的從業經驗。先后在中國海關數據中心、索尼移動通信、 中國體彩科技有限公司、去哪兒網等公司工作。

 

devops 是文化、流程與工具的有機結合。Qunar 具有先天的 devops 文化，在研發過程中有很多自動化工具的支持。在傳統的“我能做什么”的思維模式驅動下，每個工具就是一個信息孤島，工程師使用這些工具存在著多種浪費。借助 devops 思想，拆掉原先“各自為政”的自動化工具的墻，建立以應用為中心的全生命周期管理平臺。

 

1

存在的問題

 

去哪兒目前有 1200+工程師、500 個項目經理、6500 個線上應用、每天有 200 個需求發布、3000+的 beta 環境更新、500 個應用版本被部署到線上環境。下圖是 IC 系統統計出的 9 月 20 日全天數據，beta 部署 3338 次，線上更新圖 529 次。

 

 

早在三年前，Qunar 的發布系統就已經可以做到多個應用按照預定義的順序一鍵發布了。但是，多個單點上高效的工具組成的過程，就一定是高效的嗎？聽聽業務線的反饋，答案就不難得出。下圖，是在沒有做 devops 之前，線上應用擴容一臺機器的過程。步驟繁瑣，效率低下。

 

 

問題及根源分析

 

從上面這個簡單的場景暴露出我們目前面臨的問題：工具太多、工程師學習成本高；維度不同、同類數據在不同工具中不一致；權限管理混亂。

究其原因分為兩點：

1. 各個工具由不同部分負責開發，而這個部分由于按照工作職責劃分，所以出發點不同。這就是經常說的“部門壁壘”。

2. 不同工具的管理對象和目標不一致，導致信息集成困難，流程自動化就很難推進。

 

Qunar 的 devops 方針：一個中心，兩條主線

 

所謂“一個中心”，就是以提高工程效率為中心。實施 devops 不是目的，提高效率才是目的，所以我們內部都很少去講 devops 這個詞。而是不斷去收集和發現業務線的需求，通過現場觀察發現影響效率的環節，通過值班熱線來收集高頻問題，這些不僅是我們改進的原動力，也可以直接驗證我們的改進效果。所謂“兩條主線”，第一條是“應用線”。一個應用被注冊后，從開發到上線到運維，是一個不斷迭代的過程；第二條是“需求線”。持續交付關注的是一個需求從提出到交付的時間，這個時間越短說明一家企業越高效。而隨著微服務架構的盛行，很多時候為了一個業務需求需要改動幾個，甚至十幾個應用。如何管理這個過程讓其高效，也是非常重要。明確了“一個中心，兩條主線”的方針后，我們解決問題的思路也非常清晰了。下圖是落實這一方針后，我們工具平臺的宏觀表現。

 

 

2

取得的成果

 

一、應用的生命周期管理

 

解決思路

 

為了解決過去的部門壁壘和信息孤島問題，我們在建立應用的全生命周期管理時，第一件事情就是為每個應用創建一個全局唯一的 ID：APP_CODE。一個擁有了 APP_CODE 的應用，就好比一個被分配了身份證號的合法公民，享有很多合法權益。以前分散在各個階段各個系統的信息，都將與這個 APP_CODE 建立聯系，或作為應用的基本屬性，或作為應用的孤島資產（典型資產：機器，IP）。當然應用也要“遵紀守法”，這里特別強調做 devops 的一大原則——規范先行。所謂沒有規矩不成方圓，而沒有規范的 devops 就是無稽之談。

 

關于應用的屬性：

在對應用的屬性數據進行梳理后，我們把它分為三類：基本屬性、部署屬性、服務屬性（偏運行時）。其中，基本屬性數據包括：服務類型，服務歸屬（業務線或 BU），Owner，member 等；服務屬性包括：對機器資源的要求，對操作系統／基礎軟件的要求，服務啟/停配置等；部署屬性包括：源碼地址，打包命令，部署時個性開關等。

 

關于應用的資源：

我們把應用所需的機器、域名等都做為資源來管理，尤其是機器資源，能夠精確到具體應用，不僅給 OPS 運維提供更大的便利，一旦機器出現問題可以快速定位 APP_CODE 的 owner，而且在做成本核算時也更清晰準確。為了方便對不同用途的機器進行管理，我們又引入了一層邏輯概念，即環境。一個應用可以被部署在多個環境，一個環境可以包含多臺機器。典型場景就是一個應用，先被部署在一個 dev 環境（1 臺機器），然后部署在一個 beta 環境（2 臺機器），最后部署在 prod 環境（4 臺機器）。

 

為了實現信息的自動整合、工程師操作的流暢，我們對原有工具進行了系統點整合。是的，是整合，而不是推翻重建，我希望你們也是這樣去做。

整合后的平臺（我們后面都叫它 Portal）的系統結構如圖所示：

 

當我們把原有散落在各個工具平臺中的信息，按照以上維度重新定義后，應用的生命周期脈絡變得非常清晰。下面，我們再看看一個工程師的日常工作模式吧。如下圖：

 

工程師進入 Portal 平臺后，選擇要處理的一個應用便進入該應用的詳情頁。這個詳情的版面被分為 4 塊：（1）左上角展示應用的基本屬性；（2）左下角展示服務屬性；（3）右上角是線上服務的變更事件：如定時任務執行情況；服務重啟；服務發布等；（4）右下角是應用的環境/機器信息，以及運行在機器上的服務版本信息。原來需要在多個系統間切換才能收集到的信息，在這樣一個詳情頁直觀的展示出來，而且高頻動作也都有相應的快捷按鈕，非常方便。

 

與此同時，我們還做了一些過程可視化的改進。比如，原來的發布系統都是把過程日志輸出給用戶看，很多時候出現問題，工程師看不懂日志，也不好定位在哪個環節出了錯，我們的服務熱線每天疲于應付這些咨詢問題。現在，我們把文字轉換成了流程圖的形式展現給工程師，當一次發布失敗后，工程師可以一目了然的定位到出現的環節，然后再點擊查看日志確定錯誤原因。工程師自助排查問題的能力明顯提高。

 

如圖：

 

 

 

二、項目的生命周期

 

解題思路

 

與應用生命周期保持一致。在項目管理中，有兩個明顯的問題：（1）項目進入開發階段的過程對于項目經理來講就是黑盒，想要了解細節溝通成本很高。（2）項目的實際數據靠手動填寫，既不及時，也不準確。為此，我們通過規范源碼的分支命名規范，將工程信息與項目信息建立了聯系，通過工程中的不同事件映射到項目的不同階段，從而自動填寫項目管理中的“實際時間”自動。

 

先以一個實際的項目為例，看看整合了工程信息后的項目管理平臺都有哪些變化吧。

 

除了原有項目管理平臺維護的需求詳情，計劃安排，人員信息外，我們通過嵌入頁面的方式，將所有與這個項目相關的工程信息進行了集中展示。在這個工程信息窗口中，除了應用名稱，源碼地址，分支名稱外，還將 CI 結果進行了匯總展示。不僅可以清晰看到進度，還可以看到質量。

 

 

能夠做到項目信息與工程信息的集成，關鍵一點就是通過分支命名規范建立關系，即：在分支名稱中包含 PMOID 的，之后項目管理平臺通過消費各種工程類消息，進行信息整合。稍后我也會再單獨介紹為我們的 devops 平臺立下汗馬功勞的消息系統 IC。用下圖更能直觀看到消息的生產者和消費者的關系：

 

 

說到這里，不得不介紹一下為我們的 devops 平臺立下汗馬功勞的消息系統 IC。IC 的誕生背景就是為了降低系統集成的復雜度，消息生產者只負責發送消息，任何對該消息感興趣的一方都可以來消費它。比如 PMO 中展示的工程信息，就是由項目管理平臺消費了這樣幾類消息：

1. branch-created：生產者——git

2. sonarResult：生產者——Sonar

3. codediff：生產者——codereview

4. beta-released: 生產者——發布系統

5. prod-released: 生產者——發布系統

IC 中已經定義的消息類型已經有 40 多種，在我們內部工具集成中發揮著越來越重要的作用。

 

三、其他基礎服務

 

測試環境管理平臺 Noah

 

當我們的服務拆分到一定程度后，馬上會面臨的一個新問題就是——要驗證一個業務場景，需要部署 N 多個服務。如何提高這個過程的效率，在 Qunar 也有一個強大的平臺支持，那就是 Noah。在 Noah 平臺，用戶可以通過選擇應用的各種組合快速構建滿足業務測試的環境，或基于一個已有環境快速 copy 出一個全新環境。目前使用 Noah 的典型場景有兩類：一類按照項目創建環境，滿足開發工程師和測試工程師的驗證需要；一類是滿足接口自動化測試。關于 Noah 是值得專門寫一篇文章來介紹的，這里只貼幾個截圖讓大家有個直觀了解吧。

 

在 Noah 平臺新建環境，選擇一種新建類型。如果是復雜的應用組合，我們建議用戶以環境模版的形式保存下來，方便其他用戶復用。

如果是自定義方式新建環境，用戶可以按需添加應用信息，數據庫，以及配置網絡以及環境變量。

 

環境的創建過程我們也做了可視化展示，方便用戶了解進度或定位問題。

 

環境的每一次變更我們也會如實記錄下來：

 

 

一個被成功創建的環境，我們還提供對其服務的監控：

 

 

四、實踐總結

 

提高效率、以始為終

 

我們實踐 devops 的目的是要提高效率，那么第一步是要能夠準確發現那些地方效率低下。精益生產中定義了七大浪費，而這些問題在軟件開發過程中同樣適用。發現這些浪費最直接的辦法就是走進現場。去哪兒王老師的經驗是：沒有比現場觀察更能發現問題的根源所在。

 

一旦找到低效的根源，接下來我們還需要用系統的思路去解決它。而不要簡單的頭痛醫頭，腳痛醫腳。最終改進方案上線后，我們還要去驗證那個被我們識別為低效的問題，是不是真的被消滅了。

 

 

Qunar devops 工程實踐總結

 

1. 每個應用有自己的唯一標識，貫穿應用整個生命周期

2. 每個項目有自己的唯一標識，貫穿項目管理生命周期

3. 通過分支命名規范建立起項目與工程信息打通的基石

4. 每個工具是一個獨立服務，通過消息中心實現系統集成

5. 做自己工具的第一個用戶

 

工具一覽

 

 

3

還要做的事情

 

沒有最好，只有更好，注定了提高工程效率是一條沒有終點的路。接下來去哪兒在工程效率提升上，將要完成信息可追溯到可預測，過程自動化到智能化的邁進。

 

Q&A

 

Q：配置中心可以解決配置帶來的效率問題，想知道去哪兒的配置中心如何實現？能不能講一下基于開源框架和自主研發。

A：這個平臺是我們自研的，它的初衷是為了做到應用和配置的剝離，在代碼中不要有配置的東西。

 

Q：應用之間的依賴是自動分析出來的嗎？應用服務的注冊是基于某種自動發現機制嗎？

A：依賴關系目前來說不是自動發現，我們內部有 rust 數據，所以那個數據我們分析的不全。目前還是靠人工配置這個數據，但是我覺得不遠的將來我們可以解析依賴數據。關于先注冊還是基于發現做這個問題，首先一定先有這個標識才能去發現，如果連這個 ID 都沒有其實無從談起，注冊一定是手工先做的事情。

 

Q：jira 的項目質量表格是怎么實現的？自己開發插件還是 jira 的某個可定制頁面？

A：表格是自研的，大家如果有 jira 的二次開發經驗并不難。插件也是自己開發的。

 

以上內容來自王曉翔老師的分享。