《DevOps與傳統(tǒng)的融合落地實(shí)踐及案例分析（上）》要點(diǎn)：
本文介紹了DevOps與傳統(tǒng)的融合落地實(shí)踐及案例分析（上），希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

導(dǎo)讀：5月6日,優(yōu)維科技與數(shù)人云主辦了【DevOps&SRE超越傳統(tǒng)運(yùn)維之道 · 深圳站】,6月北京站敬請(qǐng)關(guān)注~本文是優(yōu)維科技CEO王津銀關(guān)于DevOps與傳統(tǒng)的融合落地實(shí)踐的精彩分享

 

作者：王津銀／優(yōu)維科技創(chuàng)始人&CEO

中國(guó)開(kāi)放運(yùn)維聯(lián)盟發(fā)起人,精益運(yùn)維”理論提出者,中國(guó)第一批DevOps Master授權(quán)講師,持續(xù)交付專(zhuān)家,業(yè)內(nèi)人稱(chēng)“老王”.“互聯(lián)網(wǎng)運(yùn)維雜談”公眾號(hào)創(chuàng)辦者.致力于互聯(lián)網(wǎng)運(yùn)維整體解決方案的產(chǎn)品化能力提升,縮短企業(yè)到達(dá)互聯(lián)網(wǎng)運(yùn)維的路徑.

一直覺(jué)得華南這一片技術(shù)沙龍?zhí)倭?在DevOps、SRE理念大熱的今天,我們希望能把一些先進(jìn)的經(jīng)驗(yàn)分享出來(lái),讓更多的企業(yè)能夠受益.華南有很多優(yōu)秀的業(yè)界從業(yè)者,比如說(shuō)今天邀請(qǐng)到的大梁,騰訊內(nèi)部關(guān)于DevOps還是有很多的經(jīng)驗(yàn)值得分享的.

今天活動(dòng)主題是DevOps&SRE,我來(lái)講DevOps,王璞分享SRE,SRE是谷歌的DevOps實(shí)踐,大梁把DevOps最后一棒——持續(xù)反饋跟大家分享,希望把這些鏈條全部的打通.

今天的演講主要分為以下三個(gè)部分：第一個(gè)是DevOps全局的理解以及DevOps與ITIL的對(duì)比融合,第二個(gè)是DevOps落地經(jīng)驗(yàn)14則,第三個(gè)是案例的分析.

DevOps全局的理解

其實(shí)講DevOps特別的多,官方里面給了一個(gè)框架圖,從計(jì)劃需求、設(shè)計(jì)、開(kāi)發(fā)、部署、運(yùn)營(yíng)、宗旨,持續(xù)交付到IT運(yùn)營(yíng)管理、經(jīng)營(yíng)管理,后來(lái)擴(kuò)展了一下,大家看到這個(gè)全景圖的時(shí)候的確有概念的認(rèn)知,我覺(jué)得不夠.做了以下幾點(diǎn)改動(dòng)：

第一： ?IT運(yùn)營(yíng)管理

以前叫IT服務(wù)管理,因?yàn)镮T服務(wù)管理帶來(lái)很多ITIL的認(rèn)知,今天看IT運(yùn)營(yíng)范疇變得很多了.面向IT運(yùn)營(yíng)管理的實(shí)踐,ITIL延伸出來(lái)的IT服務(wù)管理只是其中一部分,還有運(yùn)營(yíng)管理、性能管理、監(jiān)控管理、分析管理等等.

第二： ?擴(kuò)展上層的實(shí)踐和工具部分

同時(shí)給出一個(gè)從理念—工程與方法—過(guò)程—實(shí)踐—工具的轉(zhuǎn)換路徑圖.這樣讓我們更能清晰的看到DevOps的整體框架和落地實(shí)踐及工具的關(guān)系.

今天看DevOps整體框架,其實(shí)也是一連串工程實(shí)踐組合,包括敏捷工程、持續(xù)交付和IT運(yùn)營(yíng)管理及其精益實(shí)踐等等.在過(guò)去IT組織中,或多或少都有敏捷管理和IT運(yùn)營(yíng)管理的實(shí)踐,但I(xiàn)T的效率依然不高,為什么?今天似乎在持續(xù)交付中可以找到答案——IT如何成為業(yè)務(wù)的核心競(jìng)爭(zhēng)力.

