DevOps 在2018年的五個趨勢

剛剛過去的2017年對於 DevOps 來講是里程碑式的一年，各個行業都開始結合自身的業務特色，在落地 DevOps 這件事情上有了一些規劃、探索。雖然你們對於 DevOps 到底是什麼依然未能徹底達成一致，但每一個企業確實又能找到符合自身能力需求的部分。DevOps 帶有很強的實踐色彩，解決實際問題纔是王道，既然那麼多的 DevOps 工具、流程和方法沒法一次性落地，那麼先解決一部分問題老是好的，這也很符合 DevOps 的實踐精神。

2018年，容器技術和 DevOps 這對好兄弟會聯手上演一場大戲，這是業內你們都認同的趨勢。但具體落地的路徑究竟如何，目前都仍是經驗積累階段。聞道有前後、術業有專攻，在衆多的工具、流程和方法中找到一個解決全部問題的「銀彈」當然是不大可能，但總結一些經驗和教訓，對將來作一些預測總歸是有備無患。

趨勢一 統一的自動化流程

DevOps 最直觀的一個價值就是自動化，自動化構建、自動化測試、自動化部署等等。自動化的價值天然是很清晰的，但目前的自動化仍是各類工具、各類平臺、各類語言獨立在走自動化之路。好比，公司裏的 Java 項目和 Node 項目，因爲其私服都是各自搭建的，倉庫也是各個團隊在維護，天然各個團隊直接都是煙囪式的結構。這種結構的問題在於不少協做變得不可能，好比 Java 項目團隊將倉庫分爲了開發庫、測試庫和發佈庫，制定了一套機制很好地實現了發佈流程自動化的機制，但其餘項目仍是得從新去構建本身的流程和規範。

將來的趨勢確定是一個倉庫包含全部的語言類型，好比 Java、Node、Python 等等開發語言，統一提供高可用、負載均衡和容災備份等問題，那麼這些倉庫都適用同一套自動化規則。DevOps 一個很重要的標準就是可度量，只有在流程統一的狀況下才方便去持續度量，而後發現問題從而持續改進。

趨勢二 基於數據的決策

在規範了自動化的流程後，數據將會變得更有價值，並且隨着時間的推移，歷史數據將能提供更多的智能化決策建議。每個數據點的背後，都帶有一個基準數據做爲參照系，企業能夠根據自身的成熟度模型適當調整，但整體來講，數據再也不只是反映當前的狀態，更多地是實時與歷史數據、基準數據作對比分析，動態提供建議、風險評估和預測。

如上圖所示，在1月23日這段時間，與基準的運行軌跡差異很大，說明計劃外的任務或者 Bug 比較多，那麼意味着工做量評估存在一些問題，多是 Buffer 設置不合理，或者是對人員的能力評估不許確等等。系統在這些異常點給出一些警示及可能的建議，那麼在下一個 Sprint 開始時，對於用戶的設置提出一些風險及建議。

數據變得有溫度，這是數據應用的最佳實踐，但這背後要有不少的數據分析能力的支撐，因此，DevOps 變得智能將是下一代 DevOps 的顯著特色。

固然，數據決策最直觀的方式仍是可視化，在這方面 Capitalone 開源了一款 DevOps 可視化面板 -Hygieia。這款產品是支持高度自定義，且支持多種 DevOps 工具的可視化，如代碼提交頻率，構建狀況及質量狀況等等，從團隊管理者提供快速的決策支持。

趨勢三 加速基礎設施獨立性

容器的興起對 DevOps 有不小的促進做用，這也是將來的趨勢。Mesos 與 Kubernetes 爭雄的時候，不少人認爲 Kubernetes 只是玩具，難以擔當數據中心操做系統的大任。容器編排的意義不只僅在於管理一堆容器，更重要的目的在於將整個數據中心抽象成一臺服務器。好在 Kubernetes 發展迅猛，從應用運行的角度切入，最終贏得了你們的歡心。Mesos 只是作了更長遠的事情，但未能知所前後，致使發展趨緩。

目前還有不少應用是經過腳原本部署的，固然大部分都採用了 Ansible 等工具，但只是提升了時效性，部署者依然須要關注應用運行的基礎設施是什麼樣的。容器及容器編排技術使得徹底能夠不關注底層基礎設施，將一個應用扔到服務器的×××大海里，可能在物理機上運行，也多是虛擬機，多是 CPU，也多是 GPU 的，更加不用關心是什麼樣的操做系統。大有「只在此山中，雲深不知處」的意味。

從最近流行的 Service Mesh 更加佐證了這一觀點，應用和基礎設施的剝離是大勢所趨，只不過是一個按部就班的過程。因此，Devops 和容器技術是互爲因利乘便的關係，容器是將來應用運行的標準形式，DevOps 也將加速這個潮流。但這並不否定傳統非容器應用的價值，但也必定是朝着與基礎設施無關的方向發展。

趨勢四 更豐富的灰度場景

若是前三個方面趨勢成爲現實，那麼應用發佈的速率將會呈指數上升，發佈日將再也不存在，隨時隨地上線，滾動升級將成爲現實，然而大規模、複雜系統的上線靠什麼來保證質量呢？ 最近比較流行的混沌工程多是這方面的一個探索，經過引入一些擾動因素來逐步完善灰度的策略，這個過程就是一個持續學習、持續優化的過程，一樣，歷史數據起着相當重要的做用，大量的算法和機器學習開始登場了。

Netflix 公司的開源項目 Chaosmonkey 已經有這樣的趨勢，經過隨機地關停虛擬機或者容器去看系統如何作出反應。目前來看，Kubernetes 的應用遷移、彈性擴容、副本集等特性具備很大優點。但單純從應用層面處理確定不夠，還有一個很重要的層面須要關注，那就是應用的模板-鏡像(或者二進制包)，將來的複雜場景確定是多地域的，那麼數據中心之間的快速自動分發，倉庫高可用、容災備份等也是確保整個灰度系統正常運轉的關鍵要素。

趨勢五 須要更多企業級特性

正如第四點所述，更復雜的灰度場景，須要更多底層的支持。目前一時間還難以實現應用所有容器化，但多種語言、倉庫的高可用、容災和分發是必須知足的場景。既然應用能夠在多個數據中心任意遷移，那麼應用的"母體"也必須能夠同步遷移，不然混沌工程必然發生混亂。

從目前的工具來看，不多能夠達到這種要求，JFrog Artifactory 具備這種全球分發的案例，在2017年 AWS 技術峯會上，HERE Technology 分享了他們的案例，經過這種方式支撐了百萬級別工件量級的分發，天天在系統裏流轉的數據超過 10TB，從市場上的狀況來看，他們已經走在了前列。