day-log

지난달 얘기다. 우리 팀 결제 API에 SLO를 새로 걸었고, burn rate 알림도 같이 설정했다. Google SRE 워크북에 나온 그 유명한 멀티 윈도우, 멀티 burn rate 알림 말이다. 문서 그대로 따라 붙였으니 잘 돌 줄 알았는데, 첫 주에만 새벽에 두 번 깨졌다. 둘 다 진짜 장애는 아니었다.처음 걸었던 설정우리 SLO는 30일 창(window) 기준 가용성 99.9%다. 워크북에서 권장하는 대로 두 개 알림을 걸었다.- alert: HighErrorBudgetBurnFast expr: | ( job:slo_errors_ratio:rate1h{job="payment-api"} > (14.4 * 0.001) and job:slo_errors_ratio:r..

지난달 얘기다. SLO 도입한 지 반 년쯤 지났고, 이제 대시보드에 error budget 남은 % 뜨는 것도 익숙해질 무렵이었다. 그런데 정작 알림이 이상하게 울렸다. 새벽 2시에 페이지 오는데 실제로 보면 이미 회복돼 있고, 반대로 며칠에 걸쳐 조금씩 새는 장애는 누구도 눈치를 못 챘다. 팀 회고 때 한 명이 "우리 burn rate alert가 알림 역할을 못 하고 있는 것 같다"고 얘기했고, 그때부터 3주 동안 정말 여러 번 갈아엎었다.처음엔 그냥 5분 창이었다부끄러운 얘기지만, 처음 세팅한 알림은 "최근 5분 error rate가 SLO 임계값의 10배 넘으면 페이지" 정도였다. 이게 왜 문제인지는 세팅한 사람도 알고 있었을 텐데, 그냥 다들 바빠서 방치돼 있었다.문제는 두 가지였다.첫째, 트래..

지난 화요일 새벽에 사고가 하나 있었다. 결제 API의 error rate가 슬금슬금 올라가고 있었는데, 우리가 그렇게 자랑하던 multi-window multi-burn-rate alert는 새벽 5시가 다 되어서야 울렸다. CS팀이 먼저 알아챈 걸 사후에 확인했다. 그 시간까지 error budget의 30% 가까이가 이미 타버린 상태였다.사실 이 alert 룰은 팀 내부에서 두 달 전에 큰 리팩터링을 마쳤던 것이라 더 뼈아팠다. Google SRE 워크북에 나온 그 표를 그대로 옮겨놓고, PromQL도 두 번 세 번 리뷰했었다. 근데 왜 안 울렸을까.룰은 정석대로였다우리가 쓰던 fast burn 알람은 이런 모양이었다.- alert: PaymentApiErrorBudgetBurnFast expr:..

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. PM이 슬랙에 던진 메시지였는데, 솔직히 그때까지 우리는 아무 알림도 못 받은 상태였다. SLO 대시보드를 켰다. 99.5% 목표인 가용성 SLI가 99.1%까지 떨어져 있었다. error budget이 이미 절반 가까이 타들어간 상태였다.근데 burn rate 알림은 조용했다. 한 번도 안 울렸다.우리가 깔아둔 알림 구성Google SRE 워크북에 나오는 multi-window multi-burn-rate 패턴 그대로였다. 페이지(긴급) 알림은 1시간 윈도우 + 5분 윈도우 둘 다 14.4배 burn rate를 넘기면 발사. 티켓(완만) 알림은 6시간 + 30분 윈도우에 6배 burn rate. 표준 구성이다.- al..

새벽에 burn rate 알람이 안 울렸다 — multiwindow SLO 알람 삽질 노트지난주 금요일, 정확히는 토요일 새벽 4시쯤에 한 통의 메시지로 잠에서 깼다. 새벽이라 페이저는 아니었다. 결제 팀 PL이 슬랙 DM으로 "혹시 새벽 2시 ~ 3시 사이에 결제 실패 폭주한 거 알고 있냐"고 물어본 게 시작이었다. 모니터링 알람은 한 통도 받지 못한 상태였다.대시보드를 켜보니 새벽 2시 12분부터 약 32분간 결제 API의 5xx 비율이 8%까지 튀었다가 자연 복구됐다. 우리 SLO는 가용성 99.9%, 즉 한 달에 약 43분의 에러 예산이 전부였다. 사실상 한 번의 사고로 한 달치를 다 태운 거다. 그런데 왜 burn rate 알람이 안 울렸지? 이날 알게 된 multiwindow burn rate..

P99 레이턴시가 살짝 튀었다고 한밤중에 페이저가 울리는 경험, 다들 한 번쯤 해봤을 것 같다. 우리 팀도 작년에 SLO를 도입하고 단일 burn rate 알람으로 굴리다가 알람 피로도 때문에 결국 6개월 만에 갈아엎었다. 이번 글에서는 그때 갈아탔던 멀티 윈도우, 멀티 burn rate 방식의 셋업 가이드를 정리해본다. Google SRE workbook에 나온 것을 우리 팀 환경에 맞춰 변형한 버전이고, Prometheus 기반이라면 거의 그대로 쓸 수 있다.단일 burn rate가 왜 안 되냐먼저 단일 윈도우 알람이 왜 망가지는지부터 짚고 가자. SLO 99.9% 가용성을 가정해보자. 30일 기준 에러 버짓은 약 43분이다. burn rate가 1이면 에러 버짓을 정확히 30일에 걸쳐 다 쓰는 속도..