通常業務通常比較關心哪些指標？我們的巡檢是不是也可以換個方式來做，既能服務于業務，也能體現我們工作的深度和廣度，這樣一來，我們提供的就不是一個黑盒服務，而是可以轉變為更加主動的自助服務了，簡而言之，目標就是讓別人看得懂的巡檢。自助巡檢設計的初衷就是基于這樣的情況，如果換一個角度，在做好本職工作的前提下，也讓別人效率提高，我們的服務才更有價值。
業務巡檢應該關注什么？
一般來說，運維巡檢都是系統層面的，偏向于技術方向的，會出來一些很抽象的報告和一大堆的數據。對于業務來說，這種互動很不友好，對于絕大多數人來說，我們看一個偏理本行業內容的報告時，潛意識里是排斥的。而系統巡檢方向的內容是更加底層的，有些信息其實對于業務來說壓根不重要，但是我們的報告反而把這些放在了前面比較醒目的地方，但卻導致的結果就是報告有，但是難以消化。
從另外一個維度上來說，運維中的很多操作都是手工式，腳本化，或者平臺化的，這些操作對于開發人員來說是一種黑盒的操作，技術方向的代溝勢必會使得業務不能理解我們在做的事情，包括巡檢也是如此。對于他們來說，這可能就是巡檢人員份內的事情。其實恰恰不是，我們巡檢后的很多問題，如果開發人員能夠提早了解和介入，在問題的處理流程和改進上效果更佳。
我們在和業務溝通的時候，期望得到體系化的信息，所以在進行溝通調研之前，我們需要了解下應用關注的問題，大體分為這幾類：問題需求、時間周期、結果預測、權重、容易衡量、重要緊急、期望支持效率提高的需求、周期較長，需要迭代優化、重新適配操作方式，周期相對較長、重要不緊急、期望支持更靈活的需求、周期較長，改動難度較大、結果難以量化、不重要不緊急等等。為了避免范圍鋪的太大，難以聚焦，我們需要做一些引導。以下是我們預設的一些問題和業務提出的問題，整理后的結果：
從溝通的情況來看，他們對于很多需求還是很迫切的，但是如果你不去問，可能他們也不知道該找誰，所以在信息的透明性和對等性方面還是存在較大的改進空間。比如對于系統配置和系統性能，我們可以提供相關的API或者數據查詢服務來開放這些數據。有兩個指標是業務格外關注的，一個是數據延遲，一個是連接數情況，這個是和我們預設的情況偏差較大的情況，我們需要引起注意。
在技術細節上，他們也存在一些疑惑，那就是對于一些指標的量化，比如CPU監控指標，我們設定閾值是30%，現在的狀態是20%，業務在查看的時候大多數情況是沒有概念的，如果沒有量化的指標其實也不知道20%是高還是低，而我們如果提供詳盡的文檔這些信息也不能夠充分利用起來，所以我們可以對指標數據通過可視化來銜接，比如我們顯示的CPU監控曲線圖，有一條閾值線（在這里就是30%），通過閾值來作為參考，高還是低，就一目了然了。
巡檢的維度設計
整體可以分成巡檢信息分的三個維度：系統，數據庫和業務。大部分數據是通過數據字典的配置信息得到，而對于業務巡檢來說，更有意義的便是后面三類信息的聚合。通過后面三類信息的提取和聚合，能夠根據設定的數據模型來發現一些潛在的問題。
對于系統巡檢問題，主要是面向運維人員，需要作出響應和明確的處理方法，而對于業務而言，就是一種透明的處理方式，比如業務發現某個服務產生了問題，可以通過系統的配置信息和監控報警來確認是不是服務出現了問題。在這個時候他們可以主動提取這些信息，這就是一個自助服務的初衷。
對于數據庫巡更，對于業務來說就是一種全新的補充，比如對于業務開放了VIP，但是實際業務中可能是一主多從的架構，那么業務就需要了解目前的架構方式，比如一主多從，那么就可以使用多個從庫提供讀寫分離的服務，而不是僅僅告訴一個VIP就完事了。通過數據庫信息的補充，能夠減少業務處理中的更多確認環節，起碼業務提出一個需求就可以明確知道你們理解問題的維度是不是基本平衡。
對于業務能夠接觸到的就是數據庫，表和索引了，但是絕大多數情況下，業務根不知道自己所處的環境是否存在問題，是否配置得當等。在權限允許的情況下，我們可以提供這樣的自助服務來明確告訴業務這樣做是有問題的，這樣做是有風險的。這樣做有幾個好處，一種是由被動變為主動，主動發現問題主動提示，也是一種相對友好的方式，遠比出現問題被動處理要好得多。
如需要了解電子巡更、巡更棒、巡更系統、巡更、巡檢的可繼續關注慧友安的動態，我們會隨時更新，及時上傳客戶的使用反饋體驗，無論是簡單的修改，還是復雜的功能定制，我們都可以快速地為您提供合適的解決方案。我們堅持：“您提要求，我們來做”為服務宗旨。我們已為100多家公司進行OEM、ODM研發生產。
