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
반응형