在IT界，特別是在數據中心架構、建設和維護工作中，我們能夠從構建新事物以及看著它們成功運作中獲得滿足感。在數據中心的所有領域都是如此，從網絡到存儲，我們喜歡構建事物。
在我們構建了事物后，我們會開始優化它。在這里做些調整，那里做些更新，并監控一切以確保其正常運行。在大多數情況下，這最終會涉及到一定程度的自動化，而這正是工具箱腳本和開發發揮作用的地方。我們編寫一些代碼來自動化手動任務，將其放入生產環節，并移動到下一個目標。
理想情況下，我們應該盡可能多地對代碼進行錯誤檢查，但很多時候，開發人員并不會進行真正的錯誤檢查，這可能帶來巨大的災難。
我們看一個真實的例子。我們有一個虛擬服務器模版(用于進行自動服務擴展)，當web應用程序的負載增加時，該模版會用來增建web服務器。這是簡單的事情—我們只需要能夠按一個按鈕(或者自動執行它)。
假設我們已經部署了程序來調整負載均衡器，以及添加新的web服務器，我們真正要關注的是確保這些服務器上的應用程序堆棧的穩定性和正常運行。我們編寫了一些代碼，并將其放入到init腳本，讓每臺web服務器可以下載某些需要的變量因素，以便可以正常運行。這又是簡單的事情。我們可以自動化anrsync或者scp進程。我們可以非常快速方便地測試這個代碼。
但是，如果我們沒有對該代碼進行足夠的錯誤檢查，我們可能會發現，在半年內，整個應用程序開始間歇性崩潰。也許文件名更改了，或者服務器被替換，或者某人更改了authorized_keys文件。這些都是看蘇無害的變化，當這些web服務器啟動時，它們將無法訪問它們需要的東西，從而無法正常運行。
在這種情況下應該會發生這樣的事情：服務器通過SNMP或者電子郵件顯示錯誤，并不會打開web服務。這個問題將會顯而易見，也許一些調試就可以解決。然而，如果服務器繼續打開所有服務，并加入到負載均衡組，它可能無法正常工作。
根據所遇到的實際問題，這可能意味著新服務器上的所有服務都崩潰了，可能讓服務、內容和應用程序監控框架無法檢測到攻擊。服務器可能看起來沒問題，但實際并不是這樣。
如果這種影響相對較小，可能更加令人不安，這意味著通過該模版生成的新服務器啟動時，又會出現錯誤報告，或者只會有小部分用戶受影響，因為已經運行的服務器沒有相同的問題。這些問題很難發現。筆者更愿意看到這樣的情況：啟動十幾臺服務器、發現一個錯誤、發送警報，然后破壞應用程序。與損壞的可能破壞數據庫的快速應用程序相比，容量較低而減緩運行的應用程序更可接受。
這個問題的關鍵是，看似微小的自動化工作可能能夠完美地工作很長的時間，但最終還是會帶來破壞。自動駕駛儀是偉大的發明，但我們還是希望由人來駕駛汽車，以確保事情的正常運行。對于簡單的自動化任務，我們應該盡可能多地進行錯誤檢查，因為這和自動化本身一樣重要。
筆者的一些自動化腳本是25%的函數代碼，以及75%的錯誤檢查和故障處理。當自動化腳本出現問題時，我們應該將調試信息輸出到STDOUT。當與cronjobs或啟動腳本中的mail-E結合使用時，調試到STDOUT能夠帶來簡單的通知步驟。
自動化確實能夠帶來很大的滿足感。我們能夠構建一個機智的框架來簡化一些工作，然后看著其運作。但就像樂高車一樣，如果我們不重視，它最終將會碰壁。最好一開始就做好規劃。
京公網安備 11010502049343號