監控功能是指針對某項數據或某項業務流程進行系統層面的定時掃描和執行控制措施，旨在定位目標數據中的風險或發現業務流程中的問題，并通過系統采取必要的自動化控制手段并沉淀相關數據。監控功能是后臺系統中的輕量級應用，一般較多的涉及數據、邏輯層面，較少的涉及界面原型設計。
02 為什么需要監控功能？
任何公司在運營一段時間以后，都會產生數據，這些數據可能是與業務目標直接相關的核心指標。對于電商產品而言，是GMV、是利潤；對于社交、短視頻等c端產品而言，是DAU、MAU。這些數據一般出現在Dashboard面板上，由于業務部門、產品部門每天都在看，當出現業務指標的數據浮動時，即使不設置針對關鍵業務指標的監控功能，也一樣能很快發現問題。對于核心指標的監控，重點不在于發現問題，而在于快速定位問題的原因，并進行自動化的控制。而一些隱藏較深的間接數據，是從側面影響核心數據的，而這個影響可能具有滯后性。如果能在其影響核心數據前，監控間接數據，并及時采取控制措施，那么可以將業務損失降至最低，影響范圍降至最小。
03 監控的核心要素
監控的核心要素為監控的對象及其限定條件、監控的時間范圍或監控的數量級、系統執行的時間和頻次、觸發條件、處理機制。
1. 監控對象及其限定條件
如果監控對象是利潤，這個數據是系統已有的，也不需要限定條件，直接對利潤監控即可。如果監控對象是某項復雜業務流程，那必須明確說明選取對象的規則。如：針對首次充值訂單，且充值時間在30分鐘以內的所有訂單進行監控。
2. 監控的時間范圍或數量級
根據不同業務的數據量級不同，選擇合適的監控時間范圍，對于利潤，半小時內已經足以產生波動較大的數據，根據利潤的數據波動情況進行數據分析，選擇合適的時間范圍進行監控，選擇最小產生明確利潤波動的時間單位。假設通過數據分析得出該類產品訂單量和供貨渠道都相當不穩定，10分鐘就可能產生利潤相差較大的結果。那么在定義該產品監控時間范圍時，選擇監控近10分鐘的數據。通常這個時間尺度越小，則控制起來風險越小。以上情況適用于數據在時間分布中是均勻的，那么對于一些數據分布不均勻的業務而言，應該使用累計數量劃定監控范圍。比如異常訂單，它的出現往往伴隨著隨機性，出現的時間完全不可控。那么就應該設定：監控近x筆異常訂單中，異常問題定義為無狀態碼的訂單。
3. 系統執行的時間和頻次
設置固定時間點執行；
設置固定的間隔時間執行。
選擇1意味著業務流程，可能含有更多人工干涉的因素；或者系統在執行其他程序時與此程序有些不兼容的問題，比如前置條件和后置條件，為防止程序產生沖突，設置固定的時間點執行。間隔時間的設置跟業務的響應時間成正比，業務越需要快速響應的，執行的頻次越高。如利潤屬于公司核心指標，出現虧損是不可接受的，所以響應時間要盡可能快，間隔時間可設置為5分鐘或10分鐘執行一次。即使選擇了按照固定頻次執行，也不意味著萬事大吉。產品人員還需要與技術協商好該程序幾點開始執行，執行一次的時間大概是多少秒，執行程序是否會對關聯數據產生影響。
4. 觸發條件
監控既然是對業務中風險進行控制，那么必然需要有響應的觸發條件。觸發條件主要依賴于閾值的設置，通過閾值的靈活設置，可以讓業務部門隨時根據業務情況自行配置相關閾值。如下圖所示：
5. 處理機制
（1） 告警按照問題出現的嚴重程度，采取不同的告警措施：
數據波動幅度較大，情況緊急，設置電話通知的告警方式，保證消息及時收到，業務人員可以及時處理（即使在非工作日遇到緊急情況也能迅速處理）；
數據波動幅度一般，對于時間要求較寬松的，采用短信通知的告警方式，業務人員看到后處理即可；
數據波動較小，處理或不處理影響不大的，或僅做通知用途的，可采用系統推送消息的方式告警。
如果是日常運營內容，如工單的處理、審核等（數據量小，頻次不高的情況），也可采用系統推送的方式。
當對某項業務數據進行告警時，告警信息務必明清晰告警內容主體，告警相關數據，該主體對應設置的閾值，便于第一時間明確問題出現的層次和范圍，查找更深層次的原因并進行控制。（2） 另外一種處理機制是系統強制執行，控制目標產品下架、強制關閉某功能。一般為達到止損或減損的目的，通常配合告警信息同步使用，一方面起到通知的作用，另一方面便于后續查找問題。所有的超過閾值和相關處理措施都應該形成日志記錄，如需要后續迭代和分析數據的，則需要形成完整和規范的數據報表，并且需要導出功能。
04 監控的其他輔助功能
1. 主監控頁面
主要以表單頁面呈現，對于處理需求頻次較高的業務，或比較重要的業務，需要設計該頁面。如果監控的產品處理頻次低，告警頻次低，則不必設計該頁面?？筛鶕幚淼牟僮鞑煌瑓^分不同的監控產品，如產品強制下架的劃分為一類，產品訂單限制的劃分為一類，分類方法沒有局限，主要根據業務需求。表單頁面設計，必須包含監控主題、統計范圍、數據相關閾值、觸發動作、詳情等，如下圖示例：
2. 數據統計功能
監控功能的設計不是一蹴而就的，先設計出基本的功能，然后再憑借數據統計功能分析數據，掌握其中數據的規律，做好下次迭代。一般針對數據較復雜、設置閾值不清晰、產品需要個性化閾值方案的監控功能。同樣以表單頁面進行呈現，數據統計一般根據業務需要，每隔一段時間生成一組數據，字段需要包含監控主體、閾值相關的所有數據（如時長、訂單數、統計時間段等）、是否觸發動作、統計時間等。需要導出功能以方便分析，另外數據統計需要和設置閾值的統計頻次盡量保持一致。
3. 操作記錄功能
不一定所有執行動作都是系統完成的，人工也有可能操作。處于風險管理的需要和追責，需要記錄所有操作的操作人，操作人一般為系統和具體人名。字段包含操作內容、操作人、操作時間。不光是對于產品的操作需要操作人，對于閾值的操作也需要操作人，比如誰調整了相關閾值，這些都是需要記錄下來的。
4. 閾值配置功能
閾值配置一般適用于觸發條件會隨著業務需求變化的情況，這樣方便業務操作人員根據業務需求靈活調整閾值配置?；蛘弋a品繁多，各個產品都需要配置個性化的閾值方案。閾值配置也并非一味的追求靈活配置，需要非常清楚這些閾值對業務的影響，部分數據需要可配置的方式，而一些數據固定后臺寫死比較好，一方面出于風險控制考慮，配置越靈活，越有可能出錯；另一方面考慮到開發成本，配置項過多的，開發難度越大。而一些業務對于時間不敏感的，可以長期使用一套固定的閾值方案，那么可以不設計配置功能。
05 其他注意事項
后臺產品核心就是業務，一切都在滿足核心業務需求的基礎上提高用戶體驗，原型圖不追求高大上，也不能一開始就把原型畫的很完善。
先出一個簡單的功能邏輯、流程圖，描述你將要做的功能是什么，先進行內部的業務評審，評審通過后再著手完善原型和文檔；
監控類產品的核心在于閾值的設置、監控范疇、統計頻次、統計時長、數據敏感度這些抽象邏輯層面，而不是具象化的原型demo，所以事先做好業務需求調研和數據分析非常重要，這樣在設計功能時才能有的放矢；
監控類產品不能一開始就追求大而全，先重點解決對業務影響較大的、急需監控的數據，保證核心功能的可用性，再通過數據沉淀分析數據，逐步細化產品需求，并逐漸迭代產品；
后臺產品大部分頁面都是在設計表單頁面，必須清晰明白哪些字段屬于核心信息，哪些信息屬于不必要信息，精簡字段，字段太多也會影響查詢效率的。
