在金融或電商行業，凡是涉及到交易的業務，都會有很大的系統風險。若系統異常，導致使用者無法完成交易；又或者是運營人員操作不當，導致公司虧損，這些都是可能會遇到的問題。因此，我們在聚焦業務增長時，往往需要注意監控告警該關鍵環節。

上週的某一天晚上九點多，剛剛下班上地鐵，就在企業微信群中收到訊息。

“我們的成交金額見底了，快看看發生了什麼？”

“系統某個接口出現異常，使用者無法完成交易，研發正在解決”、

“問題發生多久了？造成多少損失？”

“大概一個小時，預計少了兩百萬交易量。”

“為什麼持續將近一小時才發現解決？”

我工作後在兩家公司待過，公司業務和業績不盡相同，但都遇到過一樣的事情——系統異常導致損失。這似乎成了每個公司都必須要經歷的事情，甚至有的損失慘重而造成了一系列多米諾效應。

不管是電商行業還是金融行業，凡涉及到交易的業務，其實都會有很大的系統風險。例如，系統或者介面異常導致使用者無法完成交易，這對公司來說是交易額的損失。又比如，運營人員操作不當導致被刷單或者薅羊毛，這對公司來說是利潤的損失。

當我們聚焦於業務的增長時，往往會遺漏一個關鍵環節——監控告警。

無論是研發人員、產品人員、運營人員，其實都不能保證任何事情百分百“無bug”，研發介面可能受效能影響等會報錯，產品人員可能設計邏輯時會有遺漏，運營人員配置活動時可能會失誤。金無足赤，人無完人。但是，當出現問題時，我們需要能最及時的監控告警，最實時的排查解決。

無論是什麼公司，什麼業務，監控告警都是不可或缺的。

一、需要監控什麼？

我們日常監控的內容，大多包含兩個層面。

一是研發介面監控。

在很多情況下，流程異常都是介面先報錯，進而影響到後續業務，所以介面一般會比業務資料更快的暴露問題。

研發在開發各類介面，尤其是核心流程介面時，大多會有介面監控，例如建立訂單介面、訂單支付介面等。

研發側會監控介面報錯次數，正常情況下介面會正常執行並返回結果。但當介面報錯時，意味著無法正常返回結果，會導致流程阻塞。所以如果介面在某一段時間內，報錯數量陡增，那意味著該接口出現異常。該類告警必須為實時監控告警。

二是業務資料監控。

對於產品和運營人員，每天最需要關注的就是業務資料，比如當天的成交使用者數，成交GMV等。大多數情況下，我們會T+1去檢視並分析前一天的詳細資料，畢竟所有業務資料都實時跑，對效能的壓力比較大，並非每個公司都有足夠的資源和實力。

但是對於部分核心業務資料，需要進行實時監控並預警。例如，下單人數、下單數量、成交人數、成交單數、成交金額等。如果發現在某個時間段內，成交金額突然急劇下滑或者上升，那麼很可能是業務出現異常。

針對核心業務指標，我們需要重點觀察其變化趨勢和極端絕對值。無論是突然同比增長200%，或者變化為0，都是屬於異常情況。

綜上所述，我們可以監控的內容包括：

介面報錯監控，實時監控核心介面的報錯數量和成功率

業務報錯監控，實時監控核心業務指標的變化趨勢

二、如何監控告警？

如何監控告警，實際上蘊含了三個問題：

1. 針對什麼進行告警？

針對什麼進行告警，其實在上文需要監控什麼中已經有所提交，我們一般需要對研發介面的報錯情況和業務資料進行監控並告警。研發介面一般情況下研發系統會有專門的管理和監控，此處我們重點講針對業務資料的監控和告警。

上文提到，我們需要對核心業務指標進行監控，實際操作中，我們需要明確定義這些指標。

首先，要找到資料來源，研發側對於資料的上報，是上報到某個資料庫例項中的某個資料庫的某個資料庫表的某個欄位，然後業務側對這個欄位透過運算子公式加工為指標。

資料庫例項是程式，是位於使用者和作業系統之間的一層資料管理軟體，是訪問資料庫的通道；使用者對資料庫中的資料做任何的操作，包括資料定義、資料查詢、資料維護、資料庫執行控制等等都是在資料庫例項下進行的，應用程式只有透過資料庫例項才能和資料庫打交道。通常來說一個數據庫例項對應一個數據庫。

資料庫中會儲存很多張資料庫表，每張資料庫表有其應用意義。每張資料庫表又會有很多個欄位，每個欄位對應不同的內容。當我們將資料上報時，意味著將某個資料作為欄位值寫入到對應欄位中。

把欄位值透過運算子公式進行加工，就能得到指標。常見的運算子公式包括sum（求和）、count（計數）、avg（平均值）、max（最大值）、min（最小值）等。

舉個例子，我們要監控成交金額這一指標。

1）選擇資料庫例項，例如ec_database_instance

2）選擇資料庫例項中的資料庫，例如ec_order_database

3）選擇資料庫中的資料庫表，例如ec_order_detail

4）選擇資料庫表中的欄位進行加工，形成指標，例如sum（order_amount）

2. 什麼情況下進行告警？

我們知道要針對某些資料指標進行告警後，還要知道什麼情況下進行告警，此處可以理解為設定告警規則，命中規則的情況下，就啟動告警。

如果公司的大資料能力較強，包括資料完善、計算能力較強，可以使用大資料能力分析其合理範圍。即大資料會計算某個指標的預估變化範圍，如果指標值在該範圍內，則表示正常；若指標值超出該範圍，則表示資料異常。

