DevOps：軟體架構師行動指南1.3 DevOps視角

<b>1.3　devops視角</b>

<b></b>

一個重大的呼籲是縮短新功能推向市場的時間，減少部署過程中發生的錯誤，考慮到我們讨論的問題并且這些問題都存在已久，這種呼籲也就不足為奇了。devops有很多形式，是對現有實踐不同程度的改編，但是各種不同形式都始終貫穿着兩個主題：自動化及開發團隊的職責。

1.3.1　自動化

圖1-1顯示了各種生命周期過程。從建構、測試到執行的步驟在某種程度上都可以實作自動化。我們将在适當的章節中讨論這些步驟中的每一步使用的工具，這裡首先強調自動化的優點。在1.7節中讨論依賴于自動化的一些問題。

工具可以執行這個過程中每一步所需的操作，針對生産環境或者一些外部規格說明檢查操作的有效性，把過程中發生的錯誤通知适當的人，并且保留操作曆史，以用于品質控制、報告和審計等目的。

工具和腳本也可以強制推行組織層面的政策。假設組織有一項政策是，每個變更都要有與之相關的合理理由。那麼在送出變更前，工具或腳本可以要求做變更的人提供理由。當然這個要求也可能被設法規避，但是讓工具要求一個理由，将會增加對這個政策的符合度。

在工具成為一組過程的中心後，就必須對這些工具的使用進行管理。比如說，工具可以從腳本、配置變更或運維的終端調用。如果是複雜的終端指令，即使使用的隻是幾個指令，也建議把指令的使用腳本化。工具可以通過規格說明檔案進行控制，例如chef cookbooks或amazon cloudformation——今後還會有更多。腳本、配置檔案和規格說明檔案必須遵從與應用程式代碼本身一樣的品質控制。腳本和檔案也應該進行版本控制，也應該進行錯誤檢查。這個術語常常稱為“基礎設施即代碼”（infrastructure-as-code）。

1.3.2　開發團隊的職責

自動化将減少錯誤的發生，縮短部署時間。為了進一步縮短部署時間，考慮前面較長的描述的運維人員的職責。如果開發團隊接受devops的職責，即開發團隊傳遞、支援并維護服務，那麼因為所有所需的知識都保留在開發團隊，是以向運維團隊和支援人員轉交知識也就少了。不需要轉移知識也就省掉了部署過程中的大量協作步驟。