如今，數據中心越來越趨于自動化，并已成為數據中心精采運營的強大力大舉量。以下列出在數據中心監控自動化中常常呈現的兩個主要問題。

問題1：房間里的大象

“房間里的大象”是指人們私密糊口和民眾糊口中對付某些顯而易見的事實，集團保持沉默沉靜的社會現象。人們在進一步深入自動化之前，無論是自動發明，陳訴交付或警報觸發操縱，必需做出一個要害點：在某些方面，它被稱為DPR周期。DPR代表檢測，防范和響應。

警報是事戀人員在產生錯誤時捕捉錯誤的方法，可是由數據中苦衷戀人員來抉擇它們產生的原因，并找到一種防備錯誤再次產生的要領。當構建一個辦理方案以自動響應警報并舉辦修復時，作為認真任的數據中心專業人員，還應該致力于闡明環境的費力事情，以找到模式和基礎原因。然后需要辦理基礎原因，并建設查抄，以便知道是否再次呈現問題。

對警報的自動響應保持企業的業務在所有的時間運行，并輔佐確保知道你需要的時間，事戀人員必需可以或許看到產生了什么，做的事情出來為什么會產生，所以可以防備它在未來產生。這樣才不會呈現“房間里的大象”問題。

問題2：心田驚駭

許大都據中心專業人員在第一次提出自動響應警報的想法時感想擔憂。而具有一個真正有活力的大腦的人會對這些警報舉辦仔細思考，然后審慎采納動作。這種想法就像站在“自動化”海洋的邊沿。有點令人望而生畏。但你必需相信不會被海水淹死，而且有本領一步步地實驗。這并不是一個全有或全無的命題，其風險也將會從零到全部。

與任何IT事情一樣，有實施打算有時比實施（或在這種環境下是自動化）自己更重要。所以可以再談談這個實施打算：

首先識別測試呆板。無論是為這些目標而陳設的嘗試室設備照舊那些不太重要的志愿者，請配置警報，以便觸發這些呆板。

進修利用反向閾值。固然企業的最終警報將查抄CPU的事情負載量大于90％，事戀人員大概但愿制止重復測試。而CPU的事情負載量小于90％將觸發更多的靠得住性，至少事戀人員但愿如此。

查找復位選項。與上面密切相關，相識數據中心監控東西如何重置警報，以便再次觸發。也許很大概會許多利用誰人成果。

具體環境。數據中苦衷戀人員想要相識產生什么和什么時候大概產生。假如數據中心的東西支持本身的日志記錄，美國抗攻擊服務器 亞洲服務器，請將其打開。在自動化中大量插入“我此刻開始XYZ步調”動靜。固然很乏味，但你會很興奮所做到的工作。

本身處理懲罰警報。假如你認為會通過發送這些警報隨處事器團隊舉辦測試，事實上，你并不會把它發送到任何團隊，而會認為本身可以處理懲罰這些警報。

你真的不需要通過電子郵件觸發那些警報。所有這一切都是在基本設施上造成特另外延遲和壓力，以及假如你的警報同時啟動多個動靜，大概會發生其他問題，會將動靜發送到當地日志文件和顯示屏。

分享警報提醒。此刻，你可以通過對話與小組的其他人分享警報提醒。

回收對話。這個進程將涉及與其他人攀談。配置自動化是協作的，因為你和那些天天都在一起事情的人都應該同意從根基成果到動靜名目標一切。

將相位器配置為滿。一旦自動化在企業的測試系統上事情，打算通過度階段的要領實施。利用溝通的機制，你用來限制幾個警報，你向網絡擴展，也許10-20個系統。而且你再次測試調查功效。然后你擴大到50個閣下。確保你和收件人都很滿足所看到的功效。記著，在這一點上，團隊正在吸收通例警報，但你仍然應該看到之前提到的具體動靜。你應該與團隊舉辦審查，以確保你認為產生的是真正產生的工作。

遵循這些指南，任何自動響應應該有很高的樂成機率，可能至少你會制止陷入糟糕的自動化，不會發生太多的損害。回收自動化的一個很好的履歷法例是用最小的盡力得到最大的回報。無論你此刻看到的是什么基于系統的事件，這大概是你可以得到的最大影響。另一個找到自動化想法的步伐就是凝聽團隊的想法，思量是否有哪些用戶投訴是由系統妨礙驅動的。假如是這樣，它大概是辦理自動化呈現問題的時機。最后，不要打算得太遠。你大概此刻感想擔憂在得到一兩個樂成之后，你會發明團隊正在尋求你的發起，以你的方法得到輔佐。