網(wǎng)絡(luò)DevOps探索與實(shí)踐
掃描二維碼
隨時(shí)隨地手機(jī)看文章
為什么要引入DevOps模式?
老的開(kāi)發(fā)模式這樣會(huì)出現(xiàn)多個(gè)問(wèn)題:
-
最常見(jiàn)的一個(gè)場(chǎng)景:開(kāi)發(fā)這邊的排期已經(jīng)到2個(gè)月之后,運(yùn)營(yíng)這邊覺(jué)得太晚了。但前面確實(shí)有那么多開(kāi)發(fā)需求待實(shí)現(xiàn)。開(kāi)發(fā)搞不過(guò)來(lái)了。
-
某些新的監(jiān)控項(xiàng)目,運(yùn)營(yíng)通過(guò)具體的數(shù)據(jù)才能知道該功能的業(yè)務(wù)價(jià)值;開(kāi)發(fā)的同學(xué)把功能上線后,就忙著下一個(gè)需求了,對(duì)后續(xù)的運(yùn)營(yíng)關(guān)注不多。經(jīng)常會(huì)導(dǎo)致歷史上積累了非常多的工具系統(tǒng),但作用都很寥寥。
-
基礎(chǔ)架構(gòu)的運(yùn)營(yíng)系統(tǒng),原來(lái)只針對(duì)自研業(yè)務(wù)做了大量的功能;后來(lái)到公有云,現(xiàn)在也有大量的私有云客戶(hù),服務(wù)的對(duì)象發(fā)生了變化。外部的客戶(hù)對(duì)功能需要做二次開(kāi)發(fā),需要具備DevOps能力。
為了解決以上這些問(wèn)題,需要系統(tǒng)化的來(lái)進(jìn)行解決。根本上來(lái)說(shuō),就是要以人為本,提升運(yùn)營(yíng)與開(kāi)發(fā)的滿意度,DevOps是一個(gè)切實(shí)可行的方案。
DevOps沒(méi)有發(fā)明任何新技術(shù),他只是一種軟件開(kāi)發(fā)的模式。這里有個(gè)DevOps的分級(jí)模型,是國(guó)內(nèi)業(yè)界的前輩制定了一個(gè)規(guī)范,最近也已經(jīng)通過(guò)了ITU-T組織的審核。這里內(nèi)容比較多,不逐一贅述。基礎(chǔ)架構(gòu)DevOps的實(shí)踐過(guò)程,是借鑒其理念,讓大家都在同一個(gè)簡(jiǎn)單易用的軟件平臺(tái)上進(jìn)行合作開(kāi)發(fā),達(dá)到服務(wù)快速上線目的。其中最主要的一個(gè)關(guān)鍵點(diǎn)就是雙方要進(jìn)行融合,互相促進(jìn)。
騰訊網(wǎng)絡(luò)運(yùn)營(yíng)DevOps系統(tǒng)的現(xiàn)狀
騰訊的網(wǎng)絡(luò)運(yùn)營(yíng)先后經(jīng)歷人工操作、工具腳本、自動(dòng)化等這幾個(gè)階段。運(yùn)營(yíng)團(tuán)隊(duì),就是我們熟悉的網(wǎng)工,過(guò)去都有專(zhuān)業(yè)的開(kāi)發(fā)人員來(lái)進(jìn)行配套的工具系統(tǒng)開(kāi)發(fā)。在過(guò)去幾年,網(wǎng)工們的開(kāi)發(fā)能力持續(xù)提升,在DevOps平臺(tái)的加持下,已經(jīng)掌握了通用的開(kāi)發(fā)能力,一些運(yùn)營(yíng)過(guò)程中需要的功能,可以基于DevOps平臺(tái)自行開(kāi)發(fā)了。這樣,傳統(tǒng)的開(kāi)發(fā)人員和網(wǎng)工,都可以基于這個(gè)統(tǒng)一平臺(tái)來(lái)“吃自己的狗糧”。運(yùn)營(yíng)人員自行開(kāi)發(fā)功能,上線后出現(xiàn)問(wèn)題,反查自己設(shè)計(jì)的業(yè)務(wù)邏輯;開(kāi)發(fā)人員主導(dǎo)開(kāi)發(fā)功能發(fā)布后,出現(xiàn)了bug,也自己定位代碼或者平臺(tái)的問(wèn)題。這樣,發(fā)現(xiàn)問(wèn)題后,都先從自身出發(fā)來(lái)排查,減少了互相埋怨,大家的關(guān)系也相對(duì)融洽起來(lái)。
如何建設(shè)DevOps平臺(tái)?
我們把建設(shè)的過(guò)程分以下6個(gè)方面來(lái)介紹。
1、上層規(guī)劃 – 運(yùn)營(yíng)事務(wù)流程化
無(wú)流程不運(yùn)營(yíng)。我們?cè)趦?nèi)部先把這個(gè)意識(shí)先進(jìn)行了統(tǒng)一,這個(gè)是DevOps開(kāi)發(fā)的前提,也是DevOps任務(wù)可編排的前提。我們經(jīng)常說(shuō)可編排,編排完了之后,不就是由一個(gè)個(gè)編排后節(jié)點(diǎn)串接起來(lái)的流程嗎?下面跟大家介紹下我們內(nèi)部總結(jié)出來(lái)的流程成熟的模型。初步評(píng)估,騰訊基礎(chǔ)架構(gòu)運(yùn)營(yíng)處在level 3這個(gè)階段。怎么解讀呢?
-
流程體系化,是指我們各個(gè)運(yùn)營(yíng)業(yè)務(wù)基本都有了對(duì)應(yīng)的線上流程。幾乎不存在線下操作的場(chǎng)景了。
-
部分的流程完成生命周期管理,這個(gè)是對(duì)流程控制端到端的一個(gè)需求。
-
較為完善的OLA/SLA管理,有了詳細(xì)的OLA數(shù)據(jù),我們就能對(duì)每個(gè)工單的實(shí)施過(guò)程都能詳細(xì)的分析和管理。
-
工具系統(tǒng)敏捷迭代,系統(tǒng)工具除了能直接解決業(yè)務(wù)的需求,還要有二次開(kāi)發(fā)的能力。
在系統(tǒng)架構(gòu)頂層設(shè)計(jì)方面,我們使用DDD—領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的模式,具體到DevOps平臺(tái),著重領(lǐng)域?qū)拥膶?shí)踐。把DevOps的整體功能模塊分為四大塊:
-
可視化編排平臺(tái):這個(gè)是運(yùn)營(yíng)事務(wù)流程化的具體落地方式。流程圖讓業(yè)務(wù)邏輯可以非常直觀的展示出來(lái)。
-
應(yīng)用管理模塊:方便用戶(hù)參與開(kāi)發(fā)。SDK的方式,是開(kāi)源共建的基礎(chǔ),減少了大量重復(fù)代碼;權(quán)限管理,有效避免了用戶(hù)之間的互信影響。
-
數(shù)據(jù)運(yùn)營(yíng)模塊:數(shù)據(jù)化管理。流程及工單數(shù)據(jù)每天都會(huì)以非常大的量級(jí)增長(zhǎng),沒(méi)有完善的任務(wù)超時(shí)告警及運(yùn)營(yíng)數(shù)據(jù)自動(dòng)收集分析功能,后續(xù)的業(yè)務(wù)維護(hù)會(huì)非常耗時(shí)耗力。
-
平臺(tái)管理:是系統(tǒng)運(yùn)維的重要窗口。讓人人可運(yùn)維成為可能。
無(wú)代碼化開(kāi)發(fā),并不是指一行代碼都沒(méi)有。而是盡量減少編碼的場(chǎng)景。在很多模塊中,DevOps平臺(tái)把設(shè)備命令模板層、業(yè)務(wù)函數(shù)、業(yè)務(wù)流程及觸發(fā)規(guī)則等這四個(gè)層次,都用對(duì)應(yīng)的模板或SDK封裝起來(lái),形成可復(fù)用的邏輯。這里列舉的是命令模板這一層的封裝。對(duì)于運(yùn)營(yíng)人員來(lái)說(shuō),在DevOps體系的驅(qū)動(dòng)下,開(kāi)發(fā)能力逐步提升。同時(shí),通過(guò)配置化或少量的代碼,可以用極低的成本,快速開(kāi)發(fā)上線驗(yàn)證類(lèi)的功能,不需要任何專(zhuān)業(yè)開(kāi)發(fā)資源投入,大大較少試錯(cuò)的成本。
3、DevOps的生命周期管理
這里是從DevOps開(kāi)發(fā)的新模式出發(fā),把過(guò)程中需要配套的功能點(diǎn)逐一進(jìn)行完善,從而完成了DevOps開(kāi)發(fā)整個(gè)生命周期的管理。
-
需求管理。對(duì)需求進(jìn)行建模,把功能點(diǎn)往各個(gè)預(yù)分配好的領(lǐng)域靠攏,避免功能碎片化。在騰訊內(nèi)部,有TAPD工具對(duì)需求做詳細(xì)跟蹤,保證落地效果。
-
開(kāi)發(fā)環(huán)境。這個(gè)是參與DevOps開(kāi)發(fā)同學(xué)最關(guān)心的地方,直接關(guān)系到開(kāi)發(fā)效率。主要涉及環(huán)境統(tǒng)一配置、代碼版本管理、測(cè)試覆蓋及CI/CD等環(huán)節(jié)。
-
流程管理。事務(wù)流程化后,會(huì)產(chǎn)生非常多的流程,流程圖需要方便創(chuàng)建及修改;其次在工單建立后,會(huì)馬上實(shí)例化,任務(wù)執(zhí)行過(guò)程中的異常超時(shí)基礎(chǔ)配置需要在OLA/SLA中進(jìn)行配置。
-
任務(wù)管理。具體事務(wù)的操作,更多的是調(diào)用第三方接口和對(duì)設(shè)備進(jìn)行查詢(xún)操作。需要全程對(duì)任務(wù)的執(zhí)行過(guò)程進(jìn)行跟蹤,其次需要把可以復(fù)用的代碼通過(guò)SDK有效管理起來(lái),避免重復(fù)開(kāi)發(fā)。
-
運(yùn)維管理。這塊是整個(gè)DevOps平臺(tái)的后腰,保證系統(tǒng)的正常運(yùn)行,以及出現(xiàn)問(wèn)題后快速恢復(fù)。
提供便于DevOps應(yīng)用開(kāi)發(fā)和運(yùn)維的Web控制臺(tái),旨在通過(guò)頁(yè)面可視化以及頁(yè)面可操作的手段,提升開(kāi)發(fā)和運(yùn)維效率。在過(guò)去,我們講的D/O分離是指開(kāi)發(fā)與系統(tǒng)運(yùn)維的分工。在DevOps時(shí)代,運(yùn)維工具不但面向?qū)I(yè)開(kāi)發(fā)人員,也需要面向業(yè)務(wù)開(kāi)發(fā)人員,讓大家在同一個(gè)控制臺(tái)中發(fā)現(xiàn)問(wèn)題、定位問(wèn)題。在運(yùn)維底層功能方面,我們把流程實(shí)例管理、任務(wù)管理及控制臺(tái)的功能,按不同的角色進(jìn)行開(kāi)放。本著誰(shuí)開(kāi)發(fā),誰(shuí)負(fù)責(zé)的原則,大家一起共同把系統(tǒng)平臺(tái)及業(yè)務(wù)功能模塊的可用性維護(hù)起來(lái)。
5、認(rèn)證管理 – 建立崗前認(rèn)證培訓(xùn)體系
DevOps是一個(gè)以人為本,回歸人性的一種開(kāi)發(fā)運(yùn)維文化,其效果體現(xiàn)更多的是在于人,在于從業(yè)人員能力的提升,更注重開(kāi)發(fā)人員的感受。所以,在內(nèi)部有一個(gè)DevOps的認(rèn)證體系,經(jīng)過(guò)這個(gè)體系的培訓(xùn),可以讓一個(gè)小白用戶(hù)從零開(kāi)始逐步上手。這個(gè)培訓(xùn)體系主要分為四個(gè)步驟:
-
開(kāi)發(fā)知識(shí)基礎(chǔ)。主要是學(xué)習(xí)開(kāi)發(fā)環(huán)境、代碼管理及代碼檢查一些基礎(chǔ)的知識(shí)。
-
DevOps功能開(kāi)發(fā)。這個(gè)是按照基礎(chǔ)架構(gòu)運(yùn)營(yíng)功能的特點(diǎn)來(lái)展開(kāi)的,主要的內(nèi)容包括需求的提煉匯總,把運(yùn)營(yíng)需求用流程圖的形式展示出來(lái),然后進(jìn)行任務(wù)節(jié)點(diǎn)的邏輯代碼編寫(xiě)。
-
demo實(shí)戰(zhàn)。經(jīng)過(guò)以上兩個(gè)階段的學(xué)習(xí),這里可以開(kāi)始動(dòng)手了。
-
經(jīng)過(guò)一系列培訓(xùn),通過(guò)考試后,對(duì)學(xué)員頒發(fā)證書(shū)。并根據(jù)不同的能力水平,證書(shū)也會(huì)區(qū)分一級(jí)、二級(jí)和三級(jí)。
我們的題目叫“最佳實(shí)踐”,但這個(gè)過(guò)程并不是一帆風(fēng)順的,過(guò)程中經(jīng)歷了非常多的挫折與不理解。我們把這些因?yàn)榭紤]不完善而踩坑的地方總結(jié)了幾個(gè)最差實(shí)踐。
第一方面就是主要功能點(diǎn)缺乏,用戶(hù)使用滿意度不高。
1)嘗試去優(yōu)化某個(gè)具體的環(huán)節(jié),而忽略了全局優(yōu)化的可能
前期缺少頂層設(shè)計(jì),舉個(gè)例子,我們之前一直以為畫(huà)流程圖是用戶(hù)接觸DevOps系統(tǒng)的第一個(gè)界面,是業(yè)務(wù)需求轉(zhuǎn)化的第一步。就千方百計(jì)的把畫(huà)流程圖的界面進(jìn)行優(yōu)化。但用戶(hù)在畫(huà)完圖了后,后面就很少會(huì)關(guān)注了。
2)產(chǎn)品化不夠,用戶(hù)使用不夠友好
一個(gè)功能完備的DevOps平臺(tái)就跟建設(shè)一座城市或一個(gè)小區(qū)一樣,有太多的功能點(diǎn)需求開(kāi)發(fā)。SDK的合入規(guī)則,云函數(shù)的調(diào)用方式等等。這些專(zhuān)業(yè)的開(kāi)發(fā)技能,對(duì)于傳統(tǒng)的開(kāi)發(fā)同學(xué)來(lái)說(shuō),大家交流起來(lái)是很順暢的。但對(duì)于運(yùn)營(yíng)同學(xué),要跟大家解釋就顯得比較費(fèi)勁。
3)研發(fā)效能低下
本地開(kāi)發(fā)環(huán)境無(wú)法與線上環(huán)境保持一致,調(diào)試?yán)щy。還有業(yè)務(wù)代碼邏輯的經(jīng)常需要線上調(diào)試,測(cè)試的覆蓋率長(zhǎng)期偏低,功能穩(wěn)定性無(wú)法保證。還有bug定位跟蹤的方式比較單一,一個(gè)bug需要分析半天才能知道問(wèn)題點(diǎn)在哪里。
第二方面是過(guò)度設(shè)計(jì),沒(méi)有使用戶(hù)真正獲益。對(duì)于Devops的深入程度,有一點(diǎn)我們必須牢記,那就是DevOps平臺(tái)系統(tǒng)本身的成功并不是真正的成功,只能是業(yè)務(wù)的效率提升,使用DevOps的用戶(hù)滿意度提升了,才是檢驗(yàn)成功的唯一標(biāo)準(zhǔn)。
網(wǎng)絡(luò)運(yùn)營(yíng)DevOps系統(tǒng)的后續(xù)發(fā)展 - 打造生態(tài)
羅馬不是一天建成的,這個(gè)DevOps平臺(tái)凝聚了騰訊基礎(chǔ)架構(gòu)運(yùn)營(yíng)多年的經(jīng)驗(yàn)。之前我們談的自動(dòng)化及數(shù)據(jù)化運(yùn)營(yíng),更多是端到端的傳統(tǒng)開(kāi)發(fā)方式。具體到DevOps,我們希望可以打造一個(gè)生態(tài),可以跟眾多的合作伙伴和外部的用戶(hù)一起,一起在同一個(gè)平臺(tái)上進(jìn)行功能完善和迭代。
在接口對(duì)接方面,近期我們跟很多運(yùn)營(yíng)商及設(shè)備廠商一起努力,把報(bào)障、割接、還有case管理、備件管理等幾個(gè)使用頻率最高的場(chǎng)景進(jìn)行了線上對(duì)接。在外部用戶(hù)方面,我們通過(guò)騰訊云的窗口,把DevOps的能力對(duì)外進(jìn)行的開(kāi)放。使用的用戶(hù)越多,發(fā)現(xiàn)越多的問(wèn)題,DevOps平臺(tái)的功能就可以越趨完善。
文章來(lái)源:鵝廠網(wǎng)事