在金融或電商行業(yè)，凡是涉及到交易的業(yè)務(wù)，都會有很大的系統(tǒng)風(fēng)險。若系統(tǒng)異常，導(dǎo)致用戶無法完成交易；又或者是運(yùn)營人員操作不當(dāng)，導(dǎo)致公司虧損，這些都是可能會遇到的問題。因此，我們在聚焦業(yè)務(wù)增長時，往往需要注意監(jiān)控告警該關(guān)鍵環(huán)節(jié)。

上周的某一天晚上九點(diǎn)多，剛剛下班上地鐵，就在企業(yè)微信群中收到消息。

• “我們的成交金額見底了，快看看發(fā)生了什么？”
• “系統(tǒng)某個接口出現(xiàn)異常，用戶無法完成交易，研發(fā)正在解決”、
• “問題發(fā)生多久了？造成多少損失？”
• “大概一個小時，預(yù)計少了兩百萬交易量。”
• “為什么持續(xù)將近一小時才發(fā)現(xiàn)解決？”

我工作后在兩家公司待過，公司業(yè)務(wù)和業(yè)績不盡相同，但都遇到過一樣的事情——系統(tǒng)異常導(dǎo)致?lián)p失。這似乎成了每個公司都必須要經(jīng)歷的事情，甚至有的損失慘重而造成了一系列多米諾效應(yīng)。

不管是電商行業(yè)還是金融行業(yè)，凡涉及到交易的業(yè)務(wù)，其實(shí)都會有很大的系統(tǒng)風(fēng)險。例如，系統(tǒng)或者接口異常導(dǎo)致用戶無法完成交易，這對公司來說是交易額的損失。又比如，運(yùn)營人員操作不當(dāng)導(dǎo)致被刷單或者薅羊毛，這對公司來說是利潤的損失。

當(dāng)我們聚焦于業(yè)務(wù)的增長時，往往會遺漏一個關(guān)鍵環(huán)節(jié)——監(jiān)控告警。

無論是研發(fā)人員、產(chǎn)品人員、運(yùn)營人員，其實(shí)都不能保證任何事情百分百“無bug”，研發(fā)接口可能受性能影響等會報錯，產(chǎn)品人員可能設(shè)計邏輯時會有遺漏，運(yùn)營人員配置活動時可能會失誤。金無足赤，人無完人。但是，當(dāng)出現(xiàn)問題時，我們需要能最及時的監(jiān)控告警，最實(shí)時的排查解決。

無論是什么公司，什么業(yè)務(wù)，監(jiān)控告警都是不可或缺的。

一、需要監(jiān)控什么？

我們?nèi)粘１O(jiān)控的內(nèi)容，大多包含兩個層面。

一是研發(fā)接口監(jiān)控。

在很多情況下，流程異常都是接口先報錯，進(jìn)而影響到后續(xù)業(yè)務(wù)，所以接口一般會比業(yè)務(wù)數(shù)據(jù)更快的暴露問題。

研發(fā)在開發(fā)各類接口，尤其是核心流程接口時，大多會有接口監(jiān)控，例如創(chuàng)建訂單接口、訂單支付接口等。

研發(fā)側(cè)會監(jiān)控接口報錯次數(shù)，正常情況下接口會正常運(yùn)行并返回結(jié)果。但當(dāng)接口報錯時，意味著無法正常返回結(jié)果，會導(dǎo)致流程阻塞。所以如果接口在某一段時間內(nèi)，報錯數(shù)量陡增，那意味著該接口出現(xiàn)異常。該類告警必須為實(shí)時監(jiān)控告警。

二是業(yè)務(wù)數(shù)據(jù)監(jiān)控。

對于產(chǎn)品和運(yùn)營人員，每天最需要關(guān)注的就是業(yè)務(wù)數(shù)據(jù)，比如當(dāng)天的成交用戶數(shù)，成交GMV等。大多數(shù)情況下，我們會T+1去查看并分析前一天的詳細(xì)數(shù)據(jù)，畢竟所有業(yè)務(wù)數(shù)據(jù)都實(shí)時跑，對性能的壓力比較大，并非每個公司都有足夠的資源和實(shí)力。

