DevOps架構(gòu)落地三部曲

1、 DevOps架構(gòu)落地三部曲如何歸責(zé)？用啥工具？往哪里去？本文主要是從兩個(gè)方面去探討DevOps，由于大部分的同學(xué)可能更多的是看到了運(yùn)維這個(gè)層面，所以我更多側(cè)重的是Dev這個(gè)層面，也就是從Dev到運(yùn)維，因?yàn)檎檬钦麄€(gè)全流程走到這里，我們看到了一些實(shí)踐，也看到了將來(lái)的一些機(jī)會(huì)和趨勢(shì)，所以今天會(huì)談一談我們公司近兩年做的過(guò)程，也就是我們?cè)趺醋鯠evOps。一、從業(yè)務(wù)、系統(tǒng)發(fā)展看問(wèn)題從業(yè)務(wù)和系統(tǒng)的發(fā)展，我們來(lái)看當(dāng)時(shí)面臨的問(wèn)題和解決的措施，有一些總結(jié)性和思考性的東西。就像程永新老師在 HYPERLINK /s?_biz=MzI4NTA1MDEwNg=&mid=2650763371&idx=1&sn=a8

2、b595ac86d3720c84b3ee276a223152&chksm=f3f9c5fec48e4ce8df0197f487b0797c943e0d027280f9040d4b827619c6ac48a355cb04507b&scene=21 l wechat_redirect t _blank 企業(yè)級(jí)運(yùn)維三板斧所說(shuō)的，未來(lái)不是DevOps，關(guān)注方向的可能是AIOps這個(gè)層面，也就是說(shuō)DevOps更要關(guān)注的是ADPaas平臺(tái)，而在運(yùn)維側(cè)則更多的是AIOps，就像谷歌的系統(tǒng)是自治的，不需要人為介入，所以運(yùn)維側(cè)是要受到很大挑戰(zhàn)的。這是我當(dāng)時(shí)加入公司時(shí)的一個(gè)基礎(chǔ)組織架構(gòu)，跟所有互聯(lián)網(wǎng)公司，或者一些

3、創(chuàng)業(yè)已經(jīng)過(guò)了風(fēng)險(xiǎn)期的公司大致相似，這是標(biāo)準(zhǔn)化的建制，就是說(shuō)業(yè)務(wù)和研發(fā)、測(cè)試、運(yùn)維都有，是這樣的一個(gè)結(jié)構(gòu)。敏捷與持續(xù)集成第一個(gè)過(guò)程，當(dāng)我加入到這個(gè)團(tuán)隊(duì)里面時(shí)，整個(gè)研發(fā)體系加上在一起大概40人左右。剛進(jìn)去時(shí)我們做敏捷和持續(xù)集成，跟所有的創(chuàng)業(yè)團(tuán)隊(duì)一樣，內(nèi)部沒有規(guī)范，做事圖快，質(zhì)量較低。大家在創(chuàng)業(yè)公司或者是一些中型公司呆過(guò)的話就會(huì)知道，基本上沒有走到標(biāo)準(zhǔn)化流程階段，基本上都會(huì)存在相同的問(wèn)題，就是業(yè)務(wù)和研發(fā)對(duì)接的管理非常混亂，沒有相對(duì)規(guī)范的流程。開發(fā)做出來(lái)的東西提交測(cè)試時(shí)沒有太多的責(zé)任心（在心理定位上將測(cè)試人員當(dāng)作編碼質(zhì)量的防護(hù)網(wǎng)），里面Bug非常多。然后上線測(cè)試，我們當(dāng)時(shí)讓測(cè)試做構(gòu)建，把這個(gè)包構(gòu)建出來(lái)