在公司資料能力建設還未完備的情況下，我們可以考慮自行設定監控規則。

一個指標的監控，可能是由多條規則組成，我們需要考慮是針對多條規則取交集還是取並集。取交集則表示，同時命中多條規則就會告警。取並集則表示，命中任一一條規則就會告警。

每條具體的規則需要設定對比規則和對比閾值，常見的閾值規則包括：

固定值大於/小於X

同比昨天同一時間段大於/小於X%

環比上一時間段大於/小於X%

環比前N個週期的平均值大於/小於X%

環比前N個週期的最大值/最小值大於/小於X%

舉個例子，我們對十分鐘內成交金額進行監控，如果其絕對值小於100，或者同比昨天同一時間段內十分鐘交易金額大於10%，則啟動告警。如果昨天10：00-10：10成交金額為1000，今天10：00-10：10成交金額為2000，則命中第二條規則，同比金額大於10%（（2000-1000）/1000=100%），命中告警規則。

3. 要怎麼告警通知？

當我們針對某個指標設定的告警規則生效後，需要如何通知接受人呢？

這個問題的實質，是我們對告警級別的處理，不同級別的告警有不同的執行頻率和通知機制。我們大致可以分為以下三種：

1） 普通告警

普通告警一般為資料變化存在異常，需要產品或者研發進行確認是否存在問題，此時不一定有系統異常，可能是活動等原因造成的波動。

一般為每N個小時執行一次。

通知方式可以是透過企業微信或者釘釘等OA辦公軟體觸達。

2） 緊急告警

緊急告警一般為資料變化異常幅度較大，需要馬上確認是否有問題並進行跟進。

一般為每半小時或每小時執行一次。

通知方式除了OA軟體觸達，還可以透過郵件等方式，儘快告知處理人。

3） 致命告警

致命告警為資料絕對值出現明顯異常，需要馬上解決問題。例如，交易額突然降為0。

一般為每5分鐘或每10分鐘執行一次。

通知方式除了OA軟體和郵件，還需要加上電話通知。當系統出現異常時，自動撥打電話或傳送簡訊至處理人。

三、怎麼搭建監控告警系統？

對於產品經理而言，知道如何進行監控告警後，還需要有對應的系統承接需求。現在市場上很多BI工具其實就有相關功能，除了幫助業務人員展示資料、分析資料外，也會提供監控告警功能，支援業務人員配置使用。

如果公司沒有采購外部BI工具，而是選擇自行開發的話，那就需要一套監控告警系統。

1. 配置告警指標

配置一項告警指標，有資料來源、維度、有指標、有篩選條件，就好像寫一段sql，包括select、from、where、group by。

（1）資料來源

例項、資料庫、資料庫表：即中間表資訊。選擇資料上報到的資料庫例項、資料庫和資料庫表。此處一般只支援選擇，而不允許輸入。

（2）維度

配置查詢資料時的維度欄位，即sql中的group by欄位，可按照實際需求配置多個維度欄位，或者不配置維度欄位。

（3）指標

配置查詢資料時的資料指標，即sql中的select欄位，其中指標值內支援常用的計算函式，比如count、sum等，如果對應的欄位無需進行計算，可直接填寫欄位名稱

（4） 篩選條件

配置查詢資料時的過濾條件，即sql中的where欄位。此處一般會提供欄位值對應的計算公式，比如某個欄位的欄位值等於或者包含某些內容，形成一個篩選條件。

2. 配置告警規則

配置告警條件，滿足規則的資料將會被視為告警資料進行通知。

告警規則：配置滿足告警的條件，可按需進行對比型別、對比方式等配置。

執行頻率：告警任務的執行頻率，按需配置。

時間維度：告警任務是按照執行頻率查詢某個時間區間內的資料，此處指定了所選擇的資料庫表中對應的時間欄位。

3. 配置告警通知

產生告警資料後，如何通知到相關的責任人進行處理。

告警級別：包括【普通告警】、【緊急告警】、【致命告警】。

通知時間：在此區間內的告警資料才會通知，否則不會進行通知。

提醒間隔：通知的頻率限制。

告警方式：支援多選，包括企業微信、郵件、電話等。

告警處理人：接收告警通知，並有告警處理的許可權。

4. 記錄告警處理

收到告警通知後，可在系統檢視待處理的告警並進行處理。針對每項告警，可判斷為有效告警還是無效告警，並選擇對應的問題原因和解決方案。

透過記錄告警處理，一方面可以追溯告警的有效性和準確性，便於持續迭代最佳化告警系統的功能。一方面可以確保每次告警處理結果有跡可循，方便業務側追蹤問題原因和解決方案。

日常的監控和預警必然重要，但我們也需要知道，無論是研發介面的告警，還是業務資料的異常，都是問題呈現到了使用者端才被我們發現。實際上，有很多問題也許在管理端，研發人員操作或者運營人員配置時就可以體現。例如，我們監控到成交金額暴增，可能是被使用者刷單薅羊毛了，那麼在運營人員配置運營活動時，是否可以先計算相關金額並提醒其配置的準確性。儘可能的將問題前置暴露並及時解決，才是根源所在。

每年9月份開始都是各大公司的“體檢季”，別忘了給公司業務和系統也體檢一下，有很多趕緊“告警”！

作者：球溜溜，微信公眾號：產品小球

本文由 @溜溜球 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。