題幹與適用場景
這是面向平台、雲端基礎設施和嵌入式系統職位的系統設計題。裝置可能長期離線、儲存有限、網路昂貴，錯誤韌體會讓整批裝置失聯。平台必須確保只有相容裝置能安裝已簽章套件，發布可以暫停，裝置可恢復或回到上一版本。
預設一百萬台裝置、每天最多十萬台並發下載；更新套件 20 MiB；裝置按型號、硬體修訂、地區和目前版本分組。題目不要求選定 AWS，雲端服務只是幫助說明狀態和控制面邊界。
面試官考察點
- 是否把套件完整性、來源認證、裝置授權和相容性檢查分開。
- 是否設計控制面與裝置資料面的狀態機，而非只畫一個檔案下載桶。
- 能否計算頻寬、並發和失敗門檻，並說明暫停、重試、回復與人工介入條件。
強回答會把「發布成功」定義為裝置驗證、安裝、重新啟動和健康回報，而不是 CDN 下載完成。
回答前需要釐清的問題
- 裝置能否雙分割區啟動？ 雙分割區允許先寫非作用中槽並在啟動失敗時回復；單分割區需要更保守的引導程式和現場恢復路徑。
- 更新是否有安全或監管區域限制？ 目標篩選必須包含型號、硬體版本、地區、憑證狀態和目前版本，不能只用裝置標籤。
- 裝置多久必須更新？ 期限決定批次大小、維護時段、離線裝置重試和是否允許強制安裝。
- 失敗是裝置級還是批次級？ 裝置失敗可重試；同一韌體在某型號的失敗率升高應暫停該分組，而不是繼續全域擴量。
30 秒回答框架
「我把平台拆成簽章套件倉庫、發布控制面、裝置代理和遙測回報。發布前產生帶型號、硬體、版本、依賴和過期時間的 manifest，離線簽章並讓裝置在安裝前驗證簽章、摘要和相容條件。控制面按目標分組做 canary、固定或指數速率 rollout，保存每台裝置的狀態和冪等 job ID；裝置下載支援分塊斷點續傳，寫入非作用中分割區，重新啟動後健康檢查成功才提交。失敗率、下載錯誤、啟動回復或安全告警超過門檻就暫停並保留舊版本。離線裝置按維護時段重試，所有動作進入稽核與回放日誌。」
分步驟深入解答
第一步：計算主要瓶頸。
若一百萬台裝置都下載 20 MiB，總量約 20 TiB。每天完成十萬台代表平均約 2 TiB/日，約 23.7 MiB/s；峰值還要乘以並發和重試餘量。物件儲存和 CDN 承擔套件分發，控制面只傳送 manifest 和短期下載授權，不能讓裝置輪詢大型資料庫。
第二步：建立不可偽造的套件與 manifest。
建置流程產生不可變套件、摘要和 manifest。簽章金鑰放在受控簽章服務，發布記錄保存簽章版本和審批。裝置內建信任根，驗證簽章、套件摘要、目標型號、最低 bootloader、版本防回復計數和過期時間；下載網址本身不是信任邊界。
第三步：分離控制面和資料面。
控制面建立發布、目標查詢、批次、裝置 job 和暫停命令；裝置資料面從 CDN 分塊下載並向 job 端點回報狀態。每台裝置以 (deviceid, jobid) 冪等更新，重複回報不推進錯誤狀態。狀態至少包括 QUEUED、DOWNLOADING、VERIFIED、INSTALLING、SUCCEEDED、FAILED、ROLLED_BACK 和 REJECTED。
第四步：設計安全安裝與回復。
裝置先把套件寫入非作用中槽，逐塊校驗摘要，完成後驗證 manifest，再切換啟動槽。引導程式記錄嘗試次數和啟動確認；應用在健康檢查、關鍵感測器和通訊恢復後提交確認。連續失敗回復舊槽，並把原因和啟動計數上傳。單分割區裝置需要恢復映像或現場維護，不能假設相同的原子切換。
第五步：控制 rollout。
先在內部裝置和小型 canary 組發布，再按型號和地區逐步擴大。速率可以固定或指數成長，但每一組都設定最大並發、維護時段和 abort 條件。失敗門檻按裝置群組計算，區分下載失敗、簽章拒絕、安裝失敗、啟動回復和健康檢查逾時。
第六步：處理離線、重試與稽核。
裝置上線後領取尚未過期的 job；下載使用斷點續傳和指數退避，重試必須重用同一 job 與套件版本。超過 deadline 的裝置進入待處理清單，不直接標記成功。控制面保留發布審批、manifest、目標快照、狀態轉移、操作者和暫停原因，支援回放和合規追溯。
高品質示範回答
「我會先拆出控制面、套件倉庫/CDN、裝置代理和遙測系統。發布流程產生不可變套件和 manifest，manifest 寫明目標型號、硬體修訂、最低 bootloader、版本計數和摘要，由離線或受控簽章服務簽章；裝置用內建信任根驗證，下載 URL 只負責傳輸。
假設一百萬台裝置、20 MiB 套件、每天完成十萬台，套件總量約 20 TiB，因此 CDN 承擔分發，控制面只保存發布和每台裝置的 job 狀態。裝置分塊下載到非作用中槽，完成摘要驗證和重新啟動健康檢查後才提交；失敗就回復並回報原因。發布先走 canary，再按型號和地區逐步加速。對每組設定並發、失敗率和回復率門檻，超過就暫停，不自動把壞套件擴散。離線裝置在維護時段領取同一 job，重試可恢復，所有狀態、審批和版本都可稽核。」
常見錯誤
- 錯誤表現：只校驗 HTTPS → 失敗原因：傳輸安全不證明套件來源和內容未被替換 → 修正方法：裝置驗證 manifest 簽章和套件摘要。
- 錯誤表現：下載完成就標記成功 → 失敗原因：安裝、啟動和健康檢查可能失敗 → 修正方法：把成功定義為啟動確認後的終態。
- 錯誤表現：全量同時發布 → 失敗原因：一個相容性錯誤會影響整個裝置群 → 修正方法：canary、分組、速率和 abort 條件。
- 錯誤表現：每次重試建立新任務 → 失敗原因：狀態重複、稽核斷裂且無法恢復 → 修正方法：重用
(deviceid, jobid)冪等狀態。 - 錯誤表現：允許任意版本回復 → 失敗原因：攻擊者可能誘導裝置安裝舊漏洞版本 → 修正方法：簽章版本計數、防回復策略和受控回復清單。
追問及應對
追問一：發布到 2% 時某型號啟動回復率達到 4%，怎麼辦？
立即暫停該型號和同一套件版本的後續 rollout，保留已成功裝置的監控。按硬體修訂、bootloader、地區和套件建置切片，確認是否為單一相容組合；必要時發布已驗證的舊版本或恢復命令。不要因全域平均失敗率低就繼續擴量。
追問二：裝置下載到 80% 後斷電，如何保證下次不會重頭開始？
分塊寫入非作用中槽，並保存套件版本、塊摘要、已確認偏移和整體 manifest 摘要。重新啟動後裝置驗證本地區塊和 manifest，再從最後連續可信區塊請求範圍下載。若套件版本或簽章變化，丟棄舊暫存槽，避免把兩個版本拼在一起。
追問三：如何防止攻擊者把合法舊套件重新推送？
manifest 包含單調版本計數或安全版本號，裝置持久化已接受的最高值；引導程式拒絕低於策略的套件。緊急回復必須由受控簽章、明確裝置群組和時限授權完成，並把例外寫入稽核，不能讓普通下載介面繞過防回復。