CSDN研發頻道推出了2014年DevOps實踐調查活動，據活動報告顯示：有60%的用戶表示只知道DevOps概念，但尚未使用;有37%的開發者聽說過DevOps并且很感興趣正準備使用;能夠熟練使用的用戶只占到19%。
根據CSDN的數據可以很明顯發現DevOps依舊是一個很新鮮的概念，也勢必在先進的開發—運維工具推動下變成當前軟件開發的潮流，然而如何實施DevOps依舊困惑著企業管理者們。眾所周知，推進DevOps應從文化、流程和工具三部分來實施DevOps，但是具體如何實施卻一頭霧水。突然變革是不可能的，只會使開發人員和運維人員都無法適應新環境，從而怨聲載道。DevOps的理念要求開發人員和運維人員在傳統思維上改變的同時，也在技術上互相了解彼此的工作方式。那么，從文化和技術上交替改變或許能讓開發人員和運維人員更能欣然接受這種新的工作方式。
實施DevOps首先該做的事是在組織內對架構和應用層啟用指標監控。當開發人員添加或修改代碼以滿足客戶新的需求時，只會關注代碼改變后的直接結果——是否實現了某個功能。但是運維人員會在系統運行中獲得內存利用率、CPU利用率等參數，以此來分析代碼改變對系統運行的真實影響,這種場景卻是屢見不鮮的，可以通過在Graphite中監控系統指標，并提供開發人員相關的API來解決。運維人員搭建一個監控系統，同時調用Statsd和Graphite的接口，開發人員在系統中增加幾行代碼，以此來獲得CPU利用率、內存利用率等信息的圖像表示，從而實時監控代碼改變后對系統的真實影響。
在完成指標監控后，然后應對基礎架構實施文檔化。根據DevOps的思想，開發人員應該更加了解運維系統人員的工作方式，加深對系統架構的認知。通過基本的高階流程圖來繪制請求流程，從而反映軟件對請求的處理情況。同時，記錄系統架構中每個模塊的具體作用及優勢，并記錄新服務器的上線過程、潛在故障和解決方案。通過這些記錄來提高開發人員對系統架構的認知程度。
指標監控和架構文檔化實現了開發人員對系統運行情況和系統架構的了解，并實現了開發和運維在監控和文檔上的溝通、協作。接下來就要解決系統內部機制的問題。開發環境和生產環境問題一直是系統穩定性的主要原因，通過引入Vagrant工具，來封裝一個Linux開發環境，分發給團隊成員，成員可以在自己喜歡的桌面系統(Mac/Windows/Linux)上開發程序，代碼卻能統一在封裝好的環境里運行。由于Vagrant使用VirtualBox虛擬化系統，通過使用Chef創建自動化虛擬環境。這樣就很容易解決開發環境與生產環境不盡相同的問題，并解決了開發人員和運維人員手動配置腳本和文件所產生的一些BUG。
在完成這些工具和流程的改變后就需要企業進行思維的改變了，緩慢而有效的進行DevOps的文化改變。共同的辦公地點和辦公時間不失為一種行之有效的方法，降低開發—運維的敵意，增進彼此的團隊精神，認知到彼此都只是軟件開發生命周期中的一部分。
在完成這些思維和工具的改變后就要進行最后的改變——Pull請求、代碼復審和持續集成。當開發人員需要滿足新的需求時，在Vagrant中配置好的虛擬機上進行變更，并更新發布一個Pull請求，提交到運維人員手中進行審查與完備性測試，從而反饋結果，通過則Pull請求被合并，存在問題就可以直接刪除Vagrant中的虛擬機以重新開發需求。同時，通過類似Jenkins的持續集成服務器去驗證運維人員用于創建容器環境的腳本是否正確，或者冒煙測試等方式。
當企業完成這些部署后，就可以充分享受DevOps帶來的快捷開發的益處了。開發與運維的更多交流與協助，使得產品能夠更高頻率的部署交付，減少了因進行大規模升級變更的停機時間。開發對系統代碼更加負責，運維對系統穩定的管理也變得更加輕松。
