DevOps轉型成功之路2 - 轉型的五個誤區

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！