카테고리 없음

MTTD / MTTR 완벽 정리 (2026년 DevOps/SRE 기준) — 장애 대응 핵심 지표

idea9329 2026. 3. 16. 16:49
728x90
반응형
[장애 타임라인과 지표 위치]

  장애 발생      탐지        인지        복구 완료
     │           │           │              │
     ▼           ▼           ▼              ▼
─────●───────────●───────────●──────────────●─────▶ 시간
     │←─ MTTD ──→│           │              │
     │←────────── MTTR ──────────────────→│
     │           │←─ MTTA ──→│              │
     │           │           │←── MTTF ────→│

개요

MTTD와 MTTR은 SRE/DevOps 팀의 장애 대응 능력을 수치화하는 핵심 지표다. 숫자가 낮을수록 좋고, 이 두 지표를 줄이는 것이 온콜 운영의 핵심 목표다.

SEO 키워드: MTTD MTTR 차이, DevOps SRE 지표, 장애 대응 지표, Mean Time To Detect, Mean Time To Recover, 인시던트 관리 2026

1. MTTD — Mean Time To Detect (평균 탐지 시간)

장애가 발생한 시점 → 팀이 인지한 시점까지의 평균 시간

장애 발생 → [모니터링/알림] → 팀이 장애 인지
    └──────── MTTD ────────┘

MTTD가 길어지는 원인

  • 알림 임계값이 너무 높게 설정됨
  • 모니터링 커버리지 부족 (blind spot)
  • 알림 피로(Alert Fatigue)로 무시됨
  • 로그/메트릭 수집 지연

MTTD 단축 방법

방법설명

다층 알림 설정 Warning → Critical 단계별 알림
Anomaly Detection 이상 패턴 자동 감지
합성 모니터링 외부에서 주기적으로 헬스체크
로그 기반 알림 Error 로그 급증 시 즉시 알림

2. MTTR — Mean Time To Recover (평균 복구 시간)

장애가 발생한 시점 → 서비스가 정상 복구된 시점까지의 평균 시간

장애 발생 → 탐지 → 분석 → 조치 → 서비스 정상화
    └──────────────── MTTR ───────────────────┘

MTTR 구성 요소

MTTR = MTTD + MTTA + MTTF

MTTD : 탐지 시간
MTTA : Mean Time To Acknowledge (담당자 할당 시간)
MTTF : Mean Time To Fix (실제 수정/복구 시간)

MTTR 단축 방법

방법설명

Runbook 자동화 장애 유형별 대응 절차 문서화
롤백 자동화 배포 실패 시 즉시 이전 버전 복원
온콜 로테이션 24/7 담당자 명확히 지정
카오스 엔지니어링 사전 장애 훈련으로 복구 숙련도 향상
Feature Flag 코드 수정 없이 기능 즉시 비활성화

3. 관련 지표 전체 비교

지표풀네임의미

MTTD Mean Time To Detect 장애 발생 → 탐지까지
MTTA Mean Time To Acknowledge 탐지 → 담당자 인수까지
MTTF Mean Time To Fix 담당자 인수 → 수정 완료까지
MTTR Mean Time To Recover 장애 발생 → 완전 복구까지
MTBF Mean Time Between Failures 장애와 장애 사이 평균 간격 (안정성 지표)

4. EKS/클라우드 인프라 관점에서

[EKS 장애 시나리오 예시]

Pod OOMKilled 발생
    │
    │ MTTD: CloudWatch/Prometheus 알림까지
    ▼
PagerDuty/Slack 알림 수신
    │
    │ MTTA: 온콜 엔지니어 확인까지
    ▼
kubectl 로그/이벤트 분석
    │
    │ MTTF: memory limit 조정 + 재배포까지
    ▼
서비스 정상화 → MTTR 종료

인프라별 MTTR 단축 전략

상황전략

EKS Pod 장애 HPA + PDB로 자동 복구, Liveness Probe 튜닝
배포 장애 ArgoCD/Helm 롤백 자동화
DB 장애 RDS Multi-AZ 자동 페일오버
네트워크 장애 멀티 AZ 구성, Health Check 기반 라우팅

5. 목표 수치 기준 (업계 일반)

등급MTTDMTTR

🏆 Elite < 1분 < 1시간
✅ High < 10분 < 1일
⚠️ Medium < 1시간 < 1주
❌ Low 1시간 이상 1주 이상

Google DORA Research 기준. EKS 운영에서는 MTTD < 5분, MTTR < 30분을 실용적 목표로 설정하는 경우가 많다.

마무리

  • MTTD: 얼마나 빨리 장애를 감지하느냐 → 모니터링/알림 품질이 핵심
  • MTTR: 얼마나 빨리 장애를 복구하느냐 → 자동화/Runbook이 핵심

Kiro의 Bug Fix Spec이나 AWS Observability Power가 MTTD 단축에 기여하는 도구인 이유가 바로 여기 있다. 탐지와 복구 두 지표 모두 자동화 수준에 비례해서 개선된다.

728x90
반응형