tech-log-backend/docs/runbooks/dependency-unavailable.md

title, category, error_codes, severity, owner, last_updated, status

title	category	error_codes	severity	owner	last_updated	status
Runbook — 외부 의존성 unavailable	TRANSIENT_DEPENDENCY	DEPENDENCY_TIMEOUT DEPENDENCY_CONNECT_FAILED DEPENDENCY_DNS_FAILED DEPENDENCY_CIRCUIT_OPEN DEPENDENCY_5XX_SERVER CACHE_UNAVAILABLE DB_UNAVAILABLE	P1	oncall	2026-05-22	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 임계로 보강 필요.