SLO·SLI·오류 예산(error budget)과 온콜 핸드오프·알림 정책을 배포 전 체크리스트로 정리한다. 가용성 99.9% 월간 허용 분, burn rate, 런북 첫 5분, 2주 도입 순서, 구글 SRE·OpenTelemetry·Prometheus 출처와 카나리·Sentry·성능 예산 내부링크. 개발자·백엔드·데브옵스·클라우드·API 관측 실무 가이드.
SLO(Service Level Objective) 없이 온콜만 돌리면 알림은 늘고 개선은 멈춘다. 오류 예산(error budget)은 “이번 달에 허용 가능한 실패 분량”을 숫자로 박아, 기능 배포와 안정성 작업을 같은 테이블에 앉히는 도구다. 가용성 99.9%를 목표로 두면 한 달에 약 43분 실패가 예산이고, 그 숫자를 넘기면 신규 기능보다 신뢰성 티켓이 먼저다.
배포 게이트는 카나리 배포·헬스체크와 프로덕션 배포 체크리스트를, 관측 스택은 OpenTelemetry 트레이싱·Prometheus·Grafana·Sentry 런타임 에러를 같이 보면 빈칸이 줄어든다. 아래는 서비스 레벨 지표 정의부터 온콜 핸드오프까지, PR·스프린트 리뷰에 붙일 수 있는 점검 목록이다.
용어를 섞으면 회의가 길어진다. 구글 SRE 문서도 세 층을 분리한다. 먼저 표로 갈라 두고, 팀에 “우리는 지금 어느 줄을 말하고 있나”만 합의해도 온콜 티켓이 줄어든다.
| 용어 | 한 줄 정의 | 팀에서 쓰는 곳 |
|---|---|---|
| SLI | 측정 가능한 지표(성공 요청 비율, 지연 p99 등) | 대시보드·알림 쿼리 원천 |
| SLO | SLI에 대한 내부 목표(예: 30일 성공률 ≥99.9%) | 스프린트 우선순위·배포 동결 판단 |
| SLA | 고객·계약 상대와의 약속 + 위반 시 보상 | 법무·세일즈 문서. 보통 SLO보다 느슨 |
| 오류 예산 | 1 − SLO. 허용 실패 분량 | 기능 vs 안정성 자원 배분 |
SLA를 먼저 박고 SLO를 맞추려 하면 과잉 엔지니어링이 난다. 내부 목표는 계약보다 빡세게 두고, 계약 위반 전에 팀이 먼저 빨간불을 보는 구조가 실무에 가깝다.
한 줄 판정 — “이 알림이 어떤 SLI를 지키려는가?”에 답이 없으면 그 알림은 소음 후보다. 쿼리부터 다시 쓴다.
지표를 20개 나열하면 온콜이 죽는다. 첫 주는 로그인·핵심 쓰기·핵심 읽기처럼 돈·신뢰가 걸린 경로 3개만 고른다. 나머지 배치는 2주 뒤에 붙인다.
요청 단위가 애매한 배치·웹소켓은 “작업 단위 성공 여부”로 SLI를 정의한다. 웹훅 수신은 멱등 키와 재시도 폭주 방지가 같이 가야 한다. 관련 순서는 웹훅 재시도·멱등을 참고한다.
가용성 목표를 퍼센트로만 말하면 감이 없다. 분·요청 수로 바꿔 적는다. 아래는 대략 값이다. 팀은 실제 월간 유효 요청 수를 분모에 넣으면 된다.
| SLO(가용성) | 월간 허용 다운타임(약) | 실무 감각 |
|---|---|---|
| 99% | 약 7.3시간 | 내부 도구·실험 서비스에 흔함 |
| 99.9% | 약 43분 | 일반 B2B API 출발점 |
| 99.95% | 약 22분 | 결제·인증 핵심 경로 |
| 99.99% | 약 4.3분 | 멀티 AZ·자동 페일오버 전제 |
요청 기반이면 오류 예산 요청 수 = 전체 유효 요청 × (1 − SLO)다. 한 달에 1,000만 유효 요청·SLO 99.9%면 예산은 1만 실패 요청이다. 대시보드에 “남은 예산 %”를 켜 두면 배포 회의가 짧아진다.
알림이 많으면 온콜은 무감각해진다. 페이지(전화·푸시)는 “지금 사람이 개입해야 하는 사용자 영향”에만 쓰고, 나머지는 티켓·주간 리뷰로 내린다.
소음 신호 — 온콜이 “일단 확인” 후 아무 조치 없이 close하는 비율이 높으면 임계값·필터가 틀린 것이다. 사람을 더 넣지 말고 규칙을 줄인다.
로테이션만 정하고 인수인계를 안 하면, 주말 장애 때 “저 사람은 알고 있는데”가 반복된다. 핸드오프는 30분 미팅이 아니라 문서 한 장 + 대시보드 상태 확인으로 끝내는 편이 지속 가능하다.
런북이 위키 장문이면 장애 때 안 읽는다. 알림 하나당 한 화면이 목표다. 증상 → 영향 범위 → 즉시 조치 → 에스컬레이션 → 종료 조건을 고정 순서로 둔다.
카나리 중 에러율 상승처럼 배포 연동 알림은 롤백 버튼 위치와 담당 파이프라인 이름을 런북 상단에 박는다. 배포 회귀 사례는 카나리 5% 트래픽 회귀 글의 헬스체크·롤백 순서를 그대로 런북 초안으로 쓸 수 있다.
예산이 남아 있는데 매번 배포를 막으면 제품이 멈추고, 예산이 바닥났는데 기능을 밀어 넣으면 장애가 일상이 된다. 남은 예산 구간별로 자동에 가까운 규칙을 미리 적는다.
| 남은 예산(월간 창) | 기능 배포 | 신뢰성 작업 |
|---|---|---|
| 70% 이상 | 정상 카나리·일반 리뷰 | 백로그 소화, 예방 작업 |
| 40~70% | 위험 변경은 추가 리뷰·피크 시간 회피 | 토일 감소, 알림 소음 정리 우선 |
| 15~40% | 핵심 경로 외 기능 속도 제한 | 스프린트 용량 30%+ 신뢰성 |
| 15% 미만 또는 소진 | 핫픽스·보안만. 신규 기능 동결 | 원인 제거·SLO 재협상 회의 |
숫자는 예시이다. 트래픽이 작은 팀은 절대 실패 횟수가 적어 예산이 들쭉날쭉하다. 그때는 요청 수 기반보다 이벤트·합성 모니터링 비중을 높이거나, 창을 분기 단위로 늘리는 선택을 문서에 남긴다.
한 번에 “전사 SRE 체계”를 만들지 않는다. 서비스 하나, 경로 세 개, 알림 다섯 개로 끝내는 2주 스프린트가 현실적이다.
범위 고정 — 2주 목표에 “모든 마이크로서비스 SLO”를 넣지 않는다. 결제 또는 로그인 하나라도 예산 대시보드가 보이면 성공이다.
도구를 사서 해결되는 문제가 아니다. 아래 패턴은 체크리스트에 “금지” 칸으로 넣어 두는 편이 낫다.
내부 연계: 카나리 배포 회귀 · Sentry 런타임 에러 · OpenTelemetry 실전 · Prometheus·Grafana · 회로 차단기 · 성능 예산
내부 SLO를 먼저 정한다. SLA는 고객 계약·보상과 묶이므로 법무·세일즈와 맞춰야 하고, 보통 내부 목표보다 느슨하게 둔다. SLO 없이 SLA만 있으면 위반 직전에야 뛰어다니는 구조가 된다.
형식적인 월간 예산표까지는 과할 수 있다. 대신 “핵심 경로 합성 모니터링 1개 + 실패 시 알림 1개 + 롤백 방법 1줄”만 있어도 온콜 수준의 최소 세트다. 트래픽이 늘면 그때 요청 기반 예산으로 올린다.
아키텍처와 복구 시간에 맞춘다. 단일 존·수동 페일오버면 99.99%는 매주 예산이 탄다. 멀티 존 자동 복구·카나리·빠른 롤백이 준비된 핵심 결제 경로에 높은 목표를 쓴다. 근거 없는 네 개 9는 문서 장식에 가깝다.
90일간 조치 없이 닫힌 페이지 알림부터 삭제하거나 티켓으로 강등한다. 사용자 SLI와 무관한 CPU·디스크 경고는 업무 시간 티켓으로 내린다. 알림마다 런북이 없으면 그 알림을 끈다.
핫픽스·보안 패치·데이터 손상 방지는 예외로 두는 팀이 많다. 그 외 신규 기능은 동결하고 신뢰성 작업에 용량을 돌리는 식이 일반적이다. 예외 승인 경로를 정책 문서에 한 줄로 적어 두면 논쟁이 줄어든다.
넣는다. LCP·INP 같은 필드 지표를 “좋은 비율” SLI로 정의할 수 있다. 백엔드 가용성만 보면 앱은 200을 주는데 사용자는 느려서 이탈하는 사각지대가 남는다. 성능 예산 문서와 SLO 리뷰를 같은 주간에 묶는 편이 좋다.
