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

監控，可以拆解為“監視+控制”，監視（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協議