企業建立成功 DevOps 模式所需應對的5個挑戰

要給 devops 下個簡明、準确而又恰當的定義真不是件容易的事兒。不過，以前看到過一句話，似乎能較好地解釋什麼是 devops——“devops 是一種文化、運動或者實踐，它強調軟體開發人員和其他 it 專業技術人員之間的溝通與協作，以共同促進軟體傳遞流程和基礎設施變更的自動化。”

現在，你明白了什麼是 devops，什麼不是 devops，那麼你又要思考，為什麼你的企業應該使用 devops？除了打破兩個分散部門之間獨立的工作模式，你還可以期待怎樣的顯著變化和成果？根據 puppet 最新的《devops 現狀報告》，他們發現“高效能的it組織比低效能的it組織經曆的故障要少 60 倍，故障恢複速度要快 168 倍。而且，他們的部署時間要短 200 倍但部署頻率卻高出 30 倍。”簡單地說就是，成功的 devops 組織能在更短的時間内實作更快的産品釋出頻率，而且出現的問題更少。

要實作更具有協作性的 devops 轉變，在開始前，必須搞清楚公司可能會面臨哪些潛在的挑戰。

這是很多企業試圖在内部實作 devops 時最常遇到的問題之一。在實際過程中，任何高管都不可能直接将一個成功的 devops 模式生搬硬套，一聲令下就開始在整個公司内實施。因為這根本不可能由上而下地推行。

成功的 devops 運動應該由“草根”發起，然後演變成一場全公司的文化變革。最完美的情況是，幾個開發和運維人員湊在一起，共同處理一些小事件，并在合作過程中建立起良好的默契。然後這種新式的團隊氛圍逐漸升溫，自然而然地向雙方部門滲透，最終形成步調一緻的回報流程和工作節奏。

很多大中型企業的員工和辦事處遍布全球。毫無疑問，這給協作帶來了巨大的挑戰。因為無論是語言障礙還是時差問題，又或者隻是因為各部門之間的分散獨立，總之公司越大，就越難形成一個完善的 devops 模式。這就是為什麼使用正确的工具促進協作至關重要（後面再詳細讨論這個問題）。同樣重要的是，開始部署 devops 時，必須選擇正确的項目。

通過使用各種工具，如果你的 devops 團隊一步一個腳印地向前邁進，雖然一路進展緩慢，但是确實取得了實質性的成果，那麼全球的團隊成員就會更加關注這個新的工作模式，并且迫切地想要加入其中。運維和開發團隊通力合作完成的産品，其品質也會更好，而且所有的團隊成員都會為此感到驕傲。尤其是看到了自己的工作成果以後，每個成員将會更有責任感，接下來的工作也會更加努力。

“遺留”，在這裡指的是那些阻礙 devops 運動的政策性和工具性挑戰。首先最重要的是有關團隊氛圍和文化的遺留問題。我們經常聽到管理層說：“我們一直都是這樣做的”。沒錯，這就是筆者為什麼開篇就強調要從公司的技術層而不是管理層推動 devops 運動。因為下面的人既需要也想要向 devops 發展，一旦他們取得了成效，上面也就不會有太多的反對意見。

第二個遺留問題是關于現有的工具。如果你的團隊還在使用一些釋出緩慢且不靈活的古董級工具，那麼你可以借此開始讨論工具的遷移問題。越來越多的企業已經在雲和內建産品上投入了大量的資金和信任。你在決定要購買哪些工具時，一定要考慮它們是否和應用程式的生命周期相比對，以及它們和其他工具是否能共同發揮最大的效用。

我們經常聽到的另一個挑戰是，企業裡很多成功的 devops 團隊很難得到管理層的支援，因為他們的成果難以量化。雖然puppet的調查報告顯示 devops 成績斐然，但是公司的管理層未必這麼認為。作為 devops 團隊的領頭羊，你需要考慮以下幾個問題：

你的團隊多久釋出一次更新？

釋出更新後，獲得了多少支援票？

平均多久釋出一個應用？

每次釋出的應用帶來了怎樣的收益，以及/或者形成了怎樣的品牌影響？

這些問題有助于評定你目前的釋出流程和績效，并發現哪些地方可以實作最大程度的改進。一旦明确了這些問題，你就可以拿着這份最适合公司情況的 kpi 資料去和管理團隊談你的成果。