4、，最后交給運(yùn)維，由運(yùn)維負(fù)責(zé)上線。整個(gè)過(guò)程很亂，比如拷到某一個(gè)發(fā)版機(jī)器上，拷上去以后用文件夾打個(gè)標(biāo)簽交給運(yùn)維，運(yùn)維再往線上扔，扔到線上以后就要人肉一段時(shí)間，看一看沒什么問(wèn)題才回家睡覺。存在問(wèn)題：你可以看到基本上的問(wèn)題就是，需求側(cè)這面項(xiàng)目管理非常亂，研發(fā)的交付質(zhì)量很低，會(huì)有很多返工的事。項(xiàng)目上線的周期長(zhǎng)，問(wèn)題非常多。我們首先做的是基于持續(xù)集成的改善。從過(guò)程管理這個(gè)層面，我們把Scrum引入進(jìn)來(lái)，對(duì)Scrum做了一定的調(diào)整。實(shí)際上最近在敏捷圈子里吵得非常厲害，各種方法論大家都不服，都認(rèn)為自己代表了“天意”。但從企業(yè)的角度，尤其是我們解決問(wèn)題的角度，用哪個(gè)都無(wú)所謂，能解決問(wèn)題才是根本。所以我們根據(jù)企業(yè)

5、當(dāng)前人員情況對(duì)Scrum進(jìn)行了裁剪，不是什么都要，明確哪些問(wèn)題需要用Scrum去做。把Scrum流程引入之后，再用JIRA做需求管理、排期這些事情，然后內(nèi)部用GitLab去做整個(gè)代碼的管理，搭一個(gè)服務(wù)器，把UT做起來(lái)，很快能夠得到好的反饋。這個(gè)是非常成熟的套路，如果用強(qiáng)制的方法做的話見效很快，基本上1-2個(gè)月就能梳理出來(lái)。在我們做完了后會(huì)發(fā)現(xiàn)，這個(gè)過(guò)程不是那么順，不是上來(lái)以后奇跡一般的就做好了，中間肯定有很多很多需要去溝通、協(xié)調(diào)的一些過(guò)程。你可以看到業(yè)務(wù)跟研發(fā)的對(duì)接相對(duì)來(lái)說(shuō)變得好了，不一定非常流暢，但可控了。但研發(fā)到測(cè)試這邊，你會(huì)發(fā)現(xiàn)它的墻變灰了，不是那么實(shí)了，因?yàn)楫?dāng)你有UT搭建起來(lái)后，其實(shí)提

6、交的質(zhì)量、責(zé)任已經(jīng)放在研發(fā)這一側(cè)了，這時(shí)候測(cè)試拿到的東西相對(duì)就好很多，它就不會(huì)來(lái)來(lái)回回地在底層的一些簡(jiǎn)單問(wèn)題上掰扯。但這時(shí)運(yùn)維這一側(cè)還沒有受到太大的影響。存在問(wèn)題：這時(shí)我們發(fā)現(xiàn)還是有一些問(wèn)題，就是研發(fā)到測(cè)試的交付物不同源，一致性存在問(wèn)題（我們后面會(huì)講一致性的問(wèn)題）；測(cè)試手工驗(yàn)證周期還很長(zhǎng)，因?yàn)樗鼪]有做測(cè)試的自動(dòng)化，即功能測(cè)試和性能測(cè)試都沒有做自動(dòng)化；項(xiàng)目上線時(shí)間長(zhǎng)，因?yàn)闆]有觸動(dòng)到運(yùn)維側(cè)。所以這時(shí)候我們要做的就是持續(xù)交付的第一個(gè)版本，我們把它叫做持續(xù)交付的1.0。持續(xù)交付1.0持續(xù)交付的1.0做了什么事？就是我們現(xiàn)在大部分在40人以下的小團(tuán)隊(duì)要做的一個(gè)交付流水線，其實(shí)多數(shù)團(tuán)隊(duì)都是這樣做，就是加一

