今天的分享主要包含以下幾個方面的內(nèi)容：

一.Qunar devops生態(tài)概覽

1、項目流程

看我們生態(tài)之前，大家先看一下我們的整個項目流程。

在整個項目流程中，首先是業(yè)務(wù)，我們做DevOps的時候一定要從業(yè)務(wù)目標(biāo)出發(fā)，業(yè)務(wù)人員先去確定業(yè)務(wù)目標(biāo)，然后進(jìn)行產(chǎn)品的規(guī)劃，規(guī)劃完成之后進(jìn)行產(chǎn)品的設(shè)計。設(shè)計拆分成具體的功能，功能對應(yīng)我們的需求。在需求出來之后，我們進(jìn)行敏捷開發(fā)。開發(fā)完成后進(jìn)行集成測試驗證，最終發(fā)布運維上線。我們DevOps其實主要是致力于為產(chǎn)品設(shè)計到發(fā)布運維這一過程提供支持，完成服務(wù)目標(biāo)。整個過程也是我們項目管理的過程。

2、目標(biāo)和方法

基于整個項目流程，我們看一下我們DevOps的目標(biāo)和方法。

這個目標(biāo)和方法我借鑒了百度工程能力的定義：工程能力是使用系統(tǒng)化的方法，在保證質(zhì)量的前提下，更高效率地為客戶/用戶持續(xù)交付有價值的軟件和服務(wù)的能力。其中有幾個關(guān)鍵詞，首先它是系統(tǒng)化的方法，對應(yīng)去哪兒我們這么拆解系統(tǒng)化的方法。

首先要有流程規(guī)范，因為有了流程規(guī)范，具體的一些落地才有章可循，而不是做各種單獨的一些場景化支持。有了流程規(guī)范，我們?nèi)ヂ涞兀嚷涞氐轿覀兊墓ぞ咂脚_，這一層落地工具平臺都是先做一些普適性的工具。但普適性的工具雖然對所有的場景都支持，但也存在對真正具體的一個場景化支持不流暢的問題，因此我們拆分出具體的場景化實踐。遵循這一閉環(huán)，我們來建立我們DevOps的生態(tài)。

有了方法之后，我們的目標(biāo)是什么呢?當(dāng)然是提升交付速度。但是在提升交付速度的過程中，我們又必須保障質(zhì)量，所以我們的兩大核心目標(biāo)就是提升交付速度和保證交付質(zhì)量。

基于以上的目標(biāo)和方法，我們落地了DevOps生態(tài)。

3、完整生態(tài)

首先看一下完整的流程。

• 貫穿全部流程的是項目管理。在上層，我們根據(jù)不同的域進(jìn)行了拆分，可拆分為開發(fā)、測試、上線和運維。
• 開發(fā)部分包括的內(nèi)容就是應(yīng)用注冊、代碼管理、sonar、Cr等。
• 測試部分包括缺陷管理、case接口、測試性能、接口測試和代碼覆蓋率。
• 上線包括發(fā)布步驟編排、產(chǎn)物管理、回滾管理、負(fù)載均衡等。
• 運維包括監(jiān)控、日志、事件、報警等。

上圖右方是我們的一些公共服務(wù)，底層的資源是KVM跟k8s。整個過程我們也遵循云原生的基本原則，開源與自建結(jié)合。圖中藍(lán)色部分是使用開源的，黃色部分在使用開源的基礎(chǔ)上進(jìn)行了二次開發(fā)，紅色部分完全由我們自建。

生態(tài)是以是以唯一的管理單元——APPCODE串聯(lián)的，APPCODE是指應(yīng)用的唯一標(biāo)識，因為有了APPCODE，才會使我們整個過程可追蹤，數(shù)據(jù)可追溯，服務(wù)可運維。所以APPCODE是我們非常核心的要素，建立生態(tài)的關(guān)鍵。

4、效果

建立生態(tài)之后，看一下我們現(xiàn)在基于生態(tài)實現(xiàn)的效果。

這幾個數(shù)字是基于月均的數(shù)字統(tǒng)計。我們現(xiàn)在每月平均有3000+項目發(fā)布，15萬次+部署，涉及到2000+應(yīng)用，1000+開發(fā)測試運維。由此來看，我們的體量還是相當(dāng)龐大的。

值得一提的是，在這3000+的項目發(fā)布中，有很大一部分是開發(fā)自測自發(fā)，即完全沒有測試人員的參與。這完全依賴于我們 DevOps生態(tài)建設(shè)對開發(fā)測試進(jìn)行賦能，也因此，我們的開發(fā)同學(xué)自測自發(fā)不僅保證了質(zhì)量，同時也保證了我們的交付速度。

