정책의 출발점은 이미 정의된 SLI다
SLO를 만들고 대시보드에 99.x%를 띄운다고 배포 기준이 생기지는 않습니다. 실제 잣대가 되려면 어떤 사용자 결과를 측정하는지, 어느 수준을 목표로 삼는지, 어느 기간을 평가하는지, 에러 버짓을 얼마나 썼을 때 어떤 종류의 변경을 제한하는지, 누가 예외를 승인하는지까지 하나의 운영 정책으로 합의해야 합니다. Google SRE도 이 지점을 분명히 나눕니다.[2] 조직이 에러 버짓을 실제 의사결정과 업무 우선순위에 쓰기로 합의하지 않으면 SLO는 또 하나의 보고용 숫자에 머무릅니다.
목표값부터 정하면 순서가 뒤집힙니다. 먼저 중요한 사용자 여정을 정의하고 성공과 실패를 어떤 이벤트로 판단할지 정해야 합니다. 정책이 그 앞 단계에서 받아야 할 입력은 여덟 가지입니다.
여기에 조건이 하나 더 붙습니다. SLI 자체를 믿을 수 없는 상태에서는 에러 버짓도 배포 잣대가 되지 못합니다. 계측이 끊겼는데 이를 100% 정상으로 처리하거나 실제 요청의 상당 부분이 분모에서 사라진 상태라면 에러 버짓이 충분히 남았다는 계산도 의미가 없습니다. 그래서 정책에는 버짓 상태뿐 아니라 측정을 믿는지 믿지 못하는지의 상태도 필요합니다.
- 핵심 사용자 여정
- 정책에서 필요한 이유: 어떤 사용자 결과를 보호하는지 고정한다
- 성공 이벤트와 유효 이벤트
- 정책에서 필요한 이유: 목표값과 에러 버짓의 분자와 분모를 정한다
- 제외 규칙
- 정책에서 필요한 이유: 사용자 취소나 잘못된 요청을 서비스 실패와 혼동하지 않는다
- 측정 지점
- 정책에서 필요한 이유: 실제 사용자 경험과 측정값 사이의 거리를 안다
- 계측 포괄 증거
- 정책에서 필요한 이유: 계측 누락을 정상으로 오해하지 않는다
- 핵심 사용자 구간
- 정책에서 필요한 이유: 전체 평균이 특정 사용자 집단의 실패를 가리는지 확인한다
- 결과 미상 요청 처리
- 정책에서 필요한 이유: 결과를 알 수 없는 요청을 임의로 성공 처리하지 않는다
- 배포 버전 연결
- 정책에서 필요한 이유: 버짓 소비와 특정 변경 사이의 관계를 조사한다
99.9%부터 적고 시작하지 않는다
목표값은 서비스 등급을 장식하는 숫자가 아닙니다. Google SRE는 세 조건을 함께 요구합니다.[2] 제품 쪽에서는 그 이하의 성능이면 사용자를 위해 엔지니어링 시간을 쓸 가치가 있다고 동의해야 합니다. 개발 쪽에서는 버짓이 소진되면 실제 행동을 바꾸겠다고 합의해야 합니다. 운영 책임자는 과도한 노역이나 소진 없이 목표를 방어할 수 있어야 합니다.
따라서 99.9%를 기본값으로 놓고 이유를 나중에 붙이는 방식은 피하는 편이 낫습니다. 목표값을 정할 때는 적어도 여섯 질문에 답해야 합니다. 이 사용자 여정이 어느 정도 실패하면 실제 사용자가 문제를 체감하는가. 금전과 데이터, 권한, 업무 중단처럼 실패 비용이 큰 여정인가. 현재 지표는 어느 정도이고 그 측정값을 믿을 수 있는가. 정상적인 운영 여건에서 이 목표를 유지하는가. 더 높은 목표를 위해 더해지는 비용과 운영 복잡성이 사용자에게 실제 가치를 주는가. 지금 목표가 너무 느슨해 상당한 사용자 피해가 생긴 뒤에야 정책이 작동하지는 않는가입니다.
처음부터 완벽한 숫자를 찾을 필요도 없습니다. Google SRE는 초기 목표를 측정하고 반복적으로 고치는 접근을 권합니다.[2] 지금 달성할 수 없는 더 높은 목표가 필요하다면 이를 지향 목표로 따로 추적합니다. 에러 버짓 정책을 즉시 발동시키는 운영 목표와 구분하는 방법도 제시합니다. 즉 목표값에는 숫자만이 아니라 왜 이 숫자인지에 대한 근거가 붙어야 합니다.
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
평가 기간도 정책의 일부다
같은 목표값이라도 어느 기간을 보느냐에 따라 결정이 달라집니다. Google SRE는 이동 창과 달력 정렬 창을 구분합니다.[2] 이동 창은 월말에 발생한 장애가 다음 달 1일이 됐다는 이유만으로 사용자 경험에서 사라지지 않는다는 점에서 사용자 경험과 잘 맞습니다. 달력 창은 분기별 인력과 프로젝트 계획처럼 조직의 계획 주기와 잇기 쉽습니다.
Google은 4주 이동 창을 범용적인 출발점으로 소개하지만 이를 표준 기간으로 강제하지 않습니다. 짧은 창은 빠른 운영 조정에, 긴 창은 큰 신뢰성 투자 판단에 더 맞는다고 설명합니다. 따라서 정책에는 창의 유형과 길이, 배포와 변경 판단에 쓰는 운영 검토 주기, 신뢰성 투자 우선순위를 보는 장기 검토 주기, 그리고 이 창이 사용자 경험과 업무 주기에 맞는 이유를 함께 기록합니다.
28일과 30일, 한 달은 비슷해 보여도 늘 같은 의미가 아닙니다. 평일과 주말 트래픽이 크게 다르거나 월말 업무가 몰리는 서비스라면 창을 고르는 일 자체가 지표 결과를 바꿉니다.
에러 버짓은 항상 허용 다운타임 몇 분이 아니다
에러 버짓의 기본 개념은 단순합니다. 목표값을 1에서 뺀 값이 버짓입니다. 그러나 실제 소비량의 단위는 지표 계산 방식에 따라 달라집니다.
유효 요청 200,000건에 대한 성공률 목표가 99.5%라면 해당 기간에 허용되는 실패 이벤트는 1,000건입니다. 허용 실패 이벤트는 유효 이벤트에 1에서 목표값을 뺀 값을 곱해 구합니다. 버짓 소비율은 실제 실패 이벤트를 허용 실패 이벤트로 나눠 구합니다. 이 경우 에러 버짓은 다운타임 몇 분이 아니라 실패한 이벤트 수를 중심으로 읽습니다. 반면 시간을 일정 구간으로 나눠 각 구간이 성공인지 실패인지 판정하는 목표라면 실패한 시간 조각이 버짓을 소비합니다.
현재 클라우드 사업자 문서도 요청 기반 지표와 시간 창 기반 지표를 구분합니다. OpenSLO v1은 버짓 산정 방식을 발생 건수와 시간 조각, 비율 시간 조각으로 명시적으로 나눕니다.[1] 정책 템플릿에는 목표값만 적지 말고 버짓 산정 방식과 소비 계산식까지 기록해야 합니다. 특히 트래픽 양에 따라 분모가 변하는 요청 기반 목표를 운영 중간에 평가한다면, 이번 기간의 최종 에러 버짓이 정확히 몇 건인지가 아직 확정되지 않을 수 있습니다. 달력 창에서 미래 요청량을 모르는 경우 중간 시점의 판단에는 이런 불확실성이 있다는 점도 Google SRE가 지적합니다.[2]
남은 예산보다 지금 어떤 정책 상태인가를 정한다
대시보드에는 여러 숫자가 있습니다. 목표 준수율, 허용된 에러 버짓, 사용한 버짓, 남은 버짓, 최근 소비량, 소진 속도입니다. 문제는 이 숫자가 행동으로 바뀌지 않을 때입니다. 운영 정책에서는 숫자를 네 가지 정책 상태로 옮기는 편이 관리하기 쉽습니다.
CONSTRAINED로 넘어가는 정확한 수치를 모든 조직에 똑같이 적용할 이유는 없습니다. 팀이 필요하다면 남은 버짓의 비율, 기간 종료 전 소진 가능성, 특정 규모의 단일 사건 같은 조건을 정하면 됩니다. 그러나 그 값을 인터넷의 템플릿에서 가져오기보다 서비스의 배포 빈도와 트래픽 패턴, 실패 피해, 대응 능력에 맞춰야 합니다.
버짓 소비를 어떤 속도로 계산하고 언제 호출과 티켓, 대시보드로 전달할지는 경보 설계의 문제입니다. 여기서는 정책에 어떤 상태가 필요한지까지만 정합니다.
정책 상태 | 의미 | 기본 운영 태도 |
|---|---|---|
| NORMAL | 합의한 범위 안에서 버짓이 충분하다 | 기존 릴리스 정책에 따라 변경한다 |
| CONSTRAINED | 버짓 여유가 줄었거나 현재 소비 추세가 위험하다 | 위험이 큰 변경을 줄이고 증거와 승인 수준을 높인다 |
| EXHAUSTED | 해당 기간의 에러 버짓을 모두 소비했다 | 신뢰성 회복 전에는 추가 위험을 만드는 변경을 기본 제한한다 |
| MEASUREMENT_UNTRUSTED | SLI 포괄성이나 데이터 품질 문제로 버짓을 믿을 수 없다 | 자동 허용하지 않고 수동 판단 또는 보수적 변경 정책을 적용한다 |
버짓이 소진됐다고 모든 배포가 같은 위험은 아니다
에러 버짓 정책에서 가장 위험한 단순화는 버짓이 있으면 배포 가능, 없으면 모든 배포 금지라는 한 줄입니다. 실제 변경에는 서로 다른 목적과 위험이 있습니다. 버짓 상태와 변경 유형을 결합하는 편이 더 현실적입니다.
이 표의 목적은 모든 회사가 똑같이 운영하라는 것이 아닙니다. 정해야 할 것은 버짓이 줄어들수록 어떤 종류의 위험을 덜 받아들일 것인가입니다. Google의 예시 에러 버짓 정책도 소진 시 기능 변경을 제한하면서 최우선 등급과 보안 수정을 예외로 둡니다.[3] 또한 의존성이 원인인 목표 미달의 처리도 내부 릴리스를 계속한다와 추가 사고를 막기 위해 변경 동결을 적용한다는 서로 다른 접근이 있으므로, 서비스에 맞는 선택을 정책에 기록하라고 설명합니다.
EXHAUSTED는 아무것도 건드리지 않는다가 아니라 추가적인 사용자 위험을 만드는 변경의 기본 허용 수준이 낮아진 상태로 읽는 편이 정확합니다. 실제 변경을 일시 정지와 기능 플래그 끄기, 트래픽 회수, 롤백, 전진 수정 가운데 어떤 방식으로 실행할지는 별개의 문제입니다. 코드와 설정, DB, 데이터, 기능 노출, 트래픽을 함께 다루는 롤백 설계가 그 실행 계약을 맡습니다.
변경 유형 | NORMAL | CONSTRAINED | EXHAUSTED |
|---|---|---|---|
| 신규 기능·실험 | 일반 릴리스 정책 | 영향 범위 축소, 추가 검토 또는 연기 | 기본적으로 제한 |
| 정기 설정·인프라 변경 | 정상 진행 | 필요성과 변경 위험 재검토 | 긴급하지 않으면 연기 |
| 고위험 DB·데이터 변경 | 별도 고위험 변경 정책 | 원칙적으로 보수적 적용 | 기본적으로 제한 |
| 신뢰성 개선 | 정상 진행 | 우선순위 상향 | 필요 시 우선 수행 |
| 보안·긴급 수정 | 위험에 따라 진행 | 지연 위험과 변경 위험 비교 | 사전 정의된 예외·승인 절차로 수행 |
| 장애 완화·롤백 | 필요 시 수행 | 필요 시 수행 | 서비스 회복을 위해 수행 |
안정성 작업도 정책에 적어야 한다
기능 동결만 적고 그동안 안정화한다고 쓰면 실제 업무 우선순위는 여전히 모호합니다. 버짓이 빠르게 소비되거나 소진됐을 때 어떤 신뢰성 작업을 시작할지도 정의해야 합니다.
예를 들면 여덟 가지입니다. 에러 버짓을 가장 많이 소비한 실패 유형 분석, 반복되는 신뢰성 결함 수정, 위험한 의존성 완화, 테스트나 배포 검증 강화입니다. 나머지는 복구 시간을 줄이는 자동화, 용량과 자원 포화 문제 해결, 잘못 정의된 지표나 이벤트 분류 수정, 반복적으로 예외를 요구하게 만드는 구조적 원인 제거입니다. Google SRE도 에러 버짓을 신뢰성 프로젝트의 우선순위에 쓸 수 있다고 설명합니다.[2] 같은 인력을 투입한다면 실제 버짓 소비를 더 크게 줄일 작업을 먼저 고르면 됩니다.
여기서도 버짓 소진 시 팀 전체가 신뢰성 작업만 한다는 식의 값을 범용 규칙으로 만들 필요는 없습니다. 정책이 정해야 하는 것은 방아쇠와 신뢰성 작업 우선순위 변경, 담당자, 완료해야 할 최소 조건, 그리고 정책 상태에서 빠져나오는 종료 조건입니다. 이동 창이라면 시간이 지나면서 과거 실패가 창 밖으로 빠져나가 버짓이 저절로 회복되기도 합니다. 그래서 숫자가 다시 정상 범위에 들어왔다는 이유만으로 모든 제한을 자동 해제하면 원인이 그대로 남습니다. 중대한 미달에서는 버짓 회복과 함께 반복 위험을 줄이는 조치가 수행됐는지를 종료 조건으로 두면 됩니다.[3]
예외는 장애가 난 뒤 협상하지 않는다
에러 버짓 정책이 가장 필요한 순간은 원래 계획과 현실이 부딪칠 때입니다. 버짓은 없지만 즉시 적용해야 하는 보안 수정이 있을 수 있습니다. 현재 버전의 장애를 완화하려는 배포가 필요할 수도 있고, 데이터 손실을 막으려고 새 변경을 넣어야 할 수도 있습니다. 이때 매번 이번만 배포해도 되는가를 처음부터 토론하면 정책이 의사결정 비용을 줄이지 못합니다.
예외를 많이 허용하는 것이 목표는 아닙니다. 반대로 예외가 반복해서 필요하다면 기존 목표값이나 변경 정책이 실제 운영과 맞지 않는다는 신호입니다. 그 경우 예외를 계속 더하기보다 정책 자체를 다시 검토해야 합니다.
항목 | 기록할 내용 |
|---|---|
| 예외 후보 | 어떤 상황이 예외 후보인가 |
| 요청자 | 누가 예외를 요청했는가 |
| 사유 | 왜 현재 정책을 그대로 적용하면 더 큰 위험이 생기는가 |
| 사용자 영향 | 지연할 경우 사용자가 겪을 피해 |
| 변경 위험 | 변경 자체가 더할 위험 |
| 완화책 | 영향 범위와 실패 영향을 제한할 방법 |
| 승인자 | 누가 최종 우회 권한을 갖는가 |
| 유효 기한 | 예외가 언제까지 유효한가 |
| 증거 | 승인 당시 사용한 데이터 |
| 사후 검토 | 결과와 추가 버짓 소비를 언제 검토할 것인가 |
SLO 책임자 한 명만 지정해서는 부족하다
에러 버짓은 개발팀과 운영팀 사이의 숫자가 아닙니다. Google SRE는 제품 관리자와 개발팀, 운영 책임자가 정책에 함께 동의해야 한다고 설명하며 SLO 문서에는 작성자와 검토자, 승인자, 다음 검토일을 남기라고 권합니다.[2] 정책 적용에 이견이 생길 경우를 위한 상위 이관 경로도 필요합니다. 실무에서는 책임을 여섯 역할로 나눌 수 있습니다.
작은 팀에서는 한 사람이 여러 역할을 맡아도 됩니다. 중요한 것은 직함의 수가 아니라 누가 숫자를 계산하고 누가 배포를 제한하며 누가 예외를 승인하는지가 모호하지 않은 것입니다.
- 서비스·제품 책임자
- 서비스와 제품 책임자는 사용자 피해와 사업 요구를 기준으로 목표값의 적절성을 승인합니다.
- SLO 책임자
- SLO 책임자는 SLI와 목표값, 평가 기간, 버짓 계산의 정의와 데이터 신뢰성을 유지합니다.
- 엔지니어링·변경 책임자
- 엔지니어링과 변경 책임자는 실제 변경 정책을 적용하고 제한 상태를 실행합니다.
- 신뢰성 작업 책임자
- 신뢰성 작업 책임자는 버짓 소비의 원인과 신뢰성 작업의 우선순위를 관리합니다.
- 예외 승인자
- 예외 승인자는 정책 우회를 승인하고 그 사유를 기록합니다.
- 상위 이관 책임자
- 상위 이관 책임자는 버짓 계산이나 정책 적용에 이견이 있을 때 최종 판단을 내립니다.
검토 주기도 미리 정한다
서비스는 변합니다. 트래픽 구성이 달라지고 고객이 바뀌고 의존성이 교체되며 이전에는 중요하지 않던 사용자 여정이 핵심 기능이 되기도 합니다. SLO를 한 번 승인한 뒤 몇 년 동안 그대로 쓰면 처음의 합리적인 목표도 나중에는 잘못된 운영 잣대가 됩니다.
Google SRE는 SLO 운영을 처음 시작할 때는 월 단위처럼 비교적 자주 검토합니다. 적합성이 검증된 뒤에는 분기 단위나 더 긴 주기로 줄일 수 있다고 설명합니다.[2] 최근의 SLO 재검토 논의도 복잡한 서비스에서는 SLO를 지나치게 넓게 적용하지 말고 어떤 질문에 답하기 위한 SLO인지 좁혀서 정의하라고 지적합니다. 서비스 행동과 작업 부하가 바뀌면 계속 검증해야 한다는 뜻입니다.
달력 검토 외에 사건 기반 검토 조건도 두는 편이 좋습니다. 핵심 사용자 여정이 바뀜, 지표 이벤트나 측정 지점이 바뀜, 주요 의존성이 교체됨, 사용자와 테넌트, 리전 구성에 큰 변화가 생김, 배포 빈도나 변경 모델이 달라짐입니다. 나머지는 반복적인 정책 예외가 발생함, SLO는 만족하지만 사용자의 신뢰성 불만이 계속됨, SLO를 반복적으로 놓치지만 사용자 영향이 거의 없음입니다. 마지막 두 경우가 특히 중요합니다. SLO가 실제 사용자 경험과 상관관계를 잃었다면 목표값만 조이는 것이 아니라 지표 자체를 다시 검토해야 합니다.
정책 템플릿은 무엇을 담나
템플릿의 숫자는 조직이 직접 채웁니다. 99.9%나 30일, 특정 버짓 임계값을 기본값으로 넣지 않습니다. 템플릿은 크게 여덟 블록으로 나뉩니다.
정책 식별, SLI 입력, SLO 목표와 Window, Budget 계산은 표의 필드별로 적습니다.
정책 상태, 변경 유형별 허용·제한, Reliability Work, 예외·책임·검토 항목도 같은 양식에 적습니다. 사건 기반 검토 조건과 검토 질문은 원문 항목을 그대로 나눴습니다.
이 템플릿에서 자동화 도구가 맡을 수 있는 부분은 많습니다. 지표 계산과 버짓 소비, 변경 게이트 연동, 승인 기록을 시스템으로 옮길 수 있습니다. 그러나 시스템이 스스로 정하지 못하는 값도 있습니다. 어느 수준의 실패가 사용자에게 받아들여지지 않는가, 버짓이 부족할 때 어떤 위험을 포기할 것인가, 보안 패치를 미루는 것과 배포하는 것 중 어느 쪽이 더 위험한가는 조직의 서비스 책임과 제품 판단이 필요합니다.
필드 경로 | 기입값·허용 값 |
|---|---|
| policy.name | "" |
| policy.service | "" |
| policy.critical_user_journey | "" |
| policy.scope | "" |
| policy.status | draft | active | suspended |
| policy.authors | [] |
| policy.reviewers | [] |
| policy.approvers | [] |
| policy.approved_at | "" |
| policy.next_review_at | "" |
| sli_input.specification | "" |
| sli_input.good_event | "" |
| sli_input.valid_event | "" |
| sli_input.bad_event | "" |
| sli_input.excluded_event.definition | "" |
| sli_input.excluded_event.rationale | "" |
| sli_input.unknown_event_policy | "" |
| sli_input.measurement_point | "" |
| sli_input.minimum_measurement_coverage | "" |
| sli_input.critical_segments | [] |
| sli_input.deployment_version_correlation | "" |
| slo.target | "" |
| slo.target_rationale | "" |
| slo.type | operational | aspirational |
| slo.window.type | rolling | calendar_aligned |
| slo.window.duration | "" |
| slo.window.rationale | "" |
| budgeting_method.type | occurrences | timeslices | ratio_timeslices |
| budgeting_method.calculation | "" |
| error_budget.allowed_budget_calculation | "" |
| error_budget.consumption_calculation | "" |
| error_budget.data_source | "" |
| error_budget.dashboard_or_report | "" |
| policy_states.NORMAL.trigger | "" |
| policy_states.NORMAL.exit_condition | "" |
| policy_states.CONSTRAINED.trigger | "" |
| policy_states.CONSTRAINED.exit_condition | "" |
| policy_states.EXHAUSTED.trigger | "" |
| policy_states.EXHAUSTED.exit_condition | "" |
| policy_states.MEASUREMENT_UNTRUSTED.trigger | "" |
| policy_states.MEASUREMENT_UNTRUSTED.fallback_decision_rule | "" |
| policy_states.MEASUREMENT_UNTRUSTED.exit_condition | "" |
| change_policy.feature_or_experiment.NORMAL | "" |
| change_policy.feature_or_experiment.CONSTRAINED | "" |
| change_policy.feature_or_experiment.EXHAUSTED | "" |
| change_policy.routine_config_or_infrastructure.NORMAL | "" |
| change_policy.routine_config_or_infrastructure.CONSTRAINED | "" |
| change_policy.routine_config_or_infrastructure.EXHAUSTED | "" |
| change_policy.database_or_data_change.NORMAL | "" |
| change_policy.database_or_data_change.CONSTRAINED | "" |
| change_policy.database_or_data_change.EXHAUSTED | "" |
| change_policy.reliability_fix.NORMAL | "" |
| change_policy.reliability_fix.CONSTRAINED | "" |
| change_policy.reliability_fix.EXHAUSTED | "" |
| change_policy.security_or_emergency_fix.NORMAL | "" |
| change_policy.security_or_emergency_fix.CONSTRAINED | "" |
| change_policy.security_or_emergency_fix.EXHAUSTED | "" |
| change_policy.incident_mitigation_or_rollback.NORMAL | "" |
| change_policy.incident_mitigation_or_rollback.CONSTRAINED | "" |
| change_policy.incident_mitigation_or_rollback.EXHAUSTED | "" |
| reliability_work.activation_rule | "" |
| reliability_work.prioritization_rule | ["", ""] |
| reliability_work.required_outputs | [""] |
| reliability_work.owner | "" |
| reliability_work.exit_criteria | [""] |
| exception_policy.eligible_cases | [""] |
| exception_policy.requester | "" |
| exception_policy.required_evidence | [""] |
| exception_policy.approval_authority | "" |
| exception_policy.escalation_authority | "" |
| exception_policy.expiry_rule | "" |
| exception_policy.post_change_review | "" |
| exception_policy.audit_location | "" |
| ownership.service_or_product_owner | "" |
| ownership.slo_owner | "" |
| ownership.change_policy_owner | "" |
| ownership.reliability_work_owner | "" |
| ownership.exception_approver | "" |
| ownership.escalation_owner | "" |
| review.regular_cadence | "" |
| review.event_driven_triggers[0] | user_journey_changed |
| review.event_driven_triggers[1] | sli_definition_changed |
| review.event_driven_triggers[2] | measurement_coverage_changed |
| review.event_driven_triggers[3] | dependency_changed |
| review.event_driven_triggers[4] | traffic_or_customer_mix_changed |
| review.event_driven_triggers[5] | repeated_policy_exception |
| review.event_driven_triggers[6] | material_slo_miss |
| review.event_driven_triggers[7] | user_feedback_conflicts_with_slo |
| review.review_questions[0] | 이 SLI는 여전히 사용자 Reliability를 설명하는가? |
| review.review_questions[1] | Target은 실제 사용자 피해와 맞는가? |
| review.review_questions[2] | Window가 운영·Planning 의사결정에 적합한가? |
| review.review_questions[3] | Budget State가 실제 업무 우선순위를 바꾸고 있는가? |
| review.review_questions[4] | 제한된 Change와 허용된 Change의 구분이 적절했는가? |
| review.review_questions[5] | Exception이 정상 경로보다 자주 사용되고 있지 않은가? |
| review.review_questions[6] | Policy 적용이 과도한 Toil이나 반대로 과도한 위험을 만들고 있지 않은가? |
측정과 결정과 실행을 세 문서로 나눈다
신뢰성 운영을 한 문서에서 모두 해결하려 하면 경계가 흐려집니다. 앞 단계의 지표 설계는 사용자 여정에서 SLI를 만들고 목표값과 평가 기간, 에러 버짓, 배포 정책을 다음 단계로 넘깁니다. 이 글은 그 입력으로 목표값과 창, 에러 버짓, 버짓 소비, 정책 상태, 릴리스와 변경 정책, 신뢰성 작업과 예외, 책임자를 결정합니다.
그다음 문제는 다시 갈라집니다. 버짓 소비를 언제 사람에게 알려야 하는가는 경보 설계입니다. 장애가 났을 때 로그와 지표, 추적, 프로파일 가운데 무엇부터 볼 것인가는 신호 선택입니다. 탐지와 완화, 복구, 커뮤니케이션은 장애 대응 런북이 소유합니다. 그리고 정책이 일시 정지와 롤백, 트래픽 회수를 요구했을 때 이를 실제로 안전하게 수행하는 아키텍처는 롤백 설계의 문제입니다.
SLO와 에러 버짓이 실제 잣대가 됐는지는 대시보드 수로 판단하지 못합니다. 버짓이 줄었을 때 팀의 행동이 달라지고, 그 행동이 사전에 합의돼 있어야 합니다. 위험을 줄이는 변경과 위험을 더하는 변경을 갈라 보고 예외와 책임까지 기록해야 합니다. 버짓이 아무 결정도 바꾸지 않는다면 SLO는 보고용 숫자에 가깝습니다. 반대로 버짓이 줄었다는 이유만으로 모든 변경을 똑같이 막는다면 정책이 지나치게 거칩니다. 실제 운영 잣대는 그 사이에 있습니다. 사용자에게 약속한 신뢰성과 현재 남은 에러 버짓, 변경이 더하는 위험, 그리고 그 결정을 책임질 사람을 하나의 정책으로 잇는 것입니다.
