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

編輯導語：對于SaaS產(chǎn)品來說，系統(tǒng)的穩(wěn)定性是產(chǎn)品可用性原則的體現(xiàn)，為保證系統(tǒng)的穩(wěn)定性，則必須做好系統(tǒng)的監(jiān)控與日志功能。本篇作者就以訂單中心這一實際的產(chǎn)品，分享了自己對異常監(jiān)控功能設計的一些理解，一起來看看吧。

對于SaaS產(chǎn)品來說，系統(tǒng)的穩(wěn)定性是產(chǎn)品可用性原則的體現(xiàn)，為保證系統(tǒng)的穩(wěn)定性，則必須做好系統(tǒng)的監(jiān)控與日志功能。日志功能已在之前的文章中進行描述 《小功能大思考：訂單軌跡日志功能設計思考》而監(jiān)控功能從以下方面保證了系統(tǒng)的穩(wěn)定性：

• 及時感知異常
• 方便排查異常
• 高效處理異常
• 降低異常影響
• 有效分析異常

筆者目前在負責一個O2O訂單中心產(chǎn)品，產(chǎn)品的主要功能為：聚合分發(fā)訂單以實現(xiàn)訂單的履約。

所謂聚合，是獲取了美團外賣、餓百、有贊等公域和私域的O2O訂單，進行了訂單數(shù)據(jù)的一致化標準化。

所謂分發(fā)，是將數(shù)據(jù)一致化后的訂單分發(fā)至門店作業(yè)系統(tǒng)，聚合物流系統(tǒng)，ERP系統(tǒng)，統(tǒng)一進行標準化揀貨作業(yè)、標準化配送、標準化記賬與庫存管理。

在實際業(yè)務開展過程中，系統(tǒng)不穩(wěn)定，由于涉及的系統(tǒng)眾多，一個完整業(yè)務流程的節(jié)點也眾多，造成運維工作量量較大。

今天筆者就以訂單中心這一實際的產(chǎn)品，分享我對異常監(jiān)控功能設計的一些理解。

一、監(jiān)控什么

有同學肯定要問，運維不是有自己的自動化運維工具，可以對諸如接口請求異常、數(shù)據(jù)庫異常等做自動化的監(jiān)控嗎，為什么我們還要設計監(jiān)控管理功能，原因有兩個：

1. 工具的使用對象不同

運維自動化工具面向的是運維部門，如kibana日志分析平臺等工具需要掌握一定的語法和在海量數(shù)據(jù)中抓住異常的技巧，而系統(tǒng)的技術支持人員如運營或客戶的IT部門，掌握這種工具或技能的成本較高，無疑使用這種工具是增加了系統(tǒng)整體運營成本的。

2. 工具的使用場景不同

如果將產(chǎn)品分為接口層、表現(xiàn)層、業(yè)務層、存儲層，那運維自動化工具是對接口層和存儲層進行的監(jiān)控，運維工程師進行監(jiān)控時也不會嘗試理解當前異常對實際業(yè)務有沒有造成影響，造成了什么影響，數(shù)據(jù)是否要修正，是否需要安撫客戶等等問題。

如讓運營同學對接運維工程師來進行判斷，運維工程師使用技術語言告知運營又經(jīng)常雞同鴨講，同事大量不影響實際的業(yè)務的異常沒有過濾直接交給運營，也大大增加了運營同學的判斷工作量。

故我們需要對系統(tǒng)各個層級的異常進行梳理、過濾、轉義，以讓運營同學聚焦影響業(yè)務的異常，那么我們一般監(jiān)控下面兩個方面：

1. 業(yè)務監(jiān)控：遵循一定的系統(tǒng)規(guī)則，判斷系統(tǒng)中的數(shù)據(jù)或指標異常，如：訂單中門店信息缺失、門店營業(yè)時長畸低、門店長時間未揀貨、多系統(tǒng)庫存差異等。
2. 系統(tǒng)監(jiān)控：系統(tǒng)故障造成正常業(yè)務無法繼續(xù)進行的異常，如：如接口調(diào)用異常，導致數(shù)據(jù)沒有正常流轉到下游系統(tǒng)。

二、如何感知

在《THINK IN UML》一書中，表述了現(xiàn)實運行的機制：人驅動系統(tǒng)、事體現(xiàn)過程、物記錄結果、規(guī)則控制運行。那么其實我們在感知異常時，也是對事和物進行監(jiān)控。

1. 物——對結果進行監(jiān)控

一般用于監(jiān)控邏輯隱藏在系統(tǒng)底層，業(yè)務節(jié)點比較復雜的業(yè)務。

