理解問題架構給持續交付帶來的難題，一種方式就是舉個反例。 讓我們假設有一個大的web應用程序，它有許多不同的功能。

中培偉業專家龔老師在這里做了比喻，他指出，在這個應用里有一個靜態網站。整個web應用部署成一個單獨的Java企業版應用程序。所以，如果只是想改正一個靜態網站的拼寫錯誤，我們就需要重新構建整個網絡應用，然后重新部署。

雖然這個例子看上去很蠢，有見識的讀者都不會這么干，但是我還真看到過這樣的反模式。作為DevOps工程師，這可能是我們要解決的真實場景。

讓我們把上面這團亂麻分解一下。在想要改正拼寫錯誤的時候發生了什么？讓我們來看一看：

1．雖然知道拼寫錯誤是哪一個，但是我們需要修改哪一個代碼庫呢？因為這是一個單塊系統，我們需要在代碼庫的版本控制系統里創建一個分支。這個新分支與生產環境的代碼相符。

2．新建分支并改正拼寫錯誤。

3．用修改后的代碼構建一個新的工件。賦給它一個新版本號。

4．將這個新工件部署到生產環境。

好了，乍一看并不是太壞。但是考慮一下：

變更是在整個業務系統上做的。如果我們在部署新版本的時候出了什么錯，其間的每分鐘都會遭受損失。我們真的那么肯定這個變更不會影響其他部分？

事實上并不只是改正了拼寫錯誤。我們還在生成新成品的時候改變了版本號。但是改變版本號應該是安全的，對吧？你確定嗎？

這里的關鍵是我們已經在確認變更是否安全這件事上費了相當大的精力。系統太復雜了，即使考慮微不足道的變更所帶來的影響也變得相當困難。

現實中，一個變更通常要比改正拼寫錯誤要復雜得多。所以，我們需要為所有變更考慮部署鏈上包括人工校驗在內的所有方面。

這樣一來我們就到了一個不該去的地方。

架構經驗法則有一些架構法則可以幫助我們處理上文描述的惡劣情形。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業