今天不談DevOps和雲原生架構對企業帶來的價值和收益，而是分析下DevOps實踐在企業內部推行困難的原因，這裏的DevOps包含了微服務，中臺，DevOps和容器雲各方面內容。對於DevOps實際上我們可以看到幾個關鍵方面內容，其一是團隊文化的改進，其二是項目管理和敏捷方法論，其三才是技術層面的類似微服務架構，持續集成，容器雲部署方面的改進。

因此要分析DevOps實踐在團隊推行困難的原因還是需要從以上這些方面進行分析。

推動力不足，優化還是變革？

對於DevOps實踐，特別是配合微服務和容器雲的時候，我們可以看到對企業傳統的IT架構是一次具體的變革而不是簡單的架構優化。任何大架構的調整一定有推動力，那麼站在CIO角度推動力在哪裏？

這裏面就存在技術驅動和業務驅動兩個關鍵概念了。技術驅動簡單來來說技術發展趨勢是這樣的，我們要早點變革做長遠打算。一個是業務驅動，即業務發展需要IT變革，否則性能，敏捷性都無法跟上業務發展需要。

現在真正驅動力一定是當前的IT系統本身通過簡單的優化已經無法應對業務需求，這纔是關鍵驅動力。否則當前IT系統本身運轉良好，爲了新技術發展趨勢或遠期規劃而需要大量前期IT預算投入，估計CIO也沒有這個能力申請到足夠的預算。

其次，傳統穩定架構轉變爲新架構一定帶來一定的不穩定期和陣痛期，大部分CIO並不願意承擔風險。

因此沒有明確的業務驅動力，再加上企業IT部門和大部分CIO都很難強勢，這些導致了DevOps推行困難度增加。IT投入預算更多的是先解決業務問題和痛點，其次纔是解決IT本身治理管控問題。

企業內部IT團隊管理和技術基礎薄弱

要明白，任何新的方法論和技術的推行和實踐本身就是一個循序漸進的過程。這和小孩爬都沒有學會就要學跑是一個道理，企業IT也很難進行跳躍式發展，而是必須一步步的逐步演進式發展提升企業IT成熟度。這裏面的薄弱實際上可以總結爲幾個方面

其一是軟件工程和研發管理基礎薄弱，比如企業是否有標準的軟件研發管理，或者實施過類似CMMI軟件過程改進，實施過敏捷項目管理，有最基本的研發管理過程規範和技術標準。如果這些都沒有做過，你會發現進入到DevOps後你的研發過程管理能力跟不上，因爲在敏捷狀態下需要更加可視化，更加高頻和可量化。

其二是研發技術基礎積累薄弱，比如企業原來本身沒有接觸過微服務架構，容器技術等，如果企業要從頭開始學習和實踐這些，那麼就需要一個長週期的學習時間，而且關鍵是自己摸索很大地方還無法徹底做到融會貫通。另外一個技術基礎就是我們常說的持續集成，企業原來是否實施過類似持續集成，如果你原來實施過持續集成，冒煙測試，自動構建，自動化測試等，那麼你會發現過渡到DevOps就相對容易。

團隊文化影響，持續改進的意願

最後一點，個人認爲也是最關鍵一點就是你當前的團隊文化究竟是如何的？團隊文化是一種安於現狀，樂於重複，拒絕變化，喜歡藏着掖着的文化，還是一種開放，透明和擁抱變化的文化。在各種敏捷方法論的推行過程中，我們始終會看到首先就會強調團隊文化，敏捷文化。而敏捷文化就是一種開放，包容，樂於接受變化，可視化，對結果負責的文化。而這些正式推行敏捷方法論和DevOps的基礎。

在推行DevOps後我們可以看到會讓每個團隊成員每天的輸出成果，和輸出質量更加可視化，完全暴露在整個團隊，你自己想藏着掖着都不行。可想而知，對於原來一些本身自律性就差，喜歡耍小聰明和偷懶，對產出質量不重視，責任心不足的團隊成員來說絕對是壞事。

這些人往往更加期望一種傳統的非透明的管理方式，這種方式下他們可以更多的划水或得過且過。

而對於原來就高度自律負責，產出質量高的成員來說往往就更加喜歡這種敏捷和DevOps的方式，這種方式反而是進一步體現和量化對比了他們自己的價值。

在敏捷方法論裏面我強調日事日畢，每天都能夠反饋和總結，就這一點估計很多人就無法做到，也不願意去做到。不是所有的程序員都熱衷於新技術，更多的人還是希望是不太動腦的重複勞動。

預算和成本，投入產出比

最後我再談一點就是推行DevOps的投入產出比的問題，要知道DevOps特別是微服務架構的實踐往往是對原有架構一次大的變革，那麼自然需要投入更多的研發資源，或者還包括外部技術產品和諮詢服務的採購，這些都是需要大量的成本投入。

而這些成本投入在剛開始你往往看不到帶來的具體收益。

舉個簡單的例子的，當前需要開發一個新的業務系統，用傳統的架構方式可能成本在30萬，但是採用微服務架構並實踐DevOps後可能總體成本在100萬。這個多投入成本在短期並沒有價值，真正的價值是在後期運維，在需求變更的快速響應，在後期系統的彈性擴展上。那麼多少人又願意爲了長遠的打算提前做出成倍的投入。