分享內(nèi)容包含如下四個方面：
DevOps 建設(shè)面臨的挑戰(zhàn)
在這些挑戰(zhàn)面前如何找到突破口
MVP 是如何助力 DevOps 建設(shè)间聊？
我會在這里重點(diǎn)分享我在 Qunar 落地 DevOps 的過程中穆碎，是如何結(jié)合 MVP 的原則陪腌，逐步優(yōu)化和完善的幌蚊。最后是我總結(jié)的關(guān)于 DevOps 體系的兩張圖万栅，希望給正在搭建體系平臺的朋友一些啟發(fā)。
一、DevOps 建設(shè)面臨的挑戰(zhàn)
首先看一下挑戰(zhàn)烂翰，回到 DevOps 的價(jià)值來講夯缺，很多人在想 DevOps 是什么，DevOps怎么做甘耿？其實(shí)我們要重新回到 DevOps 本身的價(jià)值來看踊兜，我們?yōu)槭裁匆?DevOps？DevOps 的核心價(jià)值跟精益棵里、敏捷是一致的，都是要實(shí)現(xiàn)企業(yè)從一個需求姐呐，甚至是idea到交付給用戶殿怜，整個過程快速、靈活曙砂、質(zhì)量可靠头谜。
這里面提到一個又要速度又要質(zhì)量，同時(shí)我們還希望從用戶那兒快速獲得反饋鸠澈，形成閉環(huán)柱告。所以我們做 DevOps 其實(shí)服務(wù)的是企業(yè)的業(yè)務(wù)目標(biāo)，這個大家一定要記住笑陈，因?yàn)橹挥兄牢覀優(yōu)槭裁闯霭l(fā)际度，我們才不會走偏。
企業(yè)內(nèi)部實(shí)施DevOps涵妥，會面臨各種挑戰(zhàn)乖菱，我把它總結(jié)為四個方面，每個方面展開都會特別多蓬网。第一：DevOps 的體系是非常復(fù)雜的窒所。大家在很多大會中都有見過《研發(fā)運(yùn)營一體化成熟度模型》，從模型中我們就不難看出帆锋，其體現(xiàn)所覆蓋的技術(shù)范圍和影響的人群范圍都是非常廣泛的吵取。縱向來看锯厢，第一層研發(fā)運(yùn)營一體化過程皮官，下面依次還有應(yīng)用架構(gòu)、安全管理和組織結(jié)構(gòu)实辑。
第二：關(guān)于企業(yè)文化臣疑。很多人說 DevOps 是一種文化的運(yùn)動，需要先從組織結(jié)構(gòu)的調(diào)整開始徙菠，因?yàn)闆]有組織結(jié)構(gòu)的調(diào)整讯沈，我們永遠(yuǎn)打破不了那堵墻。在很多大師的演講PPT中，一個箭頭就打破了 Dev 與 Ops 的那堵墻缺狠，而在不同企業(yè)落地的時(shí)候问慎，想做到這一點(diǎn)，可能需要幾個月挤茄，甚至幾年如叼。所以這個是我們需要克服的點(diǎn)。
第三：團(tuán)隊(duì)的能力穷劈。我們在實(shí)踐的時(shí)候會發(fā)現(xiàn) DevOps 是流程笼恰、規(guī)范、工具三維一體才能真正落地歇终，那如果原有的團(tuán)隊(duì)不具備這種能力怎么做自動化社证？所以這個時(shí)候團(tuán)隊(duì)的能力就會變成快速搭建平臺的短板。
第四：是成本收益评凝。我們回到商業(yè)的本質(zhì)來講追葡，企業(yè)一定是要盈利的。我們搞 DevOps 落地奕短，不是在搞科研宜肉，不是要把 DevOps 水平達(dá)到一個世界的先進(jìn)水平或者國內(nèi)的先進(jìn)水平，我們一定要回歸到服務(wù)企業(yè)的商業(yè)目標(biāo)這個點(diǎn)翎碑。所以谬返，落地 DevOps 也必然逃不了計(jì)算投入產(chǎn)出比。
回想當(dāng)初自己做 DevOps 的時(shí)候日杈，要在企業(yè)內(nèi)部立一個OKR朱浴，經(jīng)常會被挑戰(zhàn)，“你的ROI是怎樣的”达椰？一開始自己很不舒服翰蠢，我做那么多事，為什么總是覺得我這個事不值得做呢啰劲？后來我轉(zhuǎn)變思路之后梁沧，反倒覺得這是很好的考量一件事情價(jià)值的度量方式。沒有度量就無法管理蝇裤，持續(xù)優(yōu)化更是無從談起廷支。所以怎樣考量投入成本和取得的收益，也是非常重要的點(diǎn)栓辜。
面臨這些挑戰(zhàn)恋拍，我們很容易陷入一個困局。我們是不是要新招 DevOps 工程師，或者成立獨(dú)立的小組？誰應(yīng)該來主導(dǎo)這個事比較合適呢，是運(yùn)維饲宛、項(xiàng)目管理還是基礎(chǔ)框架呢僵娃？從哪里開始呢概作？有沒有標(biāo)準(zhǔn)的實(shí)施路徑呢？每個部門的職責(zé)邊界怎么劃分呢默怨？陷入困局的我們讯榕，總是要找到突破口的。
接下來我就與大家分享一些個人經(jīng)驗(yàn)匙睹，如何在不同階段找到突破口愚屁。可能你只需要找到一個突破口痕檬，后面的路就會很順暢的走下去了霎槐。
二、如何找到突破口
關(guān)于實(shí)施 DevOps谆棺，我總結(jié)了九個字栽燕，這九個字說起來很簡單也朗朗上口罕袋，那就是“搭班子改淑，定調(diào)子，邁步子”浴讯。
搭班子是明確職責(zé)朵夏，不一定要從外面引來很多專家，只是說做這個事的時(shí)候大家有明確的職責(zé)榆纽，這個叫做搭班子仰猖。比如說我在去哪兒的時(shí)候，開始做的時(shí)候就是配置管理組發(fā)起的奈籽。我們先從發(fā)布系統(tǒng)的優(yōu)化開始饥侵，當(dāng)然我去的時(shí)候去哪兒就已經(jīng)有了一套自動化的發(fā)布系統(tǒng)∫缕粒可能有些人覺得不可思議躏升，但是沒有關(guān)系，每個公司都有特點(diǎn)狼忱，或者每個公司的工作崗位邊界不同膨疏，只要我們在這個階段明確下來這個事誰在做，在搞什么事钻弄。
定調(diào)子就是統(tǒng)一目標(biāo)佃却，統(tǒng)一目標(biāo)的時(shí)候我們要明確實(shí)施周期和實(shí)施目標(biāo)。明確實(shí)施周期窘俺，是說我們是要一年搞成饲帅，還是作為企業(yè)內(nèi)部的優(yōu)化項(xiàng)目慢慢搞就好了。這個是很重要的，因?yàn)橛幸恍┢髽I(yè)現(xiàn)在是非橙髡ⅲ看重 DevOps染坯，覺得自己落后很多，想快速把這個搞起來丘逸。
經(jīng)常有人問我你在去哪兒七年做成這樣单鹿，如果我請你過來你能幾年做好。這個問題其實(shí)是很難回答的深纲。首先仲锄，一定程度上，投入資源的比重越大湃鹊，實(shí)施的周期會越短儒喊。但是，實(shí)施周期不會因?yàn)橥度胭Y源的無限擴(kuò)大而無限縮短币呵。
我們可以縮短踩坑浪費(fèi)的時(shí)間怀愧，可以省去走彎路浪費(fèi)的時(shí)間，但是余赢，在企業(yè)內(nèi)部摸索出一條適合的路子芯义，必然是需要一定時(shí)間的，揠苗助長的方式只會損害長期利益妻柒。舉例來說扛拨，我買了一輛跑車回來，我就能成為一名優(yōu)秀的賽車手了嗎举塔？
關(guān)于統(tǒng)一目標(biāo)還有一個想跟大家分享的绑警，就是當(dāng)年我在與 Ops、基礎(chǔ)架構(gòu)組一起討論搞DevOps 門戶網(wǎng)站央渣，關(guān)于它的作用和功能计盒，真的就是很簡單的畫了一個手串。手串中間是應(yīng)用芽丹，周圍每個圈是一個個散在各處的系統(tǒng)北启。
我說，有了這個入口平臺志衍，工程師可以從需求管理到開發(fā)到測試再到最后的上線暖庄、運(yùn)營，都能一站式搞定楼肪。大家看了這個圖之后覺得太好了培廓，一拍即合就開始搞了。我們甚至連正式的立項(xiàng)過程都沒有走春叫。
可能這也是去哪兒的文化決定的肩钠，大家認(rèn)為這個目標(biāo)正確泣港，是值得做的，就可以得到資源和支持价匠〉鄙矗可見，一個清晰的目標(biāo)對于推進(jìn)工作有多么重要踩窖，這個清晰是好理解坡氯，不是講大道理，是告訴大家我要做的東西洋腮，每個人都很清晰箫柳。
最后就是邁步子，今天跟大家分享的就是堅(jiān)持 MVP 原則去落地我們的 DevOps 整體的體系啥供，所以會重點(diǎn)在如何邁步子上悯恍。
MVP 是什么呢？MVP 即：Minimum Viable Product伙狐，翻譯過來是最小化可行產(chǎn)品涮毫。這個概念是由硅谷創(chuàng)業(yè)家 Eric Rise 在其創(chuàng)作的《精益創(chuàng)業(yè)》一書中提到的。這本書是指導(dǎo)創(chuàng)業(yè)公司如何走向成功贷屎，以及在創(chuàng)業(yè)的過程中如何提高成功概率的罢防。
但是為什么在這里提到 MVP？我覺得MVP有一個目標(biāo)豫尽，就是以最快的速度篙梢、最小的精力完成一次反饋的循環(huán)顷帖，這個反饋的循環(huán)對于我們做持續(xù)改進(jìn)的人來講美旧，也是非常重要的。我們會假設(shè)某個實(shí)踐是有效的贬墩，或?qū)μ岣哔|(zhì)量有效或者對加快交付速度有效榴嗅，但是我們要在企業(yè)快速落地，就需要快速實(shí)踐陶舞，形成一個閉環(huán)告訴自己這個假設(shè)是否真的正確嗽测。
這與創(chuàng)業(yè)公司CEO去找到自己的第一批用戶，驗(yàn)證自己的商業(yè)邏輯是否可行是完全一致的肿孵。
三唠粥、MVP 助力 DevOps 建設(shè)
接下來我跟大家分享四個案例，每個案例都是從堅(jiān)持MVP原則停做，開始一個新的優(yōu)化方向晤愧。
從解決一個痛點(diǎn)開始。剛才講到我們面臨那么多復(fù)雜的挑戰(zhàn)和自己所陷入的困境蛉腌，我們總要找到一個突破口官份。這個突破口只厘，我建議大家從找到第一個痛點(diǎn)開始。誰痛舅巷？有可能是開發(fā)人員痛羔味，有可能是測試人員痛，總之需要先到一線去了解誰最痛钠右，這個人會是你第一個解決方案的忠實(shí)用戶赋元。
那這個事的背景是說在三四年前，那時(shí)候 PMO 出于管理的目標(biāo)需要收集很多項(xiàng)目數(shù)據(jù)飒房，比如說計(jì)劃提測時(shí)間什么時(shí)候们陆、實(shí)際提測、計(jì)劃上線情屹、實(shí)際上線坪仇，這些數(shù)據(jù)拿到之后可以分析項(xiàng)目的過程是否健康，以及發(fā)現(xiàn)潛在風(fēng)險(xiǎn)垃你。
但問題是椅文，工程師不愿意填這些數(shù)據(jù)。等到被發(fā)現(xiàn)數(shù)據(jù)空著的時(shí)候惜颇，工程師就憑借記憶去填皆刺，甚至按照計(jì)劃時(shí)間與補(bǔ)實(shí)際時(shí)間。這樣的數(shù)據(jù)凌摄，不僅沒有分析的價(jià)值羡蛾，而且工程師還會抱怨，我已經(jīng)夠忙了你還要我做這些事锨亏。
另外一個問題是痴怨，開發(fā)人員在提測前，需要給測試人員寫一個非常詳盡的部署步驟器予。而因?yàn)闀r(shí)間一久浪藻，開發(fā)工程師開發(fā)的時(shí)候可能做了五步，但到寫的時(shí)候就只想起三步乾翔，測試人員拿到長篇大論的部署步驟開始搞爱葵，結(jié)果還是經(jīng)常出錯。
這些都是我們識別出來的痛點(diǎn)反浓，那我們當(dāng)時(shí)做什么呢萌丈？我們對這些問題進(jìn)行了根因分析，初步判斷是數(shù)據(jù)分離雷则，信息不互通導(dǎo)致的辆雾。
于是，我們做出如下假設(shè)：如果能夠建立項(xiàng)目與工程信息的互通巧婶，這些問題應(yīng)該能夠迎刃而解乾颁。所以當(dāng)時(shí)就做了第一個嘗試涂乌，建立一個分支規(guī)范，就是拉取代碼的時(shí)候在分支名稱上標(biāo)注需求編號英岭，利用 githook 方式監(jiān)測工程師的動作湾盒。如果新建一條分支，我們就自動回填到 Jira 需求中的實(shí)際開發(fā)時(shí)間诅妹。
等我們的發(fā)布系統(tǒng)開始做發(fā)布罚勾，我們會打 Tag，那時(shí)候我們會把測試用的 Tag 的生成的時(shí)間點(diǎn)作為實(shí)際提測時(shí)間點(diǎn)吭狡。當(dāng)時(shí)我們就想先去嘗試這樣的東西尖殃，看開發(fā)工程師是否接受這個規(guī)范。第一次嘗試非常成功划煮，大家覺得原來這個數(shù)據(jù)你不僅幫我回填了而且還是最準(zhǔn)確的送丰。
當(dāng)然在這個方案里面大家看到這些 githook 其實(shí)不是一個最優(yōu)的技術(shù)方案，因?yàn)槲覀內(nèi)绻竺嫦胍龈嗉傻氖虑槌谇铮薷?githook 很麻煩器躏，而且 hook 是一次性不可重試的。所以我們做完第一個嘗試發(fā)現(xiàn)這個路是完全正確的時(shí)候蟹略，我們就推出第二個迭代登失，優(yōu)化技術(shù)方案。我們把 githook 去掉了挖炬，開始建立工程效率的消息中心揽浙，系統(tǒng)間通過消息驅(qū)動的方式實(shí)現(xiàn)流程自動化。
比如說 Git 拉了一條 branch意敛，githook 就只管發(fā)一條信息出來就好了馅巷，不用管哪個系統(tǒng)來消費(fèi)，以及消費(fèi)完這條消息以后做什么空闲，這些 gitlab 都不用關(guān)心令杈。對于 JIRA走敌，它就可以來監(jiān)分支創(chuàng)建的消息碴倾，更新項(xiàng)目的實(shí)際時(shí)間，構(gòu)建流水線系統(tǒng)可以消費(fèi)這條消息掉丽，實(shí)現(xiàn)代碼自動掃描跌榔。
第三次再去迭代的時(shí)候，我們的重心放在擴(kuò)充整個平臺的功能范圍捶障，不僅是做消息中心僧须，我們還要對收集的CI數(shù)據(jù)進(jìn)行聚合展示。
第四次迭代项炼，更深入一步担平，開始把動作集成進(jìn)來了示绊。就是測試工程師進(jìn)入這個界面后，順道還可以執(zhí)行一個發(fā)布動作暂论。以下面褐，就是這個平臺最新的界面展示：
這個需求上面有36558的需求編號，下面涉及到的五個工程都是為這個項(xiàng)目做的改動取胎，從分支號上可以看到關(guān)聯(lián)展哭。最后的beta／prod標(biāo)簽，是表示該分支改動已經(jīng)發(fā)布到測試環(huán)境還是線上環(huán)境闻蛀。同時(shí)匪傍，每條工程分支的最新CI結(jié)果也可以在這里做一站的展示。
而且更有趣的是這個平臺其實(shí)不是我的團(tuán)隊(duì)做的觉痛，而是我們的機(jī)票業(yè)務(wù)部門做的役衡。所以回到搭班子的問題，真不是要所有的事情都由我來做薪棒。只要大家明確功能邊界映挂，向著一個目標(biāo)做就可以。能夠團(tuán)結(jié)到業(yè)務(wù)線參與其中是更好的盗尸。
第二個案例：借勢發(fā)力柑船、乘勢而上。
我們做DevOps的目標(biāo)是要讓業(yè)務(wù)團(tuán)隊(duì)靈活起來泼各，交付快起來鞍时，但是首先自己要是一個很敏捷的團(tuán)隊(duì)，我們自己的需求要能夠隨需而變扣蜻。
這個案例當(dāng)時(shí)的背景就是我們做了很多的CI工具逆巍，但是發(fā)現(xiàn)推行一段時(shí)間之后使用效果并不好。比如Sonar檢查結(jié)果莽使，雖然已經(jīng)精準(zhǔn)的推送給了開發(fā)人員锐极，但是開發(fā)工程師如果不修復(fù)，問題還是會流到測試階段芳肌。所以為了控制問題蔓延灵再，還需要有一個質(zhì)量門禁系統(tǒng)。鑒于當(dāng)時(shí)我們的 sonar 系統(tǒng)已經(jīng)比較完備亿笤，我們可以做到對工程師 push 代碼后自動執(zhí)行 Sonar 掃描翎迁，1分鐘后工程師收到 Sonar 報(bào)告。于是我們就準(zhǔn)備在門禁系統(tǒng)中净薛，優(yōu)先實(shí)在 sonar 增量問題的攔截汪榔。
就在我們開始規(guī)劃這個事情的時(shí)候，支付業(yè)務(wù)線的技術(shù)負(fù)責(zé)人找到我說肃拜，我們最近出了兩起故障痴腌，全都是因?yàn)槁樵儗?dǎo)致的雌团。我們在測試環(huán)境有一個慢查詢的工具，有什么辦法能夠做到士聪，發(fā)布線上前去系統(tǒng)中校驗(yàn)一下是否有慢查詢辱姨。如果有，就不允許上線發(fā)布戚嗅。
我馬上想到正在規(guī)劃中的質(zhì)量門禁系統(tǒng)雨涛，于是一拍即合，把接入慢查詢工具加入到第一次迭代需求中懦胞。通過這次溝通替久，我們緊緊的抓住了這個業(yè)務(wù)線，這個業(yè)務(wù)線不僅是門禁系統(tǒng)的第一個用戶躏尉，而且成為了系統(tǒng)的免費(fèi)宣傳用戶蚯根。
其實(shí)一個完整的門禁系統(tǒng)，還需要支持用戶能夠靈活配置胀糜，同時(shí)支持在緊急的情況下還要跳過的審判流程颅拦。但是第一次迭代中，我們評估了低頻事件和個性需求教藻，僅把最核心的功能放入第一次迭代距帅。上線之后用戶口碑非常好，我們才開始做審批括堤，而且還把審批接入手機(jī)端碌秸，隨時(shí)隨地可以做審批。
做完這些我們才開始擴(kuò)展平臺中接入的其他CI工具∏那裕現(xiàn)在讥电，已經(jīng)集成到平臺的，不僅有工程效率部自己負(fù)責(zé)的工具轧抗，還有業(yè)務(wù)部門開發(fā)的測試自動化工具恩敌。
這個案例想跟大家分享的核心思想是， DevOps工具落地時(shí)横媚，系統(tǒng)架構(gòu)和功能需要有認(rèn)真的規(guī)劃纠炮，一個好的架構(gòu)才能支持未來的功能擴(kuò)展。但是分唾，開始功能開發(fā)的時(shí)候抗碰，不是要一次性全部做好。選擇做什么容易绽乔，反倒是選擇不做什么是比較難的。一定要規(guī)劃好每次迭代的功能范圍碳褒。
所謂的MVP折砸，就是要快速試錯看疗，為了證明決策的正確性、可行性睦授，首先要快起來两芳。
第三個案例，愿意分?jǐn)偝杀具€是真需求去枷。
DevOps 轉(zhuǎn)型前期怖辆，需要優(yōu)化的需求很多，你隨便抓住一個痛點(diǎn)删顶，踏實(shí)做完就會有收益竖螃，用戶就會認(rèn)可。但是逗余，這些表面問題掃過一遍后特咆，再去找優(yōu)化點(diǎn)就需要花些心思了。什么才是真需求录粱，而不是一個錦上添花腻格，或者是臆想出來的需求。
這個時(shí)候啥繁，就可以拿一個最簡單直接的標(biāo)準(zhǔn)來衡量菜职，那就是用戶愿不愿意跟你分?jǐn)偝杀尽Ｎ业那邦I(lǐng)導(dǎo)告訴我一個秘訣旗闽，就是你看看業(yè)務(wù)線是否已經(jīng)有人開始做了些楣。業(yè)務(wù)線真正的目標(biāo)是業(yè)務(wù)量往前沖，如果他們都愿意在工具上花精力了宪睹，那一定就是剛需愁茁。
這個案例是圍繞如何快速搭建一套可測試環(huán)境的。其實(shí)這也是微服務(wù)架構(gòu)所帶來的一個挑戰(zhàn)亭病。一個業(yè)務(wù)需求哪怕只修改一個應(yīng)用鹅很，但是要想完成對變更的驗(yàn)證，就需要搭建其他的幾個甚至幾十個應(yīng)用才能完成罪帖。在當(dāng)時(shí)Qunar業(yè)務(wù)快速發(fā)展的情況下促煮，基于固定環(huán)境進(jìn)行維護(hù)、分配整袁，已經(jīng)成為影響交付效率的瓶頸菠齿。于是好幾個業(yè)務(wù)線的測試同學(xué)就開始做各種嘗試。了解到這些情況后坐昙，我們覺得公司應(yīng)該有一個可以提供更靈活绳匀、快速的創(chuàng)建一套業(yè)務(wù)測試環(huán)境的平臺。提出方案的時(shí)候，我們既沒有開始使用Docker疾棵，也沒有特別先進(jìn)的自動化運(yùn)維戈钢。我們就覺得這個方向是對的，所以這個平臺更是花了好幾年的時(shí)間在打磨是尔。
經(jīng)過三個版本的迭代殉了，到現(xiàn)在Noah平臺已經(jīng)是一個非常棒的產(chǎn)品。在與同行交流的時(shí)候拟枚，我也經(jīng)常拿 Noah 出來炫耀薪铜。一個由幾十個應(yīng)用外加幾十個中間件的環(huán)境，從點(diǎn)擊創(chuàng)建按鈕到交付給測試人員使用恩溅，僅僅十幾分鐘的時(shí)間隔箍。
但是，這個平臺能做到今天的樣子暴匠，過程中需要克服的困難有很多鞍恢。比如說第一個難點(diǎn)就是如何解決應(yīng)用自適應(yīng)環(huán)境的問題。環(huán)境動態(tài)起來了每窖，應(yīng)用的配置文件怎么更新呢帮掉？接下來，我們承諾用戶說可以10分鐘內(nèi)交付一個包含100個應(yīng)用的環(huán)境窒典。但是基礎(chǔ)設(shè)施能不能扛住這樣的并發(fā)呢蟆炊？所以解決環(huán)境管理的問題，絕對是一個系統(tǒng)工程瀑志。過程中涉及的技術(shù)難點(diǎn)多涩搓，需要配合的部門多，需要考慮的業(yè)務(wù)場景也會多種多樣劈猪。你不可能等到把所有問題都解決了昧甘，再推向用戶使用。
在1.0版本的時(shí)候战得，因?yàn)闃I(yè)務(wù)有剛需充边，所以當(dāng)時(shí)在界面交互的友好性上就不需要特別關(guān)注。而是集中精力先攻克第一個核心的技術(shù)難點(diǎn)——應(yīng)用的配置文件模版化常侦。在這里還要分享一個實(shí)踐成功的經(jīng)驗(yàn)浇冰，就是向你的第一批用戶提供VIP服務(wù)。Noah產(chǎn)品的第一批用戶聋亡，我們都提供哪些VIP服務(wù)呢肘习？我們的產(chǎn)品經(jīng)理真的是申請一條開發(fā)分支，親自幫業(yè)務(wù)線修改配置文件坡倔。
大家可以看到漂佩，即使是針對剛性需求提出的解決方案脖含，都需要提供這樣的貼心服務(wù)才能真正落地。其實(shí)背后的原因不難解釋仅仆，人都是有惰性的器赞。而由惰性帶來的慣性力量巨大垢袱。而我們做DevOps轉(zhuǎn)型墓拜，就是在跟各種慣性抗衡。
所以请契，每一個DevOps從業(yè)者要慢慢建立起服務(wù)意識咳榜。我們不再是僅僅制定標(biāo)準(zhǔn)或提供工具，我們是在提供服務(wù)爽锥。我們的用戶是整個研發(fā)過程中的所有角色涌韩，可能是產(chǎn)品經(jīng)理、開發(fā)氯夷、測試工程師臣樱，或是項(xiàng)目管理人員，還有做決策的管理者腮考。用戶的需求就是我們應(yīng)該想辦法去解決和滿足的雇毫。當(dāng)然，大家千萬不要誤解為踩蔚，是他們說什么我們做什么棚放。我們要解決的是真正的需求，不是表面現(xiàn)象馅闽。
我們的平臺飘蚯，也是給去哪兒的產(chǎn)品再打一次廣告，這個是真實(shí)的環(huán)境福也，
下面要演示的就是通過Noah平臺真實(shí)的一次環(huán)境構(gòu)建局骤。從截圖中可以看到，一個包含83個應(yīng)用暴凑，23個數(shù)據(jù)庫峦甩，7個中間件點(diǎn)環(huán)境，創(chuàng)建時(shí)間僅需要9分鐘搬设。
第四個案例與度量有關(guān)穴店。在做度量的時(shí)候，大家首先要區(qū)分虛榮性指標(biāo)和可執(zhí)行指標(biāo)拿穴。
虛榮性指標(biāo)和可執(zhí)行指標(biāo)也是精益創(chuàng)業(yè)中提到的兩個概念泣洞。什么是虛榮性指標(biāo)呢？所有假大空的指標(biāo)默色，都是虛榮性指標(biāo)球凰。看到這樣的指標(biāo)，你完全不知道指標(biāo)說明了什么呕诉，或者自己要做什么缘厢。
而可執(zhí)行指標(biāo)恰恰與其相反，指標(biāo)就是一個風(fēng)向標(biāo)甩挫，當(dāng)前的優(yōu)勢或不足贴硫，以及下一步的行動，一目了然伊者。
DevOps 的最終目標(biāo)是要按需英遭、快速交付可靠的軟件。那我們就要看每一次的改進(jìn)亦渗，到底在這三方面做了哪些貢獻(xiàn)挖诸。是幫企業(yè)節(jié)約了成本，還是加快了流程法精，或是提前發(fā)現(xiàn)了質(zhì)量問題多律。那么節(jié)約了多少成本，流程加快了多少搂蜓，狼荞，發(fā)現(xiàn)多少問題，這些問題都是什么級別的問題洛勉。下面給大家一個直觀的例子粘秆。
比如說這是我們當(dāng)時(shí)推行CI工具的時(shí)候做的一個統(tǒng)計(jì)，統(tǒng)計(jì)指標(biāo)的是接入平臺的工程數(shù)是多少收毫。從圖中看攻走，這個值還是很可觀的。已經(jīng)有四千多工程接入此再，當(dāng)時(shí)公司一共6000多個工程昔搂，除了不活躍的，基本已經(jīng)全量接入输拇。
但是現(xiàn)在想想摘符，這個就是個虛榮性指標(biāo)。因?yàn)榻尤氩淮碚娴漠a(chǎn)生作用策吠。如果大家無視Sonar的掃描結(jié)果逛裤，那么整個事情就是在浪費(fèi)資源。
那這件事情該用什么指標(biāo)度量呢猴抹？Sonar問題的增長趨勢带族，Sonar問題的修復(fù)時(shí)長，這兩個指標(biāo)是可執(zhí)行指標(biāo)蟀给。如下圖蝙砌。從問題修復(fù)時(shí)長數(shù)據(jù)的變化阳堕，能夠驗(yàn)證我們的門禁系統(tǒng)的價(jià)值假設(shè)。這也就完成了MVP的一次認(rèn)知循環(huán)择克。
再比如說恬总，Noah平臺創(chuàng)建環(huán)境很快，但是環(huán)境穩(wěn)定性一直是一個頭疼的問題肚邢。當(dāng)我們開始在提升穩(wěn)定性問題上投入精力的時(shí)候壹堰，我們需要首先分析引發(fā)環(huán)境不穩(wěn)定的各種原因。然后持續(xù)去度量道偷，來驗(yàn)證我們所采取的手段是否真的對穩(wěn)定性有提升效果缀旁。所以记劈，大家下次再定義度量指標(biāo)的時(shí)候勺鸦，首先要問問自己，這是一個虛榮性指標(biāo)還是可執(zhí)行指標(biāo)目木。
這一頁想跟大家分享的是换途，參與DevOps體系建設(shè)的團(tuán)隊(duì)，要經(jīng)歷的三個時(shí)期——依賴期刽射、獨(dú)立期军拟，互賴期。
依賴期誓禁，表現(xiàn)有兩種懈息。一種是，我們的改進(jìn)需求和方案完全依賴外界輸入摹恰，別人讓我做什么我做什么辫继。這種依賴很可怕，其實(shí)隱含的一個根本原因就是我們可能不夠?qū)I(yè)俗慈。而另外一種依賴型是姑宽，團(tuán)隊(duì)沒有開發(fā)能力，我的方案落地需要向外部團(tuán)隊(duì)申請資源闺阱。這種依賴型可能會因?yàn)橘Y源得不到支持炮车，而推進(jìn)進(jìn)度緩慢。處在依賴期的團(tuán)隊(duì)酣溃，務(wù)必要想辦法盡快完成向獨(dú)立期的躍遷瘦穆。
而獨(dú)立期的團(tuán)隊(duì)表現(xiàn)有哪些呢？第一赊豌，能夠就業(yè)務(wù)線的問題給出專業(yè)的解決方案扛或。第二，解決方案的上線時(shí)間可預(yù)期亿絮。比如我們承諾一個月上線的功能告喊，一定能夠在一個月之內(nèi)完成麸拄。一個月聽起來很長，但是如果我們真的說到做到黔姜，已經(jīng)是一個很大的進(jìn)步了拢切。在這里，為什么我只提到交付的可預(yù)期秆吵，而沒有要求特別快呢淮椰？對于內(nèi)部改進(jìn)團(tuán)隊(duì)來說，很多事情都是細(xì)水長流纳寂，持續(xù)改進(jìn)的主穗。
提前一周上線到底能帶來多大收益呢？其實(shí)不是特別好衡量毙芜。而做到如期兌現(xiàn)承諾忽媒，對于一個團(tuán)隊(duì)的收益就會不一樣。我們會慢慢建立起來與用戶間的信任關(guān)系腋粥。這種信任關(guān)系晦雨，會是我們能夠持續(xù)影響用戶，不斷優(yōu)化過程的堅(jiān)實(shí)基礎(chǔ)隘冲。
在這里還想給團(tuán)隊(duì)幾個建議闹瞧，第一就是打造一個敏捷的團(tuán)隊(duì)。一定要記住這一點(diǎn)展辞，我們自己先敏捷起來奥邮，才有資格指導(dǎo)別人如何變得敏捷。第二個就是做自己規(guī)范和產(chǎn)品的第一個用戶罗珍。很多DevOps團(tuán)隊(duì)洽腺，做的工具都是給別人用的，讓自己操作一下都不能很順暢靡砌。制定的開發(fā)規(guī)范是給別人用的已脓，自己團(tuán)隊(duì)開發(fā)恨不得連版本控制都做不到。
獨(dú)立期的下一個躍遷階段就是互賴期通殃。與誰互賴度液，那肯定是與我們的用戶呀。DevOps團(tuán)隊(duì)的終極目標(biāo)其實(shí)是成就用戶的成功画舌。所以我們還要培養(yǎng)共贏思維堕担。我們的目標(biāo)不是要證明自己做的工具、平臺有多么多么好曲聂。而且要看到業(yè)務(wù)線在使用了這些工具后有哪些提升霹购。只要這樣，我們才能與業(yè)務(wù)線建立良好的溝通朋腋。
比如說我們?nèi)ツ膬旱墓こ绦蕡F(tuán)隊(duì)可以說是已經(jīng)進(jìn)入互賴期。業(yè)務(wù)線遇到什么困難，或有一些好的想法抡砂，都會想到先和我們討論一下。一是我們積累了很多數(shù)據(jù)和底層的自動化平臺赌厅，二是大家一起討論后總還能碰撞出一些不一樣的火花。我覺得達(dá)到互賴期后轿塔，公司的DevOps文化也就形成了特愿。
四、遇見未來
我是這樣理解 DevOps 的勾缭，DevOps 體系的核心有三個對象——人揍障、項(xiàng)目、應(yīng)用俩由。人要做項(xiàng)目毒嫡，項(xiàng)目要落在不同的應(yīng)用中達(dá)到業(yè)務(wù)目標(biāo)。人的部分要關(guān)注哪些點(diǎn)呢采驻？比如工作量审胚，團(tuán)隊(duì)合作怎么樣，人的績效怎么樣等礼旅。項(xiàng)目需要關(guān)注哪些？需求現(xiàn)在是不是確定下來洽洁，進(jìn)度如何痘系，需要投入多少成本等等。應(yīng)用則會關(guān)注饿自，線上的服務(wù)穩(wěn)定性如何汰翠，容量如何評估，服務(wù)之間的依賴有哪些等等昭雌。那么 DevOps 過程复唤，就是對這三個對象所做的一系列的標(biāo)準(zhǔn)化和自動化。
經(jīng)過這幾年的 DevOps 實(shí)踐總結(jié)烛卧，我對企業(yè)內(nèi)部的 DevOps 平臺做了一個系統(tǒng)架構(gòu)上的抽象佛纫。其中，元數(shù)據(jù)中心是這個架構(gòu)的小亮點(diǎn)总放。
在底層基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)之上呈宇，構(gòu)建一個元數(shù)據(jù)層，主要目的就是解耦局雄。在元數(shù)據(jù)層甥啄，需要不斷完善不同對象對畫像。而底層基礎(chǔ)設(shè)施炬搭，就可以被當(dāng)作滿足不同對象的資源來使用蜈漓。
在元數(shù)據(jù)層之上的元服務(wù)層穆桂，會有大量功能邊界清晰的原子服務(wù)。比如制品庫就管制品融虽，那代碼倉庫就管代碼充尉，Sonar做代碼掃描等。這一層衣形，如果能有一個健壯的工作流引擎驼侠，一個可靠的消息中心，也是非常好的實(shí)踐谆吴。
最上面一層倒源，就是定義業(yè)務(wù)流的一層。企業(yè)不同的業(yè)務(wù)部門句狼，可以按照需要靈活選擇其使用哪些工具笋熬，制定合適的流水線。
