監控產品中“告警服務”的設計及演化

8 評論 26631 瀏覽 215 收藏 20 分鐘

在“告警服務”的設計過程中,首先明確了“告警服務”的價值,然后通過用戶畫像描述了“告警服務”的實際應用場景,接著通過“用戶體驗地圖”全面梳理了“告警服務”中用戶的觸點、痛點、機會點,并以此分析出設計的落地策略,最后通過對“告警服務”的設計及其迭代演化,逐步完善“告警服務”的設計方案、提升用戶體驗。

監控,可以拆解為“監視+控制”,監視(monitor)表示用戶通過觀察獲取數據,控制(control)表示數據變化引發的用戶行為。

作為云產品的一種,監控產品構成“數據—人—行為”的閉環,滿足用戶兩層需求:

  1. 提供準確實時的產品數據
  2. 產品數據引導正確的用戶行為

數據是監控的基礎,行為是監控的價值變現。本文所述的“告警服務”就是在用戶處于離線狀態下,監控產品仍然能構成“數據—人—行為”的完整閉環。

一、告警服務的價值

用戶需求

對于99%的用戶,都不能7*24盯著監控系統,當處于離線狀態時(干活、吃飯、睡覺、下班、休假…),用戶與監控數據之間是隔離的。

在這種場景中,如果監控數據發生了異常變化,用戶仍希望能夠立馬獲悉,進而采取措施應對、避免造成損失?!案婢铡睉\而生,用戶設定一定的規則,當監控數據違反規則時觸發告警并發送給用戶,打破“人”和“數據”的的隔離狀態,瞬間構成“數據—人—行為”的完整閉環。

業務價值

“告警服務”能極大解放用戶的注意力。通過對產品的業務數據設定規則,業務人員就可以7*24的掌握產品數據的健康狀態,得以將更多的精力專注于業務本身。

“告警服務”能使用戶第一時間獲取期望的業務數據。產品的業務數據一旦違反用戶設定的規則即可迅速推送至用戶,幫助用戶過濾99%的無效信息,使數據精準觸達用戶。

二、用戶畫像

用戶畫像A

任盈盈,女,25歲,產品經理

負責蘇寧易購某核心產品線-XX產品線的產品工作,日常的工作主要圍繞XX產品線的需求、排期、研發、上線開展,工作節奏快、強度高。每天會登錄數次監控產品,查看XX產品線的監控數據,以掌握XX產品線的健康狀態。

由于工作節奏快,每天難以抽出充沛的時間去分析產品監控數據,會遺漏部分關鍵數據從而留下隱患。希望能通過告警服務獲取所有XX產品線相關的關鍵異常數據,既不用花費大量的時間精力去分析數據,也不會遺漏任何關鍵數據。

用戶畫像B

令狐沖,男,35歲,技術負責人

負責蘇寧易購某核心研發中心-XX研發中心的技術工作,日常的工作主要是XX研發中心的技術保障,工作責任重、壓力大。每天一上班就會打開監控產品,隨時查看XX研發中心相關的監控數據,保證系統的穩定。

由于系統是7*24小時運行,但自身無法全天候上線查看監控數據,尤其是下班后或節假日,沒法做到隨時查看監控數據。希望能通過告警服務及時獲取XX研發中心相關的異常數據,以便第一時間作出判斷、并決定是否安排人員介入。

三、用戶體驗地圖

通過參考行業相關產品和調研用戶需求,可以將“告警服務”拆分為4個階段:

“配置告警策略——篩選產品數據——推送告警消息——接收告警消息”

以下是“告警服務”4個階段的用戶體驗地圖,可以從全局視角審視“告警服務”的每一個環節。

通過洞察用戶的行為和心理,梳理用戶在不同階段的情緒點,可以盤點、挖掘“告警服務”四個階段設計的機會點,如下:

  1. 配置告警策略:簡單的配置規則、合理的指標、提供默認的閾值
  2. 篩選產品數據:計算平臺處理能力強、計算平臺準確性高、計算平臺穩定性好
  3. 推送告警消息:告警平臺穩定性好、告警平臺對相同告警進行合并
  4. 接收告警消息:告警內容簡單易讀、告警消息支持多渠道發送、告警消息支持自定義接收者

四、分析與思考

用戶體驗地圖給出設計的“機會點”,接下來需要思考如何將其落地、形成可參考執行的設計策略。

首先,需要關注存在哪些用戶觸點,這是設計落地的切入點,通過用戶體驗地圖,分析如下:

1)在“配置告警策略”階段,存在1個觸點:告警配置模塊。

結合該階段的設計機會點,可以推定:在告警配置模塊,需要提供簡單的配置規則,在配置規則內盡量提供用戶最合適的指標或組合,并且在關于閾值的設定上可以提供默認值、或者毋需用戶設定。

