DevOps「五宗罪」，這樣向DevOps過渡註定會失敗

雲計算提供的速度響應、敏捷性和規模效應，契合了現在不斷變化的數字商業環境。企業基於最新的IT技術，重構IT架構，加速產品創新和服務交付的速度，從而提升運營效率和市場佔有。

不過，企業IT管理者在利用雲計算進行數字化轉型時，每每會面臨兩方面的挑戰：一是技術，一是企業固有的流程、文化和組織架構。許多公司仍然運轉於各個「信息孤島」，陷入依賴「瀑布式」軟件開發的泥潭中，這與技術自己提供的巨大靈活性背道而馳。

在數字化時代，速度和敏捷性是企業領跑和打造核心競爭力的關鍵。DevOps經過打破開發與運維之間的隔閡，大大縮短軟件的開發週期，並快速部署到生產環境，對企業的數字化轉型相當重要。

DevOps就像一座現代軟件開發的聖盃。許多人都在積極尋找，有些人聲稱已經找到，而更多人還在尋找中。
因爲每家公司都有其獨特的運營方式，通往DevOps成功之路上，沒有一步步的標準化指導。可是，能夠確定如下這5種方式是沒法過渡到DevOps的，DevOps不該該作什麼，但願本文可以給企業客戶以啓示。

不肯定DevOps對企業的業務意味着什麼

DevOps並無嚴格的定義，它爲何會出現，採用DevOps能夠解決什麼問題，有多種解釋。從2010年起，DevOps運動的創始人之一斯蒂芬·尼爾森·史密斯（StephenNelson-Smith）就發佈了一篇有關DevOps的很漂亮的帖子。清楚地說明了，開發、運維和QA團隊的全部成員應該就DevOps對他們各自意味着什麼達成共識。回答這些問題有助於：

團隊如何定義DevOps流程？應該在任何流程變化發生以前達成共識，不然會出現沒必要要的緊張情緒。團隊要作的是開展工做，而不是花時間肯定什麼必須作，什麼不應作。

團隊成員願意失去哪些特權?他們願意鑽研哪些任務?若是開發人員不想參與測試和基礎設施維護，Ops工程師不急於開始編寫代碼，QA團隊更喜歡手工測試，而並不是編寫自動化單元測試代碼——這樣的人將沒法在一個健康的、有競爭力的DevOps團隊中脫穎而出。

新成立的DevOps和其餘部門之間會有什麼界限？向DevOps軟件交付方式的轉變不可能在一晚上之間發生，這須要大量的時間和資源投入。在此期間，試點DevOps的團隊應該在所謂「卓越中心」的主要業務工做流程以外獨立開展工做。

沒有遵照DevOps文化
DevOps方法論實際上只有大約25%的比例使用了DevOps工具，諸如Ansible，Kubernetes，Salt，Puppet或Terraform等。75%的客戶，他們的DevOps方法依賴於組織內部的文化變革，正如咱們在另外一篇文章中所描述的，「爲何說DevOps文化是人類的一大步？」。

DevOps的理念很是簡單: 提供持續集成、持續交付和基礎設施即代碼。這意味着DevOps工程師不只要熟練使用多個DevOps工具進行代碼開發、構建、測試和部署;還應該爲代碼交付自動化測試，並維護生產基礎設施，所以，任何有可能出現的問題，均可以由團隊中的任何成員來解決掉。

成功採用DevOps範式的最後一點，是將基礎設施做爲代碼構建，儘管是最後強調的一點，但這並不表明它不重要。當企業基礎設施遷移到私有云或混合雲以後，將有可能實現。當全部基礎設施參數能夠由每位團隊成員經過輕鬆訪問和修改文件進行配置時，就不存在瓶頸和過分的運營成本。這正好對應了「你構建，你運行」的範例，造成了DevOps方法論的核心。