以庫存同步舉例：商品運營經(jīng)歷在訂單中心發(fā)起庫存校準任務，ERP識別到此消息后根據(jù)任務任務加工同步數(shù)據(jù)，接著同步至訂單中心，然后由訂單中心根據(jù)庫存策略加工出不同的數(shù)量分發(fā)至各個平臺。

在這個業(yè)務中，我們經(jīng)常會發(fā)現(xiàn)，由于系統(tǒng)累積性的差異，如ERP中庫存扣減憑證未及時生成或服務短時波動造成數(shù)據(jù)同步丟失等等原因（異步系統(tǒng)不可避免出現(xiàn)的問題），造成多方系統(tǒng)數(shù)據(jù)不一致，往往可以通過對多個系統(tǒng)的數(shù)據(jù)限定范圍進行盤點來發(fā)現(xiàn)異常。此種對異常的監(jiān)控一般是由監(jiān)控系統(tǒng)的使用者主動發(fā)起的。

或是對于系統(tǒng)中描述性的數(shù)據(jù)進行監(jiān)控，也是一種對結果的監(jiān)控，這些描述性的數(shù)據(jù)由于它達到了預設的標準，滿足了預設的規(guī)則，它的數(shù)據(jù)才視為有意義的異常，數(shù)據(jù)本身在累加計算的過程中是沒有意義的。比如此門店的本日營業(yè)額畸低等等。

需要說明的是，對結果的監(jiān)控一般不會獨立使用，它應作為對事的監(jiān)控的補充兜底。

那什么是對事的監(jiān)控呢？

2. 事——對過程中的節(jié)點進行監(jiān)控

以訂單業(yè)務為例，涉及到訂單中商品的翻譯、庫存尋源確定發(fā)貨門店、門店揀貨、ERP生成憑證等節(jié)點，門店揀貨從系統(tǒng)實現(xiàn)層面上又可以分為通知門店前臺作業(yè)系統(tǒng)，門店前臺系統(tǒng)作業(yè)提醒，門店確認揀貨完成等節(jié)點。

由于各種業(yè)務節(jié)點是清楚的明確的（借用UML的的觀點簡單闡述一下為什么業(yè)務節(jié)點一定是清楚的明確的：系統(tǒng)設計是對現(xiàn)實世界的抽象，現(xiàn)實世界抽象成一個個用例，用例驅動概念設計，并最終進行編碼，每一個用例都有明確的執(zhí)行者，前置條件，可選流程與輸出物）。

當我們按照MECE原則拆分到一個可供監(jiān)控且有意義的顆粒度，如對訂單中心推送新訂單消息至門店前臺系統(tǒng)失敗，此業(yè)務只是訂單履約中的一個節(jié)點，當此異常出現(xiàn)時，系統(tǒng)即自動標記異常，不用等待系統(tǒng)定時的比對發(fā)現(xiàn)異常。

當然，從另一個角度來說，我們也可以將異常感知的方式區(qū)分為這么兩種：

1. 業(yè)務進行中出現(xiàn)異常，系統(tǒng)自動標記。
2. 監(jiān)控系統(tǒng)使用者主動發(fā)起異常校驗或系統(tǒng)根據(jù)預設的規(guī)則定時比對發(fā)現(xiàn)異常。

三、如何處理

當系統(tǒng)識別到異常時，應當如何處理呢，我們一般有兩種方式：

1. 系統(tǒng)自動處理

如從外賣平臺拉取訂單時，數(shù)據(jù)缺失，系統(tǒng)可以做自動重試機制。

使用系統(tǒng)自動處理機制一般比較慎重，僅使用在可以依靠重新嘗試拉取可以解除異常的場景下，一般不做復雜的異常解除邏輯的自動化，如訂單長時間未備貨，此時如果系統(tǒng)自動備貨，可能會造成系統(tǒng)無法反映真實作業(yè)情況的問題，具體可以看這篇文章，來理解為什么要慎用系統(tǒng)自動邏輯《1-2年產(chǎn)品經(jīng)理：教你接盤與重構的姿勢》。

2. 人工介入處理

仍以外賣平臺拉取訂單時數(shù)據(jù)異常的例子來說，當系統(tǒng)自動重試次數(shù)達到上線后，為減輕系統(tǒng)壓力，不影響其他正常單據(jù)的處理，往往會停止自動重試，此時應允許人工介入處理。在設計人工處理異常數(shù)據(jù)時，應注意：