7、個(gè)pipeline的插件，部署的腳本寫在Jenkins里頭，然后把它跟源代碼放在一起，這就是我們現(xiàn)大部分持續(xù)交付的事情加一個(gè)pipeline插件。我沒有截那個(gè)圖，這里畫了一個(gè)大概的形式。你可以看到之前的CI我們還需要做，但Jenkins有了一定的構(gòu)建能力，并且通過(guò)pipeline插件我們可以做多環(huán)境的部署，只要構(gòu)建出來(lái)以后一步一步往上推（Promotion），但在UAT到生產(chǎn)這一步需要人工做最后的審批，并不全自動(dòng)化。這里涉及到兩個(gè)概念的差別呢？就是什么是持續(xù)交付，什么是持續(xù)部署，現(xiàn)在行業(yè)里頭談持續(xù)交付多一些，談持續(xù)部署少一些。持續(xù)集成是關(guān)注在研發(fā)側(cè)，不涉及到后面的自動(dòng)化驗(yàn)證和部署的過(guò)程，但持續(xù)

8、交付關(guān)注到了構(gòu)建后的部署和驗(yàn)證，但它有一部分的手工驗(yàn)證過(guò)程，它可能在全線是貫通的，但最后的一步和中間驗(yàn)證都是手工的。而持續(xù)部署強(qiáng)調(diào)的是全自動(dòng)，中間沒有任何人為的干預(yù)，只要你一提交代碼馬上就開始通過(guò)部署流水線向生產(chǎn)流動(dòng)。我們現(xiàn)在說(shuō)的是持續(xù)交付，所以這在生產(chǎn)過(guò)程實(shí)際上還需要手工去審核的。但這個(gè)過(guò)程實(shí)際是有問(wèn)題的，在系統(tǒng)很小的時(shí)候可以這么做，但團(tuán)隊(duì)變大的時(shí)候就有問(wèn)題。存在問(wèn)題：什么問(wèn)題？持續(xù)交付說(shuō)只構(gòu)建一次，然后在這個(gè)構(gòu)建的產(chǎn)物上進(jìn)行驗(yàn)證和部署，這就需要引入制品庫(kù)。但是我們遇到了一些團(tuán)隊(duì)，你會(huì)發(fā)現(xiàn)實(shí)際上在代碼的生成和驗(yàn)證的過(guò)程中，它都是從版本庫(kù)里頭直接拉代碼回來(lái)，不斷地拉代碼，拉了以后再動(dòng)態(tài)地打包，

9、這樣的話會(huì)有一些問(wèn)題。所以我們希望把制品庫(kù)引進(jìn)來(lái)，就是拿的東西是第一次就構(gòu)建成功的東西，然后在這個(gè)上面不斷地附加原數(shù)據(jù)。什么是原數(shù)據(jù)？就是經(jīng)過(guò)或沒經(jīng)過(guò)單測(cè)，單測(cè)的百分比是多少，然后誰(shuí)去驗(yàn)證它，這都是跟這個(gè)制品有關(guān)的一些行為和流程數(shù)據(jù)，它必須要記錄下來(lái)，因?yàn)楹笃诘幕顒?dòng)可以基于這些數(shù)據(jù)去做選擇。制品庫(kù)：Nexus-Artifactor-自研我們整個(gè)制品庫(kù)過(guò)程選擇經(jīng)過(guò)了3個(gè)階段，最早的整個(gè)項(xiàng)目是用Java來(lái)做的，很自然的，我們就用Nexus做私庫(kù)，去做制品的構(gòu)建產(chǎn)物管理。因?yàn)樗苋菀捉鉀Q依賴的問(wèn)題，而依賴是很麻煩的事情。因?yàn)镹exus支持產(chǎn)品版本，不支持構(gòu)建版本的追蹤，同時(shí)它沒有原數(shù)據(jù)管理的能力。所