2)在“篩選產品數據”、“推送告警信息”兩個階段,均由后臺系統自動完成、用戶不會直接接觸,因此不存在用戶觸點。

但是并不意味著設計不需要關注這兩個階段,在設計的過程中,需要根據目前的技術能力給出合理的設計方案,盡量避免憑空想象。

3)在“接受告警消息”階段,存在2個觸點:終端接收設備、告警內容。

結合該階段的設計機會點,可以推定:

  • 針對“終端接收設備”,用戶希望可以選擇自己需要的渠道接收告警消息,并且告警消息發送給誰也由用戶自己決定,這兩項均屬于配置階段的內容。
  • 針對“告警內容”,用戶希望能按照重要、緊急兩個維度將告警內容從上到下排列,并且盡量減少冗余信息、提升可讀性。

通過以上分析,可以清晰歸納出,設計的落地點主要由兩個:

  1. 配置告警策略(支持自定義的渠道和接收者)
  2. 告警消息所推送的內容

針對這兩項的設計策略如下:

五、設計及演化

配置告警策略

參考行業相關產品,告警配置模塊主要分為兩個部分:

  1. 告警策略的展示列表
  2. 告警策略的添加/編輯狀態

本質上兩者都是即圍繞“告警策略”開展設計。

針對“告警策略”,一般由4種內容組成:

  1. 告警策略的名稱
  2. 告警監控的對象
  3. 告警針對的指標
  4. 告警觸發的條件

在本案例中,由于“終端接收設備”模塊的內容合并至“告警配置模塊”,因此本案例中的告警策略需要再增加一項內容:告警消息的推送。

1)告警策略的名稱:指本條告警策略的名稱,與人的姓名一樣,是用戶識別告警策略的主要標識。

2)告警監控的對象:指本條告警策略是針對哪些對象而配置的,監控這些對象的狀態變化。

3)告警針對的指標:指針對哪個數據指標設立告警規則,指標可以是單個或一組,需要選擇合適的指標才能更好的發揮告警服務的價值。

4)告警觸發的條件:指選定的數據指標達到什么閾值即觸發告警的生成,這個決定告警服務的精確程度。

5)告警消息的推送:指告警消息發送的人員,以及發送的方式,也就是解決“通知誰、怎么通知”的問題。

梳理完告警配置模塊的元素,就可以根據“配置告警策略”的設計原則,開展設計:“配置規則簡單、指標契合、閾值有默認值、自定義接收渠道、自定義接收者”

當用戶進入告警配置模塊,未配置任何告警策略,提示、引導用戶開始創建。

針對“添加告警策略”,經歷了3版設計方案的演變。

第一版方案,基本符合上述的設計原則。

該方案上線之后用戶配置了大量的告警策略,但發生了意想不到的事情:不告警。經過排查定位,最終確認是計算平臺產生了非常嚴重的阻塞,即“用戶體驗地圖”的第二階段“篩選產品數據”出了問題。復盤之后,認定有兩方面的原因:

  1. 一是所選擇的告警指標“影響用戶占比的環比增長率”涉及大量的“去重”計算,嚴重消耗計算平臺的性能;
  2. 二是監控對象沒有做限制,多個篩選條件排列組合之后產生了大量監控對象,遠遠超過了計算平臺的極限。

因此,決定從兩個方面優化設計方案:

  1. 使用新的告警指標
  2. 對監控對象做限制

這是第二版方案,在延續第一版所遵循的設計原則基礎上,針對性做了優化。

  1. 監控對象限制了可配置的數目,降低現有計算平臺產生阻塞的風險;
  2. 改用新的告警指標,舍棄了“去重”計算,提供“絕對值”、“相對值”兩種指標供用戶選擇,覆蓋面更廣;
  3. 精簡了觸發條件,減輕現有計算平臺的壓力;
  4. 消息推送的渠道默認值只設置“豆芽”,降低成本(豆芽是蘇寧內部員工使用的IM工具)

第二版方案上線之后,告警計算平臺的阻塞問題解決了,但是用戶反饋:監控對象可配置的太少。這個當時已經預料到會有這個問題,但是現有的計算平臺性能受限,“巧婦難為無米之炊”,只能采取這種妥協的方式。

隨著新的計算平臺上線,性能得到極大提升,設計方案也不用“畏手畏腳”。第三版方案在保留原有優點的基礎上,主要針對“告警對象”做了重點優化。

  1. 告警名稱提供默認值,解決用戶對告警名稱填寫過程中“不愿想、不愿寫”的”懶“需求;
  2. 監控對象的來源,提供用戶常見的場景作為待選集合,方便用戶快速選擇告警對象;
  3. 監控對象的配置,讓用戶行為從“輸入”變成“勾選”,并提供批量選擇,簡化用戶的配置步驟;
  4. 監控對象的數目,限制數放開至200,并可通過后臺配置進行動態調整。之所以將數目暫定于200,是方便用戶從四個TOP異常的場景中分別選中一類,正好200。