DevOps與ITIL的對(duì)比融合

DevOps跟ITIL對(duì)比,其實(shí)兩個(gè)不屬于同一個(gè)范疇,DevOps是屬于IT全局的,ITIL是屬于運(yùn)維這塊的,IT服務(wù)管理的,其實(shí)聚焦的領(lǐng)域不一樣,但是還是有必要做一個(gè)對(duì)比.

因?yàn)槲矣X(jué)得在運(yùn)維的行業(yè),我覺(jué)得還是要把這兩個(gè)理念做一個(gè)清晰的劃分,比如說(shuō)今天講的以DevOps整個(gè)理念做平臺(tái),到底以ITIL做這個(gè)平臺(tái)有什么樣的不同.這里面是做一個(gè)對(duì)比.

首先ITIL是面向管理的過(guò)程,以這個(gè)目標(biāo)規(guī)范優(yōu)先,DevOps是面向IT運(yùn)營(yíng)過(guò)程,是執(zhí)行的能力跟自動(dòng)化,ITIL 是離線任務(wù)管理為主要特征,而DevOps是以在線服務(wù)的.

可以看這里面有關(guān)鍵的作用力,我自己的理解把云計(jì)算、上層的框架模式拆分出來(lái)之后你會(huì)發(fā)現(xiàn)越接近上層應(yīng)用,其實(shí)ITIL 對(duì)它的作用力越來(lái)越小.

比如說(shuō)之前大梁給我的數(shù)據(jù),他的部門(mén)兩個(gè)星期發(fā)布9000次,這個(gè)不可能針對(duì)每一次的發(fā)布建立強(qiáng)流程,這樣流程太多帶來(lái)成本非常高,達(dá)不到那種的效率.

我們?cè)诘紫驴梢钥吹?在底層基礎(chǔ)設(shè)施這塊的,硬件基礎(chǔ)能力還沒(méi)有達(dá)到軟件定義這種SDX化,它的作用力依然存在的,但是未來(lái)隨著軟件定義化的能力越來(lái)越強(qiáng),這波浪潮也會(huì)改變.NetDevOps的興起就是一個(gè)極好的例子.

DevOps自動(dòng)化與ITIL規(guī)范之間的融合

DevOps可以看到在線服務(wù)管理里面,可以兼顧質(zhì)量效率和成本規(guī)劃,上圖就是DevOps自動(dòng)化與ITIL怎么融合,極力避免形成OA流程在IT部門(mén)的應(yīng)用.這是按照優(yōu)維的實(shí)踐,在傳統(tǒng)的行業(yè)做交付的過(guò)程中我們的產(chǎn)品怎么跟ITIL流程思想對(duì)接得出來(lái)的模式：

?第一種模式：申請(qǐng)ITIL流程的時(shí)候可以直接調(diào)動(dòng)DevOps的工具

典型的特征,比如說(shuō)第一種在線服務(wù)開(kāi)通流程,我要把我的防火墻開(kāi)通了,這時(shí)候申請(qǐng)一個(gè)表單,審核通過(guò)了立馬調(diào)用DevOps的工具執(zhí)行.

但以前是離線的IT服務(wù)目錄,我提一個(gè)表單、需求單,這個(gè)需求單審核通過(guò)同意之后,方案管理人員再跑去設(shè)備去開(kāi)通,今天不一樣,讓流程變成立即可以執(zhí)行的模式.

今天舉例：資源申請(qǐng)流程,在CMDB整個(gè)資源申請(qǐng)里,這是國(guó)信證券的典型案例,比如說(shuō)以前資源申請(qǐng),我從庫(kù)房拿一個(gè)設(shè)備,這個(gè)設(shè)備拿出來(lái)我要分配網(wǎng)絡(luò)重組,以前是各個(gè)角色分配完了填寫(xiě)回復(fù),今天不是這樣的,把這個(gè)流程在線化,所有的資源通過(guò)CMDB資源層拿出來(lái)直接在表單里執(zhí)行.