從單一任務和責任到統一的團隊，擁有通用的工具集和技能集，以及共同的思惟方式，對於培養可行和持久的DevOps團隊相當重要。最重要的一點，這不可能做爲一項基層行動而發生，它必須獲得企業裏C-Suite和經理們的全力支持。然而，這點引發了企業內部對治理和安全的關注，應該加以解決。
沒法重組組織結構和治理
向DevOps遷移的緣由之一仍然是，在企業業務中，錯誤的成本過高。這意味着錯誤的決策可能會讓經理們失去他們的位置，這也是爲何他們真正抵制變化的緣由。「若是它行得通的話，爲何要改變它呢?」 然而，在現代快節奏的世界裏，遵循傳統慣例並非頗有效，由於沒有按時交付價值意味着沒有交付價值。

所以，爲了加速軟件開發，儘量多地從交付流水線中去除管理開銷。可是，不須要多個審批並不意味着不須要遵照安全和合規性限制。這僅僅意味着DevOps應該對其行爲的後果負責，而且若是失控，有能力糾正錯誤。

正確的作法是在，DevOps團隊的軟件交付流水線上複製審批功能，同時將最後的消息留給管理人員。經過這種方式，管理人員可讓DevOps在軟件部署和基礎設施更新方面作出決策，同時根據須要，也能夠取消它們。若是缺少這種控制，整個企業的軟件部署和基礎架構的統一結構就可能會變成雜亂無章的混亂。

DevOps工程師只有開發出穩定的和可以檢驗錯誤的工做流程，使全部更新順利進行，DevOps才能夠自行開展工做。任務和職責的這種漸進式過渡，應該發生在整個企業中。這有助於創建一支強大自信的團隊，自主展開工做，同時遵照安全和治理法規。
沒法評估風險
持續交付、自動化測試、持續集成，構建不可變基礎設施即代碼—DevOps這些諸多優點都將會大大縮短上市時間和反饋循環。可是，若是出現差錯，一樣的行爲會致使重大損失。所以，DevOps工程師應該接受培訓，儘量地移除錯誤產生的因素。

這一般意味着自動化測試過程，俗話說:「若是能夠自動化，就必須自動化」。軟件交付最近的階段若是出現錯誤，那麼成本對業務來講是至關高的，這會給 QA 和 DevOps 團隊帶來消極影響和倦怠狀態。

爲了不這種結果，最好在DevOps中投入大量的精力來編寫自動化單元測試，並鍛鍊使用Ansible和Terraform等配置管理工具，掌握Docker技能，實現快速部署測試和環境搭建，發佈滾動更新，並在須要時快速回滾到之前的版本。從而下降風險，並提供穩定、不間斷的服務。
沒法提供可測量的統計數據
任何企業的核心目標都是同樣的：賺取利潤。所以，對企業來講，每個變化首先應該是可行的，並獲得高管們的承認。雖然 DevOps 有助於加快服務和軟件交付流程，但它應該知足某些KPI，從而證實其實施的合理性。

這些 KPI 將根據行業、傳統基礎設施的情況以及其餘因素有所不一樣，但有一點是同樣的：DevOps的採用應該解決問題並證實切實的結果。爲了達到這些結果，管理層應審覈整個企業使用的遺留基礎設施，系統和流程的狀態。從而肯定效率和性能的大體水平，例如，重新特性的發佈到發佈這項功能的天數等。

一旦肯定了上面這些參數，衡量成功就變得至關簡單了。不過，這不是一個月、兩個月就能達成的任務，部署全面的DevOps模型須要一年之久，這取決於企業的規模和重組工做流所需的工做量。密切關注DevOps團隊的表現，並將其與常規團隊進行比較，有助於評估向DevOps過渡的進展和效率。
結論
向DevOps過渡毫不是一時之功就能實現。它須要打好基礎，得到企業整個管理層的支持，投入大量的時間和資源。這一轉型的結果一般會給企業帶來切實的好處，正如Puppet關於DevOps的報告所論述過的。

本文拋磚引玉，若是你有DevOps方面的任何看法，歡迎後臺留言與咱們交流~~