每個人都想上DevOps，無奈沒見哪家出什麼成功的方法論。可能他們那些成功實踐了DevOps的人/組織做這種佈道的動力不足，也不知道這樣做是否正確。

眾所周知，市面上雖然有幾百上千家公司為DevOps下定義做先驅，但它對一幫吃瓜群眾來說仍是一個難題。雖然每個人都想上DevOps，但絕大多數人並不得其真意，不知道重要性和需求。偏偏這玩意兒曲解起來又會造成很多問題，甚至嚴重影響業務運營。就目前的行業態勢，我們來聊聊DevOps失敗的背後原因。

一、DevOps沒有明確的成功定義

大多陣列織不知道他們什麼時候該做，也不知道DevOps該應用的方向。這樣的話，你怎麼知道你是不是“完成了這歷史性的壯觀一步”？還有，你產出的單位時間是多久，每天？每週？還是每個世紀？

二、坑爹無底線的零碎工具

目前大部分可用的DevOps工具都是基於“碎片點”的孤立解決方案，只能協助你在DevOps工作流的特定階段搞定特定任務。記住，扳手永遠替代不了氣筒。

三、不得不用不方便的方法

DevOps的需求方向往往又會呈點狀分佈，並不是整個組織的整體處理。

當你剛開始轉型DevOps時，萬事開頭難；理清頭緒，開始DevOps之旅後，問題又來了：如何開始？到哪結束？以及到哪個度才算完成。。。然後，踩坑無數。。。有可能最終以錯誤方式，甚至危及原本可能還算穩定的業務流程。

因此，一個方便手冊的是多麼重要啊！裡面儘管可以描述那些各種端到端的實現手法，你們要是不小心發現了，務必也告訴我啊！

看過Shippable最近的“ DevOps Playbook”，簡要描述下這個DevOps手冊的內容（我沒整套按它說的流程實踐過，有興趣的童鞋可以試試，成了記得吱一聲）：

• 一些定量的方法依據：是不是用DevOps的理念完成了所有手頭工作？整個IT運營的流程呢？這塊也叫DevOps Reality Score；
• 衡量DevOps Automation的標準，即可以連線各種可用工具的平臺，分別不衝突的提供標準方式保持各自工具平臺的“原有標準”和總體可見性的端到端管道。（很認證的說句實話，這點我也不是很懂）

四、DevOps現實得分的評判標準

理想狀態是，你在整個組織的所有應用中實現了零觸控的自動化……這就是Full DevOps的成熟度，當然前提是你真正以應用的視角看待整件事。

上圖的示例矩陣中，DevOps成熟度為3/8，即37.5％。通過這個簡單的矩陣可以大概估計出交付流程的哪些部分完成了自動化任務，看著目標也能知道距離零觸控自動化還有多少差距。

我感覺這個矩陣確實比較好的量化了技術的成熟水平，最主要這個矩陣對數學要求還不高。為組織中的所有應用流提供了一個可參考的現實得分，並指明瞭接下來的努力方向。

文章來自微信公眾號：DevOps研究院