你全量發佈了一個新版本應用，怎麼在商戶的大面積投訴之前，率先發現閃退趨勢呢？ 如果商戶投訴設備運行緩慢，你怎麼分析性能瓶頸呢？坐高鐵到現場嗎？ ...
鄭昀 創建於2017/10/29
關鍵詞：設備，遠程管理，安全桌面，應用商店，遠程式控制制，同屏映射，調用鏈分析，異常上報，卡頓上報
如果你要管理橫跨 80 城的數以萬計台商用設備，你會怎麼做？
怎麼保證設備不被濫用，比如看視頻，打游戲？
怎麼保證應用能快速分發？怎麼做到幾分鐘之內大江南北都打了補丁？
某商戶投訴新版本應用出現閃退，你做了一個測試版本，怎麼投放到指定設備上運行並收集日誌呢？
你全量發佈了一個新版本應用，怎麼在商戶的大面積投訴之前，率先發現閃退趨勢呢？
如果商戶投訴設備運行緩慢，你怎麼分析性能瓶頸呢？坐高鐵到現場嗎？
唯一的出路
唯一的出路就是這些設備接受雲端系統的嚴格管控。
太空橋（SpaceBridge） 就是這樣一款設備運維管理平臺。
為什麼叫太空橋？
太空橋是變形金剛里一種連通遙遠區域的瞬時通道，以供塞伯坦人通行其間。這一計劃是以在各個世界間通行為最終目的。
智慧設備
太空橋（含太空橋Agent，太空橋移動客戶端）充分體現了我們技術團隊一直以來奉行的哲學：
● Dont make me think：減少無謂的猜測和思索，用不會出錯的機器智能來替代人工；
● 日拱一卒，功不唐捐：構建一套體系就可以一勞永逸，掌管現在和未來所有的設備、數據和客戶。
我們所有未來的設備，都必須是智慧設備。
何謂智慧設備？接受我太空橋統一管理，能做安全桌面，遠程式控制制，應用商店（應用分發），應用黑白名單，增量更新，熱修複，灰度發佈，性能監控，異常和卡頓上報，調用鏈分析等等。如果做不到這些，就不應該拿這種無法遠程管理的設備給我們這些最終兜底的技術團隊挖坑埋雷，因為我們不希望到全國80城出差做技術支持。
如何接受太空橋管理呢？
首先需要註冊。
也就是把設備 SN 號和 GUID 號在雲端報備。
可以由人掃碼來報備。設備上會預設安裝我們的太空橋 Agent，它預設界面上會展示一個二維碼。項目實施工程師持太空橋 App 掃碼，則將該設備報備到雲端，與某個商戶下的某個門店綁定。
其次設備連接雲端首次發送心跳，就算是設備激活了。
由於保持了心跳，所以雲端能知道設備是離線、線上還是關機。如下圖所示，我們能準實時觀測到不同管理區有多少台設備，分別處於什麼狀態，查看各項性能指標，如系統可用記憶體，CPU使用率，SD卡大小等。
圖1 首頁-設備監控大圖
如何保證設備不被濫用呢？
在下雙屏一體機（就是一臺安卓設備）的初期，收到過設備越來越慢的投訴，調查發現，設備上被安裝了優酷等視頻和游戲 App，難怪速度越來越慢。
所以之後新設備發貨時燒的ROM就是我們定製的ROM，沒有我們簽名的應用是會被自動攔截，無法安裝的。我們還隨系統下發了安全桌面，限定桌面上只出現我們的應用。
圖2 應用商店-太空橋安全桌面
應用如何分發呢？
太空橋實現了一個應用商店，管理 App 以及它們的版本，如下圖所示。凡是要部署到智慧設備上的應用，都要通過太空橋應用商店來分發。
應用商店這個概念大家都很熟悉。
創建了應用之後，就要管理版本了。首先上傳包文件，填寫版本描述，選擇支持的設備型號（應用不一定能分發到各種安卓設備上）。其次系統會自動從包文件里讀出版本號。
圖4 版本管理-更新管理
有了版本，就要針對版本設置版本策略了。
什麼是版本策略？你是要全量發佈，還是灰度發佈？它倆的區別如下圖所示：
圖5 設置策略
目前灰度發佈允許兩種範圍：
-
按設備：選擇具體的一批設備；
-
按餐飲中心：選擇具體的一批餐飲中心，整個餐飲中心的設備都會更新版本；
發佈到設備是最小粒度。這樣就可以做到，某個檔口投訴新版本有閃退，我們給他單獨提供一個測試版本來排查問題。
如何對設備遠程式控制制？
目前設備層級的遠程式控制制僅支持重啟和關機，還將支持一些關鍵特性，比如同屏映射，即設備和太空橋頁面操作上的同步顯示，比如設備的目錄瀏覽和文件讀取，日誌文件還是要說拿就拿的。
設備上的應用層級則支持卸載、打開和關閉。當然 agent 和安全桌面是禁止卸載的。
如何發現異常呢？
餐飲中心如果投訴“檔口 A 剛纔從點餐界面切到已售情況會卡一下，最近偶爾會遇到幾次”、“檔口 B 反饋點菜單切換卡了五六秒”、“檔口 C反饋點擊列印餐櫃密碼，App 退出了”。
這種投訴遠程協助的話，跟進很難。第一，它可能不易重現，比如與當時的網路環境卡有關。第二，不定是哪兒出的問題，日誌不一定打點了。
這時候就需要所有的應用都引入我們的性能 SDK，主動上報卡頓（對於安卓來說就是ANR（Application Not Response）了）、異常、崩潰了。
圖9 異常上報-崩潰分析
我們可以看一下上圖中的空指針異常，能看到這種異常分佈在哪幾個版本里，影響了多少個客戶。
圖10 崩潰分析-異常詳情1
所有上報的設備的信息也能看到：
圖11 崩潰分析-異常詳情2
當然必不可少的是堆棧信息：
圖12 崩潰分析-異常詳情3
甚至可以看到崩潰那一刻的記憶體大小、存儲空間大小、安卓系統版本號：
圖13 崩潰分析-異常詳情4
總的來說還是非常便於發現問題和排查問題的。
如何主動診斷異常呢？
現在正在做的是：
網路請求分析。主要是圍繞著設備上應用的 HTTP 請求做分析，DNS 解析時間，遠端響應時間，數據傳輸時間等等。別人說應用慢，你好歹讓 ISV 知道慢在哪一段。
調用鏈分析。當系統出現問題時，我們可以迅速切入設備，調用鏈可視化，從而便於排查問題出在網路操作、文件讀寫還是什麼函數上，指導 ISV 解決問題。
總結
總的來說，太空橋是一個非常優秀的設備運維管理平臺，已經能很好地管控智慧設備了，太空橋的開發者們都非常厲害，在非常短的時間內攻剋了一個又一個技術難點，大踏步挺進這個我們以往未曾涉足過的領域。
-EOF-
語錄1枚：
公司大了，久攻不下的堡壘，確實需要來一次三板斧共創，跨團隊組成戰隊，互相PK，高壓態勢下激蕩心力腦力體力，最終逼出落地方案。
