這是我目前的模型，也是很長一段時間我跟許多客戶和同事分享過的一個模型：
第一階段：“按部就班的完成一切”——每次都按照列表逐步完成。或部署、或測試、或其他隨便什麼，只要歸屬於日常工作，都按表單逐步完成。在這個層次中，效能並沒有太大優化，一切任務都完成地非常機械。
第二階段：“必要工作遵循手冊”——經過一段時間以後，我們發現：如果在任務執行前先做一個快速的影響評估，並且按照評估結果只完成那些必需的步驟，那麼有很多步驟就可以直接跳過了（像是：不重新部署未更改的元件，或者不測試那些未更改的功能）。然而我們身處的這個時代，經過評估的每個部署看起來都不一樣——如果資源流動太快，或者人員頻繁更替，總是使用缺乏完成可靠評估所需技能和知識的新手，那麼在這一階段中，實際執行起來也會相當困難。
第三階段：“自動化”——接著我們發現了自動化。但是，評估影響的自動化比通用步驟的自動化要複雜得多，因此每次我們都需要返回最初，重新執行所有的步驟。這樣做減少了部署的工作量，但有可能會影響實際執行的持續時間。
第四階段：“效能優化”——一旦掌握了自動化，我們開始尋求相應的優化方案。我們發現了這樣的策略：只確認每個活動所必需的步驟，建立並執行動態的自動化指令碼。這樣一來我們減少了工作量，同時也不斷降低著總花費時間。在執行的自動化方法切實可靠的基礎上，我們使得整體結構逐步優化。
到這裡我的故事通常就結束了，而且我會告訴你這是一個優化的最終狀態，不會真正地再誤入歧途。不過我認為，基於雲的DevOps會更進一步，這使得我必須更新模型來適應：
在這個新模型中，我們需要再次執行之前的所有步驟。讓我來解釋一下：在自動化部署的情況下，不僅需要將所需的增量變化新增到環境中，而且需要完全例項化環境（以程式碼作為基礎架構）。在自動化測試的情況下，則需要建立多個並行環境，同時執行多個測試以節省時間，取代在評估影響的基礎上建立多個測試子集的測試形式。我們現在可以負擔起這樣奢侈的執行方式，因為我們在模型中遇到了新的壁壘，我稱之為雲壁壘。
誠實點來講，我早就該做這個更新了，這也顯示了這樣的道理：如果很長一段時間你都使用同一個模型工作的話，就無法在它過時的時候意識到這一點，而只會一直嘗試讓它符合現實情況。希望更新後的模型也能幫你明確你的企業規劃。通往DevOps成熟的道路雖然曲折，卻是有捷徑可尋的，但就如攀登險峰時一般，捷徑往往會更險峻，耗費更多的體力。期待在“峰頂”與你相見！
評論(1)