# 장애 대응 (Incident Response)

## 개요

**장애 대응(Incident Response)**이란 IT 인프라, 소프트웨어 시스템, 또는 네트워크 서비스에서 예상치 못한 중단, 성능 저하, 보안 침해 등 비정상적인 상태(장애)가 발생했을 때, 이를 신속하게 탐지하고 분석하여 복구하고, 재발을 방지하기 위한 체계적인 프로세스와 활동을 의미합니다.

현대 기업에서 시스템 가용성(Availability)은 비즈니스 연속성의 핵심 요소입니다. 따라서 장애 대응은 단순히 '고치는 것'을 넘어, 최소한의 서비스 중단 시간(Minimum Downtime)을 확보하고 고객 신뢰를 유지하기 위한 전략적 활동으로 인식됩니다. 본 문서는 장애 대응의 주요 단계, 핵심 원칙, 그리고 효과적인 운영을 위한 가이드라인을 다룹니다.

## 장애 대응의 주요 단계 (PDCA 기반)

효율적인 장애 대응은 일반적으로 **PDCA(Plan-Do-Check-Act)** 사이클을 기반으로 한 구조화된 접근 방식을 따릅니다. 주요 단계는 다음과 같습니다.

### 1. 준비 (Preparation)
장애가 발생하기 전에 대비하는 단계입니다. 이 단계는 가장 중요하지만 종종 간과되기도 합니다.
*   **대응 팀 구성**: SRE(Site Reliability Engineering) 팀, 개발자, 운영자, 커뮤니케이션 담당자 등 역할 분담 명확화.
*   **도구 구축**: 모니터링(Monitoring), 로깅(Logging), 알림(Alerting) 시스템의 정상 작동 확인.
*   **시나리오 기반 훈련**: 정기적인 치트 게임(Chaos Engineering) 또는 모의 훈련을 통해 대응 매뉴얼의 실효성 검증.

### 2. 탐지 및 분석 (Detection & Analysis)
장애가 발생했을 때 이를 신속하게 인지하고 원인을 규명하는 단계입니다.
*   **신속한 인지**: 모니터링 시스템의 이상 징후 감지 또는 사용자/고객의 신고 접수.
*   **초기 진단**: 장애의 범위(전체/부분), 심각도(P1~P4 등급), 영향 받는 서비스 식별.
*   **근본 원인 분석(Root Cause Analysis)**: 로그, 메트릭, 트레이스 데이터를 통해 장애의 근본 원인을 추적합니다. 이때 '5 Whys' 기법 등을 활용하여 표면적인 증상보다 근본 원인을 파악하는 것이 중요합니다.

### 3. 대응 및 복구 (Containment, Eradication & Recovery)
서비스를 정상 상태로 되돌리기 위한 실행 단계입니다.
*   **확산 방지(Containment)**: 장애가 다른 시스템으로 퍼지지 않도록 격리 조치 (예: 트래픽 차단, 서버 분리).
*   **근본 원인 제거(Eradication)**: 버그 수정, 설정 오류 정정, 악성 코드 제거 등.
*   **서비스 복구(Recovery)**: 백업 데이터 복원, 롤백(Rollback) 또는 롤포워드(Rollforward)를 통해 서비스를 정상화.
    *   *주의*: 완벽한 원인 규명보다 **신속한 서비스 복구**를 우선시해야 합니다. ("Fix first, analyze later")

### 4. 사후 관리 및 개선 (Post-Incident Review & Improvement)
장애가 해결된 후, 유사한 사건이 재발하지 않도록 하는 단계입니다.
*   **사후 검토 보고서(Post-Mortem Report)**: 장애 발생 시간선, 원인, 대응 과정, 개선 사항을 기록한 문서 작성.
*   **블ーム라이트 문화(Blameless Culture)**: 개인의 실수를 비난하기보다 시스템적 결함을 개선하는 데 초점을 맞춘 문화 조성.
*   **개선 사항 이행**: 모니터링 규칙 추가, 자동화 스크립트 개발, 문서 업데이트 등 구체적인 액션 아이템(Action Item) 도출 및 이행.

## 장애 대응의 핵심 원칙

성공적인 장애 대응을 위해 다음과 같은 원칙들이 권장됩니다.

| 원칙 | 설명 |
| :--- | :--- |
| **신속성 (Speed)** | 장애 감지부터 복구까지의 시간(MTTD, MTTR)을 최소화하는 것이 최우선 목표입니다. |
| **투명성 (Transparency)** | 내부 팀뿐만 아니라 외부 고객에게도 장애 현황과 예상 복구 시간을 정중하고 투명하게 공개합니다. |
| **명확한 역할 (Role Clarity)** | 대응 지휘관(Triage Lead), 기술 담당자, 커뮤니케이션 담당자 등 명확한 역할 분담이 필요합니다. |
| **자동화 (Automation)** | 반복적인 진단 및 복구 작업을 자동화하여 인간의 실수를 줄이고 대응 속도를 높입니다. |

## 관련 용어 설명

*   **MTTD (Mean Time To Detect)**: 장애가 발생한 시점부터 시스템이 이를 감지하기까지 걸리는 평균 시간.
*   **MTTR (Mean Time To Recover/Resolve)**: 장애가 감지된 시점부터 서비스가 완전히 복구될 때까지 걸리는 평균 시간.
*   **SLA (Service Level Agreement)**: 서비스 제공자와 사용자 간에 체결한 서비스 수준 계약으로, 가용성 목표(예: 99.9%)를 포함합니다.
*   **Chaos Engineering**: 시스템의 강건성을 검증하기 위해 의도적으로 장애를 발생시켜 대응 능력을 테스트하는 공학 분야.

## 참고 자료 및 관련 문서

*   [시스템 가용성 관리 가이드]
*   [모니터링 및 알림 시스템 구축 방법]
*   [블룸라이트 사후 검토(Post-Mortem) 작성 템플릿]
*   [ITIL v4 서비스 운영 지침]

---
*본 문서는 시스템 관리 및 SRE 관행에 기반하여 작성되었습니다. 조직의 특성에 따라 장애 대응 프로세스는 유연하게 조정되어야 합니다.*