但是對于部分核心業(yè)務(wù)數(shù)據(jù)，需要進(jìn)行實(shí)時監(jiān)控并預(yù)警。例如，下單人數(shù)、下單數(shù)量、成交人數(shù)、成交單數(shù)、成交金額等。如果發(fā)現(xiàn)在某個時間段內(nèi)，成交金額突然急劇下滑或者上升，那么很可能是業(yè)務(wù)出現(xiàn)異常。

針對核心業(yè)務(wù)指標(biāo)，我們需要重點(diǎn)觀察其變化趨勢和極端絕對值。無論是突然同比增長200%，或者變化為0，都是屬于異常情況。

綜上所述，我們可以監(jiān)控的內(nèi)容包括：

• 接口報錯監(jiān)控，實(shí)時監(jiān)控核心接口的報錯數(shù)量和成功率
• 業(yè)務(wù)報錯監(jiān)控，實(shí)時監(jiān)控核心業(yè)務(wù)指標(biāo)的變化趨勢

二、如何監(jiān)控告警？

如何監(jiān)控告警，實(shí)際上蘊(yùn)含了三個問題：

1. 針對什么進(jìn)行告警？
2. 什么情況下進(jìn)行告警？
3. 要怎么告警通知？

1. 針對什么進(jìn)行告警？

針對什么進(jìn)行告警，其實(shí)在上文需要監(jiān)控什么中已經(jīng)有所提交，我們一般需要對研發(fā)接口的報錯情況和業(yè)務(wù)數(shù)據(jù)進(jìn)行監(jiān)控并告警。研發(fā)接口一般情況下研發(fā)系統(tǒng)會有專門的管理和監(jiān)控，此處我們重點(diǎn)講針對業(yè)務(wù)數(shù)據(jù)的監(jiān)控和告警。

上文提到，我們需要對核心業(yè)務(wù)指標(biāo)進(jìn)行監(jiān)控，實(shí)際操作中，我們需要明確定義這些指標(biāo)。

首先，要找到數(shù)據(jù)來源，研發(fā)側(cè)對于數(shù)據(jù)的上報，是上報到某個數(shù)據(jù)庫實(shí)例中的某個數(shù)據(jù)庫的某個數(shù)據(jù)庫表的某個字段，然后業(yè)務(wù)側(cè)對這個字段通過運(yùn)算符公式加工為指標(biāo)。

數(shù)據(jù)庫實(shí)例是程序，是位于用戶和操作系統(tǒng)之間的一層數(shù)據(jù)管理軟件，是訪問數(shù)據(jù)庫的通道；用戶對數(shù)據(jù)庫中的數(shù)據(jù)做任何的操作，包括數(shù)據(jù)定義、數(shù)據(jù)查詢、數(shù)據(jù)維護(hù)、數(shù)據(jù)庫運(yùn)行控制等等都是在數(shù)據(jù)庫實(shí)例下進(jìn)行的，應(yīng)用程序只有通過數(shù)據(jù)庫實(shí)例才能和數(shù)據(jù)庫打交道。通常來說一個數(shù)據(jù)庫實(shí)例對應(yīng)一個數(shù)據(jù)庫。

數(shù)據(jù)庫中會存儲很多張數(shù)據(jù)庫表，每張數(shù)據(jù)庫表有其應(yīng)用意義。每張數(shù)據(jù)庫表又會有很多個字段，每個字段對應(yīng)不同的內(nèi)容。當(dāng)我們將數(shù)據(jù)上報時，意味著將某個數(shù)據(jù)作為字段值寫入到對應(yīng)字段中。

把字段值通過運(yùn)算符公式進(jìn)行加工，就能得到指標(biāo)。常見的運(yùn)算符公式包括sum（求和）、count（計數(shù)）、avg（平均值）、max（最大值）、min（最小值）等。

舉個例子，我們要監(jiān)控成交金額這一指標(biāo)。