10、以第二步我們跟JFrog對(duì)接，希望用它的Artifactory，這是用得比較成熟且用得比較多的，目前谷歌、騰訊、阿里也在用。但問(wèn)題是公司體量不大，而專業(yè)版的Artifactory比較貴，我們負(fù)擔(dān)這樣的花費(fèi)有點(diǎn)不劃算，跟大家一樣我們想用開源版本的，但社區(qū)版的Artifactory不支持多語(yǔ)言，而且它構(gòu)建版本的支持要專業(yè)版，所以沒辦法，我們調(diào)研以后自己做，拿什么做？很簡(jiǎn)單，你可以搭一個(gè)類似S3的文件服務(wù)，把它放在文件服務(wù)上去。第二種方式我們用數(shù)據(jù)庫(kù)去做，有些數(shù)據(jù)庫(kù)實(shí)際上是可以去存二進(jìn)制的大文件的，而且它可以很方便地做Key-Value的元數(shù)據(jù)管理，但自己研發(fā)制品庫(kù)的問(wèn)題在于并發(fā)、高可用和快速下發(fā)。

11、在規(guī)模較小時(shí)，這些還不是問(wèn)題。它的好處是什么？加了制品庫(kù)以后，我們能保證把構(gòu)建版本和元數(shù)據(jù)打上去，在這樣的話我們保證部署的都是同源的，而且一步一步可以在它的部署邏輯里頭根據(jù)元數(shù)據(jù)經(jīng)過(guò)選擇，就是它沒有經(jīng)過(guò)前面的階段或者到達(dá)一定的百分比我是不允許后面的階段看到這個(gè)構(gòu)建產(chǎn)物?，F(xiàn)在你可以看到我們的整個(gè)結(jié)構(gòu)，就是說(shuō)開發(fā)到測(cè)試的階段實(shí)際上這個(gè)墻就沒有了。這里說(shuō)一下我們自己的業(yè)務(wù)，我們的業(yè)務(wù)基本上是支持公司內(nèi)部的電商和公司內(nèi)部的其它互聯(lián)網(wǎng)產(chǎn)品。這時(shí)你可以看到測(cè)試到運(yùn)維這邊的墻實(shí)際上可以把它拿走，但運(yùn)維這時(shí)還有一些問(wèn)題就是他的事比較雜，為什么雜？因?yàn)閼?yīng)用的運(yùn)維。我們可以把運(yùn)維看成兩部分，一部分是傳統(tǒng)的運(yùn)維或者

12、說(shuō)是基礎(chǔ)設(shè)施和工具化的運(yùn)維，另一方面是跟應(yīng)用相關(guān)的運(yùn)維，應(yīng)用的運(yùn)維我們也是放在運(yùn)維團(tuán)隊(duì)的，這個(gè)安排實(shí)際上是不合適的。所以說(shuō)運(yùn)維的事就比較雜，不能專心地干自己特別擅長(zhǎng)的事。存在問(wèn)題：這時(shí)我們發(fā)現(xiàn)運(yùn)維人員需要維護(hù)大量的環(huán)境，包括應(yīng)用的部署；第二，構(gòu)建環(huán)境與生產(chǎn)環(huán)境的一致性是有問(wèn)題的。為什么？比如說(shuō)構(gòu)建環(huán)境放在Jenkins里，如果去用它做構(gòu)建的話，它的環(huán)境是定好的，例如JDK1.8，那我所有的東西只能在JDK1.8上去構(gòu)建，但如果我要裝JDK1.7呢？那就另搭一套環(huán)境去做它，比較麻煩。部署邏輯和Jenkins是緊耦合的，因?yàn)檫@些東西我們是在Jenkins里用腳本編程，而且它沒有快速回滾機(jī)制。有些時(shí)

