成功的數字化轉型需要來自內部的破壞，想要擁抱數字化未來的首席信息官們必須經常改變他們的IT運行模式才能實現這一點。沒有什么比開發軟件和服務更為明顯的了。

為了更快地構建軟件，首席信息官們開始放棄舊的瀑布式的習慣，轉而采用敏捷方法，同業務利益相關方合作，用迭代沖刺的模式更快地構建應用程序。而有一些人則相信通過采用一種名為DevOps的新興哲學，他們甚至可以進一步加速軟件開發工作。

DevOps是“開發”和“運營”的混搭，描述了實現敏捷開發和可擴展運營所需的組織結構、實踐和文化。DevOps使軟件組裝自動化，利用持續集成、開發和部署，改善客戶體驗，更快地響應業務需求，并確保創新與安全和運營需求相平衡。你可以將DevOps視為使用了類固醇的敏捷開發。

它正在迅速蔓延。Forrester Research的調查顯示，在237個接受調查的機構中，有50%的機構表示他們正在實施DevOps。分析師Robert Stroud在研究報告中寫道：“DevOps的發展勢頭正在蔓延至所有的行業。”他表示，“由于我們即將迎來2017年年底，越來越多的詢問集中在組織能夠如何在壓力下成功地提高應用程序和服務的交付速度上——而且不能增加人手。”

由于組織孤島、文化障礙和變革管理等問題，向DevOps的過渡絕非易事。來自Intuit、大都會人壽(MetLife)和Red Hat的IT高管們介紹了他們在DevOps變革方面的經驗，并為希望擁抱DevOps的首席信息官們提供一些建議。

向DevOps轉變

對于一家擁有4500名開發人員、而且他們都已經習慣了瀑布式工作方式開發應用程序的軟件制造商來說，融合網絡安全和DevOps可不是一件容易的事。但是，對于Intuit的DevSecOps總監Shannon Lietz來說，這是她的首要任務。Lietz表示：“這是一種文化上的轉變。”她表示：“越是接近客戶，開發人員、公司里的其他人的經驗就愈加豐富，你的客戶也是如此。”

Lietz表示：“科學的奉獻精神使DevOps現實可行并取得成功，而我發現試圖將科學引入公司是非常困難的。”她表示， “這是一種完全不同的進行方式。”

對大都會人壽(MetLife)而言，引入DevOps與創新攜手共進。Alex Seidita是這家擁有150年歷史的保險公司的首席技術架構師，Alex表示，在過去幾年里，大都會人壽(MetLife)在開始采用DevOps的同時還采用了來自微軟和IBM的云服務，并使用了來自Docker的容器技術。

大都會人壽(MetLife)的ModSquad是一個由工程師、網絡專業人員和開發人員組成的創新團隊，這個團隊已經接受了云計算、敏捷開發和DevOps，采用了“快速學習、快速失敗、快速交付”的模式。ModSquad的口號是：“你不用等到自己知道了所有的事情之后才開始動手。”

對于容器、微服務和其他工具宗教般的狂熱，讓Mike Kelly 于2016年8月在DevOps的誘惑下加入了Red Hat。曾在McKesson 擔任首席信息官的Kelly厭倦了首席信息官是如何演變成為軟件賣家的過程，因此在離開這個職位之后，加入了這家開放源代碼軟件開發企業。

Kelly表示，企業首席信息官們采購打包軟件以確保流程效率，并管理與這些應用程序相關的變化。但是，首席信息官們的手腳被定制軟件束縛了，這些定制針對的是太過獨特或者難以改變的流程。

在McKesson引入DevOps的Kelly表示：“我總是覺得自己能夠完成這些大項目，會有一些人并不開心。” Kelly表示：“有了這些(DevOps、敏捷開發和文化變革)，我們現在擁有了眾所周知的工具箱中的工具，可以幫助我們解決這些長期以來一直存在的問題。”

實施DevOps的十二個最佳實踐

根據他們在向DevOps過渡過程中的親身實踐經驗，Lietz、Seidita和Kelly提供了以下建議，以保障DevOps的成功。