第二種模式：重大變更的流程

這個(gè)流程在華南很大的銀行總結(jié)出來(lái)的案例,我們把所有的變更流程、審批流程做完之后,立馬啟動(dòng)執(zhí)行流,對(duì)于高穩(wěn)定性服務(wù)保障流程非常的重要.

比如說(shuō)對(duì)于銀行基礎(chǔ)設(shè)施的網(wǎng)絡(luò)等等非常重要的,這里有一個(gè)問(wèn)題,這個(gè)流程我在審批的時(shí)候是A方案,到審核之后方案有可能會(huì)被人為改變,怎么辦?這種情形有改進(jìn)的措施,我們把DevOps調(diào)度流作為審批流方案一部分,審批通過(guò)了這個(gè)流程可以去進(jìn)行執(zhí)行,這個(gè)保證了流程審批完了以后和在線的流程是一致的.

第三種模式：敏捷發(fā)布的流程,或者是DevOps變更的流程

因?yàn)榻裉旌芏嗟牧鞒滩辉僖蕾?lài)ITIL 完成的,比如說(shuō)敏捷的發(fā)布流程JIRA管理,這是一個(gè)新的研發(fā)管理工具,不可能再回到ITIL 提一個(gè)發(fā)布單,這里面我總結(jié)的是紅綠燈機(jī)制.當(dāng)我進(jìn)入到某一個(gè)環(huán)節(jié),比如說(shuō)測(cè)試環(huán)節(jié)不符合的時(shí)候,我看到基于什么樣的狀態(tài)?如果通過(guò)了就開(kāi)始的執(zhí)行.

今天講的DevOps,還可以從另一個(gè)維度看,叫軟件研發(fā)的模式去看.我們經(jīng)歷了幾種模式的變化,第一種是waterfall 的模式,比如說(shuō)研發(fā)、測(cè)試、運(yùn)維間彼此是割裂的,獨(dú)立的,中間有一個(gè)墻存在的,這里面有嚴(yán)格的輸入輸出在進(jìn)行傳遞.

往下面走就是敏捷研發(fā)的模式,這里面講的TDD的測(cè)試研發(fā),在每一次的版本可以做很多的小迭代,比如說(shuō)今天我們做easyops平臺(tái),我們規(guī)定兩個(gè)星期出一個(gè)小版本,這兩個(gè)星期出一個(gè)小版本的時(shí)候,內(nèi)部還經(jīng)歷一個(gè)小迭代,內(nèi)部很多的小迭代做這個(gè)事情.

但是這里面依然有問(wèn)題,研發(fā)跟測(cè)試是一體化的,測(cè)試驅(qū)動(dòng)研發(fā),這塊運(yùn)維、operation 還是被隔離在外了,但是隨著新的業(yè)務(wù)形態(tài)出現(xiàn)后,比如說(shuō)互聯(lián)網(wǎng)的模式出現(xiàn)了之后,要強(qiáng)調(diào)端到端能力的整合.

DevOps軟件研發(fā)模式就出現(xiàn)了,在和客戶(hù)交流的時(shí)候,不斷的觸發(fā)思考一個(gè)點(diǎn),實(shí)施了敏捷和IT服務(wù)管理,為什么IT依然看成成本中心而不是業(yè)務(wù)的核心競(jìng)爭(zhēng)力,為什么還是對(duì)業(yè)務(wù)需求響應(yīng)很慢?在前面講的持續(xù)交付就是來(lái)解決這個(gè)問(wèn)題的.

可以看在幾種研發(fā)模式中,比如說(shuō)這個(gè)Develop以前測(cè)試的時(shí)候占的70%,詳細(xì)的設(shè)計(jì)占比重越來(lái)越大,但是到小迭代、小設(shè)計(jì)的時(shí)候Design工作變得越來(lái)越小,研發(fā)居多了,再往下看測(cè)試的工作量變得越來(lái)越少,變成自動(dòng)化的工具.這是我們總結(jié)的數(shù)據(jù),可以看到隨著研發(fā)模式的變化,各個(gè)角色在里面承擔(dān)了工作量的配比也在發(fā)生變化,研發(fā)越來(lái)越重要,很多工作也前置到研發(fā)階段.