13、候?qū)嶋H上是要快速回滾的，不能重新拉代碼版本再部署一次。最后，依然需要大量的人員去做半自動(dòng)化的測(cè)試。持續(xù)交付2.0用配置管理工具（Ansible）管理環(huán)境這時(shí)我們就想做2.0的持續(xù)交付，最早我們是用Ansible做環(huán)境的管理，在持續(xù)交付2.0之前和持續(xù)交付1.0之間發(fā)生了一件事情：我們把大量的機(jī)器從阿里云上搬到自己的私有云上，在一年不到的時(shí)間我們搭建了OpenStack的私有云，一年里給公司節(jié)省的成本大概是在幾百萬(wàn)左右，除了少量對(duì)外的一些服務(wù)必須要放在阿里云上，我們大部分核心計(jì)算都是放在內(nèi)部的私有云上，這是我們運(yùn)維團(tuán)隊(duì)做的非常大的貢獻(xiàn)。我們到了2.0的階段，實(shí)際上大部分的機(jī)器都是虛機(jī)。這時(shí)候加上

14、Ansible以后，可以拿Jenkins去管這些集群的環(huán)境，這樣的大家相對(duì)都用得比較多，就不過(guò)多解釋。存在問(wèn)題：這時(shí)整個(gè)場(chǎng)景里可以看到，有一部分是應(yīng)用的業(yè)務(wù)部署，有一部分是環(huán)境的部署、管理，但當(dāng)真正去實(shí)踐時(shí)發(fā)現(xiàn)有些問(wèn)題。第一個(gè)是需要構(gòu)建環(huán)境和生產(chǎn)環(huán)境的版本是一致的，即應(yīng)用包依賴的版本一致，包括操作系統(tǒng)也是一致的。第二個(gè)就是需要構(gòu)建工具的一致性，就是說(shuō)，構(gòu)建時(shí)比如說(shuō)是1.9構(gòu)建的，回滾時(shí)也必須要回滾到1.9進(jìn)行重建，必須要把這個(gè)信息記錄下來(lái)。如果大家讀過(guò)谷歌的文章，講他們bazel整個(gè)構(gòu)建系統(tǒng)的話，你會(huì)發(fā)現(xiàn)它的一個(gè)巨大的目標(biāo)就是要做到一致性，最重要的經(jīng)驗(yàn)就是把所有的構(gòu)建的依賴和構(gòu)建工具放到版本庫(kù)

15、里進(jìn)行統(tǒng)一管理?，F(xiàn)在用Ansible這個(gè)方式去管環(huán)境，用Jenkins去構(gòu)建，不會(huì)有什么問(wèn)題。但當(dāng)發(fā)現(xiàn)應(yīng)用包丟了，想重新構(gòu)建一次時(shí)用Jenkins進(jìn)行環(huán)境構(gòu)建時(shí)相對(duì)比較麻煩，很難自動(dòng)化再一鍵構(gòu)建出來(lái)一個(gè)。怎么辦？接下來(lái)我們?cè)?.0里頭會(huì)講我們是怎么做的。測(cè)試人員和測(cè)試工作的定位這時(shí)，我們開始做測(cè)試的自動(dòng)化，就是功能測(cè)試，還包括測(cè)試平臺(tái)。這樣的話，測(cè)試人員和測(cè)試工作的定位我們需要重新反思一下。因?yàn)槲覀冏龅墓ぷ鞲鷤鹘y(tǒng)的業(yè)務(wù)相對(duì)還不是那么結(jié)合緊密，基本上就做數(shù)據(jù)支持的，大數(shù)據(jù)、用戶行為分析，包括我們自己做APM和其它工具，這些工作大部分是技術(shù)性的工作，在這里面人肉QA的工作沒有那么大量。所以這時(shí)我們

