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

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

預(yù)測錯誤并在構(gòu)建時牢記它們

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

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

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

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

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

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

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

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

秒藍(lán)牙芯片開啟

藍(lán)牙斷開次數(shù)

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

設(shè)備在一小時內(nèi)連接到藍(lán)牙的時間

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

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

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

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

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

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

審核編輯：郭婷