Appearance
二線運維 SOP
這是什麼 Argus 平台本身出狀況（不是業務 DB 出狀況）時，二線運維（SRE / 平台）的標準排查順序。 對應主管要求 ④ 二線運維。
不該用本頁的情境
- 業務 DB 的事故 → 走 緊急回滾
- 帳號 / 權限 / IdP 故障 → 走 認證模式 / FAQ
觸發條件（任一）
- [ ] Argus UI 完全打不開（HTTP 5xx）
- [ ] Argus UI 可開但功能異常（task scheduler 不動、plan check 卡住、IM 通知不發）
- [ ] Metric 異常（latency p99 飆高、CPU / 記憶體告警）
- [ ] 內部用戶 / DBA 多人回報相同症狀
對應端點 / 觀測點
| 來源 | URL / 指令 |
|---|---|
| Health | GET $ARGUS/healthz |
| Readiness | GET $ARGUS/readyz |
| Metrics | GET $ARGUS/metrics（Prometheus 格式） |
| Server log | journalctl -u argus -f 或 stdout |
| Metastore | psql -U argusdev argusdev |
| Container | docker logs -f argus / kubectl logs deploy/argus -f |
排查順序
1. 確認影響範圍
bash
# 服務存活
curl -s -o /dev/null -w "%{http_code}\n" $ARGUS/healthz
# Metastore 連線
psql -U argusdev -d argusdev -c "SELECT now();" -h $PG_HOST| 狀況 | 跳到 |
|---|---|
healthz 200 但功能異常 | 步驟 3（runner 排查） |
healthz 5xx | 步驟 2（server 排查） |
| Metastore 連不上 | 步驟 4（metastore 排查） |
2. Server 排查
a. 看 server log
bash
# 取最近 200 行非 INFO log
journalctl -u argus -n 500 | grep -v 'level=info' | tail -200關注：
panic、fatal- DB 連線錯誤
migration相關 fail-fastOOM
b. 看 resource
bash
# Process
ps -aux | grep argus
# Memory / CPU
top -p $(pgrep argus)
# File descriptors
ls /proc/$(pgrep argus)/fd | wc -lc. 嘗試重啟
bash
systemctl restart argus
# 或
kubectl rollout restart deploy/argus如果重啟回不來 → 看 startup log（多半是 migration 卡住）：
bash
journalctl -u argus -f | grep -i 'migration\|startup\|listen'3. Runner 排查
Argus server 內有多個非同步 runner：
| Runner | 看什麼 |
|---|---|
taskrun-scheduler | task 是否一直 pending |
plancheck-scheduler | plan check 卡住 |
relay-runner | webhook / IM 通知 |
mail-runner | email 通知 |
slow-query-runner | 慢查詢收集 |
metric-reporter | 內部指標上報 |
判斷方法：
- 在 UI 對應功能上做動作，觀察是否寫進 DB
- 查 server log 的 runner 標籤（
runner=taskrun-scheduler）
若是單一 runner 異常，重啟 server 即可恢復。runner 之間沒有共享狀態。
4. Metastore 排查
bash
# 連線
psql -U argusdev -d argusdev -h $PG_HOST -c "SELECT pg_is_in_recovery(), now();"
# 連線數
psql -U argusdev -d argusdev -h $PG_HOST -c \
"SELECT count(*) FROM pg_stat_activity WHERE datname = 'argusdev';"
# Lock 等待
psql -U argusdev -d argusdev -h $PG_HOST -c \
"SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL;"
# Replication lag（若為 replica）
psql -U argusdev -d argusdev -h $PG_HOST -c \
"SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()));"常見：
- 連線爆滿（>200）→ 看是否有 stuck transaction
- 高 lock wait → 識別兇手 query
- Replica lag 高 → 走 metastore 的 SOP（不在本 runbook 範圍）
5. 仍找不到原因
- 抓 server 一份 pprof：
curl -o /tmp/heap.pprof $ARGUS/debug/pprof/heap（前提是--debug開） - 開 incident ticket，上傳：log 樣本 + pprof + metric screenshot
- 標記值班 Argus owner
緊急 kill-switch
若需要全平台暫停所有 in-flight rollout：
Settings → Emergency Pause → 切 ON。
這會：
- 凍結所有
running與pending的 task - 寫進 audit log（
bb.setting.update，severity =critical） - 通知所有 admin
用完記得切回
OFF。在 Pause 期間任何試圖啟動的 rollout 都會直接 reject。
紀錄與覆盤
- 寫事件單，附 timeline + root cause + 影響範圍
- 一週內排覆盤會
- 若涉及程式 bug，開 issue 追蹤
演練
- 上次演練：NaN
- 頻率：每季一次（建議與 緊急回滾 合併演練）