題干與適用場景
一個多發行版 Linux fleet 想透過 OpenTelemetry 打包倉庫安裝 Injector、自動插樁套件和 Collector，以減少人工部署。官方說明該打包工作仍在早期，倉庫不是生產級託管方案，軟體包尚未簽名。請設計從實驗到生產的安全邊界、驗證、權限和回滾。
面試官考察點
面試官考察你是否能把「安裝方便」與「供應鏈可信」分開，識別腳本權限、包來源、自動注入副作用、網路出口和版本回滾風險。高品質回答會說明哪些環境可以試用、哪些環境必須等待成熟，並給出證據和護欄。
回答前需要釐清的問題
- 目標主機發行版、架構、代理和升級策略是什麼？
- 安裝的是 Collector、Injector、語言套件，還是全部元件？
- 主機是否允許新增 systemd 服務、eBPF 權限和外連端點？
- 組織的軟體簽名、映像代理、SBOM 和回滾要求是什麼？
30 秒回答
「我不會把早期倉庫的一鍵腳本直接放進生產。先在隔離主機驗證包內容、來源、雜湊、權限、systemd 單元、網路出口和卸載路徑；未簽名包只能用於短期實驗，不能繞過組織供應鏈門檻。生產候選必須經過內部鏡像、簽名驗證、最小權限和可回滾版本管理。灰度從非關鍵主機開始，觀察 CPU、記憶體、網路、進程啟動、資料洩漏和卸載成功率，護欄失敗就停止擴展。」
分步驟深入解答
1. 劃定試用邊界
把官方倉庫標為實驗源，不把「可用命令」當作生產批准。選擇可重建、無敏感資料的主機，禁止在核心資料庫、跳板機和高權限控制節點直接運行。
2. 做供應鏈驗證
鎖定倉庫提交、包版本和依賴清單，校驗下載地址、雜湊、構建來源、SBOM 和簽名狀態。未簽名包必須經過內部審核和隔離代理；不得使用腳本中的 trusted 或跳過校驗選項來解決安裝失敗。
3. 檢查權限與副作用
審閱安裝腳本、systemd unit、檔案路徑、使用者身份、Capabilities、eBPF 需求和防火牆變更。確認 Injector 只作用於允許的進程，Collector 只能存取必要日誌和指標，憑據使用短期引用而非明文檔案。
4. 控制資料出口
列出 OTLP endpoint、TLS、代理、重試、佇列和脫敏規則。先把資料發往隔離後端，驗證服務名、主機標識、命令列參數和個人資料不會越過租戶或地域邊界。無網路時應有明確丟棄或本地緩衝策略。
5. 設計灰度指標
按發行版、架構和業務重要性分批。觀察安裝成功、進程啟動、CPU/記憶體、eBPF 錯誤、Collector 佇列、出口流量、敏感欄位命中和卸載成功率。任何異常只停止新主機加入，不擴大權限來掩蓋問題。
6. 回滾和升級
保留原始包、設定、systemd 狀態和檔案清單；回滾先停 Injector 和 Collector，再恢復舊包和防火牆。為每個版本記錄可重複卸載命令與恢復時間。供應鏈簽名、託管倉庫和安全審查未成熟前，維持實驗範圍。
高品質示範回答
我會把這個倉庫當實驗源。先在可重建主機檢查提交、雜湊、SBOM、簽名、依賴、systemd、權限、eBPF 和網路出口；未簽名包不進入生產。Injector 只允許作用於明確進程，Collector 採用最小權限、短期憑據和隔離後端，資料經過 TLS 與脫敏。灰度按發行版和業務重要性推進，觀察安裝、資源、佇列、出口和卸載指標。保留舊包、設定與恢復步驟，失敗時停新主機並逐台回滾；直到內部鏡像和簽名流程成熟才擴大範圍。
常見錯誤
- 一鍵腳本直接生產執行 → 權限和供應鏈未知 → 先隔離審閱和內部鏡像。
- 忽略未簽名包 → 無法證明來源 → 要求雜湊、SBOM 和簽名門檻。
- 讓 Injector 作用所有進程 → 業務和隱私風險擴大 → 按進程白名單限制。
- 只監控安裝成功 → 運行後可能洩漏資料 → 監控出口、脫敏和資源指標。
- 沒有卸載與恢復清單 → 失敗後只能人工排障 → 版本化回滾步驟。
追問及應對
未簽名包是否完全不能測試？
可以在隔離、無敏感資料且可銷毀的環境短期測試，但必須標記為實驗，禁止把測試結果當作生產批准。
為什麼不直接給腳本 root 權限？
root 會擴大安裝腳本和依賴的影響面。應預先審閱所需權限，用專用帳號、Capabilities 和受控 systemd 服務縮小邊界。
如何證明自動插樁沒有改變業務？
對照同版本主機的錯誤率、延遲、進程啟動參數和關鍵路徑，檢查新增 span、日誌和網路連線；異常時關閉 Injector 而非修改業務程式碼。
什麼時候可以進入生產？
至少需要受控託管倉庫、可驗證簽名、SBOM、最小權限、資料出口審計、可重複回滾和分批驗收。早期倉庫自身的生產就緒聲明不能被推斷。