在咱們構建了事物后，咱們會開端優化它。在這里做些調整，那里做些更新，并監控全部以保證其正常運轉。在大多數情況下，這結尾會涉及到必定程度的主動化，而這正是工具箱腳本和開發發揮作用的當地。咱們編寫一些代碼來主動化手動使命，將其放入生產環節，并移動到下一個目標。

抱負情況下，咱們大概盡可以多地對代碼進行過錯查看，但許多時分，開發人員并不會進行真正的過錯查看，這可以帶來無窮的災禍。

咱們看一個實在的比如。咱們有一個虛擬效勞器模版(用于進行主動效勞擴展)，當web應用程序的負載增加時，該模版會用來增建web效勞器。這是簡略的作業—咱們只需求可以按一個按鈕(或許主動履行它)。

假定咱們現已部署了程序來調整負載均衡器，以及增加新的web效勞器，咱們真正要注重的是保證這些效勞器上的應用程序倉庫的穩定性和正常運轉。咱們編寫了一些代碼，并將其放入到init腳本，讓每臺web效勞器可以下載某些需求的變量要素，以便可以正常運轉。這又是簡略的作業。咱們可以主動化anrsync或許scp進程。咱們可以十分疾速方便地測驗這個代碼。

可是，假如咱們沒有對該代碼進行滿足的過錯查看，咱們可以會發現，在半年內，整個應用程序開端間歇性潰散。或許文件名更改了，或許效勞器被更換，或許某人更改了authorized_keys文件。這些都是看蘇無害的變化，當這些web效勞器發動時，它們將無法訪問它們需求的東西，從而無法正常運轉。

在這種情況下大概會發生這樣的作業：效勞器經過SNMP或許電子郵件顯現過錯，并不會翻開web效勞。這個疑問將會清楚明了，或許一些調試就可以處理。但是，假如效勞器持續翻開一切效勞，并加入到負載均衡組，它可以無法正常作業。

依據所遇到的實踐疑問，這可以意味著新效勞器上的一切效勞都潰散了，可以讓效勞、內容和應用程序監控結構無法檢測到進犯。效勞器可以看起來沒疑問，但實踐并不是這樣。

假如這種影響相對較小，可以愈加令人不安，這意味著經過該模版生成的新效勞器發動時，又會呈現過錯報告，或許只會有小部分用戶受影響，由于現已運轉的效勞器沒有相同的疑問。這些疑問很難發現。筆者更情愿看到這樣的情況：發動十幾臺效勞器、發現一個過錯、發送警報，然后損壞應用程序。與損壞的可以損壞數據庫的疾速應用程序相比，容量較低而減緩運轉的應用程序更可承受。

這個疑問的關鍵是，看似細小的主動化作業可以可以完美地作業很長的時刻，但結尾仍是會帶來損壞。主動駕馭儀是巨大的創造，但咱們仍是期望由人來駕馭轎車，以保證作業的正常運轉。對于簡略的主動化使命，咱們大概盡可以多地進行過錯查看，由于這和主動化本身相同重要。

主動化的確可以帶來很大的滿足感。咱們可以構建一個機敏的結構來簡化一些作業，然后看著其運作。但就像樂高車相同，假如咱們不注重，它結尾將會受阻。最佳一開端就做好計劃文章來源：http://www.28ut.com