1）選擇數(shù)據(jù)庫實(shí)例，例如ec_database_instance

2）選擇數(shù)據(jù)庫實(shí)例中的數(shù)據(jù)庫，例如ec_order_database

3）選擇數(shù)據(jù)庫中的數(shù)據(jù)庫表，例如ec_order_detail

4）選擇數(shù)據(jù)庫表中的字段進(jìn)行加工，形成指標(biāo)，例如sum（order_amount）

2. 什么情況下進(jìn)行告警？

我們知道要針對某些數(shù)據(jù)指標(biāo)進(jìn)行告警后，還要知道什么情況下進(jìn)行告警，此處可以理解為設(shè)置告警規(guī)則，命中規(guī)則的情況下，就啟動告警。

如果公司的大數(shù)據(jù)能力較強(qiáng)，包括數(shù)據(jù)完善、計算能力較強(qiáng)，可以使用大數(shù)據(jù)能力分析其合理范圍。即大數(shù)據(jù)會計算某個指標(biāo)的預(yù)估變化范圍，如果指標(biāo)值在該范圍內(nèi)，則表示正常；若指標(biāo)值超出該范圍，則表示數(shù)據(jù)異常。

在公司數(shù)據(jù)能力建設(shè)還未完備的情況下，我們可以考慮自行設(shè)置監(jiān)控規(guī)則。

一個指標(biāo)的監(jiān)控，可能是由多條規(guī)則組成，我們需要考慮是針對多條規(guī)則取交集還是取并集。取交集則表示，同時命中多條規(guī)則就會告警。取并集則表示，命中任一一條規(guī)則就會告警。

每條具體的規(guī)則需要設(shè)置對比規(guī)則和對比閾值，常見的閾值規(guī)則包括：

• 固定值大于/小于X
• 同比昨天同一時間段大于/小于X%
• 環(huán)比上一時間段大于/小于X%
• 環(huán)比前N個周期的平均值大于/小于X%
• 環(huán)比前N個周期的最大值/最小值大于/小于X%

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

3. 要怎么告警通知？

當(dāng)我們針對某個指標(biāo)設(shè)置的告警規(guī)則生效后，需要如何通知接受人呢？

這個問題的實(shí)質(zhì)，是我們對告警級別的處理，不同級別的告警有不同的運(yùn)行頻率和通知機(jī)制。我們大致可以分為以下三種：

1） 普通告警

普通告警一般為數(shù)據(jù)變化存在異常，需要產(chǎn)品或者研發(fā)進(jìn)行確認(rèn)是否存在問題，此時不一定有系統(tǒng)異常，可能是活動等原因造成的波動。

一般為每N個小時運(yùn)行一次。

通知方式可以是通過企業(yè)微信或者釘釘?shù)萇A辦公軟件觸達(dá)。

2） 緊急告警

緊急告警一般為數(shù)據(jù)變化異常幅度較大，需要馬上確認(rèn)是否有問題并進(jìn)行跟進(jìn)。

一般為每半小時或每小時運(yùn)行一次。

通知方式除了OA軟件觸達(dá)，還可以通過郵件等方式，盡快告知處理人。

3） 致命告警

致命告警為數(shù)據(jù)絕對值出現(xiàn)明顯異常，需要馬上解決問題。例如，交易額突然降為0。

一般為每5分鐘或每10分鐘運(yùn)行一次。

通知方式除了OA軟件和郵件，還需要加上電話通知。當(dāng)系統(tǒng)出現(xiàn)異常時，自動撥打電話或發(fā)送短信至處理人。

三、怎么搭建監(jiān)控告警系統(tǒng)？

對于產(chǎn)品經(jīng)理而言，知道如何進(jìn)行監(jiān)控告警后，還需要有對應(yīng)的系統(tǒng)承接需求?，F(xiàn)在市場上很多BI工具其實(shí)就有相關(guān)功能，除了幫助業(yè)務(wù)人員展示數(shù)據(jù)、分析數(shù)據(jù)外，也會提供監(jiān)控告警功能，支持業(yè)務(wù)人員配置使用。

