談起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一個另類的思考吧。

文/老王

文章出處：網際網路運維雜談