DevOps成熟前的曲折之路

編者按： DevOps和敏捷資深專家Mirco Hering日前在個人博客上分享了自己的團隊建設經驗，如果你正遇到運維等方面的困難，不妨看下Hering是如何一步步科學解決問題的。以下為原文：

這些年來，我發現這樣一種現象：每當團隊發展到DevOps即將成熟時，就會有這樣的趨勢，且稱之為成熟前的曲折之路吧。近來，我曾使用一個前一 段時間設計的DevOps模型，試圖對這個過程進行闡述，然后發現隨著云基礎DevOps的出現，這個模型必須得更新了。所以我覺得應該跟大家分享一下， 也聽聽別人的想法。令人驚訝的是在許多不同的工作環境中，比如在部署自動化、測試自動化還有許多其他情況下，都會出現這樣的模式。在本文中，我會僅僅用部 署自動化方案作為例子，但是請相信：這種模式同樣適用于其他的技術方面。

這是我目前的模型，也是很長一段時間我跟許多客戶和同事分享過的一個模型：

第一階段：“按部就班的完成一切”——每次都按照列表逐步完成。或部署、或測試、或其他隨便什么，只要歸屬于日常工作，都按表單逐步完成。在這個層次中，性能并沒有太大優化，一切任務都完成地非常機械。

第二階段：“必要工作遵循手冊”——經過一段時間以后，我們發現：如果在任務執行前先做一個快速的影響評估，并且按照評估結果只完成那些必需的步 驟，那么有很多步驟就可以直接跳過了（像是：不重新部署未更改的組件，或者不測試那些未更改的功能）。然而我們身處的這個時代，經過評估的每個部署看起來 都不一樣——如果資源流動太快，或者人員頻繁更替，總是使用缺乏完成可靠評估所需技能和知識的新手，那么在這一階段中，實際執行起來也會相當困難。

第三階段：“自動化”——接著我們發現了自動化。但是，評估影響的自動化比通用步驟的自動化要復雜得多，因此每次我們都需要返回最初，重新運行所有的步驟。這樣做減少了部署的工作量，但有可能會影響實際運行的持續時間。

第四階段：“性能優化”——一旦掌握了自動化，我們開始尋求相應的優化方案。我們發現了這樣的策略：只確認每個活動所必需的步驟，建立并執行動態 的自動化腳本。這樣一來我們減少了工作量，同時也不斷降低著總花費時間。在執行的自動化方法切實可靠的基礎上，我們使得整體結構逐步優化。

到這里我的故事通常就結束了，而且我會告訴你這是一個優化的最終狀態，不會真正地再誤入歧途。不過我認為， 基于云的DevOps會更進一步，這使得我必須更新模型來適應：

在這個新模型中，我們需要再次運行之前的所有步驟。讓我來解釋一下：在自動化部署的情況下，不僅需要將所需的增量變化添加到環境中，而且需要完全 實例化環境（以代碼作為基礎架構）。在自動化測試的情況下，則需要創建多個并行環境，同時執行多個測試以節省時間，取代在評估影響的基礎上建立多個測試子 集的測試形式。我們現在可以負擔起這樣奢侈的運行方式，因為我們在模型中遇到了新的壁壘，我稱之為云壁壘。

誠實點來講，我早就該做這個更新了，這也顯示了這樣的道理：如果很長一段時間你都使用同一個模型工作的話，就無法在它過時的時候意識到這一點，而 只會一直嘗試讓它符合現實情況。希望更新后的模型也能幫你明確你的企業規劃。通往DevOps成熟的道路雖然曲折，卻是有捷徑可尋的，但就如攀登險峰時一 般，捷徑往往會更險峻，耗費更多的體力。期待在“峰頂”與你相見！

原文鏈接： The Winding Road to DevOps Maturity （譯者/李貽麗 責編/錢曙光）