Ÿ將DevOps戰略與業務結合起來。確保IT和業務戰略的一致性是首席信息官們共同的責任，這一點對于DevOps來說同樣重要，如果IT和業務不能夠保持一致，項目就會失敗。Lietz表示：“如果你不這樣做，那你就只是在創造驚喜”——而且很有可能是不受歡迎的“驚喜”。

Ÿ切入現有的項目。不要將DevOps作為一個獨立地科學項目;相反，把它插入到現有的項目中，這樣它就有責任遵從通常的交付截止日期。Seidita 表示：“選擇一個、兩個或三個項目，你可能會冒一點風險，但時間并不是無限的。”Seidita表示：“你希望人們能夠沖刺，并最終將結果投入生產。”

Ÿ心胸寬廣。要想讓DevOps發揮作用，文化是至關重要的。Seidita表示，要盡可能地包容，這樣你就可以“改變心靈和思想”。Seidita補充表示，非常重要的一點是不要排斥人，因為這可能會造成問題。“你必須心胸寬廣并且非常包容，這樣人們才會覺得他們參與了這段旅程，并為之做出了貢獻。”

Ÿ聚焦讓你獨一無二的東西。在選擇實施項目的時候，要選擇那些能夠增加價值，并讓業務變得與眾不同的項目。Kelly表示：“不要試圖在你的核心ERP系統上實施DevOps。”

Ÿ選擇經過驗證的平臺。工具是DevOps的另一個重要組成部分。從配置管理到持續交付平臺，選擇具有知名網絡的工具。Kelly表示，把賭注押在未知的平臺上會帶來風險。

Ÿ嘗試在內部培養技能。市場上沒有足夠的DevOps人才，因此你應該吸引整個組織內部有經驗的人才。讓他們為項目做出貢獻。Lietz表示：“他們可以給你一個滾動條來看待事情。”她表示，Intuit研究了“無邊界領導”，管理者可以從公司內部抽出自愿參與的團隊成員。更多的時候，他們同意提供幫助，是因為他們知道自己正在從事的工作是業務戰略的一部分。

Ÿ避免“劃分等級”的問題。許多組織都有喜歡冒險的工程師，他們致力于新興技術，也會有一些維護傳統技術(例如ERP系統)的工程師。這些酷酷的冒險者可能會招致怨恨。Kelly表示：“你必須非常認真地同你的同事進行交談，向他們解釋說這并不是非黑即白的問題。”他說，在傳統環境中工作的員工和那些實施DevOps的員工是同等重要的。

Ÿ時間永遠是一個重要因素。不要低估時間的重要性，特別是那些每個季度都要公布財務報告的上市公司。Lietz表示，公司必須致力于為特定的季度創造價值，并讓每個利益相關方都專注于學習開發渠道的一部分。IT和業務利益相關方都應該學習，以確保任務和結果之間的一致。

Ÿ不要看得太遠。鑒于DevOps的高速度，一些組織可能會試圖解決在遙遠的未來才會出現的問題。這可能導致他們錯過迭代創造價值的機會，甚至會導致產品召回，浪費每個人的時間。

Ÿ擁抱故事寫作。把它看成是為客戶創造價值的藍圖。它從一個動詞開始，例如“啟用”一個特定的產品功能，以使其變得更加安全。Lietz表示，如果你無法創建一個故事線來描述你計劃如何滿足你的客戶的需求，你可能就不會打造出最好的產品。

Ÿ避免官僚主義。官僚主義可能會成為DevOps殺手，特別是在那些已經圍繞著接訂單建立了成熟規則的IT組織中更是如此。Lietz表示：“不要相信有一個方法可以做出決定。” Lietz表示：“實驗是關鍵，一旦你在DevOps融入了官僚作風，DevOps就會失敗。”

Ÿ迭代學習。確保員工為踏上這段旅程做好了準備并且犯下一些錯誤。Seidita表示：“不要把它們與嚴格的財務模型聯系起來，那樣的話你就需要在今天告訴我明年你打算花多少錢。”“要一點點來。”