中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

• “我們的成交金額見底了，快看看發生了什么？”
• “系統某個接口出現異常，用戶無法完成交易，研發正在解決”、
• “問題發生多久了？造成多少損失？”
• “大概一個小時，預計少了兩百萬交易量?！?/li>
• “為什么持續將近一小時才發現解決？”

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

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

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

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

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

一、需要監控什么？

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

一是研發接口監控。

在很多情況下，流程異常都是接口先報錯，進而影響到后續業務，所以接口一般會比業務數據更快的暴露問題。

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

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

二是業務數據監控。

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

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

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

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

• 接口報錯監控，實時監控核心接口的報錯數量和成功率
• 業務報錯監控，實時監控核心業務指標的變化趨勢

二、如何監控告警？

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

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

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軟件和郵件，還需要加上電話通知。當系統出現異常時，自動撥打電話或發送短信至處理人。

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

對于產品經理而言，知道如何進行監控告警后，還需要有對應的系統承接需求?，F在市場上很多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月份開始都是各大公司的“體檢季”，別忘了給公司業務和系統也體檢一下，有很多趕緊“告警”！