題幹與適用場景
一個多執行緒、非同步 Python 服務在尖峰出現間歇性 CPU 飆高。團隊希望在不對每次函式呼叫插樁、不中斷程序的情況下採集呼叫堆疊，並讓開發者回放結果。Python 3.15 引入 profiling.sampling，PEP 799 也把追蹤與採樣工具整理到統一命名空間。
請說明何時選採樣、何時選確定性追蹤，如何設定 CPU 或 wall 時鐘、如何處理多執行緒和 free-threaded 建置，以及如何避免把採樣估計誤讀為精確耗時。
面試官考察點
面試官看重候選人是否理解統計採樣的誤差邊界，能否解釋它與 cProfile 的插樁開銷和觀測範圍差異。
強回答還會涵蓋 attach 權限、敏感資料、採樣頻率、短命任務漏樣、profile 版本化和回放重現，而不是只給出一個命令。
回答前需要澄清的問題
- 問題是 CPU 飽和、I/O 等待、鎖競爭還是短時尖峰？
- 線上允許多少 CPU、記憶體和磁碟開銷？
- 需要執行緒、async task、GIL 狀態還是原生擴充堆疊？
- 是否允許 attach 到既有程序，資料保存和存取權限如何控制？
- 目標是定位熱點、比較版本，還是證明回歸已消失？
30 秒回答框架
「我先用採樣器低侵入定位長期熱點，再用小流量或離線重現的確定性追蹤確認短函式路徑。profiling.sampling 的時間是樣本估計，不是函式精確耗時；我會分別採 CPU 和 wall 視角，覆蓋執行緒與非同步場景，記錄直譯器、建置、採樣參數和提交版本。採樣檔脫敏後進入受控儲存，發現開銷或資料風險就停止 attach 並回到離線 profiling。」
分步驟深入解答
先確定採樣問題
採樣適合長時間、低侵入地估計熱點，無法保證捕獲極短函式或給出每次呼叫的精確計時。先定義 CPU、wall、鎖等待和尾延遲訊號，再決定採樣時鐘和持續時間。
區分 profiling.sampling 與 tracing
PEP 799 將確定性工具放在 profiling.tracing，cProfile 保留相容別名；採樣工具放在 profiling.sampling。追蹤記錄每次呼叫，適合短流程和呼叫計數但開銷較高；採樣按週期觀察堆疊，適合生產熱點和長請求。
python -m profiling.sampling record --pid 1234 --clock cpu --duration 30 --output profile.bin
python -m profiling.sampling replay profile.bin --view flamegraph命令列選項需以目標 3.15 版本文件為準，示例表達工作流，不承諾所有 beta 建置參數完全一致。
選擇 CPU 與 wall 時鐘
CPU 時鐘回答「執行緒實際消耗多少處理器時間」，適合定位計算熱點；wall 時鐘包含睡眠、I/O 和等待，適合解釋端到端延遲。兩者混用會把等待誤判為 CPU 優化機會，應在 profile 元資料記錄時鐘類型。
處理執行緒、async 和 free-threaded
採樣器應按執行緒或任務彙總堆疊，避免只看主執行緒。非同步服務要區分事件迴圈忙於計算還是等待 I/O；free-threaded 建置還要觀察並行競爭和原生擴充邊界。採樣結果要帶服務實例、直譯器建置和執行緒識別，才能比較不同部署。
控制開銷與短命任務漏樣
採樣頻率越高，時間解析度越好但讀取堆疊與寫盤開銷越大。短命任務可能在兩次採樣間結束，不能據此斷言沒有執行。透過延長視窗、彙總多個實例或對關鍵路徑做離線追蹤補足，並監控採樣器自身 CPU 和丟樣率。
保護資料與權限
attach 需要程序權限，profile 可能含模組名、路徑和業務函式。限制誰能 attach，避免把參數、使用者識別或請求內容寫入標籤；二進位檔加密、設 TTL，並用脫敏版本分享。故障排查日誌只記錄 profile ID、版本和採樣設定。
回放、比較與回歸門檻
保存採樣參數、時鐘、直譯器版本、提交雜湊和負載視窗。回放時比較熱點堆疊占比、執行緒分布、wall/CPU 差異和樣本數，不能把不同採樣率的百分比直接橫比。把 profile 與基準負載配對，設定「回歸超過閾值才阻斷發布」的規則。
灰度、停止與回滾
先在一個可撤銷實例啟用短視窗採樣，確認開銷、權限和資料治理，再擴大範圍。若 CPU、記憶體或隱私風險超標，停止新 attach、撤銷臨時權限並刪除過期檔案；服務繼續運作，後續分析切換到離線重現和 tracing。
高品質示範回答
「我會把採樣當作低侵入的定位工具，而不是精確計時器。先用 profiling.sampling 在一個實例以 CPU 和 wall 兩種視角採集，再用 profiling.tracing 或基準重現確認短路徑。每份 profile 記錄直譯器建置、提交、採樣參數和負載視窗；採樣檔加密、限權、脫敏並設 TTL。比較時統一時鐘和採樣率，關注熱點占比、執行緒分布與回歸閾值。若採樣器開銷或資料風險超標，撤銷 attach 權限並回到離線分析。」
常見錯誤
- 把樣本時間當精確耗時 → 優化方向被誤判 → 解釋樣本估計和信賴邊界。
- 只看 CPU 時鐘 → I/O 等待被遺漏 → 按問題同時測 CPU 與 wall。
- 只採主執行緒 → 執行緒池或事件迴圈熱點消失 → 保留執行緒、任務和建置元資料。
- 提高採樣頻率就一定更好 → 採集開銷和寫盤壓力上升 → 測量採樣器自身成本。
- 不同採樣率直接比較百分比 → 結果不可比 → 統一參數並配對相同負載。
- 無期限保存 profile → 業務路徑和隱私洩露 → 脫敏、加密、限權和 TTL。
追問及應對
追問一：什麼時候必須用 tracing？
需要每次呼叫計數、精確呼叫關係或重現極短路徑時使用 tracing，最好在離線或小流量環境。生產長期熱點優先採樣，以控制侵入和開銷。
追問二：採樣沒有抓到短任務怎麼辦？
延長採樣視窗或彙總更多實例只能提高出現機率，不能保證捕獲。對短路徑使用基準測試、日誌時間點或離線 tracing 交叉驗證，不能把「零樣本」當成「零執行」。
追問三：為什麼需要記錄 free-threaded 建置？
執行緒排程、鎖競爭和堆疊形態可能隨建置模式改變；不記錄建置就無法解釋 profile 差異，也無法判斷優化是否只在單一直譯器成立。
追問四：如何把 profile 用於發布門禁？
固定負載、時鐘、採樣率和視窗，比較同一指標的分布而非單個樣本。只有熱點占比、尾延遲或採樣開銷超過預先定義閾值才阻斷，其餘差異進入人工複核。