---
title: Runbook — 외부 의존성 unavailable
category: TRANSIENT_DEPENDENCY
error_codes: [DEPENDENCY_TIMEOUT, DEPENDENCY_CONNECT_FAILED, DEPENDENCY_DNS_FAILED, DEPENDENCY_CIRCUIT_OPEN, DEPENDENCY_5XX_SERVER, CACHE_UNAVAILABLE, DB_UNAVAILABLE]
severity: P1
owner: oncall
last_updated: 2026-05-22
status: stub
---

# Runbook: 외부 의존성 unavailable

## 1. Trigger

이 runbook은 다음 alert에서 발동됩니다.

- alert name: `dependency_error_rate_critical` 또는 `circuit_breaker_open`
- alert payload 필수 field: `operation`, `error.code`, `error.category`, `dependency_name`, `dependency_kind`(required|optional), `runbook_link`
- 임계:
  - P1: required dependency의 error rate > 50% 1분 OR circuit_open state 활성
  - P2: optional dependency degraded (fail-open으로 동작 중)

## 2. First Response (5분 이내)

### Step 1 — 확인
1. `dependency_name` 별 status page 확인 (외부 SaaS면 vendor status, internal이면 해당 service dashboard)
2. log query로 실패 패턴 확인: timeout / connect / DNS / 5xx 중 어떤 모드인지
3. runtime-health Dependency Matrix에서 required vs optional 분류 확인
4. circuit breaker state 확인 (Resilience4j metric)

### Step 2 — 임시 격리
- required dep이면 readiness probe로 traffic 차단 (회복 대기) — cascade failure 방지
- optional dep이면 fail-open with degraded mode 확인. degraded banner를 client에 노출
- DNS failure면 resolver/coredns 상태 확인. cache 강제 flush 검토

## 3. Diagnosis

- log query: `{service="app"} | dependency_name="<name>" | stats count by error.code`
- metric panel:
  - `resilience4j_circuitbreaker_state{name="<name>"}`
  - `resilience4j_retry_calls_total{kind="failed_without_retry"}`
  - `hikaricp_connections_active`, `hikaricp_connections_pending` (DB_UNAVAILABLE)
  - `http_client_requests_seconds_count{outcome="SERVER_ERROR"}`
- trace: 실패 request의 outbound span에서 timeout/connect/DNS 분류, target endpoint 확인
- 가능한 원인:
  - vendor outage → status page 확인, 회복 대기
  - 네트워크 문제 (DNS, security group, NAT) → infra team 확인
  - connection pool 고갈 (Hikari) → pool size/timeout 점검
  - circuit breaker open 후 half-open 전환 실패 → 수동 reset 검토
  - retry-storm으로 인한 self-DoS → retry budget 축소

## 4. Mitigation

- 단기: required면 회복 대기 + traffic 차단, optional이면 degraded mode로 유지
- pool 고갈이면 일시 pool size 상향 + leak detection 활성화
- circuit이 stuck이면 수동 reset (`actuator/circuitbreakerevents`)
- 장기: retry budget·timeout·circuit 임계 재조정, fallback path 보강, vendor SLA 재협상

## 5. Escalation

- 다음 on-call로 page: required dep 5분 내 회복 안 되면 외부 dep team 또는 vendor에 page
- 다중 dep 동시 장애면 incident commander 호출 (네트워크 전반 문제 의심)

## 6. Recovery / Verification

- 회복 확인 metric: dependency error rate < 1% 5분 지속, circuit_breaker_state = CLOSED, pool utilization 정상
- post-incident:
  - vendor postmortem 요청 (외부 SaaS면)
  - timeout/retry/circuit 설정 재검토
  - degraded mode가 사용자 경험에 미친 영향 측정
  - chaos test에 해당 시나리오 추가

## 7. Related

- error-codes.yaml rows: `DEPENDENCY_TIMEOUT`, `DEPENDENCY_CONNECT_FAILED`, `DEPENDENCY_DNS_FAILED`, `DEPENDENCY_CIRCUIT_OPEN`, `DEPENDENCY_5XX_SERVER`, `CACHE_UNAVAILABLE`, `DB_UNAVAILABLE`
- metrics.yaml: `resilience4j_circuitbreaker_state`, `hikaricp_connections_active`, `http_client_requests_seconds_count`
- 관련 branch: [[feature-outbound-http-client-baseline]], [[feature-persistence-failure-baseline]]

---

> **Stub 상태 안내**: 이 runbook은 skeleton 단계의 stub. 도메인 도입 시 실제 dependency 목록·required/optional 분류·vendor 연락 체계·circuit/timeout 임계로 보강 필요.