이 글은 서비스 장애·안정성과 관련된 네 가지 주제 — 장애 대응 체크리스트, 포스트모템 작성 방법, 온콜(On-call) 경험 정리, 데이터베이스 장애 시나리오 — 를 개발자·운영자 관점에서 정리한 메모이다.
1. 장애 대응 체크리스트 – 처음 5분/30분/1시간
1) 처음 5분 – 상황 파악과 영향 범위 확인
장애가 감지된 직후 첫 5분은 \"무엇이 얼마나 심각한가\"를 파악하는 시간이 되어야 한다. 이 시점에는 깊은 원인 분석보다, 영향 범위와 현재 상태를 빠르게 파악하는 것이 중요하다.
- 모니터링 확인 — 대시보드에서 에러율, 응답 시간, 트래픽, 자원 사용량(CPU·메모리·디스크)을 확인한다.
- 알람 메시지 정리 — 어떤 서비스/엔드포인트/리전에서 경고가 발생했는지 파악한다.
- 사용자 영향 — 전체 장애인지, 일부 기능·일부 지역에 한정된 장애인지 확인한다.
2) 처음 30분 – 원인 후보 좁히기와 임시 완화 조치
첫 30분 동안은 로그·릴리스 이력·설정 변경 이력을 확인해 원인 후보를 좁히고, 동시에 가능한 임시 완화 조치를 검토한다.
- 최근 배포·설정 변경 이력 확인
- 에러 로그·슬로우 쿼리 로그·애플리케이션 로그 확인
- 임시 완화 — 트래픽 제한(레이트 리밋), 일부 기능 비활성화, 캐시 TTL 조정 등
3) 처음 1시간 – 에스컬레이션과 커뮤니케이션
1시간 이내에 해결되지 않거나 영향이 크다면, 에스컬레이션 기준에 따라 추가 인원을 호출하고, 이해관계자(내부/외부)에 상황을 공유해야 한다.
- 에스컬레이션 — 관련 팀(인프라, DB, 보안 등) 호출, 온콜 로테이션에 따라 다음 단계 담당자를 호출
- 커뮤니케이션 — 내부 채널(슬랙 등)에 현황·추가 조치·예상 복구 시간 공유, 필요 시 상태 페이지 업데이트
- 결정 기록 — 언제 어떤 조치를 했는지 간단히 기록해, 이후 포스트모템에 활용
2. 포스트모템(Postmortem) 작성 – 블레임 없이 정리하기
장애가 해결된 뒤에는 포스트모템을 통해 원인·영향·조치·재발 방지 대책을 정리한다. 포스트모템의 목적은 \"누구를 탓하는 것\"이 아니라, 재발 가능성을 줄이는 것이다.
1) 기본 구조
- 개요 — 장애 요약, 영향 범위, 발생/해결 시각
- 타임라인 — 감지 → 인지 → 조치 → 복구까지 시계열 정리
- 근본 원인 — 직접 원인(예: 잘못된 설정), 그 배경(프로세스/테스트 부재 등)
- 영향 — 사용자 영향, 데이터 영향, 내부 작업 영향 등
- 조치 사항 — 당시 취한 임시 조치와 영구 조치
- 재발 방지 대책 — 모니터링·테스트·프로세스 개선 항목
2) 블레임 없는 문화
포스트모템에서는 \"누가 이 설정을 잘못 바꿨다\"보다, \"어떻게 하면 다음에 같은 실수를 시스템적으로 막을 수 있는가\"에 초점을 맞춰야 한다.
- 개인 이름보다 역할·프로세스를 중심으로 서술
- \"수동 작업 과정에서 실수가 발생했다\" → \"이 작업을 자동화/리뷰하도록 변경\"과 같이 연결
- 동일 유형 장애가 다시 발생할 가능성을 줄이는 개선안에 집중
3. 온콜(On-call) 경험 정리 – 알람·런북·심리적 부담
온콜(On-call)은 근무 시간 외에도 장애 알람을 받고 대응하는 역할이다. 온콜이 건강하게 운영되려면, 알람 품질·런북·심리적 부담 관리가 중요하다.
1) 알람 품질 관리
알람이 너무 많거나 의미 없는 경고가 많으면, 알람 피로(Alert fatigue)로 인해 정말 중요한 알람도 무시되기 쉽다.
- 알람은 \"즉시 사람이 개입해야 하는 상황\"에만 보내도록 기준을 정한다.
- 지속적으로 발생하는 경고는 임계치 조정·대시보드 전용 알람으로 옮기는 등 정리한다.
- 온콜 이후 포스트모템에서 \"불필요했던 알람\"을 줄이는 액션을 함께 도출한다.
2) 런북(Runbook) 준비
런북은 특정 알람·문제 상황이 발생했을 때, 어떤 순서로 무엇을 확인하고 어떤 조치를 할지 정리한 문서이다.
- 각 알람 유형별로 확인할 대시보드·로그·명령어를 정리한다.
- 임시 조치(트래픽 제한·재시작·롤백 등)와, 반드시 확인해야 할 영향 범위를 함께 적는다.
- 온콜 후에는 런북을 최신 상태로 업데이트해, 다음 온콜러가 같은 실수·혼란을 겪지 않게 한다.
3) 심리적 부담 줄이기
온콜은 심리적 부담이 크므로, 로테이션·백업과 명확한 책임 범위를 정해 두는 것이 중요하다.
- 온콜 로테이션을 구성해, 특정 사람에게만 부담이 쌓이지 않게 한다.
- 야간 온콜 시에는 2명 이상이 참여할 수 있도록 백업 체계를 둔다.
- 온콜 중 발생한 장애에 대해, 사후 포스트모템에서 \"개인 탓\"이 아닌 구조 개선 관점으로 다룬다.
4. 데이터베이스 장애 시나리오 – 실제로 자주 겪는 유형
데이터베이스(DB)는 장애 시 전체 서비스에 큰 영향을 주는 구성 요소이다. 실제 운영에서 자주 겪는 DB 장애 시나리오는 다음과 같다.
1) 디스크 풀(FULL) – 공간 부족
로그 파일·임시 파일·아카이브가 예상보다 빨리 쌓이면, 디스크가 가득 차서 DB가 쓰기 작업을 못 하거나, 심한 경우 프로세스가 멈출 수 있다.
- 증상 — INSERT/UPDATE 시 에러, 슬로우 쿼리 급증, DB 프로세스 다운
- 대응 — 불필요한 로그·백업 정리, 파티션·스토리지 확대, 로그 로테이션 정책 재검토
2) 연결 폭주 – 커넥션 풀 고갈
애플리케이션에서 DB 커넥션을 적절히 반환하지 않거나, 트래픽 급증·슬로우 쿼리로 인해 세션이 쌓이면, 동시 연결 수가 최대값에 도달해 신규 연결이 실패할 수 있다.
- 증상 — \"too many connections\" 오류, 애플리케이션에서 DB 연결 실패
- 대응 — 애플리케이션 커넥션 풀 크기 점검, 슬로우 쿼리 최적화, 읽기/쓰기 분리, 캐시 도입
3) 문자셋/인코딩 문제
DB 문자셋·컬레이션과 애플리케이션 인코딩 설정이 맞지 않으면, 문자 깨짐·저장 오류가 발생한다.
- 증상 — 특정 문자(이모지 등) 저장 실패, 데이터 조회 시 \"물음표\" or 깨진 문자열
- 대응 — DB·테이블·컬럼 문자셋을 애플리케이션과 일치(예: utf8mb4)시키고, 연결 시에도 같은 인코딩을 사용
한 줄 요약
장애·안정성을 다룰 때는 초반 5분/30분/1시간의 대응 체크리스트, 블레임 없는 포스트모템, 온콜 알람·런북·심리적 부담 관리, 그리고 디스크 풀·연결 폭주·문자셋 문제 같은 DB 장애 시나리오를 미리 정리해 두는 것이 중요하다. 이렇게 해 두면 실제 장애 시 대응 속도와 재발 방지 효과를 크게 높일 수 있다.
댓글 0