添加完告警策略之后,告警模塊至少會有一條告警策略。

  1. 支持用戶對告警策略列表進行篩選、搜索
  2. 支持繼續添加告警策略
  3. 將告警策略的五種主要內容(告警名稱、監控對象、告警指標、觸發條件、消息推送)顯示在列表內
  4. 支持對單條策略的開關、編輯和刪除,其中“開關”場景是用戶暫時需要關閉策略、但不對其進行刪除

告警消息

告警消息指的是當告警發生以后,告警平臺將該條告警相關的信息推送至用戶,是“數據—人—行為”閉環的重要一環,用戶通過閱讀告警消息獲取當前系統的健康狀況、從而采取對應的干預措施。

根據“告警消息”的設計原則,開展設計:

“提供關鍵數據、精簡告警內容、減少冗余信息、提升可讀性”

相比于“配置告警策略”,“告警消息”沒有出現過較大版本的優化。通過參考行業相關產品和用戶需求,擇取了9個字段,實際的告警消息有兩種模板,分別對應兩種告警指標:異常數、絕對值。

  1. 告警策略的名稱:用戶第一時間判斷和自身的相關程度,是否自己創建、是否是高優先級告警策略。
  2. 當前產生的告警等級:判斷該告警的嚴重程度,決定了采取何種干預措施。
  3. 產生告警的監控對象:確認告警是由哪個監控對象引起,如果要采取措施可據此聯系責任人。
  4. 觸發告警的數據:查看現場數據,在告警等級的基礎上進一步判斷該告警的嚴重程度。
  5. 告警發生的時間:時間可用于定位告警的原因和判斷時效性。
  6. 告警所屬的產品:附屬信息,當用戶名下有多個產品時據此區分。
  7. 告警發生的來源:附屬信息,當用戶使用多種監控系統時據此區分。
  8. 告警消息的接收者:附屬信息,用戶用以判斷相關干系人是誰。
  9. 告警策略的創建者:附屬信息,用戶用以判斷該告警策略是否是正常、合法創建。

六、總結

小結

在“告警服務”的設計過程中,首先明確了“告警服務”的價值,然后通過用戶畫像描述了“告警服務”的實際應用場景,接著通過“用戶體驗地圖”全面梳理了“告警服務”中用戶的觸點、痛點、機會點,并以此分析出設計的落地策略,最后通過對“告警服務”的設計及其迭代演化,逐步完善“告警服務”的設計方案、提升用戶體驗。

隨著AI和大數據等技術的引入,“告警服務”會持續進行優化迭代,主要圍繞3個方面:

  1. 更簡單的配置。通過采取態勢感知、智能化的帶狀閾值區間會逐步取代人工設定的閾值,能極大降低用戶使用“告警服務”的成本。
  2. 更具體的對象。目前的告警策略針對的還是零散的告警對象,未來將會將圍繞“場景”概念為用戶提供更加具體的業務告警對象,價值更高。
  3. 更精準的決策。目前的告警服務僅僅限于將現場數據告知用戶,未來將會提供給用戶加精準的輔助決策,以達到智能化運維的目標。

反思

設計師都是理想主義者,設計過程就是一個理想主義者不斷與這個世界妥協的過程,與用戶妥協、與技術妥協、與時間妥協,但這也體現體驗設計的魅力:圍繞用戶需求進行快速迭代。

“設計沒有好與壞,只有合不合適”

 

作者:胡欣欣,公眾號:吹拉彈唱大師(ID:cltcds)

本文由@吹拉彈唱大師 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash, 基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 發現原型一個小細節錯誤,告警消息標題上面的一張圖,異常數環比那個例子,原型寫的告警類型還是異常數,??

    來自江蘇 回復
  2. 求問畫體驗地圖的工具是啥呀~

    來自廣東 回復
  3. 寫的不錯,贊一個。正好最近我在做一個監控系統的設計,冒昧問下,線下能否深度交流呢?

    回復
    1. 可以,公眾號留言,加你微信

      回復
  4. 你好請問一下,參考行業相關產品,這些產品在哪里可以找到并體驗呢?

    來自廣東 回復
    1. 阿里云、華為云

      來自江蘇 回復
  5. 寫得很棒,想問一下:如果用一個可量化的指標衡量你的產品價值,這個指標是什么?

    來自廣東 回復
    1. 以結果為導向的話,就是:告警消息的準確率

      來自江蘇 回復