題幹與適用場景
Core dump 是程序位址空間快照，可能包含金鑰、請求內容、使用者資料和緩衝區。這題同時考察 Linux 診斷與生產資料治理，要分開說明能否收集、誰能看、保存多久及如何證明清理。
面試官真正想聽什麼
- 由退出訊號、journal、版本和 core 中繼資料確認是真崩潰，而非 OOM 或人工終止。
- 理解 systemd-coredump 的收集、壓縮、儲存和
coredumpctl邊界。 - 用匹配的二進位、除錯符號和 build ID 還原堆疊。
- 完整說明內容、權限、加密、保留期、容量和敏感資料處理。
推薦回答結構
先低風險收集服務狀態、信號、日誌、核心訊息、版本和資源指標。確認需要 core 後，在隔離實例短時啟用受控收集，限制大小和數量，使用專用權限與加密儲存；分析完成立即銷毀或依策略到期清理。
深入拆解：從崩潰到修復
先區分退出原因
檢查 systemctl status、journal、OOM 記錄、退出信號和重啟次數。SIGSEGV、SIGABRT、SIGBUS 的線索不同；exit 137 優先查 cgroup OOM。
固定可符號化的建置
保存與崩潰實例匹配的二進位、共享函式庫、除錯符號和 build ID。用受信制品庫還原，先讀執行緒與堆疊，按需檢查堆和暫存器，減少敏感資料暴露。
設計受控收集
systemd-coredump 可把 core 交給專用服務並寫入 journal 或外部目錄。設定大小、壓縮、並發和配額；高敏感服務可設定 LimitCORE=0 或只收集中繼資料與堆疊。
建立存取與保留邊界
core 儲存使用加密、最小權限和獨立稽核，禁止普通運維帳號下載。保留期依排障窗口與合規要求設定，並自動過期與告警。日誌中的命令和路徑也不可含權杖。
用修復證據閉環
重現修復前崩潰，驗證新版本不再觸發，觀察崩潰率和重啟率。檢查 core、快取和備份的到期清理並做權限稽核；無法證明移除敏感資料就不能宣稱風險關閉。
可直接套用的回答示例
「我先確認退出信號、journal、OOM 記錄、版本和 cgroup 指標，區分 SIGSEGV 與 exit 137。確認是應用崩潰後，在隔離節點短時啟用 systemd-coredump，設定單檔與總量上限，用匹配 build ID 的符號包分析堆疊。core 寫入加密目錄，故障小組以短期授權存取，不把權杖複製到工單。修復後回歸原始輸入並觀察崩潰率，分析完刪除 core，檢查 journal、備份和權限稽核。若無法建立邊界，則關閉完整 core，只保留中繼資料和受控堆疊。」
常見失分點與修正
- 看到 core 就斷定段錯誤 → 核對信號、OOM、cgroup 和部署。
- 直接在生產機安裝除錯工具 → 使用匹配制品和隔離環境。
- 只談磁碟空間 → 補充配額、保留期、加密和清理。
- 把 core 當普通日誌 → 設計最小權限、短期授權和獨立稽核。
評分標準與自檢清單
高分回答包含退出證據、build ID 與符號化、systemd-coredump 邊界、採集開關、容量、加密、存取控制、保留與刪除、敏感資料最小化、回滾和修復指標。
追問與延伸
何時應完全關閉 core？
當位址空間高度敏感且無法建立可信隔離、加密、存取和清理邊界時，關閉完整 core，改收集信號、執行緒堆疊或最小診斷資訊。
只有一台機器偶發崩潰，怎樣降低風險？
先收集中繼資料和受控堆疊，限制單台與短時間窗口；必要時設定自動過期、單次授權並刪除本地副本。
如何避免符號化誤導？
以 build ID、校驗和與制品清單確認二進位、函式庫和符號一一對應。不匹配時標記不確定，不用相似版本下結論。
core 已進入備份怎麼辦？
把備份列為獨立資料域，標記物件版本和到期時間，限制恢復權限，讓刪除流程涵蓋備份索引與輪換任務。