DevOps落地經(jīng)驗(yàn)十四則(上)

第一則：理念與價(jià)值先行

第一、二點(diǎn)

這里面一定不是簡(jiǎn)單談文化的,一定談工程實(shí)踐落地的因素.

第三點(diǎn)：端到端持續(xù)服務(wù)交付流程的改革

這里面不是講的結(jié)果而是講的過(guò)程,process不是過(guò)去講的IT服務(wù)流程,把過(guò)程的變革,一旦工具進(jìn)來(lái)簡(jiǎn)化我的流程或者是自動(dòng)化的流程都帶來(lái)變革.

第四點(diǎn)：對(duì)新的應(yīng)用和服務(wù),加快且縮短實(shí)現(xiàn)價(jià)值交付的時(shí)間.

這里面講的怎么樣有一個(gè)想法,快速實(shí)現(xiàn)這個(gè)想法,把這個(gè)想法反饋回來(lái),讓我持續(xù)的改進(jìn),不影響安全性和持續(xù)性,這一點(diǎn)我覺(jué)得蠻有意思的,比如說(shuō)在國(guó)內(nèi)講雙態(tài)運(yùn)維的理念,雙態(tài)運(yùn)維根源上有雙態(tài)IT形態(tài)的存在,

但是運(yùn)維的本身沒(méi)有所謂的雙態(tài)的差別,你使用的方法論、工具自動(dòng)化套路都是一致的,因?yàn)槲夜芾淼腎T都是從本質(zhì)上干幾件事情,把命令傳過(guò)去、文件傳過(guò)去、數(shù)據(jù)采集回來(lái),就干這三件事情,本質(zhì)上這個(gè)流程該形成有效的設(shè)計(jì),兼容安全和性能的要素.

第二則：頂層設(shè)計(jì)、全局規(guī)劃.

這個(gè)是之前給一個(gè)物流行業(yè)做咨詢(xún)的時(shí)候提出來(lái)一個(gè)模型,DevOps運(yùn)維的體系分成6個(gè)維度＋一個(gè)文化,這里面包括組織、過(guò)程、架構(gòu)、工具、基礎(chǔ)設(shè)施、度量＋文化.

第一點(diǎn)：組織

DevOps首先必須打破組織之間的隔閡,其實(shí)DevOps團(tuán)隊(duì)建立面向產(chǎn)品而非項(xiàng)目的協(xié)作文化.

第二點(diǎn)：過(guò)程

過(guò)程不是流程,輕量級(jí)流程和自動(dòng)化的工具完美結(jié)合,確保企業(yè)的高度敏捷性、自動(dòng)化為先、而后再流程.

第三點(diǎn)：架構(gòu)

架構(gòu)是應(yīng)用的架構(gòu)、基礎(chǔ)的架構(gòu)和數(shù)據(jù)的架構(gòu),數(shù)據(jù)的架構(gòu)談起來(lái)虛一點(diǎn),應(yīng)用的架構(gòu)和基礎(chǔ)的架構(gòu)是比較明確的,應(yīng)用的架構(gòu)更多講微服務(wù)的架構(gòu),基礎(chǔ)架構(gòu)是標(biāo)準(zhǔn)化的基礎(chǔ)設(shè)施,像Saas、paas平臺(tái).

第四點(diǎn)：工具

強(qiáng)調(diào)的平臺(tái)層面上,怎么樣把IT能力平臺(tái)化,從DevOps整個(gè)過(guò)程構(gòu)建持續(xù)交付的平臺(tái),到運(yùn)營(yíng)構(gòu)建IT運(yùn)營(yíng)管理的平臺(tái),都是很重要的,只有它們能夠把所有的質(zhì)量成本和效率幾者維度兼顧起來(lái),具備可落地化.

