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

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

最近我們(優維)和又拍云一起搞了次小范圍私享會,為了保證效果,我們都是控制了人群的數量(20人以內)和質量(總監級或者運維負責人).連續兩次的分享,效果還不錯.

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

說到一致性,DevOps表達的一致性路徑首先是理念的一致性,然后才是技術的一致性,最后是環境的一致性.

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

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

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

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

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

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

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

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

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

文/老王

文章出處：互聯網運維雜談

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4458.html