「基礎架構團隊是否有效率，取決於它處理變更需求的能力。」—— 《基礎架構即程式碼：管理雲端伺服器》

在過往的時代，Infra 與維運團隊經常對「變更」很感冒，可以的話，他們會希望不要經常「變更」。

畢竟那些讓人半夜被叫起床的事故，十之八九都源自於某次「變更」。

也難怪他們會產生少改少錯的想法。

或者是希望「變更」能慢一些，期望能完整的掌握變更細節才願意放行，於是漸漸地增加各式各樣的變更申請流程與審核關卡。

在這樣的狀況下，風險或許會因此下降；（應該吧？）

但可以肯定的是，交付速度必定會隨之犧牲。

服務「穩不穩」，這是一直以來我們評價 Infra 與維運團隊的慣用指標。

但在進入 DevOps 時代之後，除了「穩」，能不能「快速因應變更需求」，則是這時代團隊無可避免的挑戰。

所以，別再將變更擋在門外，該是時候想辦法讓每一次變更都足夠安全、可控且能輕易重來。

你們公司遇到「變更」時，從請求到完成需要多久時間？那些因故而被拉長的時間，是真的有助於降低風險？還是說只是在拖延風險呢？