回到頂層設(shè)計(jì)和平臺(tái)層面來(lái)說(shuō),IT運(yùn)營(yíng)管理平臺(tái)到底應(yīng)該怎么樣的設(shè)計(jì)?這里面講到的云數(shù)據(jù)平臺(tái)和iaas平臺(tái).在上面面向不同的IT管理過(guò)程,我做一些域設(shè)計(jì)的細(xì)分,比如說(shuō)ITIL,分成基礎(chǔ)、高級(jí)的、運(yùn)維服務(wù)平臺(tái)、研發(fā)的服務(wù)平臺(tái).

第五點(diǎn)：基礎(chǔ)設(shè)施

對(duì)應(yīng)的IaaS、PaaS部分,怎么樣做持續(xù)反饋?監(jiān)控,端到端的監(jiān)控,從底層的基礎(chǔ)設(shè)施,到上層的應(yīng)用服務(wù)組建,從基礎(chǔ)設(shè)施到接口、用戶(hù)測(cè)量的監(jiān)控這個(gè)端到端的能力怎么構(gòu)建?這個(gè)構(gòu)建成數(shù)據(jù)采集的基礎(chǔ).

第六點(diǎn)：度量

今天看監(jiān)控是面向數(shù)據(jù)化的思維做監(jiān)控,今天數(shù)據(jù)的特征發(fā)生了變化,不僅僅是結(jié)構(gòu)化還有非結(jié)構(gòu)化的數(shù)據(jù).比如說(shuō)日志,怎么樣把日志當(dāng)成流式數(shù)據(jù)的處理?

有了這樣的數(shù)據(jù)采集基礎(chǔ),這里面有分析的平臺(tái),結(jié)合運(yùn)維的場(chǎng)景,容量、可用性、業(yè)務(wù)連續(xù)性等等進(jìn)行分析,結(jié)合IT的規(guī)模形態(tài)發(fā)生變化,所要看到的指標(biāo)也會(huì)不一樣,比如說(shuō)基于云端要看成本和費(fèi)用分析都不一樣的,需求也不一樣的.

IT服務(wù)中心是把整個(gè)IT服務(wù)能力怎么樣的目錄化,同時(shí)結(jié)合自動(dòng)化的工具兩者銜接起來(lái).這個(gè)講的變更中心,有一個(gè)梳理的方法,現(xiàn)在的傳統(tǒng)企業(yè),比如說(shuō)國(guó)信證券,結(jié)合CMDB管理的對(duì)象,把這個(gè)管理的對(duì)象整理出來(lái),通過(guò)IT服務(wù)中心給變更能力目錄化,同時(shí)表達(dá)標(biāo)準(zhǔn)化,最后對(duì)接工具自動(dòng)化.

再往上可以提供各種的服務(wù)編排的能力,這種服務(wù)編排是跨越了各種工具的,再往上是構(gòu)建運(yùn)維的統(tǒng)一模庫(kù).這是頂層設(shè)計(jì)和全局規(guī)劃.

第三則：Start Small,從小做起.

DevOps這么大的體系,大平臺(tái)上又有這么多,是不是全都要落地?一定要Start Small,這個(gè)準(zhǔn)則很好梳理,基于每個(gè)角色＋某個(gè)場(chǎng)景從小做起,一定要把IT部門(mén)的角色梳理出來(lái),比如說(shuō)到運(yùn)維這邊,有業(yè)務(wù)運(yùn)維、系統(tǒng)管理員,網(wǎng)絡(luò)運(yùn)營(yíng).

第二可以基于每個(gè)系統(tǒng)和每個(gè)功能實(shí)施導(dǎo)入,比如說(shuō)今天就做監(jiān)控庫(kù),我看傳統(tǒng)的企業(yè)很多做CMDB導(dǎo)入,切忌貪大求全,給你畫(huà)的圖景是很美好的,很多人說(shuō)DevOps很好,怎么樣落地呢?一定要Start Small.

第四則：構(gòu)建元數(shù)據(jù)基礎(chǔ)平臺(tái)CMDB

