iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 28
1
自我挑戰組

再戰軟體工程系列 第 27

『我覺得自己來比較保險,我超有經驗』 -- 自動化部署的謬誤

自從這幾年DevOps不知怎地流行起來後,關於自動化部署這件事情,討論度一下子變得很高。贊成跟反對的聲音都有,不過,有些反對的聲音,聽起來很合理,好像沒什麼能反駁的,但是事實上都有其問題存在。我認為,世界上的經驗有千千百百種,但是邏輯只有一種。抓住邏輯,就能做出萬種應變。以下我們只簡單列出幾項常見的論述,並推敲一下其邏輯上的謬誤:

自動化部署不完全,做不了全套。

有人認為,自己寫的自動化部署腳本,無法達成所有我們在部署過程中需要執行的步驟。譬如,我自動化地上傳了binary,如jar檔,但是用戶狀態我還是得手動更新;或是我自動化地關閉與開啟了服務,但是簡訊通知客戶,我還是得電話或line通知客服等。

事實上,這樣的想法,等於是把自動化部署,侷限在了單一工具的使用,或是單一任務的執行。其實,技術上,只要是人能靠打指令做到的事,機器都可以幫忙做。譬如,上述的例子,就可以透過maven、ssh、SQLPlus、Line Robot API的協動來完成,並且利用ansible來控制這些工具在本地及遠端伺服器的動作。

所以不是自動化部署做不了整套,而是你的腳本還沒做到整套。

臨時狀況時,機器會做錯事。

如果我把部署動作拆解成: 1) 停止服務, 2) 上傳jar檔, 3) 更新設定檔與靜態資源, 與 4) 重啟服務。
很多人會擔心,設計一套固定腳本,萬一上傳jar檔卡住了,或是靜態資源沒更新完就終止,接著服務就傻傻地被開啟,那用戶不就會使用到錯誤的參數,得到錯誤的結果了嗎?那我還不如手動一步一步做,雖然慢了一點,但是我可以每做一步就停下來檢查,不是更安全?

非也,非也。

我同意『每做一步就停下來檢查』這件事,這件事在確保正確性方面,實屬有益無害。然而,人能做的檢查,機器就不能做嗎?真的不能嗎?我們舉個例子:我今天要修改服務設定檔,要把某個服務的port從3333改成7777,於是我必須要在開啟服務之前,檢查每台伺服器的該檔案的該值是否已被更新成7777,一但有任何一台有誤,我就馬上停下來修正,直到所有檢查都完成了才開啟服務。

如果你只有2台server,那妳可以一台一台ssh進去看,萬一你的伺服器有5台,或是10台,甚至20台呢?首先,ssh去檢查這件事,都不用靠任何先進工具,光靠一個shell script就能做到,更何況現在已經有諸多工具,能夠平行地上傳並檢查md5或是檔案內容,一旦有錯還能自動回朔到上一版本,而這版本也是自動記錄的,不用另外手抄。你說,到底是手動安全還是自動安全?邏輯搞通了沒?還沒?我們再看看這個:

環境變化快時,腳本不易維護

環境變化快時,需求也變得快。腳本會比較不易維護,這倒是真的。但是這個『不易維護』的現象,在邏輯上,到底是相對於誰而言?是比需求變化慢時不易維護呢,還是比手動佈署還不易維護呢?

沒有正確的對比目標,這樣的立論是不科學的。

但是,修改腳本只要存檔後,第二次的執行步驟就不會錯,除非你再因應需求再更改。反觀改變習慣呢?人的習慣一旦養成了,就很難很快改過來。再有經驗的工程師,都難逃習慣的影響。也許,他出錯率比別人低一些,但是,在環境變化快速時,你認為長久以來的習慣會不會造成若干程度的影響?

腳本不易維護是沒錯,但是養成習慣的潛意識動作難道就比較容易維護?你認為呢?


我們這麼說吧:

你的同業檢查100台機器的30個設定檔只要30秒,你需要幾秒?
你的同業上傳100台機器的jar檔只要30秒,你需要幾秒?
你的同業買了新機器並做完基礎設定後,佈署成特定版本的特定服務只要3分鐘,你需要幾分鐘?
你的同業在線上發生重大缺失時,把100台server上的服務都退回前一版本只要5分鐘,你需要幾分鐘?

回應前面說的,世界上的經驗有千千百百種,但是邏輯只有一種。找出經驗中正確的邏輯,套用在未來的事件,變成更好的經驗;找出經驗中錯誤的邏輯,加以修正,避免未來類似事件中重複同樣的錯誤,才是我們學習科學的實用之處。


上一篇
『我覺得這樣已經很方便了』 -- 測試要做到多自動化才夠?
下一篇
『珍惜生命,遠離波動拳』 -- 從壞習慣談程式可讀性
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言