如果公司沒有采購?fù)獠緽I工具，而是選擇自行開發(fā)的話，那就需要一套監(jiān)控告警系統(tǒng)。

1. 配置告警指標(biāo)

配置一項告警指標(biāo)，有數(shù)據(jù)來源、維度、有指標(biāo)、有篩選條件，就好像寫一段sql，包括select、from、where、group by。

（1）數(shù)據(jù)來源

實(shí)例、數(shù)據(jù)庫、數(shù)據(jù)庫表：即中間表信息。選擇數(shù)據(jù)上報到的數(shù)據(jù)庫實(shí)例、數(shù)據(jù)庫和數(shù)據(jù)庫表。此處一般只支持選擇，而不允許輸入。

（2）維度

配置查詢數(shù)據(jù)時的維度字段，即sql中的group by字段，可按照實(shí)際需求配置多個維度字段，或者不配置維度字段。

（3）指標(biāo)

配置查詢數(shù)據(jù)時的數(shù)據(jù)指標(biāo)，即sql中的select字段，其中指標(biāo)值內(nèi)支持常用的計算函數(shù)，比如count、sum等，如果對應(yīng)的字段無需進(jìn)行計算，可直接填寫字段名稱

（4） 篩選條件

配置查詢數(shù)據(jù)時的過濾條件，即sql中的where字段。此處一般會提供字段值對應(yīng)的計算公式，比如某個字段的字段值等于或者包含某些內(nèi)容，形成一個篩選條件。

2. 配置告警規(guī)則

配置告警條件，滿足規(guī)則的數(shù)據(jù)將會被視為告警數(shù)據(jù)進(jìn)行通知。

• 告警規(guī)則：配置滿足告警的條件，可按需進(jìn)行對比類型、對比方式等配置。
• 運(yùn)行頻率：告警任務(wù)的執(zhí)行頻率，按需配置。
• 時間維度：告警任務(wù)是按照運(yùn)行頻率查詢某個時間區(qū)間內(nèi)的數(shù)據(jù)，此處指定了所選擇的數(shù)據(jù)庫表中對應(yīng)的時間字段。

3. 配置告警通知

產(chǎn)生告警數(shù)據(jù)后，如何通知到相關(guān)的責(zé)任人進(jìn)行處理。

• 告警級別：包括【普通告警】、【緊急告警】、【致命告警】。
• 通知時間：在此區(qū)間內(nèi)的告警數(shù)據(jù)才會通知，否則不會進(jìn)行通知。
• 提醒間隔：通知的頻率限制。
• 告警方式：支持多選，包括企業(yè)微信、郵件、電話等。
• 告警處理人：接收告警通知，并有告警處理的權(quán)限。

4. 記錄告警處理

收到告警通知后，可在系統(tǒng)查看待處理的告警并進(jìn)行處理。針對每項告警，可判斷為有效告警還是無效告警，并選擇對應(yīng)的問題原因和解決方案。

通過記錄告警處理，一方面可以追溯告警的有效性和準(zhǔn)確性，便于持續(xù)迭代優(yōu)化告警系統(tǒng)的功能。一方面可以確保每次告警處理結(jié)果有跡可循，方便業(yè)務(wù)側(cè)追蹤問題原因和解決方案。

日常的監(jiān)控和預(yù)警必然重要，但我們也需要知道，無論是研發(fā)接口的告警，還是業(yè)務(wù)數(shù)據(jù)的異常，都是問題呈現(xiàn)到了用戶端才被我們發(fā)現(xiàn)。實(shí)際上，有很多問題也許在管理端，研發(fā)人員操作或者運(yùn)營人員配置時就可以體現(xiàn)。例如，我們監(jiān)控到成交金額暴增，可能是被用戶刷單薅羊毛了，那么在運(yùn)營人員配置運(yùn)營活動時，是否可以先計算相關(guān)金額并提醒其配置的準(zhǔn)確性。盡可能的將問題前置暴露并及時解決，才是根源所在。

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