在「告警服務」的設計過程中，首先明確了「告警服務」的價值，然後通過用戶畫像描述了「告警服務」的實際應用場景，接著通過「用戶體驗地圖」全面梳理了「告警服務」中用戶的觸點、痛點、機會點，並以此分析出設計的落地策略，最後通過對「告警服務」的設計及其迭代演化，逐步完善「告警服務」的設計方案、提升用戶體驗。
監控，可以拆解為「監視+控制」，監視（monitor）表示用戶通過觀察獲取數據，控制（control）表示數據變化引發的用戶行為。
作為雲產品的一種，監控產品構成「數據—人—行為」的閉環，滿足用戶兩層需求：
提供準確實時的產品數據產品數據引導正確的用戶行為數據是監控的基礎，行為是監控的價值變現。本文所述的「告警服務」就是在用戶處於離線狀態下，監控產品仍然能構成「數據—人—行為」的完整閉環。
一、告警服務的價值用戶需求對於99%的用戶，都不能7*24盯著監控系統，當處於離線狀態時（幹活、吃飯、睡覺、下班、休假…），用戶與監控數據之間是隔離的。
在這種場景中，如果監控數據發生了異常變化，用戶仍希望能夠立馬獲悉，進而採取措施應對、避免造成損失。「告警服務」應運而生，用戶設定一定的規則，當監控數據違反規則時觸發告警並發送給用戶，打破「人」和「數據」的的隔離狀態，瞬間構成「數據—人—行為」的完整閉環。
業務價值「告警服務」能極大解放用戶的注意力。通過對產品的業務數據設定規則，業務人員就可以7*24的掌握產品數據的健康狀態，得以將更多的精力專注於業務本身。
「告警服務」能使用戶第一時間獲取期望的業務數據。產品的業務數據一旦違反用戶設定的規則即可迅速推送至用戶，幫助用戶過濾99%的無效信息，使數據精準觸達用戶。
二、用戶畫像用戶畫像A任盈盈，女，25歲，產品經理
負責蘇寧易購某核心產品線-XX產品線的產品工作，日常的工作主要圍繞XX產品線的需求、排期、研發、上線開展，工作節奏快、強度高。每天會登錄數次監控產品，查看XX產品線的監控數據，以掌握XX產品線的健康狀態。
由於工作節奏快，每天難以抽出充沛的時間去分析產品監控數據，會遺漏部分關鍵數據從而留下隱患。希望能通過告警服務獲取所有XX產品線相關的關鍵異常數據，既不用花費大量的時間精力去分析數據，也不會遺漏任何關鍵數據。
用戶畫像B令狐衝，男，35歲，技術負責人
負責蘇寧易購某核心研發中心-XX研發中心的技術工作，日常的工作主要是XX研發中心的技術保障，工作責任重、壓力大。每天一上班就會打開監控產品，隨時查看XX研發中心相關的監控數據，保證系統的穩定。
由於系統是7*24小時運行，但自身無法全天候上線查看監控數據，尤其是下班後或節假日，沒法做到隨時查看監控數據。希望能通過告警服務及時獲取XX研發中心相關的異常數據，以便第一時間作出判斷、並決定是否安排人員介入。
三、用戶體驗地圖通過參考行業相關產品和調研用戶需求，可以將「告警服務」拆分為4個階段：
「配置告警策略——篩選產品數據——推送告警消息——接收告警消息」
以下是「告警服務」4個階段的用戶體驗地圖，可以從全局視角審視「告警服務」的每一個環節。
通過洞察用戶的行為和心理，梳理用戶在不同階段的情緒點，可以盤點、挖掘「告警服務」四個階段設計的機會點，如下：
配置告警策略：簡單的配置規則、合理的指標、提供默認的閾值篩選產品數據：計算平臺處理能力強、計算平臺準確性高、計算平臺穩定性好推送告警消息：告警平臺穩定性好、告警平臺對相同告警進行合併接收告警消息：告警內容簡單易讀、告警消息支持多渠道發送、告警消息支持自定義接收者四、分析與思考用戶體驗地圖給出設計的「機會點」，接下來需要思考如何將其落地、形成可參考執行的設計策略。
首先，需要關注存在哪些用戶觸點，這是設計落地的切入點，通過用戶體驗地圖，分析如下：
1）在「配置告警策略」階段，存在1個觸點：告警配置模塊。
結合該階段的設計機會點，可以推定：在告警配置模塊，需要提供簡單的配置規則，在配置規則內儘量提供用戶最合適的指標或組合，並且在關於閾值的設定上可以提供默認值、或者毋需用戶設定。
2）在「篩選產品數據」、「推送告警信息」兩個階段，均由後臺系統自動完成、用戶不會直接接觸，因此不存在用戶觸點。
但是並不意味著設計不需要關注這兩個階段，在設計的過程中，需要根據目前的技術能力給出合理的設計方案，儘量避免憑空想像。
3）在「接受告警消息」階段，存在2個觸點：終端接收設備、告警內容。
結合該階段的設計機會點，可以推定：
針對「終端接收設備」，用戶希望可以選擇自己需要的渠道接收告警消息，並且告警消息發送給誰也由用戶自己決定，這兩項均屬於配置階段的內容。針對「告警內容」，用戶希望能按照重要、緊急兩個維度將告警內容從上到下排列，並且儘量減少冗餘信息、提升可讀性。通過以上分析，可以清晰歸納出，設計的落地點主要由兩個：
配置告警策略（支持自定義的渠道和接收者）告警消息所推送的內容針對這兩項的設計策略如下：
五、設計及演化配置告警策略參考行業相關產品，告警配置模塊主要分為兩個部分：
告警策略的展示列表告警策略的添加/編輯狀態本質上兩者都是即圍繞「告警策略」開展設計。
針對「告警策略」，一般由4種內容組成：
告警策略的名稱告警監控的對象告警針對的指標告警觸發的條件在本案例中，由於「終端接收設備」模塊的內容合併至「告警配置模塊」，因此本案例中的告警策略需要再增加一項內容：告警消息的推送。
1）告警策略的名稱：指本條告警策略的名稱，與人的姓名一樣，是用戶識別告警策略的主要標識。
2）告警監控的對象：指本條告警策略是針對哪些對象而配置的，監控這些對象的狀態變化。
3）告警針對的指標：指針對哪個數據指標設立告警規則，指標可以是單個或一組，需要選擇合適的指標才能更好的發揮告警服務的價值。
4）告警觸發的條件：指選定的數據指標達到什麼閾值即觸發告警的生成，這個決定告警服務的精確程度。
5）告警消息的推送：指告警消息發送的人員，以及發送的方式，也就是解決「通知誰、怎麼通知」的問題。
梳理完告警配置模塊的元素，就可以根據「配置告警策略」的設計原則，開展設計：「配置規則簡單、指標契合、閾值有默認值、自定義接收渠道、自定義接收者」
當用戶進入告警配置模塊，未配置任何告警策略，提示、引導用戶開始創建。
針對「添加告警策略」，經歷了3版設計方案的演變。
第一版方案，基本符合上述的設計原則。
該方案上線之後用戶配置了大量的告警策略，但發生了意想不到的事情：不告警。經過排查定位，最終確認是計算平臺產生了非常嚴重的阻塞，即「用戶體驗地圖」的第二階段「篩選產品數據」出了問題。復盤之後，認定有兩方面的原因：
一是所選擇的告警指標「影響用戶佔比的環比增長率」涉及大量的「去重」計算，嚴重消耗計算平臺的性能；二是監控對象沒有做限制，多個篩選條件排列組合之後產生了大量監控對象，遠遠超過了計算平臺的極限。因此，決定從兩個方面優化設計方案：
使用新的告警指標對監控對象做限制這是第二版方案，在延續第一版所遵循的設計原則基礎上，針對性做了優化。
監控對象限制了可配置的數目，降低現有計算平臺產生阻塞的風險；改用新的告警指標，捨棄了「去重」計算，提供「絕對值」、「相對值」兩種指標供用戶選擇，覆蓋面更廣；精簡了觸發條件，減輕現有計算平臺的壓力；消息推送的渠道默認值只設置「豆芽」，降低成本（豆芽是蘇寧內部員工使用的IM工具）第二版方案上線之後，告警計算平臺的阻塞問題解決了，但是用戶反饋：監控對象可配置的太少。這個當時已經預料到會有這個問題，但是現有的計算平臺性能受限，「巧婦難為無米之炊」，只能採取這種妥協的方式。
隨著新的計算平臺上線，性能得到極大提升，設計方案也不用「畏手畏腳」。第三版方案在保留原有優點的基礎上，主要針對「告警對象」做了重點優化。
告警名稱提供默認值，解決用戶對告警名稱填寫過程中「不願想、不願寫」的」懶「需求；監控對象的來源，提供用戶常見的場景作為待選集合，方便用戶快速選擇告警對象；監控對象的配置，讓用戶行為從「輸入」變成「勾選」，並提供批量選擇，簡化用戶的配置步驟；監控對象的數目，限制數放開至200，並可通過後臺配置進行動態調整。之所以將數目暫定於200，是方便用戶從四個TOP異常的場景中分別選中一類，正好200。添加完告警策略之後，告警模塊至少會有一條告警策略。
支持用戶對告警策略列表進行篩選、搜索支持繼續添加告警策略將告警策略的五種主要內容（告警名稱、監控對象、告警指標、觸發條件、消息推送）顯示在列表內支持對單條策略的開關、編輯和刪除，其中「開關」場景是用戶暫時需要關閉策略、但不對其進行刪除告警消息告警消息指的是當告警發生以後，告警平臺將該條告警相關的信息推送至用戶，是「數據—人—行為」閉環的重要一環，用戶通過閱讀告警消息獲取當前系統的健康狀況、從而採取對應的幹預措施。
根據「告警消息」的設計原則，開展設計：
「提供關鍵數據、精簡告警內容、減少冗餘信息、提升可讀性」
相比於「配置告警策略」，「告警消息」沒有出現過較大版本的優化。通過參考行業相關產品和用戶需求，擇取了9個欄位，實際的告警消息有兩種模板，分別對應兩種告警指標：異常數、絕對值。
告警策略的名稱：用戶第一時間判斷和自身的相關程度，是否自己創建、是否是高優先級告警策略。當前產生的告警等級：判斷該告警的嚴重程度，決定了採取何種幹預措施。產生告警的監控對象：確認告警是由哪個監控對象引起，如果要採取措施可據此聯繫責任人。觸發告警的數據：查看現場數據，在告警等級的基礎上進一步判斷該告警的嚴重程度。告警發生的時間：時間可用於定位告警的原因和判斷時效性。告警所屬的產品：附屬信息，當用戶名下有多個產品時據此區分。告警發生的來源：附屬信息，當用戶使用多種監控系統時據此區分。告警消息的接收者：附屬信息，用戶用以判斷相關干係人是誰。告警策略的創建者：附屬信息，用戶用以判斷該告警策略是否是正常、合法創建。六、總結小結在「告警服務」的設計過程中，首先明確了「告警服務」的價值，然後通過用戶畫像描述了「告警服務」的實際應用場景，接著通過「用戶體驗地圖」全面梳理了「告警服務」中用戶的觸點、痛點、機會點，並以此分析出設計的落地策略，最後通過對「告警服務」的設計及其迭代演化，逐步完善「告警服務」的設計方案、提升用戶體驗。
隨著AI和大數據等技術的引入，「告警服務」會持續進行優化迭代，主要圍繞3個方面：
更簡單的配置。通過採取態勢感知、智能化的帶狀閾值區間會逐步取代人工設定的閾值，能極大降低用戶使用「告警服務」的成本。更具體的對象。目前的告警策略針對的還是零散的告警對象，未來將會將圍繞「場景」概念為用戶提供更加具體的業務告警對象，價值更高。更精準的決策。目前的告警服務僅僅限於將現場數據告知用戶，未來將會提供給用戶加精準的輔助決策，以達到智能化運維的目標。反思設計師都是理想主義者，設計過程就是一個理想主義者不斷與這個世界妥協的過程，與用戶妥協、與技術妥協、與時間妥協，但這也體現體驗設計的魅力：圍繞用戶需求進行快速迭代。
「設計沒有好與壞，只有合不合適」
作者：胡欣欣，公眾號：吹拉彈唱大師（ID：cltcds）
本文由@吹拉彈唱大師 原創發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash, 基於CC0協議