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

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

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

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

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

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

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

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

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

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