Error Budget 을 4분기 동안 *실제로* 쓴 기록 — Q1 부터 Q4 까지

작년 1월, 우리는 결제 서비스에 99.9% 월간 가용성 SLO 를 박았다. 월 43분 다운타임 = error budget. 이 budget 을 어떻게 쓸지 가 그해의 한 해를 정의했다.

이 글은 그 4분기의 실측 기록 이다. 각 분기가 다른 교훈 을 줬다.

Q1 — Budget 이 너무 많았다

1월·2월·3월의 다운타임 합 — 11분. 분기 budget 의 8.5% 만 썼다.

처음에 우리는 기뻐했다. 그러다 깨달았다 — budget 이 남아 있다는 건 우리가 너무 보수적으로 운영 하고 있다는 신호였다. 새 기능 배포 페이스가 느렸고, 위험한 변경은 미루고 있었다.

Error budget 의 절반은 변동성을 사용해서 더 빠르게 배포할 권리 를 의미한다. 안 쓰면 낭비 가 아니라 기회 비용 이다.

Q1 회고 결정 — Q2 에는 의도적으로 budget 을 쓰는 변경을 늘리자. 이게 다음 분기의 트리거가 됐다.

Q2 — Budget 을 3일 만에 다 썼다

4월 중순, 새 결제 게이트웨이로 점진적 마이그레이션을 시작했다. 3% 트래픽 → 10% → 30% → 70% → 100%. 각 단계마다 일주일 의 검증 윈도우.

10% → 30% 로 가던 4월 23일 화요일, 새 게이트웨이의 connection pool 설정 오류 가 프로덕션에서만 드러났다. 47분 다운타임. 그 다음 주 같은 패턴의 secondary 사고 17분.

분기 budget = 130분. 64분을 3일 만에 사용. 우리는 즉시 feature freeze 를 발동했고, 남은 분기 동안 신기능 배포 X 를 결정했다.

Budget 빠른 소진은 운이 나쁜 게 아니다. 우리 변경의 risk profile 이 SLO 의 가정과 다르다 는 신호다.

Q2 의 진짜 교훈은 47분 사고 자체 가 아니라, 연계된 17분 사고 였다. 큰 사고 후에는 follow-up 사고가 자주 따라온다 — 운영팀의 피로, 즉시 fix 의 부작용, 팀 주의 분산. 우리는 이것을 aftermath effect 라 명명하고 큰 사고 후 7일 동안 의도적으로 변경 빈도를 낮추는 정책을 박았다.

Q3 — Frozen 상태의 예상치 못한 발견

7월·8월·9월. 신기능 배포가 멈춰 있는 동안, 팀이 한 일 은:

• 기존 시스템의 flaky test 87 개 → 14 개로 줄임
• 알람 noise 가 주당 41건 → 9건 으로 감소
• 두 SRE 가 3년간 미뤄온 alerting 인프라 재작성 을 완료

분기 다운타임 합계 — 4분. 분기 budget 130 분 중 3%.

이 분기가 가장 신뢰성이 좋았던 분기 였다. 변경이 없으면 신뢰성이 좋다 는 동어반복 이상의 발견이 있었다 — 동결 기간이 기술 부채 를 갚을 의식적 시간을 만들어줬다.

Error budget freeze 가 처벌 이 아닐 수도 있다. 의식적으로 기술 부채 분기 를 만드는 도구가 될 수 있다.

Q4 — SLO 자체를 바꿨다

10월에 들어가면서 우리는 4분기 데이터를 모아 봤다.

분기      Budget 사용률
Q1            8.5%
Q2          ~95%  (그중 70% 가 한 사고)
Q3            3%
Q4 (예상)   ?

이 분포가 우리에게 말한 것 — SLO 99.9% 가 우리 시스템의 자연스러운 신뢰성 과 맞지 않는다. 평균은 적합한데, 분포가 극단적 이다. 한 분기에 budget 을 거의 다 쓰고, 다음 분기에 budget 의 3% 만 쓴다.

11월 말 SRE·엔지니어링·제품 합동 검토에서 결정 — SLO 를 99.9% 단일 임계 가 아니라 Multi-SLI 구성 으로 바꾼다.

이전:
  결제 가용성 99.9%

이후:
  결제 가용성 99.95%        (가용성 자체는 더 높이)
  결제 응답 p99 < 800ms     (이전엔 명시 X)
  결제 가시성 5초 안       (사고 발견 SLI)
  결제 복구 30분 안        (사고 복구 SLI)

SLI 가 4 개 가 되니, 어느 하나가 깨져도 budget 이 따로 차감 된다. 한 사고가 하나의 큰 budget 을 한 번에 소진하는 게 아니라, 서로 다른 SLI 의 budget 을 부분적으로 소진. 이게 Q1·Q2 의 극단적 분포 를 부드럽게 만들었다.

4분기를 한 줄로

• Q1 — Budget 안 쓰는 게 비용 이다
• Q2 — 빨리 쓰는 건 위험 신호 다 (그리고 aftermath 가 따라온다)
• Q3 — Freeze 는 부채 갚는 시간 일 수 있다
• Q4 — 분포가 극단적이면 SLO 자체가 잘못됐다

책의 error budget 은 한 줄짜리 가이드 다. 실제는 분기마다 다른 의미 를 가진다.

그래서 error budget 은 어떻게 운영하나

이미 SLO 를 박아 놓은 팀의 error budget 운영은 위 4 패턴 중 지금 분기가 어디 인지 식별하는 데서 시작한다. 어디인지 알면 다음 행동 이 명확해진다 — 운영이 헷갈리는 SRE / 플랫폼 리드에게 필요한 건 이 식별이다. SLO 가 처음 인 팀에게는 일러도 된다. 일단 SLI 정의부터.