編輯導語：對於SaaS產品來說，系統的穩定性是產品可用性原則的體現，為保證系統的穩定性，則必須做好系統的監控與日誌功能。本篇作者就以訂單中心這一實際的產品，分享了自己對異常監控功能設計的一些理解，一起來看看吧。
對於SaaS產品來說，系統的穩定性是產品可用性原則的體現，為保證系統的穩定性，則必須做好系統的監控與日誌功能。日誌功能已在之前的文章中進行描述 《小功能大思考：訂單軌跡日誌功能設計思考》而監控功能從以下方面保證了系統的穩定性：
- 及時感知異常
- 方便排查異常
- 高效處理異常
- 降低異常影響
- 有效分析異常
筆者目前在負責一個O2O訂單中心產品，產品的主要功能為：聚合分發訂單以實現訂單的履約。
所謂聚合，是獲取了美團外賣、餓百、有贊等公域和私域的O2O訂單，進行了訂單資料的一致化標準化。
所謂分發，是將資料一致化後的訂單分發至門店作業系統，聚合物流系統，ERP系統，統一進行標準化揀貨作業、標準化配送、標準化記賬與庫存管理。
在實際業務開展過程中，系統不穩定，由於涉及的系統眾多，一個完整業務流程的節點也眾多，造成運維工作量量較大。
今天筆者就以訂單中心這一實際的產品，分享我對異常監控功能設計的一些理解。
一、監控什麼
有同學肯定要問，運維不是有自己的自動化運維工具，可以對諸如介面請求異常、資料庫異常等做自動化的監控嗎，為什麼我們還要設計監控管理功能，原因有兩個：
1. 工具的使用物件不同
運維自動化工具面向的是運維部門，如kibana日誌分析平臺等工具需要掌握一定的語法和在海量資料中抓住異常的技巧，而系統的技術支援人員如運營或客戶的IT部門，掌握這種工具或技能的成本較高，無疑使用這種工具是增加了系統整體運營成本的。
2. 工具的使用場景不同
如果將產品分為介面層、表現層、業務層、儲存層，那運維自動化工具是對介面層和儲存層進行的監控，運維工程師進行監控時也不會嘗試理解當前異常對實際業務有沒有造成影響，造成了什麼影響，資料是否要修正，是否需要安撫客戶等等問題。
如讓運營同學對接運維工程師來進行判斷，運維工程師使用技術語言告知運營又經常雞同鴨講，同事大量不影響實際的業務的異常沒有過濾直接交給運營，也大大增加了運營同學的判斷工作量。
故我們需要對系統各個層級的異常進行梳理、過濾、轉義，以讓運營同學聚焦影響業務的異常，那麼我們一般監控下面兩個方面：
- 業務監控：遵循一定的系統規則，判斷系統中的資料或指標異常，如：訂單中門店資訊缺失、門店營業時長畸低、門店長時間未揀貨、多系統庫存差異等。
- 系統監控：系統故障造成正常業務無法繼續進行的異常，如：如介面呼叫異常，導致資料沒有正常流轉到下游系統。
二、如何感知
在《THINK IN UML》一書中，表述了現實執行的機制：人驅動系統、事體現過程、物記錄結果、規則控制執行。那麼其實我們在感知異常時，也是對事和物進行監控。
1. 物——對結果進行監控
一般用於監控邏輯隱藏在系統底層，業務節點比較複雜的業務。
以庫存同步舉例：商品運營經歷在訂單中心發起庫存校準任務，ERP識別到此訊息後根據任務任務加工同步資料，接著同步至訂單中心，然後由訂單中心根據庫存策略加工出不同的數量分發至各個平臺。
在這個業務中，我們經常會發現，由於系統累積性的差異，如ERP中庫存扣減憑證未及時生成或服務短時波動造成資料同步丟失等等原因（非同步系統不可避免出現的問題），造成多方系統資料不一致，往往可以透過對多個系統的資料限定範圍進行盤點來發現異常。此種對異常的監控一般是由監控系統的使用者主動發起的。
或是對於系統中描述性的資料進行監控，也是一種對結果的監控，這些描述性的資料由於它達到了預設的標準，滿足了預設的規則，它的資料才視為有意義的異常，資料本身在累加計算的過程中是沒有意義的。比如此門店的本日營業額畸低等等。
需要說明的是，對結果的監控一般不會獨立使用，它應作為對事的監控的補充兜底。
那什麼是對事的監控呢？
2. 事——對過程中的節點進行監控
以訂單業務為例，涉及到訂單中商品的翻譯、庫存尋源確定發貨門店、門店揀貨、ERP生成憑證等節點，門店揀貨從系統實現層面上又可以分為通知門店前臺作業系統，門店前臺系統作業提醒，門店確認揀貨完成等節點。
由於各種業務節點是清楚的明確的（借用UML的的觀點簡單闡述一下為什麼業務節點一定是清楚的明確的：系統設計是對現實世界的抽象，現實世界抽象成一個個用例，用例驅動概念設計，並最終進行編碼，每一個用例都有明確的執行者，前置條件，可選流程與輸出物）。
當我們按照MECE原則拆分到一個可供監控且有意義的顆粒度，如對訂單中心推送新訂單訊息至門店前臺系統失敗，此業務只是訂單履約中的一個節點，當此異常出現時，系統即自動標記異常，不用等待系統定時的比對發現異常。
當然，從另一個角度來說，我們也可以將異常感知的方式區分為這麼兩種：
- 業務進行中出現異常，系統自動標記。
- 監控系統使用者主動發起異常校驗或系統根據預設的規則定時比對發現異常。
三、如何處理
當系統識別到異常時，應當如何處理呢，我們一般有兩種方式：
1. 系統自動處理
如從外賣平臺拉取訂單時，資料缺失，系統可以做自動重試機制。
使用系統自動處理機制一般比較慎重，僅使用在可以依靠重新嘗試拉取可以解除異常的場景下，一般不做複雜的異常解除邏輯的自動化，如訂單長時間未備貨，此時如果系統自動備貨，可能會造成系統無法反映真實作業情況的問題，具體可以看這篇文章，來理解為什麼要慎用系統自動邏輯《1-2年產品經理：教你接盤與重構的姿勢》。
2. 人工介入處理
仍以外賣平臺拉取訂單時資料異常的例子來說，當系統自動重試次數達到上線後，為減輕系統壓力，不影響其他正常單據的處理，往往會停止自動重試，此時應允許人工介入處理。在設計人工處理異常資料時，應注意：
- 在對應異常單據中標註異常原因並提示解除異常的方法。
- 人工處理異常後，由於可能涉及到單據中資料的修改，必須提供日誌功能，記錄修改前的資料，修改後的資料以及修改的時間，修改人。
- 嚴格控制權限，因為可能要進行業務資料的修改，一般僅允許總部或區域運營進行修改。
當然還要注意一點，有一種非常特殊的異常，即系統根據預設的規則對訂單進行加工，但是由於規則預設錯誤，導致實際加工後的訂單資料也錯誤，如在系統中預設規則，購買A商品1份，實際應發貨B商品12份，但是客戶運營在設定規則時，設定成：買A商品1份，實際應發貨B商品120份。
此時系統不會對此單據標記異常，但是確實不符合實際，此時人工介入處理時，應允許人工標記訂單異常後再進行資料修正。
仍然是上面的例子，由於預設規則的錯誤，導致揀貨商品數量錯誤，進而導致揀貨商品的單價等都計算錯誤。此時應只允許修改揀貨商品的數量，而不應允許修改揀貨商品的單價，揀貨商品的單價應由系統進行計算。即規則是：只改異常直接導致錯誤的欄位值，而不改間接導致錯誤的欄位值。
四、如何提醒
上面說到，有一些異常是需要人工介入處理的，那麼異常監控相關的提醒方式一般有哪些呢，我給大家簡單介紹一下當前我們使用的方式：
五、業務的截停與恢復
當一個業務發生異常，可能導致後續動作無法開展時，需要截停業務。如訂單資料缺失，可能造成ERP系統無法正常生成憑證，此時就應該截停通知ERP系統生成憑證的動作，等待異常解除後再恢復此動作。
對於SaaS系統來講，傳遞給其他系統的資料應儘量保證正確，如果多個系統中都有此異常資料，那麼異常資料的修正就麻煩多了。這就是異常監控功能設計中必須要要考慮的如何儘可能的降低異常影響的範圍。
六、資料分析
一個健康的產品，功能體系設計一定是閉環的，當我們識別出異常後，需要對異常情況進行評估分析，以不斷提高業務水平。發現一個問題就解決一個問題，在一個專案上發現一個問題，就只處理這個專案上發現的問題，是SaaS產品運營過程中不可取的。
我們一般需要進行資料的分析，達到以下目的：
- 反應系統執行情況：展示該問題出現的次數，比例和趨勢，作為產品的健康度的考核指標，並作為績效考核指標對相關人員進行考核。
- 發現現有問題：產品功能設計是否有缺陷，使用者操作是否有問題，是否需要產品功能最佳化，是否需要進行操作人員的培訓考核等，進行針對性的改進。
如對門店揀貨超時這種異常情況進行分析，我們可以分析各個門店，各個區域的揀貨率（揀貨成功的訂單/所有訂單），揀貨超時率（揀貨超時的訂單/所有訂單）。
如揀貨超時率一直很高，我們就要調研以下揀貨超時率高的原因，是訂單太多確實沒法及時完成所有訂單的揀貨，還是門店人員不願意或忘記點選確認揀貨呢，如是第一個原因，那可以考慮多人同時揀貨或揀貨路徑規劃的功能了，如果是第二個原因，那可以考慮是否最佳化系統的操作體驗。
七、總結
異常監控功能的設計對於新手產品經理來說是有些難度的，因為要回答監控什麼，怎麼監控的問題，依賴於對業務實現邏輯的清晰理解，也依賴於對運營人員處理問題過程中痛點的準確把握，故建議多諮詢開發與一線的運營人員，做好需求調研和方案確認的工作，確保產品設計確實可以解決問題。
八、附錄
給大家一個我整理的異常監控管理需求梳理的表格，供大家參考：
本文由 @kathic 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議
