《DevOps，關(guān)于一致性(C)、可用性(A)和距離(D)的表達(dá)！》要點(diǎn)：
本文介紹了DevOps，關(guān)于一致性(C)、可用性(A)和距離(D)的表達(dá)！，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

談起DevOps,涉及到的東西太多,有文化,有工具、有架構(gòu)、有組織、有思維、有過(guò)程、有度量等.之前看了一個(gè)DevOps模型,它從持續(xù)交付的過(guò)程來(lái)看,包含源代碼管理,持續(xù)集成、持續(xù)測(cè)試等等,涉及到的點(diǎn)大概有十幾項(xiàng).

最近我們(優(yōu)維)和又拍云一起搞了次小范圍私享會(huì),為了保證效果,我們都是控制了人群的數(shù)量(20人以內(nèi))和質(zhì)量(總監(jiān)級(jí)或者運(yùn)維負(fù)責(zé)人).連續(xù)兩次的分享,效果還不錯(cuò).

在上周六的廣州分享會(huì)上,我們的主題是【運(yùn)維與架構(gòu)之美】.其中談到了DevOps,我極度簡(jiǎn)化了我過(guò)去對(duì)DevOps的理解,總結(jié)成三個(gè)詞語(yǔ)：一致性(Consistency)、可用性(Availablity)和距離(Distance).

說(shuō)到一致性,DevOps表達(dá)的一致性路徑首先是理念的一致性,然后才是技術(shù)的一致性,最后是環(huán)境的一致性.

關(guān)于一致性.DevOps取的是Dev、Test、Ops三個(gè)團(tuán)隊(duì)的交集部分,其實(shí)這里面隱含的意思就是大家的思維、目標(biāo)都需要達(dá)到絕對(duì)的一致.研發(fā)要考慮后續(xù)的可測(cè)試性和可運(yùn)維性,而運(yùn)維也要考慮你的服務(wù)能力和后續(xù)的生產(chǎn)狀態(tài)如何快速回饋到研發(fā)側(cè),從而持續(xù)優(yōu)化.

我記得Martin Fowler有一個(gè)圖很形象的表達(dá)了過(guò)去軟件組織中幾類角色存在的問(wèn)題—單一化思維.研發(fā)之關(guān)注自己的功能實(shí)現(xiàn),對(duì)于非功能性需求,基本上優(yōu)先級(jí)很低或者不考慮；對(duì)于測(cè)試來(lái)說(shuō),我只考慮在Dead Line之前版本測(cè)試完成,找到一定的Bug,完成KPI；對(duì)于運(yùn)維來(lái)說(shuō),只剩下背鍋部署,死扛的結(jié)果了.在DevOps下,不能如此了,要把彼此的思想放到對(duì)方的腦子中.這也是為什么DevOps一直在強(qiáng)調(diào)組織和文化的核心原因了.

從這個(gè)理念的一致性出發(fā),接下來(lái)要解決技術(shù)的一致性問(wèn)題,在涉及到多產(chǎn)品的研發(fā)組織中,該問(wèn)題尤其復(fù)雜.大到架構(gòu)類型的選擇,小到一個(gè)技術(shù)組件的考慮,都需要有一致性的要求,始終緊扣對(duì)業(yè)務(wù)的高質(zhì)量支撐.有了技術(shù)的一致性要求,就避免了技術(shù)的失控.

接下來(lái)解決一個(gè)交付過(guò)程中,一直沒(méi)有有效解決的問(wèn)題.只要做過(guò)手工部署的人都知道,在測(cè)試環(huán)境明明是好的,怎么到生產(chǎn)環(huán)境就出問(wèn)題了?有人說(shuō)這是環(huán)境不一致導(dǎo)致的,為什么不一致?是因?yàn)槲覀円恢笔止げ渴饘?dǎo)致,并且還是不同團(tuán)隊(duì)部署的,難免會(huì)產(chǎn)生不一致.

