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

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

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

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

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

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

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

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

接下來解決一個交付過程中,一直沒有有效解決的問題.只要做過手工部署的人都知道,在測試環(huán)境明明是好的,怎么到生產(chǎn)環(huán)境就出問題了?有人說這是環(huán)境不一致導(dǎo)致的,為什么不一致?是因為我們一直手工部署導(dǎo)致,并且還是不同團隊部署的,難免會產(chǎn)生不一致.

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

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

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

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

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

文/老王

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

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