판단 없이 즉시 실행하는 기계적 완화 조치. 롤백·오토스케일링·트래픽 차단처럼 원인 규명 없이 바로 칠 수 있는 것들을 미리 정해 둔다.
왜 원인부터 찾으면 안 되나
-
본능 — "원인을 알아야 고치지" → 로그 분석 → 코드 확인 → 핫픽스 배포
-
결과 — 그 사이에도 장애는 계속된다
- First Action "영향부터 끊는다" → 롤백 → 복구 확인 → 그 다음에 원인 분석
실측이 이를 뒷받침한다 — 롤백을 First Action으로 쓴 장애가 핫픽스를 쓴 장애보다 약 50% 빨리 해결됐다. 핫픽스는 원인을 알아야 만들 수 있지만 롤백은 몰라도 되기 때문이다.
장애 라이프사이클에서의 위치
[탐지] → ① Open → ② Investigating → ③ Identified ← First Action 이 여기
- ④ Monitoring → ⑤ Resolved → ⑥ Closure
② Investigating에서 원인을 다 밝히고 나서 ③으로 가는 것이 아니다. 영향 범위만 파악되면 바로 완화로 넘어간다.
사전 정의가 핵심이다
미리 정해 둘 것
- 어떤 상황에 무엇을 칠 것인가 (배포 직후 이상 → 롤백)
- 누가 결정 권한을 갖는가
- 실행 절차는 몇 단계인가 (버튼 하나여야 한다)
정해 두지 않으면
- 장애 한복판에서 "롤백해도 되나요?" 를 묻느라 시간이 간다
- MTTFA(장애 발생 → First Action) 가 길어진다
롤백할 수 없는 변경
스키마 마이그레이션 · 데이터 이관 · 외부 시스템 연동 변경은 되돌릴 수 없는 경우가 많다
- 배포 전에 '되돌릴 수 있는 단위' 로 쪼개 두는 것이 설계 요건이다
- (컬럼 추가는 되돌리기 쉽지만 컬럼 삭제는 어렵다 — expand/contract 패턴)
면접 함정
- ❌ "원인을 먼저 찾습니다" → 복구가 늦어진다. 영향 차단이 먼저다.
- ❌ "밤새 고쳤습니다" → 영웅담은 체계 부재의 신호로 읽힌다.
무엇이 First Action이 될 수 있나
- 조건 — ① 원인을 몰라도 실행 판단이 가능하다
- ② 실행 자체가 새로운 위험을 만들지 않는다
- ③ 몇 분 안에 끝난다
해당하는 것
- 직전 배포 롤백
- 오토스케일 (인스턴스 증설)
- 문제 인스턴스 격리 (LB 에서 제외)
- 기능 플래그 off
- 트래픽 스로틀링·차단
해당하지 않는 것
- 핫픽스 배포 (원인을 알아야 만든다)
- DB 스키마 변경 (되돌리기 어렵다)
- 캐시 전체 삭제 (DB 직격으로 더 큰 장애를 부를 수 있다)
기능 플래그가 First Action을 만든다
배포와 릴리스를 분리해 두면
- 코드는 이미 나가 있고 플래그만 off 하면 된다
- 롤백보다 빠르고 영향 범위도 좁다 (해당 기능만)
반대로 플래그 없이 배포하면
- First Action 선택지가 '전체 롤백' 하나뿐이 된다
- 무관한 다른 변경까지 함께 되돌아간다
자동화의 경계
- 자동 실행이 안전한 것 — 오토스케일 · 헬스체크 실패 인스턴스 격리
- 사람 판단이 필요한 것 — 롤백 (데이터 정합성 영향 가능)
- 트래픽 차단 (매출 직결)
자동화하더라도 '무엇이 언제 자동 실행됐는지' 를 알림으로 남겨야 대응 중인 사람이 상황을 오판하지 않는다