1. 在對應異常單據(jù)中標注異常原因并提示解除異常的方法。
2. 人工處理異常后，由于可能涉及到單據(jù)中數(shù)據(jù)的修改，必須提供日志功能，記錄修改前的數(shù)據(jù)，修改后的數(shù)據(jù)以及修改的時間，修改人。
3. 嚴格控制權限，因為可能要進行業(yè)務數(shù)據(jù)的修改，一般僅允許總部或區(qū)域運營進行修改。

當然還要注意一點，有一種非常特殊的異常，即系統(tǒng)根據(jù)預設的規(guī)則對訂單進行加工，但是由于規(guī)則預設錯誤，導致實際加工后的訂單數(shù)據(jù)也錯誤，如在系統(tǒng)中預設規(guī)則，購買A商品1份，實際應發(fā)貨B商品12份，但是客戶運營在設置規(guī)則時，設置成：買A商品1份，實際應發(fā)貨B商品120份。

此時系統(tǒng)不會對此單據(jù)標記異常，但是確實不符合實際，此時人工介入處理時，應允許人工標記訂單異常后再進行數(shù)據(jù)修正。

仍然是上面的例子，由于預設規(guī)則的錯誤，導致揀貨商品數(shù)量錯誤，進而導致揀貨商品的單價等都計算錯誤。此時應只允許修改揀貨商品的數(shù)量，而不應允許修改揀貨商品的單價，揀貨商品的單價應由系統(tǒng)進行計算。即規(guī)則是：只改異常直接導致錯誤的字段值，而不改間接導致錯誤的字段值。

四、如何提醒

上面說到，有一些異常是需要人工介入處理的，那么異常監(jiān)控相關的提醒方式一般有哪些呢，我給大家簡單介紹一下當前我們使用的方式：

五、業(yè)務的截停與恢復

當一個業(yè)務發(fā)生異常，可能導致后續(xù)動作無法開展時，需要截停業(yè)務。如訂單數(shù)據(jù)缺失，可能造成ERP系統(tǒng)無法正常生成憑證，此時就應該截停通知ERP系統(tǒng)生成憑證的動作，等待異常解除后再恢復此動作。

對于SaaS系統(tǒng)來講，傳遞給其他系統(tǒng)的數(shù)據(jù)應盡量保證正確，如果多個系統(tǒng)中都有此異常數(shù)據(jù)，那么異常數(shù)據(jù)的修正就麻煩多了。這就是異常監(jiān)控功能設計中必須要要考慮的如何盡可能的降低異常影響的范圍。

六、數(shù)據(jù)分析

一個健康的產(chǎn)品，功能體系設計一定是閉環(huán)的，當我們識別出異常后，需要對異常情況進行評估分析，以不斷提高業(yè)務水平。發(fā)現(xiàn)一個問題就解決一個問題，在一個項目上發(fā)現(xiàn)一個問題，就只處理這個項目上發(fā)現(xiàn)的問題，是SaaS產(chǎn)品運營過程中不可取的。

我們一般需要進行數(shù)據(jù)的分析，達到以下目的：

1. 反應系統(tǒng)運行情況：展示該問題出現(xiàn)的次數(shù)，比例和趨勢，作為產(chǎn)品的健康度的考核指標，并作為績效考核指標對相關人員進行考核。
2. 發(fā)現(xiàn)現(xiàn)有問題：產(chǎn)品功能設計是否有缺陷，用戶操作是否有問題，是否需要產(chǎn)品功能優(yōu)化，是否需要進行操作人員的培訓考核等，進行針對性的改進。

如對門店揀貨超時這種異常情況進行分析，我們可以分析各個門店，各個區(qū)域的揀貨率（揀貨成功的訂單/所有訂單），揀貨超時率（揀貨超時的訂單/所有訂單）。

如揀貨超時率一直很高，我們就要調(diào)研以下揀貨超時率高的原因，是訂單太多確實沒法及時完成所有訂單的揀貨，還是門店人員不愿意或忘記點擊確認揀貨呢，如是第一個原因，那可以考慮多人同時揀貨或揀貨路徑規(guī)劃的功能了，如果是第二個原因，那可以考慮是否優(yōu)化系統(tǒng)的操作體驗。

七、總結

異常監(jiān)控功能的設計對于新手產(chǎn)品經(jīng)理來說是有些難度的，因為要回答監(jiān)控什么，怎么監(jiān)控的問題，依賴于對業(yè)務實現(xiàn)邏輯的清晰理解，也依賴于對運營人員處理問題過程中痛點的準確把握，故建議多咨詢開發(fā)與一線的運營人員，做好需求調(diào)研和方案確認的工作，確保產(chǎn)品設計確實可以解決問題。

八、附錄

給大家一個我整理的異常監(jiān)控管理需求梳理的表格，供大家參考：

本文由 @kathic 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議