在IT界，特別是在數(shù)據(jù)中心架構、建設和維護工作中，我們能夠從構建新事物以及看著它們成功運作中獲得滿足感。在數(shù)據(jù)中心的所有領域都是如此，從網絡到存儲，我們喜歡構建事物。

在我們構建了事物后，我們會開始優(yōu)化它。在這里做些調整，那里做些更新，并監(jiān)控一切以確保其正常運行。在大多數(shù)情況下，這最終會涉及到一定程度的自動化，而這正是工具箱腳本和開發(fā)發(fā)揮作用的地方。

理想情況下，我們應該盡可能多地對代碼進行錯誤檢查，但很多時候，開發(fā)人員并不會進行真正的錯誤檢查，這可能帶來巨大的災難。

我們看一個真實的例子。我們有一個虛擬服務器模版(用于進行自動服務擴展)，當web應用程序的負載增加時，該模版會用來增建web服務器。這是簡單的事情—我們只需要能夠按一個按鈕(或者自動執(zhí)行它)。

假設我們已經部署了程序來調整負載均衡器，以及添加新的web服務器，我們真正要關注的是確保這些服務器上的應用程序堆棧的穩(wěn)定性和正常運行。我們編寫了一些代碼，并將其放入到init腳本，讓每臺web服務器可以下載某些需要的變量因素，以便可以正常運行。這又是簡單的事情。我們可以自動化anrsync或者scp進程。我們可以非?？焖俜奖愕販y試這個代碼。

但是，如果我們沒有對該代碼進行足夠的錯誤檢查，我們可能會發(fā)現(xiàn)，在半年內，整個應用程序開始間歇性崩潰。也許文件名更改了，或者服務器被替換，或者某人更改了authorized_keys文件。這些都是看蘇無害的變化，當這些web服務器啟動時，它們將無法訪問它們需要的東西，從而無法正常運行。

在這種情況下應該會發(fā)生這樣的事情：服務器通過SNMP或者電子郵件顯示錯誤，并不會打開web服務。這個問題將會顯而易見，也許一些調試就可以解決。然而，如果服務器繼續(xù)打開所有服務，并加入到負載均衡組，它可能無法正常工作。

根據(jù)所遇到的實際問題，這可能意味著新服務器上的所有服務都崩潰了，可能讓服務、內容和應用程序監(jiān)控框架無法檢測到攻擊。服務器可能看起來沒問題，但實際并不是這樣。

如果這種影響相對較小，可能更加令人不安，這意味著通過該模版生成的新服務器啟動時，又會出現(xiàn)錯誤報告，或者只會有小部分用戶受影響，因為已經運行的服務器沒有相同的問題。這些問題很難發(fā)現(xiàn)。啟動十幾臺服務器、發(fā)現(xiàn)一個錯誤、發(fā)送警報，然后破壞應用程序。與損壞的可能破壞數(shù)據(jù)庫的快速應用程序相比，容量較低而減緩運行的應用程序更可接受。

這個問題的關鍵是，看似微小的自動化工作可能能夠完美地工作很長的時間，但最終還是會帶來破壞。自動駕駛儀是偉大的發(fā)明，但我們還是希望由人來駕駛汽車，以確保事情的正常運行。對于簡單的自動化任務，我們應該盡可能多地進行錯誤檢查，因為這和自動化本身一樣重要。

一些自動化腳本是25%的函數(shù)代碼，以及75%的錯誤檢查和故障處理。當自動化腳本出現(xiàn)問題時，我們應該將調試信息輸出到STDOUT。當與cronjobs或啟動腳本中的mail-E結合使用時，調試到STDOUT能夠帶來簡單的通知步驟。

自動化確實能夠帶來很大的滿足感。我們能夠構建一個機智的框架來簡化一些工作，然后看著其運作。但就像樂高車一樣，如果我們不重視，它最終將會碰壁。最好一開始就做好規(guī)劃。

更多資訊請關注電力設備頻道