移動天網(wǎng)平臺搭建
部門：業(yè)務(wù)技術(shù)/零售移動組
一、背景
在快速迭代的業(yè)務(wù)需求下，難免會出現(xiàn)一些線上 bug ，特別是在 SaaS 業(yè)務(wù)領(lǐng)域，線上 bug 對于商家來說大概率會影響經(jīng)營，嚴重的話很可能引發(fā)故障。所以，我們對線上質(zhì)量要求很高。針對線上 bug ，除了商家主動上報問題，后端還有自己的天網(wǎng)監(jiān)控體系，進行主動發(fā)現(xiàn)問題，那移動端如何進行主動防控呢？所以我們也需要自己的主動防控平臺。
為什么不可以直接使用后端的天網(wǎng)系統(tǒng)？
需求功能對比
從功能來看，后端的天網(wǎng)更像一個線上接口日志存儲，結(jié)合監(jiān)控配置能力進行預(yù)警處理。經(jīng)過分析，后端天網(wǎng)無法滿足移動端的使用場景。
核心價值
提高客戶端線上質(zhì)量，減少線上問題，主動發(fā)現(xiàn)與預(yù)防線上問題，及時報警與處理，降低線上問題的影響面。做到防患于未然。
二、整體設(shè)計
根據(jù)以上背景，可以得知，移動端天網(wǎng)平臺相對于后端天網(wǎng)平臺更復(fù)雜，涉及的技術(shù)點也比較多，主要有客戶端、 PC 后臺管理（下面內(nèi)容簡稱 mpaas ）、后端服務(wù)、數(shù)據(jù)存儲等。
系統(tǒng)架構(gòu)圖
整體流程是可以區(qū)分兩部分，一部分為日志上報流程，數(shù)據(jù)來源是業(yè)務(wù)方客戶端，另一部分為日志操作流程，操作方是 mpaas 后臺。這兩者的區(qū)別，主要是一個是數(shù)據(jù)的來源方，另一個是數(shù)據(jù)的使用方。
日志上報流程
客戶端上處理流程相對來說沒有那么復(fù)雜，主要就是數(shù)據(jù)的采集與上報。其中核心邏輯都在業(yè)務(wù)服務(wù)中進行，比如日志內(nèi)容整合，觸發(fā)通知邏輯等。
日志操作流程
mpaas 平臺，是整個處理和報警的核心。提供問題查看、分配人員、狀態(tài)變更、問題備注、通知策略等功能。
后端天網(wǎng)系統(tǒng)（ skyLog ）
為什么我們自己做了數(shù)據(jù)存儲以及移動天網(wǎng)平臺，為什么還會依賴 skyLog 呢？
主要原因是，我們天網(wǎng)上報數(shù)據(jù)是區(qū)分等級，存在 info 、warning 、error 三個等級，對應(yīng)上報問題等級不同，通知策略與處理流程也會有區(qū)別，但都是需要記錄到 skyLog 日志平臺上，類似打 log 日志。目前 info 級別的數(shù)據(jù)是不會存儲到移動天網(wǎng)服務(wù)中，因為打日志內(nèi)容不在報警范圍內(nèi)，所以查詢打的日志內(nèi)容就需要到 skyLog 平臺上查詢。具體兩者區(qū)別參考前面第一部分背景介紹。
企業(yè)微信服務(wù)
公司內(nèi)部使用企業(yè)微信，針對企業(yè)微信可以自定義消息通知以及群機器人功能，可以使用企微提供的公開接口進行調(diào)用，很方便的實現(xiàn)通知報警能力，可針對不同業(yè)務(wù)場景，定制不同消息通知。針對本平臺，當觸發(fā)報警，比如 error 級別問題上報（后面會有具體通知策略分析），則會通過消息給負責(zé)人推送系統(tǒng)消息，以及群機器人觸發(fā)報警。
例：零售移動天網(wǎng)報警群機器人
具體使用參考企業(yè)微信官網(wǎng) api：https://work.weixin.qq.com/api/doc/90000/90135/90235
三、日志采集和上報
目前該平臺對接的業(yè)務(wù)方，主要是針對的是公司各業(yè)務(wù)團隊的移動端業(yè)務(wù)，日志的上報基礎(chǔ)能力集中 Zanlogger 日志二方庫。同時基于目前混合開發(fā)的現(xiàn)狀，開發(fā)了 ZanlogWeex 和 ZanlogFlutterPlugin 來實現(xiàn) Flutter 和 Weex 頁面的日志需求。
1、日志信息采集
首先看下日志內(nèi)容的組成：
其中，基礎(chǔ)信息由 Zanlogger 自主收集，業(yè)務(wù)方使用的時候，只需關(guān)注相關(guān)業(yè)務(wù)信息。
//天網(wǎng)日志上報
Log.sky("info", "sale", "startPay", "goods is xxxxx")
Log.sky("warn", "sale", "changePriceFailed", "goods is xxxxx")
Log.sky("error", "sale", "db can not open", "error:xxxx")設(shè)備型號，系統(tǒng) os 版本，應(yīng)用版本，用戶 id ，店鋪 id 等基礎(chǔ)信息，在同個設(shè)備的大部分時間段內(nèi)，都是相同的?？紤]到流量和效率問題，沒必要每條日志都上傳。
Zanlogger 的實現(xiàn)方式是，應(yīng)用啟動時，獲取設(shè)備唯一標識，上傳一次基礎(chǔ)信息。業(yè)務(wù)日志上報時，只需上傳設(shè)備唯一標識。后端服務(wù)收到消息時，通過唯一標識獲取基礎(chǔ)信息，組合成完整的日志。
2、按級別策略上報
移動天網(wǎng)平臺支持 error，warning，info 三種級別的日志上報，針對不同級別的上報信息，觸發(fā)接口上報的時機也不同。
error : 最高等級問題，如果發(fā)生，則會引發(fā)線上 bug ，客戶端會立即上報。
warning : 該級別我們定義為警告，針對一些業(yè)務(wù)場景，可能是異?；蚱渌到y(tǒng)錯誤，發(fā)生并不一定是線上 bug ，然而當短時間內(nèi)發(fā)生次數(shù)過多，則可能演變成線上 bug，所以該問題不會立即上報，而是存在一定 buffer ，當發(fā)生次數(shù)到達 buffer 量級后客戶端進行上報。
info : 低等級問題。該級別我們認為是基礎(chǔ)日志信息，并不認為是問題，基本是業(yè)務(wù)人員進行埋點數(shù)據(jù)進行線上邏輯排查與跟蹤使用，客戶端上報策略和 warning 類似，也存在 buffer ，達到量級后進行上報。該級不會進行通知，相關(guān)人員自行去天網(wǎng)日志平臺中查詢信息。
為了擔心數(shù)據(jù)量太小，buffer 一直未達到上報的條件，或者網(wǎng)絡(luò)原因，但是一直上傳失敗，同時會設(shè)置指定時間（例如 30s ）的輪詢機制，一旦發(fā)現(xiàn)有未上傳的日志，立即上報。
四、日志存儲和報警設(shè)計
1、日志存儲
實際場景中，日志的上報頻率，和日志的內(nèi)容大小是不確定的，基于性能考慮，后端的數(shù)據(jù)存儲流程如下：
原因是，相較于 RDS ，HBase 更適合適合大數(shù)量的存儲，于是日志完整內(nèi)容存放在 HBase，兩者通過每條日志存儲時，生成的 uuid 關(guān)聯(lián)。日志的頻繁上報，使用 kafka ，保證峰值處理能力。
存儲位置的問題解決后，接下來思考的是日志該以什么維度進行分組？
移動日志的解決方案是聚合 biz + sign + type + level + os ，取其 hashcode 。
這里為什么會將系統(tǒng) os 作為分組因子呢？這里的原因是，基于現(xiàn)有場景分析，存在 pad 和 phone 同一個 sign 的報警，大概率是不同的代碼流程導(dǎo)致的，應(yīng)該視為不同問題去排查和分析。
2、報警策略設(shè)計
當 error 日志上報后，后端會通過企業(yè)微信服務(wù)，向指定的群發(fā)送消息，并且 @指定的人，影響范圍大的問題甚至需要 @所有人。信息論中有個定律：“信息量越大，信息熵越小”，所以為了保證群消息的關(guān)注度，在保證關(guān)鍵信息觸達的前提下，對群內(nèi)成員減少不必要的打擾。
因此不是所有信息都需要發(fā)送到群消息，比較建議群通知的場景如下：
新問題出現(xiàn)。
已解決問題新版本再次出現(xiàn)。
閾值范圍報警。
以上是我們提供的默認配置，也支持讓業(yè)務(wù)方自定義。下一章節(jié)中會講到相關(guān)自定義配置功能。
報警策略流程中需要用到以下概念：
問題狀態(tài)：上報問題處理的狀態(tài)，分為待處理、處理中、待發(fā)版、已上線。
問題解決版本：當問題狀態(tài)變更到待發(fā)版或已上線時，需要填寫解決版本號，比如 6.5.0 ，代表該問題在該版本已解決。
完整的報警策略流程如下：
五、移動天網(wǎng)平臺可視化介紹
該平臺的核心功能就是對于上報問題的報警通知能力與處理能力，以及相關(guān)報警配置策略。這里對于客戶端的上報相關(guān)沒有什么可講的，相關(guān)的數(shù)據(jù)上報策略前面也有講。這里主要針對 mpaas 平臺進行功能與策略介紹。
1、問題查看
問題列表頁面：
問題列表主要展示上報的所有問題，上報時相同的問題會進行聚合，列表中每一條數(shù)據(jù)，代表相同一類問題。同時支持多種篩選條件進行快速查找。
業(yè)務(wù)：針對不同客戶端的業(yè)務(wù)方
平臺：iOS、Android、PC 等
版本：上報問題的 app 版本信息
類型：各業(yè)務(wù)方定義自己的問題分類 type ，比如零售定義為業(yè)務(wù)模塊
sign：上報問題的 key ，用來標識問題名稱
等級：前面也有講到，分為三個等級，error、warning、info
時間：進行時間段篩選
處理狀態(tài)：用于篩選具體問題狀態(tài)，多選
處理人：問題相關(guān)處理人
關(guān)聯(lián)問題文檔：用來快速篩選出帶有關(guān)聯(lián)問題鏈接的問題
問題詳情頁面：
針對每一類問題，點擊詳情進行查看上報的具體信息。詳情中，會包含該類問題的所有上報信息，每次上報問題都可以查看具體上報內(nèi)容信息，然后進行問題分析。
拉取設(shè)備離線日志：可以快速拉取上報問題設(shè)備的本地離線日志
操作記錄：記錄該問題的操作情況，以及該問題解決過程中的備注
2、問題處理
當問題上報上來時，會默認進行分配給上一次處理該問題的人員，如果是新問題則會分配給對應(yīng)業(yè)務(wù) owner 進行處理。當問題在解決時，需要對問題人員及狀態(tài)等進行變更。
針對問題處理的操作，主要有狀態(tài)、人員、備注信息。如果狀態(tài)為待發(fā)版或者已上線，則需要填寫修復(fù)版本，用來保證該問題在低版本的誤報情況，如果問題存在問題鏈接，則需要填寫關(guān)聯(lián)問題文檔，方便后續(xù)查看與統(tǒng)計使用。
狀態(tài)：分為四個狀態(tài)，待處理、處理中、待發(fā)版、已上線
處理人：根據(jù)公司內(nèi)部員工信息，對應(yīng)到內(nèi)部人員信息
備注：操作該問題時，需要填寫備注信息，以便后者人員進行查看
修復(fù)版本：該問題的解決版本，當狀態(tài)為待發(fā)版或已上線時需要填寫
問題文檔：該問題關(guān)聯(lián)的問題鏈接，非必填
2h 內(nèi)免打擾：當有人在處理時，為了專心解決問題，可以設(shè)置 2h 免打擾
3、報警策略相關(guān)配置
前面有講到，報警能力主要依賴企業(yè)微信進行通知到相關(guān)的人和群。實現(xiàn)自定義報警策略，那就需要相關(guān)策略配置功能頁面。
3.1 配置后臺頁面
報警策略列表頁面：
報警策略配置頁面：
配置頁面可以根據(jù)業(yè)務(wù)方需求，自行添加應(yīng)用配置策略，可根據(jù) error 和 warning 級別分別設(shè)置配置策略信息。在問題上報后，會根據(jù)不用業(yè)務(wù)方應(yīng)用（ biz ）進行識別，采用對應(yīng)的配置信息進行報警。
3.2 通知模板
通知模板主要分為三類，個人及群消息通知，日報和周報。
問題消息通知
日報和周報
個人及群消息通知，主要是針對新問題及操作變更時進行通知。日報和周報更多的是關(guān)注統(tǒng)計相關(guān)的數(shù)據(jù)，針對上報問題日報情況，可以看出當日問題的處理情況，周報數(shù)量統(tǒng)計，可以看出本周的概要情況。
四、總結(jié)
對于移動端來說，線上問題的發(fā)生是比較嚴重的問題，特別是在零售這種線下場景，很可能一個問題會給商家?guī)碣Y損的問題，所以對于移動端的質(zhì)量問題要有高標準。除了開發(fā)階段的 code review 和自測，測試階段的自動化測試和人工測試，我們?nèi)绾沃鲃颖O(jiān)控線上問題的發(fā)生就成了關(guān)鍵，移動天網(wǎng)平臺的搭建就是解決線上主動監(jiān)控的空缺。
目前移動天網(wǎng)平臺在線上已經(jīng)跑了近半年時間，其中有效幫助移動端主動發(fā)現(xiàn)線上問題數(shù)量占比已經(jīng)達到 20% 。對于主動發(fā)現(xiàn)的問題，我們快速響應(yīng)進行解決，目前主動發(fā)現(xiàn)的問題商家沒有再進行上報。這對于商家和服務(wù)同學(xué)，以及開發(fā)都是一種效率和質(zhì)量的提升。