day-log

작년 이맘때쯤 우리 팀에 Chaos Engineering 도입 미션이 떨어졌다. SRE 본부에서 "장애 대응 훈련을 코드로 돌릴 수 있게 만들자"라는 좀 추상적인 OKR이 내려왔고, 첫 분기는 Chaos Mesh, 두 번째 분기부터는 Litmus로 갈아탔다가, 결국 둘을 섞어서 쓰고 있다. 1년이 지나서 다시 정리해보니 둘 중 뭘 골라야 하느냐는 질문이 잘못된 질문이었다는 결론이 났다. 어느 팀이 어느 부분을 책임지냐에 따라 답이 달라진다.Litmus는 작년 가을 3.0으로 메이저 버전이 올라가면서 UI가 Harness UIcore 기반으로 싹 바뀌었고, Chaos Workflow가 Chaos Experiments로, Chaos Experiments가 Chaos Faults로 용어가 재정의됐다. 올해 1..

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..

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