下一個(gè)階段要把它名字改為IT資源管理平臺(tái),因?yàn)槲矣X(jué)得現(xiàn)在需要把CMDB的管理資源和職責(zé)范圍縮小,其實(shí)在不同的階段,我們管理也不能貪大求全,把所有的配置全部管理起來(lái),最后發(fā)現(xiàn)自己轉(zhuǎn)不動(dòng)了.上面的場(chǎng)景又起不來(lái),現(xiàn)在很難把場(chǎng)景構(gòu)建起來(lái),場(chǎng)景起不來(lái)的時(shí)候,結(jié)果把CMDB做死了,我們一直講這個(gè)數(shù)據(jù)的鮮活性,結(jié)果做不起來(lái).

今天我把范圍縮小了,只管基礎(chǔ)設(shè)施的資源和應(yīng)用的資源,基礎(chǔ)設(shè)施是屬于目前應(yīng)用的,這個(gè)資產(chǎn)狀況管理起來(lái)我從應(yīng)用的角度看,到底用了哪些資源?

把這兩層的維度強(qiáng)關(guān)聯(lián)起來(lái),然后在應(yīng)用上層構(gòu)建應(yīng)用的各種的管理場(chǎng)景,比如說(shuō)應(yīng)用的發(fā)布、應(yīng)用的部署、應(yīng)用的監(jiān)控等等.應(yīng)用的數(shù)據(jù)分析,由它來(lái)進(jìn)行進(jìn)一步的驅(qū)動(dòng)CMDB的流轉(zhuǎn),因?yàn)樵趹?yīng)用的維度上,才符合以前講的高頻的特征.

今天到任何一個(gè)組織,其變更的場(chǎng)景來(lái)說(shuō),應(yīng)用是最頻繁的,比頂層基礎(chǔ)設(shè)施更頻繁.如果符合高頻的特征可以理解場(chǎng)景化的能力最強(qiáng)的,場(chǎng)景化的能力強(qiáng)那驅(qū)動(dòng)力就是最強(qiáng)的,今天把CMDB轉(zhuǎn)化成IT資源管理,以應(yīng)用的視角看資源.這個(gè)平臺(tái)里它的核心作用是毋庸置疑的,應(yīng)用是CMDB平臺(tái)的元數(shù)據(jù).

這里面怎么樣的上層聯(lián)動(dòng)?CMDB這么多的數(shù)據(jù),其實(shí)就是一類(lèi)的實(shí)例的數(shù)據(jù).比如說(shuō)這里面到底有多少服務(wù)器、服務(wù)器有多少的虛擬機(jī)?這是實(shí)例的數(shù)據(jù),然后就是拓?fù)涞臄?shù)據(jù).我的服務(wù)擺在機(jī)柜上,介入的上面數(shù)據(jù)是什么.同樣是根據(jù)頂層的資源拆出來(lái)的,一個(gè)基礎(chǔ)資源一個(gè)是應(yīng)用的資源,分成實(shí)例管理和拓?fù)涔芾?

今天很多人講自動(dòng)化,其實(shí)資源有生命周期的狀態(tài),一定不能通過(guò)自動(dòng)化來(lái)替代的.比如說(shuō)這個(gè)IP地址從資源池里面分配出來(lái)給業(yè)務(wù)池使用,一定要通過(guò)一個(gè)流程申請(qǐng)出來(lái),無(wú)論是自動(dòng)化的還是以前離線流程的,這是一個(gè)生命周期的狀態(tài),IT地址退還不能保留業(yè)務(wù)使用,這個(gè)一定要有流程控制的,這里面自動(dòng)化不能代替人工的流程,流程是聚焦在事前的管理.

再往上是場(chǎng)景應(yīng)用,要找各種的場(chǎng)景應(yīng)用,構(gòu)建出來(lái)這一層做的形象的比喻就相當(dāng)于今天的地圖一樣的,比如說(shuō)百度地圖,這個(gè)地圖可以在不同的場(chǎng)景用,大眾點(diǎn)評(píng)可以用,滴滴也可以用,今天的CMDB也起到這樣的作用.這么多場(chǎng)景建設(shè)的時(shí)候,事件平臺(tái)是一個(gè)很好的入口.