二.核心領(lǐng)域?qū)嵺`

在了解我們的生態(tài)之后，下面來具體地看一下我們在一些核心領(lǐng)域的落地實踐。

1、規(guī)范化助力開發(fā)提效

上述分享的方法論中有一步很關(guān)鍵，那就是規(guī)范流程。那么規(guī)范流程有什么意義呢?

1)背景

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

在我們公司，可能其他公司也相同，在開發(fā)項目過程中一個核心資源就是開發(fā)資源，我們的理想狀態(tài)就是要實現(xiàn)開發(fā)資源利用最大化，理想狀態(tài)就是開發(fā)人員只需專心投入寫代碼即可。

但是現(xiàn)實情況是開發(fā)同學(xué)被各種角色干擾。主要有以下幾個問題。

對開發(fā)來說，頻繁的被打擾導(dǎo)致其時間碎片化，在各種任務(wù)之間切換導(dǎo)致效率無法保證。

對項目經(jīng)理來說，無法得知項目的實時進(jìn)度，項目是在開發(fā)過程中，還是在測試過程中。因此只能去跟開發(fā)進(jìn)行去人為溝通，這不僅導(dǎo)致了開發(fā)被打斷，也使項目經(jīng)理無法掌控整個項目過程。

對QA來說， QA最終要為質(zhì)量負(fù)責(zé)，但是QA不知道項目的這次需求變更了什么內(nèi)容，這就會導(dǎo)致變更靠人為的梳理很容易被遺漏，從而導(dǎo)致上線出故障。我們有很多血淋淋的教訓(xùn)，因為沒有更新DB，或者是一個配置忘記更新了，上線出現(xiàn)過很多次故障。

對PMO來說，PMO要收集整個項目過程的數(shù)據(jù)，通過數(shù)據(jù)去確定我們的改進(jìn)優(yōu)化分析，分析優(yōu)化改進(jìn)。但現(xiàn)在我們項目的所有數(shù)據(jù)全都依賴人工去填寫，很難保證數(shù)據(jù)的準(zhǔn)確性，從而給改進(jìn)優(yōu)化帶來困難。

通過上述分析，我們可以發(fā)現(xiàn)，我們對于整個過程的跟蹤是基于項目去跟蹤的，但是這個項目變更的內(nèi)容又是應(yīng)用維度的，所以導(dǎo)致我們沒有辦法被跟蹤，人為操作多。核心問題就是我們的應(yīng)用跟項目沒有建立關(guān)聯(lián)關(guān)系，所以我們要去建立這一關(guān)系，從而解決這個過程中的問題。

2)方案

那如何建立關(guān)系?依靠規(guī)范化。看看我們是怎么做的。

① 分支命名規(guī)范化

我們對分支進(jìn)行了命名規(guī)范的要求，分支名必須包含一個PMO標(biāo)識。這樣當(dāng)分支被創(chuàng)建、被push的時候，就自動將其關(guān)聯(lián)到項目上面，建立了應(yīng)用跟項目的關(guān)聯(lián)關(guān)系。

② 質(zhì)量檢查可視化

知道了項目變更了哪些內(nèi)容，變更的時候每次提交都可以去自動的觸發(fā)一些相應(yīng)的檢查，相應(yīng)的檢查結(jié)果報告就可以展示在這個項目上面。對于QA人員來說，可以直觀的了解項目當(dāng)前的質(zhì)量狀況;對于項目經(jīng)理來說，可以比較直觀地了解這個項目的狀況，從而去控制風(fēng)險。

③ 數(shù)據(jù)回填自動化

對于PMO來說，之前很多數(shù)據(jù)難以收集，有了關(guān)聯(lián)關(guān)系之后，我們會把這一次項目的發(fā)布數(shù)據(jù)，包括發(fā)布的次數(shù)，以及變更的行數(shù)等都自動回填，相當(dāng)于獲取了這個項目整體的變更數(shù)據(jù)。

④ 狀態(tài)流轉(zhuǎn)智能化

因為我的代碼已經(jīng)跟它關(guān)聯(lián)起來了，在開發(fā)中如果是提交到代碼，可以自動從項目已排期狀態(tài)變成開發(fā)狀態(tài)。當(dāng)我做了一些Beta驗證的時候，就可以自動地流轉(zhuǎn)到我現(xiàn)在是要提測了或是要發(fā)布了，所以這個狀態(tài)的流轉(zhuǎn)實現(xiàn)了智能化。結(jié)合完整的方案，我們就解決了各種開發(fā)被打斷，自動化手動操作過多的問題。

這個是我們的架構(gòu)。

相當(dāng)于開發(fā)與應(yīng)用關(guān)聯(lián)的工具，我們內(nèi)部把它叫做Qodin，底層是DB，Cache，其次是我們的數(shù)據(jù)存儲，然后各個工具平臺會把自己執(zhí)行的一些結(jié)果通過發(fā)送消息推送到我們的消息平臺。Qodin通過消費這些消息，通過外部的HTTP接口觸發(fā)各種工具平臺去執(zhí)行。上層是我們通過js一些頁面給用戶提供一些查看入口、操作入口等等。

3)效果

下面再來看一下我們實現(xiàn)的效果。

上圖是我們的一個項目，我們可以看到這個項目中到底變更了哪些內(nèi)容，首先是變更的一些質(zhì)量的情況，以及它的發(fā)布情況。其次是我們自動回填的數(shù)據(jù)，可以看到包括研發(fā)階段的市場自動計算，項目總市場等，線上發(fā)布的次數(shù)，代碼變更的一些信息，同時我們在一些項目的關(guān)鍵節(jié)點，根據(jù)時間計算關(guān)鍵節(jié)點的狀態(tài)流轉(zhuǎn)以及是否delay，這些都會有一個及時的項目提醒，這樣保證了開發(fā)和項目經(jīng)理等都可以及時地關(guān)注到整個項目過程，一旦有任何風(fēng)險也可以及時地暴露出來。

總結(jié)這一實踐，主要是通過規(guī)范化確定一個分支的命名規(guī)范來實現(xiàn)我們的應(yīng)用跟項目的關(guān)聯(lián)，然后保證了我們項目整個流程的自動化與高效。

2、多種手段+發(fā)布門禁助力質(zhì)量保證

我們再來看一下速度有保證后如何保證質(zhì)量，這就是我們的第二個實踐，通過多種手段和發(fā)布門禁助力質(zhì)量保證。

1)背景

我們先看一下理想，理想的狀態(tài)是開發(fā)修改完代碼之后，通過測試，提交給QA，然后QA同學(xué)集成測試，最后愉快地上線。但實際中常常會出現(xiàn)開發(fā)跟測試同學(xué)的相互抱怨。

開發(fā)人員表示我測了。QA人員卻說你這提交的是什么，你自己測了沒有?

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

對開發(fā)人員來說，首先測試條件是難保障的。開發(fā)人員做測試的時候，其實有環(huán)境的依賴，也有數(shù)據(jù)的依賴，有一些前提條件的準(zhǔn)備。但是這些常常會特別耗時間，準(zhǔn)備也非常困難，導(dǎo)致測試不足的問題。其次修復(fù)成本高，因為開發(fā)人員在前期的測試不足，提交給QA人員之后，通過QA人員發(fā)現(xiàn)了問題，然后再反饋給開發(fā)人員，反饋的周期就拉長了。開發(fā)人員這時可能已經(jīng)進(jìn)入到其他項目了，從而又有一個切換成本。

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

2)方案

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

① 多種手段保證效果

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

• 代碼review(code review)，即人工的review，現(xiàn)在我們公司已經(jīng)建立起了較好的code review文化，大家都已經(jīng)形成了這種習(xí)慣。
• 靜態(tài)代碼檢查sonar，這個地方sonar不只是sonar，在我們公司的話，主要技術(shù)棧是Java，所以我們會在 Sonar里邊會做一些java規(guī)則的檢查，比如說非法的包名、重復(fù)類、然后依賴多版本等檢查，同時也會把一些原數(shù)據(jù)的信息記錄下來，例如記錄變更的內(nèi)容，變更的依賴等。除此之外也會做sonar本身的一些規(guī)則級檢查，我們這個規(guī)則也會定期做review。
• 接口自動化，接口自動化我們分了兩部分，第一部分是我們的線上回歸測試，所用回歸的工具我們叫滅霸，它會在每次開發(fā)提測時自動執(zhí)行，把線上現(xiàn)在存量的一些接口做回歸驗證。如果你是新增的業(yè)務(wù)接口的話，我們也會有一個自動化測試平臺叫Qunit，它是基于unit的，去做一個新的業(yè)務(wù)的驗證。
• 代碼覆蓋率檢查，我們sonarqube等各種的自動化工具，都可以看到當(dāng)前的測試的覆蓋度。測試覆蓋度這塊大家其實一直有一個疑問，那就是我測試的時候就是代碼百分百覆蓋，也不能保證上線完全沒有問題。但是反向也有另外一種說法，起碼百分之百覆蓋了，還是會增加一定程度信心的，所以覆蓋率是非常重要的。

② 環(huán)境管理提升測試速度

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

③ 報告消息反饋結(jié)果

自動化的可行性有了，多種手段也有了，最后的這些報告信息怎么通知給開發(fā)人員?我們做了多維度的報告展示，包括項目維度，個人維度，還有組織維度等，同時我們也會通過內(nèi)部的Im消息精準(zhǔn)的通知到具體的開發(fā)人員，這樣方便他可以快速地解決問題，相當(dāng)于質(zhì)量阻力左移，降低了問題修復(fù)的成本。

④ 質(zhì)量門徑預(yù)防蔓延

我們會結(jié)合我們的項目管理系統(tǒng)、發(fā)布系統(tǒng)等去做質(zhì)量卡點，如果不通過，我們就會去做一個攔截，然后避免帶著問題上線。

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

在CodeReview方面，我們是基于開源工具phabricator實現(xiàn)的，我們會做到分支創(chuàng)建后自動同步倉庫，同時代碼push的時候自動去創(chuàng)建更新diff，這樣就避免了人工去創(chuàng)建以及后續(xù)操作。同時我們支持兩次提交diff的變更，這是為了解決發(fā)現(xiàn)問題并修改重復(fù)提交后的全量diff問題。不需要全量的再次diff，只需要看這兩側(cè)的一個變更。當(dāng)然如果影響范圍較大的話，還是建議全量的再diff一次。

靜態(tài)代碼檢查方面，我們使用業(yè)界通用的sonarqube，但我們的特色點是代碼push的時候它會自動執(zhí)行，然后消息反饋。同時我們有增量跟全量的報告。我們有很多歷史在的基礎(chǔ)上，如果你要求它去全量的解決問題，這在業(yè)務(wù)非常繁忙的時候是不現(xiàn)實的，所以我們做了增量，只去檢查當(dāng)前這次變更引入的問題，只要解決了這些問題并能夠保證不新增，后續(xù)再去慢慢地解決全量問題。

接口自動化方面，接口自動化這里我講的是滅霸即接口回歸問題，接口自動化大家最頭疼的就是要自己去寫case，業(yè)務(wù)變動又比較頻繁。我們的時間點是怎么做的?我們會基于檢查點的case自動生成補全清理。例如航司，航空公司是有很多公司的，比如說南航、國航、川航等，相當(dāng)于每一個航空公司對應(yīng)一個業(yè)務(wù)，我可能就要對這一個類型去進(jìn)行驗證，所以我們需要用戶先定義一個檢查點維度，然后業(yè)務(wù)在線上執(zhí)行的時候，會去生成日志，我們通過日志去采集這些具體的case，再生成補全。當(dāng)過了一段時間，如果檢查點沒有這種業(yè)務(wù)的case請求了，我們就可以自動清理，這就解決了我們?nèi)斯ぞS護(hù)case的一個痛點。

代碼覆蓋率是基于Jacoco實現(xiàn)的，也是增量跟全量的一個報告，可以看這次變更的一個覆蓋率情況。

上述是多種手段，下面看一下我們的測試環(huán)境。

我們對環(huán)境的定義是什么?這個環(huán)境肯定不是單應(yīng)用的環(huán)境，這種單應(yīng)用的環(huán)境是對于整個業(yè)務(wù)的測試，它起到的作用是非常薄弱的。所以我們對環(huán)境的定義是支持一種業(yè)務(wù)測試，能支持一種業(yè)務(wù)測試的應(yīng)用去依賴以及它所用的資源的一個組合。所以我們環(huán)境的組成就包括AppCode、數(shù)據(jù)存儲、中間件、網(wǎng)絡(luò)配置、環(huán)境變量等。

環(huán)境有了，但是不可能每次進(jìn)行一個業(yè)務(wù)測試或項目測試的時候，都去重新搭建一套環(huán)境，這樣成本是非常高的。我們之前去做項目復(fù)盤時，對于delay項目大家吐槽最多的是為什么delay?是因為環(huán)境問題。所以我們把環(huán)境的這些信息做成了模板可配置，這樣就實現(xiàn)了資源與信息的積累沉淀。

其次是業(yè)務(wù)巡檢。開發(fā)同學(xué)、測試同學(xué)只是去使用提供的環(huán)境，服務(wù)提供方要保證可用性，讓開發(fā)同學(xué)只是去用它，而不是再去為它的可靠性分擔(dān)精力，所以我們有業(yè)務(wù)巡檢。

我們之前創(chuàng)建一套環(huán)境后就實現(xiàn)了完全的資源隔離，相當(dāng)于有一套環(huán)境給全部的應(yīng)用分配資源，這是對于資源的極大浪費，同時創(chuàng)建速度也很低，所以我們又做了一個軟路由環(huán)境，基準(zhǔn)環(huán)境跟項目環(huán)境。

下面我們通過下圖來詳細(xì)解說。

首先是環(huán)境創(chuàng)建的流程，上圖中我們可以看到我們包含了環(huán)境，即應(yīng)用及其依賴，所以我們會先鎖定資源，包括Kvm、 DB這些東西，然后再進(jìn)行采集編排，然后去觸發(fā)任務(wù)執(zhí)行，調(diào)度執(zhí)行。

其次是業(yè)務(wù)巡檢，我們會定期去調(diào)用業(yè)務(wù)線提供的一些全鏈路測試case，定期去執(zhí)行，驗證這個環(huán)境的可靠性。同時我們也會去消費一些變更消息，包括配置變更、代碼變更、數(shù)據(jù)變更，去同步這個環(huán)境，這樣就保證了我們基礎(chǔ)環(huán)境的自運維。

然后是軟路由，我們會有一套基準(zhǔn)環(huán)境，是全鏈路的，包含了全部的應(yīng)用，但是對于項目來說，只需要建環(huán)境值，包含自己變更的這些應(yīng)用以及它的一些DB依賴。在真正業(yè)務(wù)測試的時候，從網(wǎng)關(guān)進(jìn)來，如果在軟路由，即自己這個項目環(huán)境里邊有，我就會走到自己項目環(huán)境，如果沒有就會請求到基準(zhǔn)環(huán)境。從這個層面來看，項目對應(yīng)的環(huán)境它只包含自己本次變革的應(yīng)用，對資源的節(jié)約是非常大的。同時因為應(yīng)用少了，我們創(chuàng)建的速度也提升了，這樣就會保證在我們的測試過程跟開發(fā)過程中，環(huán)境不會成為瓶頸了。

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

我們的質(zhì)量文件叫Cable，它會消費各種自動檢查手段、自動化工具執(zhí)行的一些結(jié)果，把他們推送的一些消息推送到 IC中，然后我們的質(zhì)量文件在消費這些消息的同時提供接口給Qodin、發(fā)布系統(tǒng)進(jìn)行攔截跟結(jié)果展示。

自動化工具我剛才介紹了4種，我們內(nèi)部還會有一些項目流程、慢查詢等自動化工具。這些工具并不全部都是我們來提供的，有很多是業(yè)務(wù)線來提供的。這是因為我們在實現(xiàn)Cable的時候，采用了一個通用的方式，即定義了一個通用的接入標(biāo)準(zhǔn)——業(yè)務(wù)線各種檢查手段，你只要把你的結(jié)果推送IC消息即可，這樣的話如果你某個業(yè)務(wù)線有自己的一些檢查工具，你只要按照這個標(biāo)準(zhǔn)去推送消息，我就可以快速地接入，在你的業(yè)務(wù)線去落地，這樣能極大的發(fā)揮整個業(yè)務(wù)對自己質(zhì)量負(fù)責(zé)的積極性，同時也會更有利于我們整個公司的質(zhì)量保證。

3)效果

① 環(huán)境效果

這個是基于之前環(huán)境不隔離即完全資源獨立的情況下做的方案，可以看到我們有應(yīng)用83個，數(shù)據(jù)庫23個，中間件7個，我們能保證10分鐘之內(nèi)交付，每一次變更都會有一些變更記錄。這是基于資源完全隔離的情況，基于上述新方案，我們應(yīng)用精簡后，環(huán)境交通速度就更快了。

② 質(zhì)量門禁效果

這是質(zhì)量門禁現(xiàn)在的狀況。

我們上述說到，業(yè)務(wù)線也可以提供各種各樣的檢查手段。我們現(xiàn)在有豐富的檢查手段，業(yè)務(wù)線根據(jù)自己的配置去選擇需要的一些手段。這是我們組織維度暫時的質(zhì)量情況，最終我們做的各發(fā)布系統(tǒng)集成的發(fā)布攔截。

總結(jié)這一部分的話就是質(zhì)量，我們通過多種手段加發(fā)布門禁，確保了我們的質(zhì)量。有了流程，保證了質(zhì)量，我們現(xiàn)在要去發(fā)布上線了。

3、應(yīng)用畫像助力發(fā)布運維

1)背景

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

QA人員發(fā)布時，先要去OPS那邊申請機(jī)器，再去配置發(fā)布步驟，即發(fā)布的一些相關(guān)的信息，配置非常復(fù)雜，前期需要許多準(zhǔn)備工作。

對于開發(fā)人員來說，開始運維，如果線上出現(xiàn)了一個問題，要先找到它這個機(jī)器的資源，然后再去找應(yīng)用，找代碼，這是非常割裂的。

還有一個問題，一旦遇到問題的網(wǎng)絡(luò)，還要去各個地方找這些信息，定位也十分困難。

所以總結(jié)起來是什么問題?

我們會各種工具平臺，雖然大家現(xiàn)在強(qiáng)調(diào)一站式的，但是在背后的話，各種資源服務(wù)還是不同的Team提供。因為不同的Team提供的時候只關(guān)注自己管理的領(lǐng)域，所以它的管理維度是不一樣的，這樣就會導(dǎo)致管理維度不一樣，這些數(shù)據(jù)信息無法串聯(lián)起來。

2)方案

① 應(yīng)用畫像

基于這個問題，我們可以思考一下，我們真正發(fā)布運維的到底是什么東西，它最小單元是什么?我們確定了我們最小的管理單元，其實就是我們的應(yīng)用，那么我們應(yīng)用有哪些屬性呢?我們就猜出了我們的應(yīng)用畫像，包括基本屬性、環(huán)境屬性、發(fā)布參數(shù)和依賴信息。

基本屬性是身份，Appcode就是它的唯一標(biāo)識。

這里強(qiáng)調(diào)一下等級，之前也有人問我等級有什么用，等級是非常有用的，我舉個例子，有了等級，你才知道你這個服務(wù)的重要程度，你在運維的時候你才能知道優(yōu)先把資源傾斜給哪些應(yīng)用，先去運維哪些。

• 環(huán)境屬性，包括應(yīng)用要運行的軟硬件環(huán)境配置等。
• 發(fā)布參數(shù)，包括編譯參數(shù)、打包參數(shù)、發(fā)布策略等。
• 依賴信息，包括我有哪些網(wǎng)絡(luò)依賴，例如我們的域名owner，數(shù)據(jù)庫依賴，以及服務(wù)之間的調(diào)用關(guān)系。

② 發(fā)布流程

只有真正拆分出來我們管理的最小的單元是什么，我們才可以對它進(jìn)行運維，進(jìn)行發(fā)布，所以我們基于應(yīng)用畫像拆分出應(yīng)用。下圖是我們的一個發(fā)布流程。

首先是應(yīng)用確定了自己的應(yīng)用畫像，然后使應(yīng)用畫像存在一個配置系統(tǒng)中，然后調(diào)度系統(tǒng)去從配置系統(tǒng)拿到一些配置，完了出發(fā)到我們Jenkins，部署到各種的調(diào)度資源中。

這里要強(qiáng)調(diào)的是我們這個地方有一些自定義的階段，通過這些自定義我們可以把那些非標(biāo)準(zhǔn)的過程納入進(jìn)來，業(yè)務(wù)線就可以在這里去做自己的適配。

③ 運維流程

運維也是基于一個應(yīng)用的，當(dāng)一個應(yīng)用的某些指標(biāo)報警，我就可以去快速地找到應(yīng)用對應(yīng)的Trace鏈路、日志、事件系統(tǒng)。

根據(jù)這三板斧，我就可以去定位到我的問題，最后對應(yīng)我們的運維系統(tǒng)去做對應(yīng)的運維操作。

3)效果

這是我們的應(yīng)用畫像效果。其中有應(yīng)用形式配置，包括它的一些服務(wù)依賴屬性，服務(wù)調(diào)用屬性。

上述是我們發(fā)布的過程，可以看到在發(fā)布過程中我們可以知道當(dāng)前的發(fā)布進(jìn)度，還會對接我們的異常日志，以及報警信息。還有我們的監(jiān)控，變更的事件，Trace鏈路，這三板斧實現(xiàn)了我們對應(yīng)用的可運維。

4、流水線助力持續(xù)交付

最后是流水線。我們剛才說的是對單應(yīng)用的管理，但是其實真正項目的時候是多應(yīng)用的發(fā)布，多應(yīng)用的交付，所以我們拆分了兩種類型的流水線，第一個就是單應(yīng)用的流水線，包括拆開發(fā)、測試、集成和線上。

流水線的好處我想大家應(yīng)該都知道，我這邊總結(jié)兩點：

• 使整個流程更加的自動化;
• 使一些上游的數(shù)據(jù)向下游傳遞。

我舉個例子，我們開發(fā)測試的流水線在這個過程中會產(chǎn)生一些數(shù)據(jù)，例如DB變更，DB的配置變更，定時任務(wù)監(jiān)控等，這些都可以自動的識別出來，這樣的話就可以在線上的時候自動把這些信息拿到，然后業(yè)務(wù)線只需要改一下Beta和線上的一些不同配置以及具體的值即可，這樣我就可以不用人工地去各個地方信息搬運，線上也可以快速地交付。

單應(yīng)用的交付完成之后，其實是更多的不是項目維度，項目維度我們可以組織讓業(yè)務(wù)線去做人工地編排，編排應(yīng)用之間流水線以及它的一些前置依賴。

在一般情況下交付到了發(fā)布就完成，其實我們在發(fā)布完成之后還可以做一些服務(wù)治理健康保障，例如我們有觸發(fā)的壓測，以及強(qiáng)弱依賴等。

這就是我們具體的實踐。我再總結(jié)一下，具體實踐第一是規(guī)范化，保證我們整個流程的順暢與自動化。第二是多種手段保證質(zhì)量，質(zhì)量門禁保證問題的蔓延。第三是拆分應(yīng)用畫像，使畫像確定我們的運維最小單元，實現(xiàn)可發(fā)布可運維。第四是通過流水線使我們整個流程更順暢。

三、未來規(guī)劃

最后再來看一下我們近期的一些規(guī)劃。

1、開發(fā)平臺

第一部分是開發(fā)平臺。在整個開發(fā)活動過程中，所占比例最大的還是寫代碼，我們怎么能讓寫代碼效率更高，所以我們計劃做一個開發(fā)平臺，其實也是一個開發(fā)插件。這個插件主要有哪些功能呢?

它可以接口調(diào)用自動生成，我們會有原數(shù)據(jù)信息中心，去采集我們現(xiàn)在整個公司提供的接口信息，然后業(yè)務(wù)在開發(fā)代碼的時候就可以自動拿到這些依賴，然后自動地生成代碼。

生成代碼的同時，它還可以進(jìn)行一些服務(wù)治理的配置，后續(xù)我們希望聯(lián)動其他的工具，例如我們聯(lián)動qconfig(配置中心)配置自動生成以及聯(lián)動我們的服務(wù)治理，然后自動生效等。

開發(fā)平臺，極大地提升我們的開發(fā)效率。開發(fā)平臺最終要達(dá)到的效果就是讓我們代碼編寫更簡單，規(guī)范落地有載體，服務(wù)治理更有效。

2、服務(wù)可觀測平臺

第二部分是服務(wù)可觀測平臺，剛才我們說了基于應(yīng)用畫像讓我們應(yīng)用做到可觀測，可發(fā)布，可運維，但是其實對于它整體的狀態(tài)，我們還需要有一個可觀測平臺?；谠圃乃枷耄屛覀兊膽?yīng)用服務(wù)可觀測，它主要分為三個領(lǐng)域的實踐。

• 系統(tǒng)技術(shù)先進(jìn)性，系統(tǒng)當(dāng)前使用的是不是TC組件，TC組件是不是最新的，TC組件它其實是所有服務(wù)的一個基石，后續(xù)的Trace鏈路，各種的治理全都依賴于它。技術(shù)先進(jìn)性可觀測之后，尤其是團(tuán)隊維度，在整個公司技術(shù)演進(jìn)的時候，我就可以先著力地去改進(jìn)它，去發(fā)力去做一些感性的應(yīng)用。
• 健康度，系統(tǒng)健康度是指我當(dāng)前的系統(tǒng)是不是有報警，它是不是多機(jī)房災(zāi)備，質(zhì)量保障手段是不是足夠健全等，我可以據(jù)此了解應(yīng)用的健康度。
• 一旦遇到了問題，我們可以快速定位，像上述我們說的日志、Trace以及監(jiān)控等。

已上是分享的全部內(nèi)容。

Q&A

Q1:在CI/CD流水線執(zhí)行通過后才可以進(jìn)行test測試流水線執(zhí)行。怎樣控制兩個流水線的執(zhí)行順序?建立兩者的關(guān)聯(lián)?

A1：我有三點建議。第一是流水線的出發(fā)盡可能的做到自動化，自動化的話就相當(dāng)于避免人工的處罰，這樣你的順序基本上就可控了;第二是設(shè)置卡點，流水線需要有一些前置的卡點，就是達(dá)到什么標(biāo)準(zhǔn)，然后才能去執(zhí)行這條流水線，這樣就解決了這一問題，CI/CD不通過是不允許執(zhí)行測試流水線的;第三是在一個項目階段，流水線其實是對同一個應(yīng)用來說，或者是同一個應(yīng)用同一次提交來說，它其實不是說同一次提交。同一個應(yīng)用來說的話，流水線是區(qū)分開發(fā)，測試，集成，最終到線上的，所以我們可以確定一個唯一的標(biāo)識，然后每一個流水線里邊都會有一個唯一標(biāo)識，可以把這個過程給串聯(lián)起來。

Q2：怎么建立度量體系?

A2：我有幾點建議，首先度量一定是為了解決問題的，我們做度量的時候，先要確定我們需要解決的問題的痛點是什么。根據(jù)我的理解，度量不是面向一線工程師的，所以在做度量的時候，一定要與TL一層的管理對齊目標(biāo)，對齊目標(biāo)需求，再建立對應(yīng)的指標(biāo)體系，進(jìn)行指標(biāo)的采集，度量。度量其實分為過程指標(biāo)和結(jié)果指標(biāo)。我們一般做度量的話，度量格就涉及到考核了。我覺得做度量這件事情，你首先要確定你為了做這件事情，可能需要獲得更多的支持，我們要先去拿結(jié)果指標(biāo)跟上層對齊目標(biāo)，然后獲得更多的資源，再去根據(jù)具體問題看過程指標(biāo)。最后一個原則就是MARI原則(度量分析回滾改進(jìn)原則)，我們遵循這個原則，讓數(shù)據(jù)說話，用數(shù)據(jù)去解決問題。

Q3：如何進(jìn)行需求的分層管理?

A3：我說一下我們公司的一個具體實踐。我們公司是采用OKR的管理機(jī)制，首先我們確定了整個公司的業(yè)務(wù)目標(biāo)，然后各個團(tuán)隊去制定自己的O目標(biāo)，之后根據(jù)目標(biāo)去設(shè)立對應(yīng)的一些結(jié)果指標(biāo)，然后結(jié)果指標(biāo)再去拆分成具體的一些產(chǎn)品需求，再去對這個需求進(jìn)行跟蹤管理。所以就是分了三級，對于上級來說，我們關(guān)注的是整個目標(biāo)的情況;對于中層來說，關(guān)注的是結(jié)果指標(biāo)這一層，看這一個點我是不是要達(dá)標(biāo);對于一線來說，關(guān)注的是需求的交付。

Q4：DevOps是不是一定要基于一些方法論?

A4：比如說項目管理，我們一般與敏捷相結(jié)合的話，有了敏捷方法論，然后我們?nèi)ヂ涞剡@個項目管理，例如現(xiàn)在最常用的是看板管理，它使用這些方法論會讓我們解決問題更快捷，更高效，但是它不是必須的，比如說TDD，我們在建立DevOps體系，當(dāng)初并沒有TDD，TDD測試驅(qū)動開發(fā)其實是在最近幾年體系比較完善的時候才要做的事情。所以在沒有這些方法論之前，我們做的是一些單點的提效，當(dāng)然有這些方法論的時候，我們?nèi)プ鰠⒖?，然后把這些單點的流程做場景化的落地實踐。理論跟實踐結(jié)合起來，我覺得會達(dá)到更好的效果。前兩天看一些大佬們分享，DevOps實踐其實是重在道法器術(shù)，道當(dāng)然指的方法論，所以在一些方法論的指導(dǎo)下我們?nèi)ヂ涞貙嵺`可能會更好一點。

Q5：DevOps跟SRE有什么區(qū)別?

A5：下面是我的一些理解，可能有些偏頗，然后大家如果覺得不合適，我們可以再探討。從內(nèi)容方面，我覺得是DevOps是一套方法論，它最終的體現(xiàn)是落地到一套工具，平臺，它包含了項目管理、開發(fā)、測試、運維等多個領(lǐng)域，而SRE主要還是在運維領(lǐng)域;從目標(biāo)層面來看，DevOps是保證項目過程的質(zhì)量和目標(biāo)，當(dāng)然它也對最終服務(wù)的健壯性負(fù)有責(zé)任。但是SRE主要還是為服務(wù)的可靠性提供保障;從執(zhí)行人員來看，DevOps發(fā)起方一般可以是PM，質(zhì)量保障運維或者工具等團(tuán)隊，而SRE主要還是運維人員。所以從我的理解層面來說，DevOps是囊括運維領(lǐng)域的。