day-log

SLO를 도입하고 나면 대부분 다음 관문에서 걸린다. "그래서 알림을 어떻게 쏘지?"에러 예산이 30일 기준으로 계산되니까 30일치를 보고 알림을 쏘면 너무 느리고, 5분만 보고 쏘면 배포 중 살짝 튀는 것에도 오작동한다. Google SRE 워크북에 있는 "multi-window multi-burn-rate" 패턴을 그대로 갖다 쓰긴 하는데, 이게 왜 이 조합인지, 내부에서 무슨 일이 벌어지는지는 대충 넘어가는 경우가 많다. 우리 팀도 그러다. 최근에 알림 튜닝을 다시 하면서 정리한 내용을 풀어본다.번-레이트라는 지표가 사실은 뭘 계산하는가번-레이트(burn rate)는 이름이 살짝 오해를 부른다. "얼마나 빨리 타고 있냐"인데, 기준선이 뭔지가 모호하다. 정확히는 이거다.번-레이트 = (관측 윈도우의..

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. 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..

SLO 알림 한 번 손봤다가 두 달을 끌었다. 이게 뭐 그리 복잡하다고. 처음엔 그렇게 생각했다.우리 팀은 작년 가을부터 핵심 API 다섯 개에 대해 SLO 기반 알림을 운영하고 있다. 가용성 99.9%, 레이턴시 P99 300ms 이하. 알림은 Prometheus + Alertmanager 조합. Google SRE Workbook에 나온 multi-window multi-burn-rate(MWMBR)를 그대로 베껴 쓰고 있었다. 처음엔 만족스러웠다. 그런데 올해 초부터 슬슬 문제가 보이기 시작했다.1차 시도: Workbook 그대로 베끼기처음 셋업할 때는 SRE Workbook 표를 그대로 옮겼다. 4개 티어, 각 티어마다 short/long 두 윈도우.- alert: HighErrorBudgetBu..