據(jù)自動化英才網(wǎng)了解在IT界，特別是在數(shù)據(jù)中心架構(gòu)、建設(shè)和維護工作中的工作人員都表示，能夠從構(gòu)建新事物以及看著它們成功運作中獲得滿足感。在數(shù)據(jù)中心的所有領(lǐng)域都是如此，從網(wǎng)絡(luò)到存儲，大家喜歡構(gòu)建事物。

事物構(gòu)建完成之后，我們會開始優(yōu)化它，并監(jiān)控一切以確保其正常運行。在大多數(shù)情況下，這最終會涉及到一定程度的自動化，而這正是工具箱腳本和開發(fā)發(fā)揮作用的地方。通過編寫一些代碼來取代手動任務，將其放入生產(chǎn)環(huán)節(jié)，并移動到下一個目標。

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

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

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

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

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

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

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

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

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

 

 

【打印】    【關(guān)閉】

分享到：

qq空間

新浪微博

人人網(wǎng)

豆瓣網(wǎng)

MSN

騰訊微博