16、希望把QA的工作極大地壓縮，甚至從我們的業(yè)務(wù)流程里頭去除掉，事實(shí)上我們也整個(gè)把QA給干掉了。這里面邏輯是什么？就是留活不留人，比如說(shuō)一些用戶的可用性這樣的測(cè)試我們也是需要人的，但這種工具類型的東西我們不需要人做測(cè)試，我們用機(jī)器做就可以了。所以這時(shí)你會(huì)發(fā)現(xiàn)整個(gè)流程就留下Dev和Ops了，把活留下了。Docker與不可變部署我們開始引入Docker，希望做基于Docker的不可變部署。Docker有個(gè)好處就是在生成一個(gè)鏡像時(shí)，可以通過(guò)描述來(lái)聲明其包含的內(nèi)容，并將整個(gè)應(yīng)用和它的環(huán)境打包成一個(gè)鏡像，這樣的話，測(cè)試驗(yàn)證了這個(gè)鏡像以后，它隨后進(jìn)行的所有部署都不需要變更，所需要變更的東西只是配置，你可以在啟

17、動(dòng)這個(gè)鏡像時(shí)給它加一些不同的配置，但它內(nèi)部的實(shí)現(xiàn)一般是不變的，回滾和前滾都是非常容易的。我們第一個(gè)版本的Docker部署是內(nèi)部的一個(gè)工具，一個(gè)在線報(bào)障工具，整個(gè)運(yùn)行在Docker上。因?yàn)榇蟛糠謽I(yè)務(wù)還不敢把核心業(yè)務(wù)放到Docker上去，當(dāng)然我們知道一些互聯(lián)網(wǎng)公司在做嘗試，而且我們沒有用原生的Docker commit去打包，因?yàn)檫z留系統(tǒng)應(yīng)用的打包我們還需要用，還是有一些虛機(jī)的打包，所以我們用的是Paker。那么整個(gè)流程實(shí)際上很簡(jiǎn)單，還是用Jenkins去做打包，鏡像存儲(chǔ)到內(nèi)部的私服上。既然產(chǎn)品可以運(yùn)行在Docker上，那么構(gòu)建環(huán)境能不能也運(yùn)行在Docker上？肯定能，這時(shí)候Jenkins上拉起來(lái)

18、去構(gòu)建實(shí)際是在Docker環(huán)境里頭構(gòu)建，就是我們?cè)谏梢粋€(gè)項(xiàng)目時(shí)，我們會(huì)給這個(gè)項(xiàng)目添加一些元數(shù)據(jù)：項(xiàng)目的名稱、負(fù)責(zé)團(tuán)隊(duì)、代碼庫(kù)，我們還會(huì)指定這個(gè)項(xiàng)目構(gòu)建的依賴是什么。這時(shí)它會(huì)在內(nèi)部選擇我們已經(jīng)打好的基礎(chǔ)構(gòu)建鏡像，比如到底是選JDK 1.7的Docker還是JDK 1.8的Docker，將來(lái)構(gòu)建是在Docker上構(gòu)建，就是構(gòu)建時(shí)用Docker做構(gòu)建環(huán)境。這樣的話就簡(jiǎn)單了，回滾時(shí)拉一個(gè)Docker進(jìn)來(lái)就可以了，比Jenkins自己構(gòu)建容易管理很多，同時(shí)你會(huì)發(fā)現(xiàn)重建的過(guò)程也隨之簡(jiǎn)單了。運(yùn)維人員和運(yùn)維工作的定位這時(shí)，我們開始對(duì)運(yùn)維人員和運(yùn)維的工作進(jìn)行定位，因?yàn)闇y(cè)試人員已經(jīng)被我們精簡(jiǎn)了，從整個(gè)業(yè)務(wù)流程里

