첫 incident — 어느 새벽의 30분

새벽 2시 17분

알람이 울렸다. 헬스체크 엔드포인트가 연속으로 실패하고 있다는 알림이었다. 슬랙 채널에 에러가 쌓이기 시작했고, 나는 노트북을 열었다.

처음 1분은 상황 파악에 썼다. 서버가 죽은 건지, 특정 기능만 망가진 건지, 아니면 외부 의존성 문제인지. 로그를 열었을 때 DB 커넥션 풀이 가득 찬 상태로 요청이 큐잉되고 있었다.

2시 19분 ~ 2시 32분

원인 추정부터 했다. 최근 배포가 두 시간 전에 있었고, 그 변경에 트랜잭션을 길게 잡는 코드가 포함되어 있었다. 커넥션이 반환되지 않아 풀이 소진된 것이었다.

롤백을 선택했다. 핫픽스를 바로 짜는 것보다 빠를 것이라고 판단했다. 이전 배포 아티팩트가 남아 있었기 때문에 재배포는 4분 안에 끝났다. 2시 32분에 헬스체크가 정상으로 돌아왔다.

실제 영향을 받은 시간은 15분 정도였다. 하지만 이 30분은 우리 팀이 여러 가지를 다시 생각하게 만든 계기가 됐다.

이후 바꾼 것들

커넥션 풀 모니터링: 커넥션 사용률이 80%를 넘으면 미리 알림이 오도록 했다. 100%가 되어서야 아는 것은 너무 늦다.

트랜잭션 범위 리뷰: 트랜잭션 안에서 외부 HTTP 호출을 하거나, 루프 안에서 쿼리를 반복하는 패턴을 코드 리뷰 체크리스트에 추가했다. 롱 트랜잭션의 주범 패턴이 정해져 있었다.

롤백 절차 문서화: 장애가 발생하면 판단력이 흐려진다. “이런 경우 롤백, 이런 경우 핫픽스”라는 기준을 미리 써두었다. 새벽에 졸린 눈으로 결정을 내릴 때 문서가 있는 것과 없는 것은 다르다.

배포 후 15분 모니터링: 배포 완료 후 15분 동안 주요 지표를 확인하는 것을 습관화했다. 배포했다고 바로 노트북을 덮는 것은 위험하다.

작은 팀에서 인시던트를 다루는 방식

큰 조직은 온콜 로테이션, SRE 팀, 사후 분석 프로세스가 체계화되어 있다. 우리 팀은 세 명이다. 그래서 “가능한 단순하게, 빠르게 복구, 재발 방지”라는 원칙으로 움직인다.

복잡한 프로세스보다 빠른 롤백 능력이 더 가치 있다는 것을 그날 새벽에 배웠다.

— by slecs