因?yàn)榻裉炜吹絺鹘y(tǒng)的行業(yè)太多的監(jiān)控系統(tǒng),這個(gè)監(jiān)控系統(tǒng)都要進(jìn)行收斂,怎么收斂?把所有的監(jiān)控實(shí)踐發(fā)到統(tǒng)一事件系統(tǒng),由統(tǒng)一事件系統(tǒng)根據(jù)底層的IT對(duì)象關(guān)系自己來(lái)進(jìn)行收斂,現(xiàn)在老的監(jiān)控系統(tǒng)基于CMDB收斂是很難的,基本上找不到監(jiān)控廠商來(lái)修改,提一個(gè)需求要帶來(lái)大量的成本.

為什么一直在講CMDB核心的管理模型是應(yīng)用的管理模型,IT形態(tài)發(fā)生變化了,這個(gè)模型不用改變的,不用調(diào)整的,比如說(shuō)是公有云.CMDB模型的擴(kuò)展力是把所有的資源管理起來(lái),這個(gè)資源分成本地資源和第三方的資源,本地資源是應(yīng)用部署在同一主機(jī)上的資源,比如說(shuō)程序包、操作系統(tǒng)的版本,使用的內(nèi)存,或者是這里面的配置的版本等等,甚至在本機(jī)占用了端口甚至是接口服務(wù)都是我們的資源.第三方資源如阿里云,這些資源都可以通過(guò)應(yīng)用管理維度集中起來(lái).

第五則：痛苦的事情優(yōu)先解決

基于角色和產(chǎn)品如何梳理管理能力?運(yùn)維的復(fù)雜度為什么復(fù)雜?在這兒,因?yàn)檫\(yùn)維角色太多了,管理的對(duì)象太多了,產(chǎn)品太多了,最終出來(lái)的能力管理流程也可以太多.開(kāi)發(fā)測(cè)試沒(méi)有如此復(fù)雜,開(kāi)發(fā)就開(kāi)發(fā),測(cè)試就測(cè)試.這里面一定要通過(guò)角色＋場(chǎng)景,最后導(dǎo)出我應(yīng)該構(gòu)建什么樣的能力管理的平臺(tái)出來(lái),一定要有這樣的思路.

今天講的運(yùn)維自動(dòng)化,最后我變成配置管理或者是工具的自動(dòng)化或者是調(diào)度的自動(dòng)化,這個(gè)遠(yuǎn)遠(yuǎn)不夠,其實(shí)運(yùn)維自動(dòng)化彌漫在每一個(gè)角色、每一個(gè)場(chǎng)景里,今天說(shuō)的基于容量的自動(dòng)擴(kuò)容不算自動(dòng)化嗎?CMDB的自動(dòng)發(fā)現(xiàn)不算自動(dòng)化?基于監(jiān)控事件故障自愈不算自動(dòng)化嗎?都算.基于這個(gè)圖把自動(dòng)化的場(chǎng)景收斂一樣,作業(yè)和調(diào)度的能力是底層平臺(tái)化的能力,在各個(gè)子系統(tǒng)使用.

第六則：工具也是一種文化

這里面講的作業(yè)管理和調(diào)度的管理應(yīng)該是平臺(tái)級(jí)的能力,不需要進(jìn)行場(chǎng)景化的理解.在自動(dòng)化的構(gòu)成要素里有一個(gè)原子化的事務(wù),同時(shí)有調(diào)度編排原子化的事務(wù),有兩個(gè)要素有夠了.再往上是面向角色的場(chǎng)景化收斂和歸類(lèi),工具可以把我們的能力拼裝起來(lái),在各個(gè)場(chǎng)景下使用.工具是真正推動(dòng)變革的有效手段,好的經(jīng)驗(yàn)一定是通過(guò)自動(dòng)化的手段沉淀管理過(guò)程.

文章來(lái)自微信公眾號(hào)：優(yōu)維科技EasyOps

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/4124.html