19、拿掉了。那運(yùn)維人員是不是也要被我們拿掉？其實(shí)不是，我們所做的是把運(yùn)維的工作簡(jiǎn)化了，把不該運(yùn)維負(fù)責(zé)的東西拿出來(lái)了。應(yīng)用運(yùn)維不需要運(yùn)維團(tuán)隊(duì)負(fù)責(zé)，最終，產(chǎn)品從需求變成代碼，從代碼到生產(chǎn)，生產(chǎn)上以后監(jiān)控，出了問(wèn)題以后修復(fù)，這些具體執(zhí)行都不需要運(yùn)維介入，研發(fā)來(lái)做，誰(shuí)構(gòu)建誰(shuí)運(yùn)營(yíng)。那運(yùn)維管什么？管基礎(chǔ)設(shè)施的運(yùn)維，甚至是工具的開發(fā)，我們把工具開發(fā)的團(tuán)隊(duì)放在運(yùn)維團(tuán)隊(duì)里頭。這時(shí)大家看到的就是這樣一個(gè)結(jié)構(gòu)，就是研發(fā)使用運(yùn)維提供的兩種工具，第一個(gè)是支持工具，可能在還沒有成為一個(gè)集成的工具前我們可能有多個(gè)工具，比如代碼管理、項(xiàng)目管理、分支管理、構(gòu)建系統(tǒng)，以及最后的部署和發(fā)布系統(tǒng)。還有基礎(chǔ)設(shè)施的東西也是需要運(yùn)維人員去做的

20、，所以運(yùn)維團(tuán)隊(duì)變成了兩個(gè)部分，但在亞馬遜工具的開發(fā)是放在Dev這個(gè)部分的，這樣的話就變成開發(fā)在整個(gè)生命流程中他全管，他管的是跟業(yè)務(wù)相關(guān)的使用，而并不是要去開發(fā)監(jiān)測(cè)系統(tǒng)，但所有的監(jiān)測(cè)系統(tǒng)、部署系統(tǒng)都交由運(yùn)維做。Jenkins承擔(dān)了太多職責(zé)這個(gè)時(shí)候，Jenkins承擔(dān)了太多的工作，CI、構(gòu)建、環(huán)境、部署都是放在它這兒，所以每個(gè)團(tuán)隊(duì)上來(lái)做一個(gè)新的部署流水線時(shí)，要根據(jù)他的東西微調(diào)，重寫所有的腳本，這實(shí)際上非常浪費(fèi)時(shí)間。我們希望能通過(guò)配置，不需要重寫這些東西，也就是把編程性的工作變成配置性的工作。持續(xù)交付3.0關(guān)鍵工作系統(tǒng)化首先，就是要把關(guān)鍵的工作做成單獨(dú)的系統(tǒng)，把它系統(tǒng)化；對(duì)于構(gòu)建，我們不能再把它作為

21、Jenkins的一個(gè)插件，我們需要把它單獨(dú)拿出來(lái)做一個(gè)系統(tǒng)。部署也需要單獨(dú)做一個(gè)系統(tǒng)，都需要脫離Jenkins做，這樣才好管理，好拿一些關(guān)鍵性的數(shù)據(jù)。于是就演變成這樣一個(gè)系統(tǒng)，就是環(huán)境管理系統(tǒng)、運(yùn)行環(huán)境、部署流水線、元數(shù)據(jù)服務(wù)的一個(gè)簡(jiǎn)單結(jié)構(gòu)。下一步我們要把編程性的工作變成配置性的工作，因?yàn)槲覀儾幌胱尦绦騿T老寫一大堆腳本，而且在專屬系統(tǒng)內(nèi)可以開展一些更細(xì)節(jié)的工作，這是什么意思呢？實(shí)際上你可以看到每一個(gè)部分都有很多的實(shí)踐要做，比如說(shuō)部署策略，包括了一些分層測(cè)試、環(huán)境、流量進(jìn)來(lái)怎么樣分流，一些精確測(cè)試，告警這邊也是一樣的，有很多具體的細(xì)節(jié)實(shí)踐，如果都放在Jenkins里是非常難做的。這樣的話我們軟件

