從應用系統的服務品質開始進行監測與管理

為什麼我們希望從服務品質為出發點來監控整個系統?

最簡的的說法是因為服務品質代表著使用者使用你的服務時的真正感受，IT維運旅程的目的地，也是衡量一個企業IT維運品質是否優秀的關鍵指標。傳統做法以可用度為主的監控會遇到一些問題：

見樹不見林 – 忙碌於各種告警，但不知道這次outage影響到哪些服務以及哪些客戶。

過度調用緊急資源 – 在IT許多基礎建設有高可用度的設計下，無法判斷是否嚴重影響客戶，只好事事都列為緊急待處理。

無法幫助將來的規劃 – 換了基礎建設到底有甚麼好處? 該怎麼換? 換甚麼? 最終的評價者(客戶、CxO)能感受到好處嗎?

暫列以上問題就可以看出服務品質的監控是有其必要性，主要是因為：

快速掌握使用者感受，專注在影響客戶的大事

快速定位問題的部位，同時可以產生一個標準的SoP來分派任務

透過基準值協助IT在投資與轉移運作環境時的評估

以下以一個eStore系統的服務品質儀表板來為您說明該掌握甚麼樣的資訊。首先是主畫面，該畫面顯示了eStore系統幾個黃金指標、品質率有問題的交易種類與占比：

您也許注意到有些圖片有灰色的虛線，那個就是根據過往資料所計算出來的基準值(Baseline)，底下說明各種線條的意義：

到目前為止我們已經可以透過一個儀表板得到eStore系統的黃金指標以及品質資訊，同時黃金指標的Chart當中也顯示了該指標的基準值，這有助益管理者快速瞭解目前與過去有何不同!

接著我們要瞭解eStore系統幾個重要交易回應效能與基準值

我們可以加一個儀表板來顯示如下的資訊：

到目前為止我們已經掌握了eStore系統的黃金指標、品質資訊以及重要的幾大交易種類的回應效率。接著我們得將外部系統的回應效率也納入儀表中，因為絕大部分的系統在自身當中執行程式是不大可能會慢的，緩慢通常跟外部系統(DB、Web Services、MQ、etc…)有很大的關係。

與外部系統的互動呢? 不是說DB常常有問題?

上圖揭露了與eStore系統有關的DB的一些數據，因為儀表板的空間有限，所以我們主要是呈現DB的幾個關鍵數據如呼叫次數、Connection，I/O等等。

到現在我們已經掌握eStore系統的黃金指標、品質資訊、重大交易回應效率了，最後一個我們要加上去的是很常被忽略，但也是常常肇事的基礎建設的資訊。但這裡講的基礎建設並不是一般認為的伺服器或者網路等等，我們這次要談的是中間極為重要的一層，也就是AP人員口中的Middleware (Tomcat、Websphere、IIS等等…)。

Middleware是重中之重，很多AP與OP的困擾都跟它有關

Middleware是運行程式的基礎建設，其身上有很重要的資源必須要提供給程式使用，所以Middleware的配置不當或出現問題都會對整個系統造成致命的傷害，而HEAP、Thread Pool以及Connection Pool更是其中的重災區。

上面我們列出了eStore系統的四台Middleware的CPU使用、HEAP使用以及接收了多少的使用者服務請求等數據以便協助管理者掌握哪一台伺服器較常出現狀況。Thread Pool以及Connection Pool在此圖中並未加進去，如果有需要的話，隨時可以調整版面來加入這些重要的資訊。

至此我們已經透過幾個簡單的儀表板來呈現eStore系統的整體品質、交易效率、外部系統效率以及底層的Middleware狀態，這些資訊在您還未導入APM相關工具時是很難取得的，因為有些資訊是在runtime中才會出現，根本不會被寫到log裡面，所以最好的辦法還是直接使用正確的工具(Cisco Appdynamics)來協助您以服務品質的角度來進行管理。

最後，我用底下這張圖來跟您請問，這些資訊您有嗎? 如果您喜歡以上內容並且想瞭解更多，歡迎與我們聯繫~