剛剛過去的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，從市場上的情況來看，他們已經走在了前列。