22、開發(fā)交付的是什么？應(yīng)該是一個(gè)運(yùn)行的系統(tǒng)，那么這個(gè)系統(tǒng)的生成的過(guò)程應(yīng)該是可配置、可重建、可追溯的，而且它的過(guò)程是自動(dòng)化、服務(wù)化和可視化的，整個(gè)過(guò)程都能一目了然地看到。自改進(jìn)體系報(bào)障和事故分析自改進(jìn)的體系，這個(gè)是偏運(yùn)維側(cè)的東西。第一個(gè)報(bào)障和事故分析，就是我們的系統(tǒng)到底運(yùn)行得好與不好？業(yè)務(wù)運(yùn)行的好壞怎么樣判斷？最簡(jiǎn)單的就是通過(guò)數(shù)據(jù)判斷。有一個(gè)方法就是我們一旦發(fā)現(xiàn)一個(gè)問(wèn)題，就要迅速發(fā)現(xiàn)、定位、跟進(jìn)、解決，而且要促進(jìn)分析，產(chǎn)生改進(jìn)，積累知識(shí)和支撐管理。這是傳統(tǒng)的內(nèi)部溝通的結(jié)構(gòu)。它可能有個(gè)內(nèi)部工單的系統(tǒng)，但沒有全流程的打通，而是通過(guò)郵件和IM這樣的東西去做溝通。這是我給之前公司畫的流程，包括已經(jīng)做的、還沒

23、有做的事情，很復(fù)雜。但如果我加上兩個(gè)系統(tǒng)，就可以產(chǎn)生一個(gè)是輪值、報(bào)障系統(tǒng)，加上卓越運(yùn)營(yíng)的理念，就可以基于故障做事故分析，總結(jié)經(jīng)驗(yàn)，把它變成流程和工具的改進(jìn)源頭。整個(gè)結(jié)構(gòu)如上圖所示，有智能報(bào)障系統(tǒng)、根因分析系統(tǒng)，根因分析系統(tǒng)會(huì)產(chǎn)生兩種東西，第一種流程性的改進(jìn)變成了SOP放在WIKI里頭，然后項(xiàng)目性的東西反饋到JIRA里面跟進(jìn)，即哪一個(gè)迭代需要通過(guò)系統(tǒng)進(jìn)行改進(jìn)。然后系統(tǒng)可以根據(jù)指標(biāo)（閾值）是3級(jí)報(bào)障去生成一個(gè)COE（事故分析）還是2級(jí)報(bào)障要生成一個(gè)COE，就是谷歌和亞馬遜說(shuō)的事故總結(jié)和分析，但它會(huì)有一些數(shù)據(jù)的分析和呈現(xiàn)。運(yùn)營(yíng)目標(biāo)和運(yùn)營(yíng)數(shù)據(jù)方面，我們可以看歷史的數(shù)據(jù)和它的趨勢(shì)，整個(gè)SLA趨勢(shì)是不是在變好。問(wèn)題分析實(shí)際上是這樣一個(gè)結(jié)構(gòu)，如果大家看SRE的話，SRE中的事故分析有五個(gè)結(jié)構(gòu)，我們用的是亞馬遜的一套結(jié)構(gòu)，跟谷歌的略有不同，但大致上是相同的，理念也是相同的。APM、日志與追蹤運(yùn)維側(cè)大家都比較熟悉，你會(huì)發(fā)現(xiàn)研發(fā)層面已經(jīng)順暢，這時(shí)系統(tǒng)的運(yùn)行狀態(tài)就是我們需要關(guān)注的，這實(shí)際上是縱向的和橫向的，縱向是從業(yè)務(wù)面的，橫向是在系統(tǒng)架構(gòu)從前到后那么多機(jī)器里頭，到底哪出問(wèn)題了，這時(shí)就會(huì)發(fā)現(xiàn)需要三個(gè)東西，第一個(gè)需要傳統(tǒng)的APM，第二需要日志的分析，第三需要全鏈路的追蹤能力。場(chǎng)景化運(yùn)維：定位到點(diǎn)全景圖基本上如上圖所示，可以看到左邊是偏研發(fā)的，右