https://yennj12.js.org/yennj12_blog_V4/tags/incident/Recent content in Incident on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part28-incident-communication-zh/Thu, 04 Jun 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part28-incident-communication-zh/技術問題，工程師能解。 但客戶打電話來的時候，他不想聽技術。 他想知道：這個問題嚴不嚴重？會影響我的業務嗎？你什麼時候能修好？ FDE 要能同時給工程師一個診斷計畫，給客戶一個聽得懂的答案。 面試情境 面試官：「你的客戶在生產環境上部署了一個 RAG-based 問答 Agent。上線三週後，客戶的工程師傳訊息說：每天凌晨 2 點到 4 點，P95 延遲從平常的 800ms 跳到 4 秒，然後自己恢復正常。這個問題已經發生三天了，今天下午客戶的 CTO 要開檢討會。你怎麼處理？」 一、FDE 在這個場景中要做兩件事 事情 1：技術診斷 ├── 找出根因假設（2 小時內） ├── 確認診斷路徑（不停機） └── 給工程師可執行的排查步驟 事情 2：客戶溝通 ├── 在 CTO 會議前準備好說法 ├── 用業務語言描述問題嚴重性 └── 給出有承諾的 Next Step（不是「我們在看」） 兩件事要同時跑。不能只顧技術，忘了客戶在等； 也不能只顧安撫客戶，卻說不出診斷計畫。 二、技術診斷：系統化的假設樹 看到「特定時間窗延遲飆高，自動恢復」這個 Pattern，要有一個系統化的思考框架： 延遲異常 Pattern 分類： Pattern A：週期性（固定時間，固定症狀） → 最常見原因：排程任務衝突、快取過期、Token Refresh → 本題特徵符合：凌晨 2-4 點，每天發生 Pattern B：隨機性（不定時，難以復現） → 最常見原因：資源爭用、External API 不穩定 Pattern C：累積性（越用越慢，重啟恢復） → 最常見原因：記憶體洩漏、連線池耗盡 本題是 Pattern A。先排查週期性原因。