メニュー
log/錯誤快速定位（搭配 filesystem.grep、audit.log_query）。當使用者遇到系統問題或錯誤時，快速診斷和定位問題。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | incident-triage |
| description | log/錯誤快速定位（搭配 filesystem.grep、audit.log_query）。當使用者遇到系統問題或錯誤時，快速診斷和定位問題。 |
本技能旨在提供一個標準化的方法來快速診斷和定位系統問題，包括日誌分析、錯誤追蹤和根本原因分析。
filesystem.grep: 搜尋日誌檔案中的特定模式audit.log_query: 查詢審計日誌與使用者溝通，快速收集關於問題的基本信息。
初始信息收集清單:
優先級分類:
| 優先級 | 特徵 | 響應時間 |
|---|---|---|
| P1 (關鍵) | 系統完全不可用，影響所有使用者 | 立即 (15 分鐘) |
| P2 (高) | 主要功能不可用，影響多個使用者 | 1 小時 |
| P3 (中) | 部分功能受影響，影響單個或少數使用者 | 4 小時 |
| P4 (低) | 次要功能受影響，無明顯業務影響 | 24 小時 |
進行快速的系統健康檢查，確定問題的範圍。
健康檢查清單:
健康檢查命令範例:
# 檢查進程狀態
ps aux | grep [service_name]
# 檢查網絡連接
ping [host]
curl -I [service_url]
# 檢查磁碟空間
df -h
# 檢查 CPU 和記憶體
top -b -n 1 | head -20
free -h
# 檢查資料庫連接
mysql -u [user] -p [password] -e "SELECT 1;"
# 檢查最近的日誌
tail -100 /var/log/syslog
收集與問題相關的所有日誌檔案。
日誌收集清單:
日誌位置參考:
| 日誌類型 | 常見位置 |
|---|---|
| 系統日誌 | /var/log/syslog, /var/log/messages |
| Apache 日誌 | /var/log/apache2/, /var/log/httpd/ |
| Nginx 日誌 | /var/log/nginx/ |
| 應用程式日誌 | /var/log/app/, /opt/app/logs/ |
| 資料庫日誌 | /var/log/mysql/, /var/log/postgresql/ |
| 認證日誌 | /var/log/auth.log |
使用 grep 和其他工具搜尋日誌中的錯誤和異常。
日誌搜尋策略:
日誌搜尋命令範例:
# 搜尋錯誤日誌
grep -i "error\|exception\|failed" /var/log/app.log
# 搜尋特定時間範圍的日誌
grep "2024-02-09 14:" /var/log/app.log
# 搜尋特定的錯誤代碼
grep "500\|502\|503" /var/log/nginx/error.log
# 統計錯誤頻率
grep -i "error" /var/log/app.log | wc -l
# 查看錯誤的上下文
grep -B 5 -A 5 "error message" /var/log/app.log
# 使用 awk 提取特定欄位
awk '{print $1, $2, $9}' /var/log/nginx/access.log | grep "500"
分析日誌，識別錯誤的模式和可能的根本原因。
錯誤分析步驟:
根本原因分析方法:
使用「5 Why」方法逐層深入分析：
問題: 應用程式崩潰
為什麼 1: 記憶體不足
為什麼 2: 記憶體洩漏
為什麼 3: 某個功能未正確釋放記憶體
為什麼 4: 代碼中缺少清理邏輯
為什麼 5: 開發人員未進行充分的記憶體管理測試
根本原因: 代碼中的記憶體洩漏，由於缺乏適當的測試
進行更深入的診斷，隔離問題的具體原因。
診斷技術:
診斷命令範例:
# 進行網絡追蹤
tcpdump -i eth0 -w capture.pcap
# 進行性能分析
perf record -g ./application
perf report
# 檢查開啟的檔案
lsof -p [PID]
# 檢查網絡連接
netstat -tuln | grep LISTEN
ss -tuln
# 進行堆棧追蹤
strace -e trace=file ./application
將所有診斷結果整理成一份清晰的報告。
診斷報告結構:
# 事件診斷報告
## 事件摘要
- **事件 ID**: [ID]
- **報告時間**: [時間]
- **優先級**: [P1/P2/P3/P4]
- **狀態**: [已解決/進行中/待命]
## 問題描述
[使用者報告的問題詳細描述]
## 影響範圍
- 受影響的系統: [系統列表]
- 受影響的使用者: [數量]
- 業務影響: [詳細說明]
## 時間線
| 時間 | 事件 |
|------|------|
| 14:30 | 首次報告問題 |
| 14:35 | 開始診斷 |
| 14:45 | 識別根本原因 |
| 15:00 | 實施修復 |
| 15:15 | 驗證修復 |
## 根本原因分析 (RCA)
### 直接原因
[問題的直接技術原因]
### 根本原因
[深層的根本原因]
### 相關因素
- [因素 1]
- [因素 2]
## 日誌分析結果
### 關鍵日誌條目
[時間戳] [級別] [訊息] 2024-02-09 14:32:15 ERROR Database connection timeout 2024-02-09 14:32:16 ERROR Failed to execute query
### 錯誤統計
- 總錯誤數: [數量]
- 錯誤類型分布: [分布]
- 錯誤頻率: [頻率]
## 修復方案
### 臨時修復
[立即採取的臨時措施]
### 永久修復
[長期解決方案]
### 驗證步驟
- [ ] 步驟 1
- [ ] 步驟 2
- [ ] 步驟 3
## 預防措施
[防止類似問題再次發生的措施]
## 後續行動
- [ ] 實施永久修復
- [ ] 更新監控警報
- [ ] 更新文件
- [ ] 進行事後檢討
## 附錄
- 完整的日誌輸出
- 詳細的技術分析
- 相關的配置檔案
根據診斷結果實施修復，並驗證問題已解決。
修復和驗證清單:
快速響應: 根據優先級快速響應，優先處理關鍵問題。
系統化診斷: 按照邏輯順序進行診斷，避免遺漏。
詳細記錄: 記錄所有診斷步驟和發現，便於後續參考。
根本原因分析: 不要只修復症狀，要找到並解決根本原因。
預防措施: 實施措施防止類似問題再次發生。
溝通: 定期更新利益相關者關於問題狀態的信息。
事後檢討: 事件解決後進行檢討，學習經驗教訓。
常見原因: 記憶體洩漏、未處理的異常、資源耗盡 診斷步驟: 檢查應用程式日誌、檢查系統資源、進行堆棧追蹤
常見原因: 資料庫服務停止、網絡問題、認證失敗 診斷步驟: 檢查資料庫服務狀態、測試網絡連接、驗證認證憑證
常見原因: 無限迴圈、記憶體洩漏、過度計算 診斷步驟: 進行性能分析、識別消耗資源的進程、檢查代碼
常見原因: 資料庫查詢緩慢、網絡延遲、伺服器過載 診斷步驟: 分析 API 日誌、進行資料庫查詢分析、檢查伺服器負載
常見原因: 日誌檔案過大、臨時檔案堆積、資料庫增長 診斷步驟: 檢查磁碟使用情況、識別大檔案、清理不需要的檔案
在使用者要設計網站、Web App 或元件介面時使用。常見觸發像「做 landing page」「設計 dashboard」「規劃 component UI」。輸出可上線介面與設計系統；不取代產品策略或純品牌研究。
在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex / Claude Code 的分階段 instructions；不直接代替正式文件發布。
在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。
當使用者要拆解大型、混亂、跨部門、反覆卡關或高不確定性的難題，或明確要求做問題拆解、issue tree、根因與對策分層時使用。先分清楚現象、目標落差、真正問題與根因假設，再判斷問題是範疇型、分析型、動態系統型、研究型或交付型，最後用 issue tree/MECE、WBS、系統思考、驗收標準、依賴排程、資源分派與流動指標，產出可執行的問題拆解報告、工作包、關鍵路徑、並行策略與 PDCA 回饋節奏。
當使用者要替代解法、不同思路、更簡單或更穩定做法時使用。將現有方案重構成結構問題，提出多條可落地方案與最低摩擦解。
建立定期任務（每日晨報、每週回顧）。當使用者需要設定自動化的、定期執行的任務時使用。