장애·변경·릴리스·배포 관리
장애 탐지·복구·원인분석과 변경 승인, 릴리스·배포·롤백을 안전하게 관리하는 절차를 학습한다.
1. 인시던트와 문제
- 인시던트: 서비스 중단이나 품질 저하가 발생한 사건
- 문제: 하나 이상의 인시던트를 일으키는 근본 원인 또는 잠재 원인
- 알려진 오류: 원인과 우회방법이 확인된 문제
- 서비스 요청: 비밀번호 초기화·권한 신청처럼 표준화된 사용자 요청
인시던트: 서비스가 느리다
↓ 즉시 목표
서비스 복구·영향 완화
↓ 이후
문제관리: 왜 반복되는가?
↓
근본 원인 제거·재발 방지
장애 중에는 원인 분석보다 서비스 복구가 먼저일 수 있다. 그러나 복구 후 원인을 기록하고 재발방지 조치를 수행해야 한다.
2. 장애 대응 흐름
탐지·신고
↓
영향·심각도 분류
↓
담당자·지휘체계 가동
↓
현상·범위·최근 변경 확인
↓
우회·격리·롤백·용량확대 등 복구
↓
사용자·경영진 커뮤니케이션
↓
정상화 검증
↓
사후분석·개선
반드시 기록할 정보:
- 최초 발생·탐지·복구 시간
- 사용자 영향과 범위
- 지표·로그·변경 이력
- 수행한 조치와 결과
- 의사결정자
- 남은 위험
3. 심각도와 우선순위
심각도는 업무 영향, 우선순위는 처리 순서를 나타낸다.
| 기준 | 예시 |
|---|---|
| 영향 | 전체 고객, 일부 기능, 내부 사용자 |
| 긴급성 | 즉시 금융 손실, 마감 임박, 우회 가능 |
| 가용성 | 전면 중단, 성능 저하, 잠재 위험 |
| 규제·보안 | 개인정보 유출, 무결성 손상 |
같은 기술 오류라도 업무 시간, 대상 고객, 우회 가능성에 따라 심각도가 달라질 수 있다.
4. 장애 통제
- 한 명의 인시던트 지휘자 지정
- 조치자와 커뮤니케이션 담당 분리
- 한 번에 하나의 변경 원칙
- 명령·시간·결과 기록
- 데이터 파괴 가능 조치 승인
- 비상 변경도 사후 검토
- 증거·로그 보존
- 복구 기준과 종료 조건 명확화
Incident Commander
├─ 기술 대응팀
├─ 업무 확인팀
├─ 커뮤니케이션팀
└─ 의사결정·승인
5. 변경관리
변경은 서비스·인프라·설정·문서·프로세스에 대한 추가·수정·제거이다.
변경 요청
↓
목적·범위·위험·영향 분석
↓
테스트 계획·롤백 계획
↓
승인·일정 조정
↓
변경 실행
↓
검증·모니터링
↓
성공 종료 또는 롤백
↓
문서·구성정보 갱신
변경 유형 예:
- 표준 변경: 반복적이고 위험이 낮아 사전 승인된 절차
- 정상 변경: 영향·위험 분석과 승인이 필요한 일반 변경
- 긴급 변경: 심각한 장애·보안 문제를 신속히 해결하되 통제와 사후 검토 필요
6. 변경 계획 필수 요소
- 목적과 업무 이유
- 대상 구성항목
- 선행·후행 조건
- 영향받는 사용자·시스템
- 작업 절차
- 예상 중단시간
- 검증 항목
- 롤백 조건·절차
- 담당·승인·연락체계
- 모니터링 기간
“문제가 생기면 원복”이라는 한 줄은 충분한 롤백 계획이 아니다. 데이터 스키마·메시지·외부 연계가 이미 변경되었는지 고려해야 한다.
7. 릴리스와 배포
| 용어 | 의미 |
|---|---|
| 빌드 | 소스에서 실행 가능한 아티팩트 생성 |
| 릴리스 | 배포할 기능·버전·문서·승인 단위를 준비 |
| 배포 | 아티팩트를 실제 환경에 설치·적용 |
| 활성화 | 사용자에게 기능을 노출 |
| 롤백 | 이전 안전 상태로 되돌림 |
| 롤포워드 | 수정 버전을 추가 배포해 문제 해결 |
기능 플래그를 사용하면 코드 배포와 기능 활성화를 분리할 수 있다.
8. 배포 전략
Rolling
v1 v1 v1 v1
↓ 순차 교체
v2 v1 v1 v1
v2 v2 v1 v1
v2 v2 v2 v2
Blue-Green
사용자 → Blue(v1)
Green(v2) 준비·검증
↓ 트래픽 전환
사용자 → Green(v2)
Canary
95% 사용자 → v1
5% 사용자 → v2
↓ 지표 확인
25% → 50% → 100%
배포전략은 애플리케이션만이 아니라 DB 스키마 호환성, 세션, 메시지 형식, 외부 API를 함께 고려해야 한다.
9. 롤백과 DB 변경
안전한 점진적 스키마 변경 예:
① 새 컬럼 추가: 기존 코드와 호환
② 새·구 버전이 함께 동작하도록 코드 배포
③ 데이터 백필
④ 읽기 경로 전환
⑤ 구 컬럼 사용 중지 확인
⑥ 나중에 구 컬럼 제거
한 번에 컬럼 삭제·이름 변경을 하면 구 버전 인스턴스가 장애를 일으킬 수 있다.
10. 사후분석
좋은 사후분석은 개인 비난보다 시스템·과정의 개선에 초점을 둔다.
- 무엇이 일어났는가
- 사용자 영향은 무엇인가
- 어떻게 탐지했는가
- 복구가 지연된 이유는 무엇인가
- 어떤 통제가 작동했거나 실패했는가
- 재발 방지·탐지 개선·운영 개선 조치
- 담당자와 기한
직접 원인
└─ 기여 요인
├─ 설계
├─ 테스트
├─ 변경 통제
├─ 모니터링
└─ 문서·교육
11. 사고 지휘와 우선순위
탐지 → 심각도 선언 → Incident Commander 지정
→ 고객 영향 제한 → 복구 경로 실행 → 상태 공지
→ 정상화 확인 → 문제관리·사후분석
장애 중에는 복구 의사결정과 원인 조사 역할을 분리할 수 있다. Severity는 영향·범위·지속시간·규제 위험으로 정하고, 에스컬레이션 조건과 업데이트 주기를 미리 정의한다.
12. 변경 위험 점수와 승인
변경 위험 = 영향 × 실패 가능성 × 탐지 난이도
표준 변경은 반복·저위험·검증된 절차를 사전 승인한 것이며, 긴급 변경도 사후 검토·증적을 생략하는 뜻은 아니다. 변경 창, owner, 테스트 증거, 의존성, rollback/roll-forward 기준을 기록한다.
13. 카나리 판정과 자동 중단
기존 95% + 신규 5%
→ 오류율·p99·포화도·비즈니스 KPI 비교
→ 기준 초과: 자동 중단/rollback
→ 정상: 25% → 50% → 100% 확대
표본이 너무 작으면 드문 오류를 보지 못하고, 사용자군이 치우치면 비교가 왜곡된다. 동등한 구간·트래픽 특성과 통계적 변동을 고려한다.
14. DB 변경의 롤백 한계
파괴적 스키마 변경과 새 형식 데이터 쓰기는 단순 애플리케이션 바이너리 롤백으로 되돌릴 수 없다.
Expand: 새 열/테이블 추가
Migrate: 구·신 버전 호환, 데이터 backfill·검증
Contract: 구버전 제거 후 옛 구조 제거
대규모 데이터 변경은 PITR·백업·감사 로그와 보상 또는 roll-forward 절차를 준비한다.
15. 운영 성과 지표와 DORA 최신 구분
현재 DORA의 소프트웨어 전달 성과 모델은 다음 5개 지표를 함께 본다.
| 구분 | 지표 | 해석 |
|---|---|---|
| 처리량 | 변경 리드타임 | 변경이 커밋된 뒤 운영에 반영되기까지 걸린 시간 |
| 처리량 | 배포 빈도 | 운영 환경에 성공적으로 배포하는 빈도 |
| 처리량 | 실패 배포 복구시간 | 배포 때문에 서비스가 손상된 뒤 복구하기까지 걸린 시간 |
| 불안정성 | 변경 실패율 | 운영 변경 중 장애·성능 저하·rollback을 유발한 비율 |
| 불안정성 | 배포 재작업률 | 예상하지 못한 수정·hotfix에 들어간 배포 비율 |
과거에 넓은 의미의 MTTR를 사용하던 설명과 달리 실패 배포 복구시간은 배포로 발생한 실패의 복구에 범위를 한정한다. 지표 하나만 목표로 삼아 결함을 숨기거나 작은 변경을 억지로 쪼개는 gaming을 방지해야 한다.
확인 문제
- 긴급 변경은 사후 검토를 생략해도 되는가?
- 카나리 표본이 너무 작을 때의 문제는?
- 파괴적 DB 변경이 앱 바이너리 rollback만으로 복구되지 않는 이유는?
- expand-migrate-contract의 목적은?
- 사후분석의 핵심 산출물은?