分享內(nèi)容包含如下四個方面：
DevOps 建設(shè)面臨的挑戰(zhàn)
在這些挑戰(zhàn)面前如何找到突破口
MVP 是如何助力 DevOps 建設(shè)？
我會在這里重點分享我在 Qunar 落地 DevOps 的過程中，是如何結(jié)合 MVP 的原則，逐步優(yōu)化和完善的。最后是我總結(jié)的關(guān)于 DevOps 體系的兩張圖，希望給正在搭建體系平臺的朋友一些啟發(fā)。
一、DevOps 建設(shè)面臨的挑戰(zhàn)
首先看一下挑戰(zhàn)，回到 DevOps 的價值來講，很多人在想 DevOps 是什么，DevOps怎么做？其實我們要重新回到 DevOps 本身的價值來看，我們?yōu)槭裁匆?DevOps？DevOps 的核心價值跟精益、敏捷是一致的，都是要實現(xiàn)企業(yè)從一個需求，甚至是idea到交付給用戶，整個過程快速、靈活、質(zhì)量可靠。
這里面提到一個又要速度又要質(zhì)量，同時我們還希望從用戶那兒快速獲得反饋，形成閉環(huán)。所以我們做 DevOps 其實服務的是企業(yè)的業(yè)務目標，這個大家一定要記住，因為只有知道我們?yōu)槭裁闯霭l(fā)，我們才不會走偏。
企業(yè)內(nèi)部實施DevOps，會面臨各種挑戰(zhàn)，我把它總結(jié)為四個方面，每個方面展開都會特別多。第一：DevOps 的體系是非常復雜的。大家在很多大會中都有見過《研發(fā)運營一體化成熟度模型》，從模型中我們就不難看出，其體現(xiàn)所覆蓋的技術(shù)范圍和影響的人群范圍都是非常廣泛的。縱向來看，第一層研發(fā)運營一體化過程，下面依次還有應用架構(gòu)、安全管理和組織結(jié)構(gòu)。
第二：關(guān)于企業(yè)文化。很多人說 DevOps 是一種文化的運動，需要先從組織結(jié)構(gòu)的調(diào)整開始，因為沒有組織結(jié)構(gòu)的調(diào)整，我們永遠打破不了那堵墻。在很多大師的演講PPT中，一個箭頭就打破了 Dev 與 Ops 的那堵墻，而在不同企業(yè)落地的時候，想做到這一點，可能需要幾個月，甚至幾年。所以這個是我們需要克服的點。
第三：團隊的能力。我們在實踐的時候會發(fā)現(xiàn) DevOps 是流程、規(guī)范、工具三維一體才能真正落地，那如果原有的團隊不具備這種能力怎么做自動化？所以這個時候團隊的能力就會變成快速搭建平臺的短板。
第四：是成本收益。我們回到商業(yè)的本質(zhì)來講，企業(yè)一定是要盈利的。我們搞 DevOps 落地，不是在搞科研，不是要把 DevOps 水平達到一個世界的先進水平或者國內(nèi)的先進水平，我們一定要回歸到服務企業(yè)的商業(yè)目標這個點。所以，落地 DevOps 也必然逃不了計算投入產(chǎn)出比。
回想當初自己做 DevOps 的時候，要在企業(yè)內(nèi)部立一個OKR，經(jīng)常會被挑戰(zhàn)，“你的ROI是怎樣的”？一開始自己很不舒服，我做那么多事，為什么總是覺得我這個事不值得做呢？后來我轉(zhuǎn)變思路之后，反倒覺得這是很好的考量一件事情價值的度量方式。沒有度量就無法管理，持續(xù)優(yōu)化更是無從談起。所以怎樣考量投入成本和取得的收益，也是非常重要的點。
面臨這些挑戰(zhàn)，我們很容易陷入一個困局。我們是不是要新招 DevOps 工程師，或者成立獨立的小組？誰應該來主導這個事比較合適呢，是運維、項目管理還是基礎(chǔ)框架呢？從哪里開始呢？有沒有標準的實施路徑呢？每個部門的職責邊界怎么劃分呢？陷入困局的我們，總是要找到突破口的。
接下來我就與大家分享一些個人經(jīng)驗，如何在不同階段找到突破口?？赡苣阒恍枰业揭粋€突破口，后面的路就會很順暢的走下去了。
二、如何找到突破口
關(guān)于實施 DevOps，我總結(jié)了九個字，這九個字說起來很簡單也朗朗上口，那就是“搭班子，定調(diào)子，邁步子”。
搭班子是明確職責，不一定要從外面引來很多專家，只是說做這個事的時候大家有明確的職責，這個叫做搭班子。比如說我在去哪兒的時候，開始做的時候就是配置管理組發(fā)起的。我們先從發(fā)布系統(tǒng)的優(yōu)化開始，當然我去的時候去哪兒就已經(jīng)有了一套自動化的發(fā)布系統(tǒng)?？赡苡行┤擞X得不可思議，但是沒有關(guān)系，每個公司都有特點，或者每個公司的工作崗位邊界不同，只要我們在這個階段明確下來這個事誰在做，在搞什么事。
定調(diào)子就是統(tǒng)一目標，統(tǒng)一目標的時候我們要明確實施周期和實施目標。明確實施周期，是說我們是要一年搞成，還是作為企業(yè)內(nèi)部的優(yōu)化項目慢慢搞就好了。這個是很重要的，因為有一些企業(yè)現(xiàn)在是非?？粗?DevOps，覺得自己落后很多，想快速把這個搞起來。
經(jīng)常有人問我你在去哪兒七年做成這樣，如果我請你過來你能幾年做好。這個問題其實是很難回答的。首先，一定程度上，投入資源的比重越大，實施的周期會越短。但是，實施周期不會因為投入資源的無限擴大而無限縮短。
我們可以縮短踩坑浪費的時間，可以省去走彎路浪費的時間，但是，在企業(yè)內(nèi)部摸索出一條適合的路子，必然是需要一定時間的，揠苗助長的方式只會損害長期利益。舉例來說，我買了一輛跑車回來，我就能成為一名優(yōu)秀的賽車手了嗎？
關(guān)于統(tǒng)一目標還有一個想跟大家分享的，就是當年我在與 Ops、基礎(chǔ)架構(gòu)組一起討論搞DevOps 門戶網(wǎng)站，關(guān)于它的作用和功能，真的就是很簡單的畫了一個手串。手串中間是應用，周圍每個圈是一個個散在各處的系統(tǒng)。
我說，有了這個入口平臺，工程師可以從需求管理到開發(fā)到測試再到最后的上線、運營，都能一站式搞定。大家看了這個圖之后覺得太好了，一拍即合就開始搞了。我們甚至連正式的立項過程都沒有走。
可能這也是去哪兒的文化決定的，大家認為這個目標正確，是值得做的，就可以得到資源和支持?？梢?，一個清晰的目標對于推進工作有多么重要，這個清晰是好理解，不是講大道理，是告訴大家我要做的東西，每個人都很清晰。
最后就是邁步子，今天跟大家分享的就是堅持 MVP 原則去落地我們的 DevOps 整體的體系，所以會重點在如何邁步子上。
MVP 是什么呢？MVP 即：Minimum Viable Product，翻譯過來是最小化可行產(chǎn)品。這個概念是由硅谷創(chuàng)業(yè)家 Eric Rise 在其創(chuàng)作的《精益創(chuàng)業(yè)》一書中提到的。這本書是指導創(chuàng)業(yè)公司如何走向成功，以及在創(chuàng)業(yè)的過程中如何提高成功概率的。
但是為什么在這里提到 MVP？我覺得MVP有一個目標，就是以最快的速度、最小的精力完成一次反饋的循環(huán)，這個反饋的循環(huán)對于我們做持續(xù)改進的人來講，也是非常重要的。我們會假設(shè)某個實踐是有效的，或?qū)μ岣哔|(zhì)量有效或者對加快交付速度有效，但是我們要在企業(yè)快速落地，就需要快速實踐，形成一個閉環(huán)告訴自己這個假設(shè)是否真的正確。
這與創(chuàng)業(yè)公司CEO去找到自己的第一批用戶，驗證自己的商業(yè)邏輯是否可行是完全一致的。
三、MVP 助力 DevOps 建設(shè)
接下來我跟大家分享四個案例，每個案例都是從堅持MVP原則，開始一個新的優(yōu)化方向。
從解決一個痛點開始。剛才講到我們面臨那么多復雜的挑戰(zhàn)和自己所陷入的困境，我們總要找到一個突破口。這個突破口，我建議大家從找到第一個痛點開始。誰痛？有可能是開發(fā)人員痛，有可能是測試人員痛，總之需要先到一線去了解誰最痛，這個人會是你第一個解決方案的忠實用戶。
那這個事的背景是說在三四年前，那時候 PMO 出于管理的目標需要收集很多項目數(shù)據(jù)，比如說計劃提測時間什么時候、實際提測、計劃上線、實際上線，這些數(shù)據(jù)拿到之后可以分析項目的過程是否健康，以及發(fā)現(xiàn)潛在風險。
但問題是，工程師不愿意填這些數(shù)據(jù)。等到被發(fā)現(xiàn)數(shù)據(jù)空著的時候，工程師就憑借記憶去填，甚至按照計劃時間與補實際時間。這樣的數(shù)據(jù)，不僅沒有分析的價值，而且工程師還會抱怨，我已經(jīng)夠忙了你還要我做這些事。
另外一個問題是，開發(fā)人員在提測前，需要給測試人員寫一個非常詳盡的部署步驟。而因為時間一久，開發(fā)工程師開發(fā)的時候可能做了五步，但到寫的時候就只想起三步，測試人員拿到長篇大論的部署步驟開始搞，結(jié)果還是經(jīng)常出錯。
這些都是我們識別出來的痛點，那我們當時做什么呢？我們對這些問題進行了根因分析，初步判斷是數(shù)據(jù)分離，信息不互通導致的。
于是，我們做出如下假設(shè)：如果能夠建立項目與工程信息的互通，這些問題應該能夠迎刃而解。所以當時就做了第一個嘗試，建立一個分支規(guī)范，就是拉取代碼的時候在分支名稱上標注需求編號，利用 githook 方式監(jiān)測工程師的動作。如果新建一條分支，我們就自動回填到 Jira 需求中的實際開發(fā)時間。
等我們的發(fā)布系統(tǒng)開始做發(fā)布，我們會打 Tag，那時候我們會把測試用的 Tag 的生成的時間點作為實際提測時間點。當時我們就想先去嘗試這樣的東西，看開發(fā)工程師是否接受這個規(guī)范。第一次嘗試非常成功，大家覺得原來這個數(shù)據(jù)你不僅幫我回填了而且還是最準確的。
當然在這個方案里面大家看到這些 githook 其實不是一個最優(yōu)的技術(shù)方案，因為我們?nèi)绻竺嫦胍龈嗉傻氖虑?，修?githook 很麻煩，而且 hook 是一次性不可重試的。所以我們做完第一個嘗試發(fā)現(xiàn)這個路是完全正確的時候，我們就推出第二個迭代，優(yōu)化技術(shù)方案。我們把 githook 去掉了，開始建立工程效率的消息中心，系統(tǒng)間通過消息驅(qū)動的方式實現(xiàn)流程自動化。
比如說 Git 拉了一條 branch，githook 就只管發(fā)一條信息出來就好了，不用管哪個系統(tǒng)來消費，以及消費完這條消息以后做什么，這些 gitlab 都不用關(guān)心。對于 JIRA，它就可以來監(jiān)分支創(chuàng)建的消息，更新項目的實際時間，構(gòu)建流水線系統(tǒng)可以消費這條消息，實現(xiàn)代碼自動掃描。
第三次再去迭代的時候，我們的重心放在擴充整個平臺的功能范圍，不僅是做消息中心，我們還要對收集的CI數(shù)據(jù)進行聚合展示。
第四次迭代，更深入一步，開始把動作集成進來了。就是測試工程師進入這個界面后，順道還可以執(zhí)行一個發(fā)布動作。以下，就是這個平臺最新的界面展示：
這個需求上面有36558的需求編號，下面涉及到的五個工程都是為這個項目做的改動，從分支號上可以看到關(guān)聯(lián)。最后的beta／prod標簽，是表示該分支改動已經(jīng)發(fā)布到測試環(huán)境還是線上環(huán)境。同時，每條工程分支的最新CI結(jié)果也可以在這里做一站的展示。
而且更有趣的是這個平臺其實不是我的團隊做的，而是我們的機票業(yè)務部門做的。所以回到搭班子的問題，真不是要所有的事情都由我來做。只要大家明確功能邊界，向著一個目標做就可以。能夠團結(jié)到業(yè)務線參與其中是更好的。
第二個案例：借勢發(fā)力、乘勢而上。
我們做DevOps的目標是要讓業(yè)務團隊靈活起來，交付快起來，但是首先自己要是一個很敏捷的團隊，我們自己的需求要能夠隨需而變。
這個案例當時的背景就是我們做了很多的CI工具，但是發(fā)現(xiàn)推行一段時間之后使用效果并不好。比如Sonar檢查結(jié)果，雖然已經(jīng)精準的推送給了開發(fā)人員，但是開發(fā)工程師如果不修復，問題還是會流到測試階段。所以為了控制問題蔓延，還需要有一個質(zhì)量門禁系統(tǒng)。鑒于當時我們的 sonar 系統(tǒng)已經(jīng)比較完備，我們可以做到對工程師 push 代碼后自動執(zhí)行 Sonar 掃描，1分鐘后工程師收到 Sonar 報告。于是我們就準備在門禁系統(tǒng)中，優(yōu)先實在 sonar 增量問題的攔截。
就在我們開始規(guī)劃這個事情的時候，支付業(yè)務線的技術(shù)負責人找到我說，我們最近出了兩起故障，全都是因為慢查詢導致的。我們在測試環(huán)境有一個慢查詢的工具，有什么辦法能夠做到，發(fā)布線上前去系統(tǒng)中校驗一下是否有慢查詢。如果有，就不允許上線發(fā)布。
我馬上想到正在規(guī)劃中的質(zhì)量門禁系統(tǒng)，于是一拍即合，把接入慢查詢工具加入到第一次迭代需求中。通過這次溝通，我們緊緊的抓住了這個業(yè)務線，這個業(yè)務線不僅是門禁系統(tǒng)的第一個用戶，而且成為了系統(tǒng)的免費宣傳用戶。
其實一個完整的門禁系統(tǒng)，還需要支持用戶能夠靈活配置，同時支持在緊急的情況下還要跳過的審判流程。但是第一次迭代中，我們評估了低頻事件和個性需求，僅把最核心的功能放入第一次迭代。上線之后用戶口碑非常好，我們才開始做審批，而且還把審批接入手機端，隨時隨地可以做審批。
做完這些我們才開始擴展平臺中接入的其他CI工具。現(xiàn)在，已經(jīng)集成到平臺的，不僅有工程效率部自己負責的工具，還有業(yè)務部門開發(fā)的測試自動化工具。
這個案例想跟大家分享的核心思想是， DevOps工具落地時，系統(tǒng)架構(gòu)和功能需要有認真的規(guī)劃，一個好的架構(gòu)才能支持未來的功能擴展。但是，開始功能開發(fā)的時候，不是要一次性全部做好。選擇做什么容易，反倒是選擇不做什么是比較難的。一定要規(guī)劃好每次迭代的功能范圍。
所謂的MVP，就是要快速試錯，為了證明決策的正確性、可行性，首先要快起來。
第三個案例，愿意分攤成本還是真需求。
DevOps 轉(zhuǎn)型前期，需要優(yōu)化的需求很多，你隨便抓住一個痛點，踏實做完就會有收益，用戶就會認可。但是，這些表面問題掃過一遍后，再去找優(yōu)化點就需要花些心思了。什么才是真需求，而不是一個錦上添花，或者是臆想出來的需求。
這個時候，就可以拿一個最簡單直接的標準來衡量，那就是用戶愿不愿意跟你分攤成本。我的前領(lǐng)導告訴我一個秘訣，就是你看看業(yè)務線是否已經(jīng)有人開始做了。業(yè)務線真正的目標是業(yè)務量往前沖，如果他們都愿意在工具上花精力了，那一定就是剛需。
這個案例是圍繞如何快速搭建一套可測試環(huán)境的。其實這也是微服務架構(gòu)所帶來的一個挑戰(zhàn)。一個業(yè)務需求哪怕只修改一個應用，但是要想完成對變更的驗證，就需要搭建其他的幾個甚至幾十個應用才能完成。在當時Qunar業(yè)務快速發(fā)展的情況下，基于固定環(huán)境進行維護、分配，已經(jīng)成為影響交付效率的瓶頸。于是好幾個業(yè)務線的測試同學就開始做各種嘗試。了解到這些情況后，我們覺得公司應該有一個可以提供更靈活、快速的創(chuàng)建一套業(yè)務測試環(huán)境的平臺。提出方案的時候，我們既沒有開始使用Docker，也沒有特別先進的自動化運維。我們就覺得這個方向是對的，所以這個平臺更是花了好幾年的時間在打磨。
經(jīng)過三個版本的迭代，到現(xiàn)在Noah平臺已經(jīng)是一個非常棒的產(chǎn)品。在與同行交流的時候，我也經(jīng)常拿 Noah 出來炫耀。一個由幾十個應用外加幾十個中間件的環(huán)境，從點擊創(chuàng)建按鈕到交付給測試人員使用，僅僅十幾分鐘的時間。
但是，這個平臺能做到今天的樣子，過程中需要克服的困難有很多。比如說第一個難點就是如何解決應用自適應環(huán)境的問題。環(huán)境動態(tài)起來了，應用的配置文件怎么更新呢？接下來，我們承諾用戶說可以10分鐘內(nèi)交付一個包含100個應用的環(huán)境。但是基礎(chǔ)設(shè)施能不能扛住這樣的并發(fā)呢？所以解決環(huán)境管理的問題，絕對是一個系統(tǒng)工程。過程中涉及的技術(shù)難點多，需要配合的部門多，需要考慮的業(yè)務場景也會多種多樣。你不可能等到把所有問題都解決了，再推向用戶使用。
在1.0版本的時候，因為業(yè)務有剛需，所以當時在界面交互的友好性上就不需要特別關(guān)注。而是集中精力先攻克第一個核心的技術(shù)難點——應用的配置文件模版化。在這里還要分享一個實踐成功的經(jīng)驗，就是向你的第一批用戶提供VIP服務。Noah產(chǎn)品的第一批用戶，我們都提供哪些VIP服務呢？我們的產(chǎn)品經(jīng)理真的是申請一條開發(fā)分支，親自幫業(yè)務線修改配置文件。
大家可以看到，即使是針對剛性需求提出的解決方案，都需要提供這樣的貼心服務才能真正落地。其實背后的原因不難解釋，人都是有惰性的。而由惰性帶來的慣性力量巨大。而我們做DevOps轉(zhuǎn)型，就是在跟各種慣性抗衡。
所以，每一個DevOps從業(yè)者要慢慢建立起服務意識。我們不再是僅僅制定標準或提供工具，我們是在提供服務。我們的用戶是整個研發(fā)過程中的所有角色，可能是產(chǎn)品經(jīng)理、開發(fā)、測試工程師，或是項目管理人員，還有做決策的管理者。用戶的需求就是我們應該想辦法去解決和滿足的。當然，大家千萬不要誤解為，是他們說什么我們做什么。我們要解決的是真正的需求，不是表面現(xiàn)象。
我們的平臺，也是給去哪兒的產(chǎn)品再打一次廣告，這個是真實的環(huán)境，
下面要演示的就是通過Noah平臺真實的一次環(huán)境構(gòu)建。從截圖中可以看到，一個包含83個應用，23個數(shù)據(jù)庫，7個中間件點環(huán)境，創(chuàng)建時間僅需要9分鐘。
第四個案例與度量有關(guān)。在做度量的時候，大家首先要區(qū)分虛榮性指標和可執(zhí)行指標。
虛榮性指標和可執(zhí)行指標也是精益創(chuàng)業(yè)中提到的兩個概念。什么是虛榮性指標呢？所有假大空的指標，都是虛榮性指標?？吹竭@樣的指標，你完全不知道指標說明了什么，或者自己要做什么。
而可執(zhí)行指標恰恰與其相反，指標就是一個風向標，當前的優(yōu)勢或不足，以及下一步的行動，一目了然。
DevOps 的最終目標是要按需、快速交付可靠的軟件。那我們就要看每一次的改進，到底在這三方面做了哪些貢獻。是幫企業(yè)節(jié)約了成本，還是加快了流程，或是提前發(fā)現(xiàn)了質(zhì)量問題。那么節(jié)約了多少成本，流程加快了多少，，發(fā)現(xiàn)多少問題，這些問題都是什么級別的問題。下面給大家一個直觀的例子。
比如說這是我們當時推行CI工具的時候做的一個統(tǒng)計，統(tǒng)計指標的是接入平臺的工程數(shù)是多少。從圖中看，這個值還是很可觀的。已經(jīng)有四千多工程接入，當時公司一共6000多個工程，除了不活躍的，基本已經(jīng)全量接入。
但是現(xiàn)在想想，這個就是個虛榮性指標。因為接入不代表真的產(chǎn)生作用。如果大家無視Sonar的掃描結(jié)果，那么整個事情就是在浪費資源。
那這件事情該用什么指標度量呢？Sonar問題的增長趨勢，Sonar問題的修復時長，這兩個指標是可執(zhí)行指標。如下圖。從問題修復時長數(shù)據(jù)的變化，能夠驗證我們的門禁系統(tǒng)的價值假設(shè)。這也就完成了MVP的一次認知循環(huán)。
再比如說，Noah平臺創(chuàng)建環(huán)境很快，但是環(huán)境穩(wěn)定性一直是一個頭疼的問題。當我們開始在提升穩(wěn)定性問題上投入精力的時候，我們需要首先分析引發(fā)環(huán)境不穩(wěn)定的各種原因。然后持續(xù)去度量，來驗證我們所采取的手段是否真的對穩(wěn)定性有提升效果。所以，大家下次再定義度量指標的時候，首先要問問自己，這是一個虛榮性指標還是可執(zhí)行指標。
這一頁想跟大家分享的是，參與DevOps體系建設(shè)的團隊，要經(jīng)歷的三個時期——依賴期、獨立期，互賴期。
依賴期，表現(xiàn)有兩種。一種是，我們的改進需求和方案完全依賴外界輸入，別人讓我做什么我做什么。這種依賴很可怕，其實隱含的一個根本原因就是我們可能不夠?qū)I(yè)。而另外一種依賴型是，團隊沒有開發(fā)能力，我的方案落地需要向外部團隊申請資源。這種依賴型可能會因為資源得不到支持，而推進進度緩慢。處在依賴期的團隊，務必要想辦法盡快完成向獨立期的躍遷。
而獨立期的團隊表現(xiàn)有哪些呢？第一，能夠就業(yè)務線的問題給出專業(yè)的解決方案。第二，解決方案的上線時間可預期。比如我們承諾一個月上線的功能，一定能夠在一個月之內(nèi)完成。一個月聽起來很長，但是如果我們真的說到做到，已經(jīng)是一個很大的進步了。在這里，為什么我只提到交付的可預期，而沒有要求特別快呢？對于內(nèi)部改進團隊來說，很多事情都是細水長流，持續(xù)改進的。
提前一周上線到底能帶來多大收益呢？其實不是特別好衡量。而做到如期兌現(xiàn)承諾，對于一個團隊的收益就會不一樣。我們會慢慢建立起來與用戶間的信任關(guān)系。這種信任關(guān)系，會是我們能夠持續(xù)影響用戶，不斷優(yōu)化過程的堅實基礎(chǔ)。
在這里還想給團隊幾個建議，第一就是打造一個敏捷的團隊。一定要記住這一點，我們自己先敏捷起來，才有資格指導別人如何變得敏捷。第二個就是做自己規(guī)范和產(chǎn)品的第一個用戶。很多DevOps團隊，做的工具都是給別人用的，讓自己操作一下都不能很順暢。制定的開發(fā)規(guī)范是給別人用的，自己團隊開發(fā)恨不得連版本控制都做不到。
獨立期的下一個躍遷階段就是互賴期。與誰互賴，那肯定是與我們的用戶呀。DevOps團隊的終極目標其實是成就用戶的成功。所以我們還要培養(yǎng)共贏思維。我們的目標不是要證明自己做的工具、平臺有多么多么好。而且要看到業(yè)務線在使用了這些工具后有哪些提升。只要這樣，我們才能與業(yè)務線建立良好的溝通。
比如說我們?nèi)ツ膬旱墓こ绦蕡F隊可以說是已經(jīng)進入互賴期。業(yè)務線遇到什么困難，或有一些好的想法，都會想到先和我們討論一下。一是我們積累了很多數(shù)據(jù)和底層的自動化平臺，二是大家一起討論后總還能碰撞出一些不一樣的火花。我覺得達到互賴期后，公司的DevOps文化也就形成了。
四、遇見未來
我是這樣理解 DevOps 的，DevOps 體系的核心有三個對象——人、項目、應用。人要做項目，項目要落在不同的應用中達到業(yè)務目標。人的部分要關(guān)注哪些點呢？比如工作量，團隊合作怎么樣，人的績效怎么樣等。項目需要關(guān)注哪些？需求現(xiàn)在是不是確定下來，進度如何，需要投入多少成本等等。應用則會關(guān)注，線上的服務穩(wěn)定性如何，容量如何評估，服務之間的依賴有哪些等等。那么 DevOps 過程，就是對這三個對象所做的一系列的標準化和自動化。
經(jīng)過這幾年的 DevOps 實踐總結(jié)，我對企業(yè)內(nèi)部的 DevOps 平臺做了一個系統(tǒng)架構(gòu)上的抽象。其中，元數(shù)據(jù)中心是這個架構(gòu)的小亮點。
在底層基礎(chǔ)設(shè)施和應用架構(gòu)之上，構(gòu)建一個元數(shù)據(jù)層，主要目的就是解耦。在元數(shù)據(jù)層，需要不斷完善不同對象對畫像。而底層基礎(chǔ)設(shè)施，就可以被當作滿足不同對象的資源來使用。
在元數(shù)據(jù)層之上的元服務層，會有大量功能邊界清晰的原子服務。比如制品庫就管制品，那代碼倉庫就管代碼，Sonar做代碼掃描等。這一層，如果能有一個健壯的工作流引擎，一個可靠的消息中心，也是非常好的實踐。
最上面一層，就是定義業(yè)務流的一層。企業(yè)不同的業(yè)務部門，可以按照需要靈活選擇其使用哪些工具，制定合適的流水線。
