DevOps轉型的五個誤區
Jez Humble提出了DevOps轉型的五個誤區：
下面我們來詳細分析一下：
誤區一：放棄現有的系統管理員、測試人員，招聘新的DevOps專家不得不說，這絕對是一個糟糕的想法，建議不要這樣做。從經驗來看，招聘新的DevOps專家是一件很困難的事情，我身邊的一些朋友都在尋找這樣的人才，但其實很難找到完美的人選。因爲DevOps工程師或專家不是直接能夠培訓出來的，也沒有一所大學教授DevOps的課程，這些有經驗的人都是在工作中不斷遇到和解決問題的過程中逐漸成長起來的。
所以問題的關鍵在於，如何建立一個組織環境，讓員工可以在工作中學習，他們不會被刻意地限制在各自的角色中，而是被鼓勵在解決問題的過程中不斷學習新技能，併爲整個組織服務。
誤區二：進行大規模組織結構重組（Re-Org）有的組織轉型很乾脆，一上來就進行大規模的組織結構重組。但經驗告訴我們，組織結構重組是非常容易引起混亂的活動，組織通常會消耗數月時間和巨大的能量，員工需要重新熟悉新的組織結構和工作方式，這對組織生產力的打擊是非常大的。
值得注意的是，我們並不是說不需要對組織進行改進。我們都知道，跨職能團隊（比如面向服務或特性）會比按職能切分的團隊具有更高的生產力，所以建立跨職能團隊本身是非常有效的。但這裏觀點是Re-Org並不是唯一的選擇。我們也可以用其他方式達到這個目標，比如讓這些不同角色的人員物理地聚在一起；或者下游職能團隊通過自動化的自服務平臺，把他們的能力賦予給上游的團隊使用（見下圖）。很多讓人敬佩的DevOps組織也沒有完全形成跨職能團隊（如Etsy，Google和GitHub），但他們的生產率同樣非常高。
誤區三：重新編寫你的應用並遷移到雲上DevOps現狀調查報告中也顯示，DevOps適用於各種場景，包括Mainframe主機系統和商業套裝軟件（COTS）。
在我的上一篇文章 DevOps聽起來不錯，但適合你的企業麼 ，我講到了在大型嵌入式軟件、保險公司的大型機系統上進行持續交付的案例。除此之外，在《DevOps Handbook》中也提到在傳統的POS機上，採用藍綠部署進行快速和低風險發佈的例子。
所以，你不用等待漫長的應用重建並遷移到雲上，而是可以在現有系統和組織環境中使用DevOps的思路進行逐步改進，最好的轉型啓動時間點就是現在！
誤區四：購買一攬子DevOps工具DevOps發展到今天，已經出現了非常多的支撐工具。我們認可好的工具可以對DevOps的實施提供出非常強有力的支持，但我們的觀點是：如果僅僅是購買工具，無法真正幫助你解決問題。
Jez Humble與Dave Farley在2005~2006年進行持續交付的工作時，並沒有上圖中展示的如此衆多的工具，很多自動化的工作都是由Bash腳本完成的，但也同樣獲得了非常顯著的效果。問題的關鍵在於你如何解決問題，而不是具體應用哪一款的工具。如果組織僅僅是購買工具而不改變工作流程，這樣不會改變任何事情。
我就曾經見過有人把Jira用成了管控型的傳統項目管理工具，把Jenkins用成了批處理任務的手動觸發器，只有工具而沒有方法和實踐的改變，是無法走上DevOps成功之路的。
誤區五：給開發生產環境的完全訪問權限有人說DevOps就是讓開發自己進行發佈，所以需要給開發所有生產環境的權限。我們認爲這是一種可怕的想法。理想情況下，任何人都不應該有生產環境的權限，所有生產環境的部署應該由人工觸發後，只通過自動化的方式進行。
只有在特殊的場景下，比如需要在生產環境進行診斷時，纔可以允許有人登陸到生產環境。但這種情況下仍然需要特別小心，比如使用一次性的登陸口令，並將任何操作日誌都記錄下來併發送給系統管理員。
總結今天我們從鳥飛派和空氣動力學派的類比說起，DevOps的轉型不能照搬其他組織的實施過程，而是應該深入理解其背後的原理、原則和實踐。
由於篇幅所限，本文重點介紹了DevOps轉型的五個誤區，分別是：放棄現有人員而招聘新的DevOps專家、進行大規模組織結構重組、重新編寫應用並上雲、購買一攬子DevOps工具、給開發生產環境完全訪問權限。
那麼DevOps轉型的正確姿勢應該是怎樣的呢？我將在下一篇文章中，對DevOps轉型的五個關鍵實踐、具體轉型路徑進行詳細闡述，敬請期待！
DevOpsDays大會北京站報名通道：http://event.31huiyi.com/1281765435/index?c=osc
2018年5月5日，與大神Jez Humble面對面暢聊DevOps！