的確如此,所以我們實(shí)踐DevOps,實(shí)踐持續(xù)交付,不就是要解決這個(gè)不一致的問(wèn)題么?讓我們看看12factor里面有一條核心準(zhǔn)則：Dev/Prod Parity,Keep development, staging, and production as similar as possible.這條準(zhǔn)則很好的說(shuō)明了環(huán)境之間的一致性的重要性,而問(wèn)題的核心是需要把人工部署變成自動(dòng)化部署的模式.基于應(yīng)用包的交付一定程度上解決應(yīng)用交付的一致性問(wèn)題,如果要徹底解決,此時(shí)需要建立以應(yīng)用為中心的完整資源管理,才能確保交付過(guò)程不會(huì)有遺漏.這始終還不是有效解決方案,終極方案應(yīng)運(yùn)而生—Docker.Docker提出的Immutable(不可變)概念,徹底的解決了這類不一致問(wèn)題,可以確保Dev到達(dá)Prod過(guò)程中,整個(gè)交付過(guò)程是絕對(duì)不可能被變更的.

關(guān)于可用性.DevOps實(shí)現(xiàn)了團(tuán)隊(duì)之間的容錯(cuò)性和高可用,這個(gè)和技術(shù)原理類似.以前總是想著在運(yùn)維內(nèi)部備份,是否可以實(shí)現(xiàn)一些能力在跨團(tuán)隊(duì)之間備份.當(dāng)運(yùn)維需要故障自愈的能力,研發(fā)是否可以考慮從技術(shù)實(shí)現(xiàn)?當(dāng)研發(fā)需要實(shí)時(shí)的了解服務(wù)現(xiàn)狀,運(yùn)維是否可以提供一個(gè)統(tǒng)一看板供研發(fā)了解；其次才是業(yè)務(wù)上的可用性,此時(shí)這個(gè)詞很好理解,但不好理解的是為什么這個(gè)指標(biāo)只是某個(gè)團(tuán)隊(duì)的職責(zé),而其他的IT團(tuán)隊(duì)則可以不關(guān)注?非常的不合理.難道質(zhì)量是能靠運(yùn)維或者測(cè)試出來(lái)的,與研發(fā)無(wú)關(guān)?其實(shí)可用性應(yīng)該是所有團(tuán)隊(duì)共同承擔(dān)的指標(biāo),特別是要和研發(fā)有關(guān),不能只生不養(yǎng).DevOps需要大家一起為它負(fù)責(zé)!

關(guān)于距離.這個(gè)時(shí)候我會(huì)把DevOps思想和精益思想完全做個(gè)映照,精益思想強(qiáng)調(diào)了拉動(dòng)式快速、自動(dòng)化的交付價(jià)值鏈；而關(guān)于IT的DevOps思想其實(shí)何嘗不是在講IT交付價(jià)值鏈?這套價(jià)值鏈的高效運(yùn)轉(zhuǎn)就是持續(xù)交付.通過(guò)持續(xù)交付各種技術(shù)手段：持續(xù)集成、持續(xù)測(cè)試、持續(xù)代碼審查、持續(xù)部署、持續(xù)反饋等等,不斷突破部門(mén)的障礙,打通部門(mén)障礙的同時(shí),也是在拉近內(nèi)部的IT能力到達(dá)用戶的距離,特別是時(shí)間上的距離.IT系統(tǒng)不再是一個(gè)支撐系統(tǒng),而是一個(gè)真正的創(chuàng)造價(jià)值系統(tǒng),價(jià)值在IT鏈條上流動(dòng)(Flow)的快與慢,也是企業(yè)的核心競(jìng)爭(zhēng)力的表現(xiàn).

此時(shí)距離其實(shí)就是效率的表現(xiàn),高效可以表現(xiàn)空間和時(shí)間的縮短,低效則反之.

DevOps的確是一個(gè)很復(fù)雜的體系,有人看到了驅(qū)動(dòng)因素,有些人看到了過(guò)程因素,有些人看到變革因素,有些人看到了業(yè)務(wù)因素…..,太多太多,且把CAD算是我對(duì)DevOps一個(gè)另類的思考吧.

文/老王

文章出處：互聯(lián)網(wǎng)運(yùn)維雜談

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