當您的設備組有 20 臺設備時，開發(fā)人員可以簡單地查看日志并手動搜索常見問題，或者快速構建一些簡單的 Python 腳本來解析數(shù)據(jù)以確定原因。但是當艦隊規(guī)模擴大到數(shù)千或數(shù)百萬時，Command-F 搜索和簡單的腳本無法捕獲所有錯誤——而且它們肯定不會出現(xiàn)新問題。

鑒于消費者對物聯(lián)網(wǎng)設備的需求不斷增加以及跨平臺連接性的增加，錯誤的可能性和頻率——無論是常見的還是不常見的——都在加速。正如供應商不能再發(fā)布期望不再與他們交互的產品一樣，固件工程師必須適應不斷變化的需求和不斷改進的設備功能的復雜性。制定構建、監(jiān)控和更新的計劃對于現(xiàn)代設備開發(fā)至關重要。

預測錯誤并在構建時牢記它們

不幸的是，無法預測每個最終用戶使用您的設備的輸入和操作環(huán)境。因此，與其采用被動式的開發(fā)方法，即在發(fā)布日在 Reddit 上被惱怒的用戶首先注意到問題，您應該采取積極主動的開發(fā)立場。作為常規(guī)設備管理的一部分，具有前瞻性的開發(fā)特權通過內置的未來修復和更新將產品推出市場，包括：

確?？梢灾刂脼榻^對出廠條件的設備可以恢復到舊固件或建立最小固件路徑

當車隊范圍的趨勢表明正確的方向時評估設備診斷趨勢和運輸更新，而不是需要一定天數(shù)的測試或浸泡時間

遵循第 0 天工作流程，將固件凍結在最低限度狀態(tài)并交付產品，期望您在交付后不斷改進算法并更新設備

監(jiān)控以減輕潛在問題

長期以來，設備制造商一直依賴最終用戶有效地充當產品測試人員，等待受影響的客戶向客服報告問題。但社交媒體渠道和高客戶期望的結合使這種方法不合時宜且具有風險。最終用戶不只是想要“足夠好”的產品——他們希望設備能夠提供獨特、高效和方便的功能；與其他設備和應用程序的無縫集成；安全; 和定期更新，所有這些都沒有中斷。當這些期望沒有得到滿足時，他們經常準備讓每個人都知道。

設備監(jiān)控對于滿足這些需求和確保整個設備的健康狀況至關重要。部署一個系統(tǒng)來監(jiān)控事件、它們發(fā)生的次數(shù)以及它們在設備中觸發(fā)的操作（崩潰、重置或觸發(fā)斷言）。捕獲關鍵指標，例如：

電池壽命因系統(tǒng)變化或事件而下降

秒藍牙芯片開啟

藍牙斷開次數(shù)

CPU 處于活動狀態(tài)的滴答聲或秒數(shù)

設備在一小時內連接到藍牙的時間

有了監(jiān)控系統(tǒng)，就可以及早發(fā)現(xiàn)（并修復）問題，而且通常完全不會影響最終用戶的體驗。

采用分階段推出方法來緩解潛在問題

分階段推出（逐步向所有設備提供版本）提供了更好的控制和可觀察性，從而降低了風險敞口。分階段推出允許開發(fā)人員限制版本更新和補丁中意外錯誤的影響，同時捕獲用于分類和修復的最新指標。

在最簡單的層面上，分階段推出可以包括供應商的員工及其愿意作為初始測試受眾的聯(lián)系。除了使用朋友和家人方法進行測試之外，設備制造商還可以選擇一定比例的最終用戶，他們的設備可以被監(jiān)控以評估潛在問題。

或者，開發(fā)人員可以通過定時監(jiān)控設備來實現(xiàn)不太正式的分階段部署版本。當設備以預定的時間間隔調用時，開發(fā)人員可以在特定時間段內推送 OTA 有效負載，并監(jiān)控在簽入期間收到更新的設備。

盡管設備電源、間歇性連接和資源有限等諸多限制因素，設備開發(fā)人員都在推動創(chuàng)新。通過采用預測問題的主動開發(fā)方法，開發(fā)人員可以減輕硬件開發(fā)的額外復雜性，并傾向于動態(tài)和迭代過程，從而產生更好、更強大的產品，并隨著時間的推移而改進。

審核編輯：郭婷