SLO를 만들고 대시보드에 99.x%를 표시한다고 해서 배포 기준이 생기는 것은 아니다. 실제 기준이 되려면 어떤 사용자 결과를 측정하는지, 어느 수준을 목표로 삼는지, 어느 기간을 평가하는지, 에러 버짓을 얼마나 썼을 때 어떤 종류의 변경을 제한할지, 누가 예외를 승인할지까지 하나의 운영 정책으로 합의해야 한다.
Google SRE도 이 지점을 분명히 구분한다. 조직이 Error Budget을 실제 의사결정과 업무 우선순위에 사용하기로 합의하지 않으면 SLO는 또 하나의 KPI나 보고용 숫자에 머무른다. 반대로 Error Budget Policy가 있으면 Reliability와 Feature Delivery 사이의 논쟁을 사전에 합의된 규칙으로 바꿀 수 있다.
그렇다고 에러 버짓이 소진되는 순간 모든 배포를 무조건 중단해야 한다는 뜻도 아니다. Google의 예시 정책조차 일반 변경과 P0·Security Fix를 구분하고 Dependency가 원인인 경우처럼 상황에 따라 다른 행동을 정의한다.
좋은 정책이 정해야 하는 것은 배포한다 / 배포하지 않는다라는 한 줄짜리 규칙보다 넓다.
현재 Reliability 상태에서 어떤 위험을 추가로 받아들일 수 있으며 어떤 변경은 오히려 지금 해야 하는가?
이 질문에 답할 수 있어야 SLO가 운영 기준이 된다.
SLO 정책의 출발점은 이미 정의된 SLI다
SLO Target부터 정하면 순서가 뒤집힌다.
먼저 중요한 사용자 여정을 정의하고 성공과 실패를 어떤 이벤트로 판단할지 정해야 한다. 앞선 글에서는 이를 Critical User Journey → Outcome → Event → SLI 순서로 설계했다.
017이 Parent에서 받아야 할 입력은 다음과 같다.
| 입력 | 정책에서 필요한 이유 |
|---|---|
| Critical User Journey | 어떤 사용자 결과를 보호하는지 고정한다 |
| Good Event / Valid Event | Target과 Error Budget의 분자·분모를 정한다 |
| Exclusion Rule | 사용자 취소나 잘못된 요청을 서비스 실패와 혼동하지 않는다 |
| Measurement Point | 실제 사용자 경험과 측정값 사이의 거리를 안다 |
| Coverage Evidence | 계측 누락을 정상으로 오해하지 않는다 |
| Critical Segment | 전체 평균이 특정 사용자 집단의 실패를 가리는지 확인한다 |
| Unknown / Stuck 처리 | 결과를 알 수 없는 요청을 임의로 성공 처리하지 않는다 |
| Deployment Version 연결 | Budget 소비와 특정 변경 사이의 관계를 조사할 수 있게 한다 |
Parent 016은 목표 성공률이나 평가 기간을 의도적으로 정하지 않는다. 충분한 데이터와 사용자 피해를 확인한 뒤 SLO 정책 단계에서 결정하도록 넘긴다.
여기서 중요한 조건이 하나 더 있다. SLI 자체를 믿을 수 없는 상태에서는 Error Budget도 배포 기준이 될 수 없다.
계측이 끊겼는데 이를 100% 정상으로 처리하거나, 실제 요청의 상당 부분이 분모에서 사라진 상태라면 “에러 버짓이 충분히 남았다”는 계산도 의미가 없다. 그래서 정책에는 Budget 상태뿐 아니라 measurement trusted / untrusted 상태도 필요하다.
99.9%부터 적고 시작하지 않는다
SLO Target은 서비스 등급을 장식하는 숫자가 아니다.
Google SRE는 Product 측에서는 그 이하의 성능이면 사용자를 위해 Engineering Time을 투입할 가치가 있다고 동의해야 하고 Development 측에서는 Budget이 소진되면 실제 행동을 바꾸겠다고 합의해야 하며 운영 책임자는 과도한 Toil이나 소진 없이 목표를 방어할 수 있어야 한다고 설명한다.
따라서 99.9%를 기본값으로 놓고 이유를 나중에 붙이는 방식은 피하는 편이 낫다.
Target을 정할 때는 적어도 다음 질문에 답해야 한다.
이 사용자 여정이 어느 정도 실패하면 실제 사용자가 문제를 체감하는가?
금전, 데이터, 권한, 업무 중단처럼 실패 비용이 큰 여정인가?
현재 SLI는 어느 정도이고 그 측정값을 신뢰할 수 있는가?
정상적인 운영 여건에서 이 Target을 유지할 수 있는가?
더 높은 Target을 위해 추가되는 비용과 운영 복잡성이 사용자에게 실제 가치를 주는가?
현재 Target이 너무 느슨해, 상당한 사용자 피해가 생긴 뒤에야 Policy가 작동하지는 않는가?
처음부터 완벽한 숫자를 찾을 필요도 없다. Google SRE는 초기 SLO를 측정하고 반복적으로 수정하는 접근을 권한다. 현재 달성할 수 없는 더 높은 목표가 필요하다면 이를 Aspirational SLO로 별도 추적하면서 실제 Error Budget Policy를 즉시 발동시키는 Operational SLO와 구분하는 방법도 제시한다.
즉 목표값에는 숫자만 아니라 왜 이 숫자인지에 대한 근거가 붙어야 한다.
평가 기간도 정책의 일부다
같은 Target이라도 어느 기간을 보느냐에 따라 결정이 달라진다.
Google SRE는 Rolling Window와 Calendar-aligned Window를 구분한다. Rolling Window는 월말에 발생한 장애가 다음 달 1일이 됐다는 이유만으로 사용자 경험에서 사라지지 않는다는 점에서 사용자 경험과 잘 맞는다. Calendar Window는 분기별 인력·프로젝트 계획처럼 조직의 Planning Cycle과 연결하기 쉽다.
Google은 4주 Rolling Window를 범용적인 출발점으로 소개하지만 이것을 표준 기간으로 강제하지 않는다. 짧은 Window는 빠른 운영 조정에, 긴 Window는 큰 Reliability Investment 판단에 더 적합하다고 설명한다.
따라서 Policy에는 최소한 다음을 기록한다.
| 항목 | 예시 선택지 |
|---|---|
| Window Type | Rolling / Calendar-aligned |
| Window Length | 서비스와 의사결정 주기에 맞게 결정 |
| Operational Review | 배포·변경 판단에 사용하는 주기 |
| Planning Review | Reliability 투자 우선순위를 보는 장기 주기 |
| Rationale | 이 Window가 사용자 경험과 업무 주기에 맞는 이유 |
28일, 30일, 한 달은 비슷해 보여도 항상 같은 의미가 아니다. 평일과 주말 Traffic이 크게 다르거나 월말 업무가 집중되는 서비스라면 Window 선택 자체가 SLI 결과를 바꿀 수 있다.
에러 버짓은 항상 ‘허용 다운타임 몇 분’이 아니다
Error Budget의 기본 개념은 단순하다.
Error Budget = 1 – SLO Target
그러나 실제 소비량의 단위는 SLI 계산 방식에 따라 달라진다.
예를 들어 Valid Request 200,000건에 대한 성공률 SLO가 99.5%라면, 해당 Window에서 허용되는 Bad Event는 1,000건이다.
Allowed Bad Events
= Valid Events × (1 - SLO Target)Budget Consumption
= Actual Bad Events ÷ Allowed Bad Events이 경우 Error Budget은 다운타임 N분이 아니라 실패한 이벤트 수를 중심으로 해석한다.
반면 시간을 일정 구간으로 나눠 각 구간이 Good인지 Bad인지 판정하는 SLO라면 Bad Time Slice가 Budget을 소비한다. 현재 Google Cloud 문서도 Request-based SLI와 Windows-based SLI를 구분하고 있으며 OpenSLO v1은 Budgeting Method를 Occurrences, Timeslices, RatioTimeslices로 명시적으로 구분한다.
Policy Template에는 Target만 적지 말고 Budgeting Method와 소비 계산 방식까지 기록해야 한다.
특히 Traffic 양에 따라 분모가 변하는 Request-based SLO를 운영 중간에 평가한다면 “이번 Window의 최종 Error Budget이 정확히 몇 건인가”가 아직 확정되지 않을 수도 있다. Calendar Window에서 미래 요청량을 모르는 경우 중간 시점의 판단에는 이런 불확실성이 존재한다는 점도 Google SRE가 지적한다.
남은 예산보다 ‘현재 어떤 정책 상태인가’를 정한다
Dashboard에는 여러 숫자가 있을 수 있다.
SLO Compliance
허용된 Error Budget
사용한 Budget
남은 Budget
최근 Budget Consumption
Budget이 소진되는 속도
문제는 이 숫자가 행동으로 변하지 않을 때다.
운영 정책에서는 숫자를 다음과 같은 Policy State로 변환하는 편이 관리하기 쉽다.
| Policy State | 의미 | 기본 운영 태도 |
|---|---|---|
| NORMAL | 합의한 범위 안에서 Budget이 충분함 | 기존 Release Policy에 따라 변경 |
| CONSTRAINED | Budget 여유가 줄었거나 현재 소비 추세가 위험함 | 위험이 큰 변경을 줄이고 Evidence와 승인 수준 강화 |
| EXHAUSTED | 해당 Window의 Error Budget을 모두 소비함 | Reliability 회복 전 추가 위험을 만드는 변경을 기본 제한 |
| MEASUREMENT_UNTRUSTED | SLI 포괄성·데이터 품질 문제로 Budget을 신뢰할 수 없음 | 자동 허용하지 않고 수동 판단 또는 보수적 Change Policy 적용 |
여기서 CONSTRAINED로 넘어가는 정확한 수치를 모든 조직에 동일하게 적용할 이유는 없다.
팀이 필요하다면 Budget remaining [X]%, Window 종료 전 Budget 소진 가능성, 특정 규모의 단일 사건 같은 조건을 정할 수 있다. 그러나 그 값을 인터넷의 템플릿에서 가져오기보다 서비스의 배포 빈도, Traffic Pattern, 실패 피해, 대응 능력에 맞춰야 한다.
Budget Consumption을 어떤 속도로 계산하고 언제 Page·Ticket·Dashboard로 전달할지는 Alert 설계의 문제다. 이 글에서는 Policy가 어떤 상태를 필요로 하는지까지만 정한다.
Error Budget이 소진됐다고 모든 배포가 같은 위험은 아니다
Error Budget Policy에서 가장 위험한 단순화는 다음과 같다.
Budget 있음 = 배포 가능
Budget 없음 = 모든 배포 금지
실제 변경에는 서로 다른 목적과 위험이 있다.
다음처럼 Budget State × Change Class를 결합하는 편이 더 현실적이다.
| 변경 유형 | NORMAL | CONSTRAINED | EXHAUSTED |
|---|---|---|---|
| 신규 Feature·Experiment | 일반 Release Policy | Blast Radius 축소, 추가 검토 또는 연기 | 기본적으로 제한 |
| Routine Config·Infra Change | 정상 진행 | 필요성·변경 위험 재검토 | 긴급하지 않으면 연기 |
| 고위험 DB·Data Change | 별도 고위험 Change Policy | 원칙적으로 보수적 적용 | 기본적으로 제한 |
| Reliability Fix | 정상 진행 | 우선순위 상향 | 필요 시 우선 수행 |
| Security / Emergency Fix | 위험에 따라 진행 | 지연 위험과 변경 위험 비교 | 사전 정의된 예외·승인 절차로 수행 가능 |
| Incident Mitigation / Rollback | 필요 시 수행 | 필요 시 수행 | 서비스 회복을 위해 수행 가능 |
이 표의 목적은 모든 회사가 똑같이 운영하라는 것이 아니다.
정해야 할 것은 Budget이 줄어들수록 어떤 종류의 위험을 덜 받아들일 것인지다.
Google의 Example Error Budget Policy 역시 Budget 소진 시 Feature Change를 제한하면서 P0와 Security Fix를 예외로 둔다. 또한 Dependency가 원인인 SLO Miss를 어떻게 처리할지에 대해서도 “내부 Release를 계속한다”와 “추가 사고를 막기 위해 Change Freeze를 적용한다”라는 서로 다른 접근이 있을 수 있으므로 서비스에 맞는 선택을 Policy에 기록하라고 설명한다.
EXHAUSTED는 “아무것도 건드리지 않는다”가 아니라 추가적인 사용자 위험을 만드는 변경의 기본 허용 수준이 낮아진 상태로 이해하는 편이 정확하다.
실제 변경을 Pause, Feature Flag Off, Traffic 회수, Rollback, Forward Fix 중 어떤 방식으로 실행할지는 별개의 문제다. IXC Insights의 Rollback Guide는 Code·Config·DB·Data·Feature Exposure·Traffic을 함께 다루는 실행 계약을 설명한다.
Reliability Work도 Policy에 적어야 한다
Feature Freeze만 적고 “그동안 안정화한다”고 쓰면 실제 업무 우선순위는 여전히 모호하다.
Budget이 빠르게 소비되거나 소진됐을 때 어떤 Reliability Work를 시작할지도 정의해야 한다.
예를 들면 다음과 같은 작업이다.
Error Budget을 가장 많이 소비한 Failure Class 분석
반복되는 Reliability Bug 수정
위험한 Dependency 완화
테스트나 배포 검증 강화
복구 시간을 줄이는 자동화
Capacity나 Resource Saturation 문제 해결
잘못 정의된 SLI 또는 Event Classification 수정
반복적으로 Exception을 요구하게 만드는 구조적 원인 제거
Google SRE도 Error Budget을 Reliability Project 우선순위에 사용할 수 있다고 설명한다. 같은 인력을 투입한다면 실제 Error Budget 소비를 더 크게 줄일 작업을 먼저 선택할 수 있다는 것이다.
여기서도 Budget Exhausted → 팀 전체 100% Reliability Work 같은 값을 범용 규칙으로 만들 필요는 없다.
Policy가 정해야 하는 것은 다음과 같다.
Trigger → Reliability Work 우선순위 변경 → 담당자 → 완료해야 할 최소 조건 → Policy State에서 빠져나오는 Exit Criteria
Rolling Window라면 시간이 지나면서 과거 실패가 Window 밖으로 빠져나가 Budget이 자연스럽게 회복될 수도 있다. 그래서 단순히 숫자가 다시 정상 범위에 들어왔다는 이유만으로 모든 제한을 자동 해제하면 원인이 그대로 남을 수 있다.
중대한 Miss에서는 Budget 회복과 함께 반복 위험을 줄이기 위한 조치가 수행됐는지를 Exit Criteria로 둘 수 있다. Google SRE도 극단적인 상황의 Exit Criteria로 SLO 회복뿐 아니라 후속 SLO Miss 가능성을 낮추는 조치를 함께 제시한다.
예외는 장애가 난 뒤 협상하지 않는다
Error Budget Policy가 가장 필요한 순간은 원래 계획과 현실이 충돌할 때다.
Budget은 없지만 즉시 적용해야 하는 Security Fix가 있을 수 있다. 현재 Version의 장애를 완화하기 위한 배포가 필요할 수도 있고 데이터 손실을 막기 위해 새로운 변경을 넣어야 할 수도 있다.
이때 매번 “이번만 배포해도 되는가?”를 처음부터 토론하면 Policy가 의사결정 비용을 줄이지 못한다.
예외 정책에는 최소한 다음을 기록한다.
| 항목 | 기록할 내용 |
|---|---|
| Eligible Exception | 어떤 상황이 예외 후보인가 |
| Requester | 누가 예외를 요청했는가 |
| Reason | 왜 현재 Policy를 그대로 적용하면 더 큰 위험이 생기는가 |
| User Impact | 지연할 경우 사용자 피해 |
| Change Risk | 변경 자체가 추가할 위험 |
| Mitigation | Blast Radius와 실패 영향 제한 방법 |
| Approver | 누가 최종 Override 권한을 갖는가 |
| Expiry | 예외가 언제까지 유효한가 |
| Evidence | 승인 당시 사용한 데이터 |
| Post-change Review | 결과와 추가 Budget 소비를 언제 검토할 것인가 |
예외를 많이 허용하는 것이 목표는 아니다.
반대로 예외가 반복해서 필요하다면 기존 Target이나 Change Policy가 실제 운영과 맞지 않는다는 신호일 수 있다. 그 경우 예외를 계속 추가하기보다 Policy 자체를 다시 검토해야 한다.
SLO Owner 한 명만 지정해서도 부족하다
Error Budget은 개발팀과 운영팀 사이의 숫자가 아니다.
Google SRE는 Product Manager, Development Team, SRE·Production 책임자가 정책에 함께 동의해야 한다고 설명하며 SLO 문서에는 Author, Reviewer, Approver와 다음 Review Date를 남길 것을 권한다. 정책 적용에 이견이 생길 경우를 위한 Escalation Path도 필요하다.
실무에서는 책임을 다음처럼 나눌 수 있다.
| 역할 | 책임 |
|---|---|
| Service / Product Owner | 사용자 피해와 사업 요구를 기준으로 Target의 적절성을 승인 |
| SLO Owner | SLI·Target·Window·Budget 계산 정의와 데이터 신뢰성 유지 |
| Engineering / Change Owner | 실제 Change Policy를 적용하고 제한 상태를 실행 |
| Reliability Owner | Budget 소비 원인과 Reliability Work 우선순위 관리 |
| Exception Approver | Policy Override 승인과 사유 기록 |
| Escalation Owner | Budget 계산 또는 Policy 적용에 이견이 있을 때 최종 판단 |
작은 팀에서는 한 사람이 여러 역할을 맡을 수 있다. 중요한 것은 직함의 수가 아니라 누가 숫자를 계산하고 누가 배포를 제한할 수 있으며 누가 예외를 승인하는지가 모호하지 않은 것이다.
Review Cadence도 미리 정한다
서비스는 변한다.
Traffic Mix가 달라지고 고객이 바뀌고 Dependency가 교체되며 이전에는 중요하지 않았던 사용자 여정이 핵심 기능이 될 수 있다. SLO를 한 번 승인한 뒤 몇 년 동안 그대로 사용하면 처음의 합리적인 Target도 나중에는 잘못된 운영 기준이 될 수 있다.
Google SRE Workbook은 SLO 운영을 처음 시작할 때는 월 단위처럼 비교적 자주 검토하고 적합성이 검증된 뒤에는 분기 단위 또는 더 긴 주기로 줄일 수 있다고 설명한다.
현재 Google SRE의 Rethinking SLOs 논의도 복잡한 서비스에서는 SLO를 지나치게 넓게 적용하지 말고 어떤 질문에 답하기 위한 SLO인지 좁혀서 정의하며 서비스 행동과 Workload가 바뀌면 계속 검증해야 한다고 지적한다.
Calendar Review 외에 Event-driven Review 조건도 두는 편이 좋다.
Critical User Journey가 바뀜
SLI Event나 Measurement Point가 바뀜
주요 Dependency가 교체됨
사용자·Tenant·Region 구성에 큰 변화가 생김
배포 빈도나 Change Model이 달라짐
반복적인 Policy Exception이 발생함
SLO는 만족하지만 사용자의 Reliability 불만이 계속됨
SLO를 반복적으로 Miss하지만 사용자 영향이 거의 없음
마지막 두 경우는 특히 중요하다.
SLO가 실제 사용자 경험과 상관관계를 잃었다면 Target만 조이는 것이 아니라 SLI 자체를 다시 검토해야 한다.
SLO & Error Budget Policy Template
아래 Template의 숫자는 조직이 직접 채운다. 99.9%, 30일, 특정 Budget Threshold를 기본값으로 넣지 않는다.
policy:
name: ""
service: ""
critical_user_journey: ""
scope: ""status: draft | active | suspended
authors: []
reviewers: []
approvers: []approved_at: “”
next_review_at: ""sli_input:
specification: ""
good_event: ""
valid_event: ""
bad_event: ""excluded_event:
definition: ""
rationale: ""unknown_event_policy: ""measurement_point: “”
minimum_measurement_coverage: ""critical_segments: []deployment_version_correlation: ""slo:
target: ""
target_rationale: ""type: operational | aspirationalwindow:
type: rolling | calendar_aligned
duration: ""
rationale: ""budgeting_method:
type: occurrences | timeslices | ratio_timeslices
calculation: ""error_budget:
allowed_budget_calculation: ""
consumption_calculation: ""data_source: “”
dashboard_or_report: ""policy_states:NORMAL:
trigger: ""
exit_condition: ""CONSTRAINED:
trigger: ""
exit_condition: ""EXHAUSTED:
trigger: ""
exit_condition: ""MEASUREMENT_UNTRUSTED:
trigger: ""
fallback_decision_rule: ""
exit_condition: ""change_policy:feature_or_experiment:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""routine_config_or_infrastructure:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""database_or_data_change:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""reliability_fix:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""security_or_emergency_fix:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""incident_mitigation_or_rollback:
NORMAL: ""
CONSTRAINED: ""
EXHAUSTED: ""reliability_work:
activation_rule: ""prioritization_rule:
- “”
- “”
required_outputs:
- “”
owner: ""exit_criteria:
- “”
exception_policy:
eligible_cases:
- ""requester: “”
required_evidence:
- ""approval_authority: “”
escalation_authority: ""expiry_rule: “”
post_change_review: ""audit_location: ""ownership:
service_or_product_owner: ""
slo_owner: ""
change_policy_owner: ""
reliability_work_owner: ""
exception_approver: ""
escalation_owner: ""review:
regular_cadence: ""event_driven_triggers:
- user_journey_changed
- sli_definition_changed
- measurement_coverage_changed
- dependency_changed
- traffic_or_customer_mix_changed
- repeated_policy_exception
- material_slo_miss
- user_feedback_conflicts_with_slo
review_questions:
- “이 SLI는 여전히 사용자 Reliability를 설명하는가?”
- “Target은 실제 사용자 피해와 맞는가?”
- “Window가 운영·Planning 의사결정에 적합한가?”
- “Budget State가 실제 업무 우선순위를 바꾸고 있는가?”
- “제한된 Change와 허용된 Change의 구분이 적절했는가?”
- “Exception이 정상 경로보다 자주 사용되고 있지 않은가?”
- “Policy 적용이 과도한 Toil이나 반대로 과도한 위험을 만들고 있지 않은가?”
이 Template에서 자동화 도구가 담당할 수 있는 부분은 많다. SLI 계산, Budget Consumption, Change Gate 연동, 승인 기록을 시스템화할 수 있다.
그러나 시스템이 스스로 정할 수 없는 값도 있다.
어느 수준의 실패가 사용자에게 받아들일 수 없는가, Budget이 부족할 때 어떤 위험을 포기할 것인가, 보안 패치를 지연하는 것과 배포하는 것 중 어느 쪽이 더 위험한가는 조직의 서비스 책임과 제품 판단이 필요하다.
016에서 측정하고 017에서 결정하고 030에서 실행한다
Reliability 운영을 한 문서에서 모두 해결하려고 하면 경계가 흐려진다.
Parent 016은 사용자 여정에서 SLI를 만든다. 해당 글의 Handoff Contract는 Target, Window, Error Budget과 Deployment Policy를 다음 단계로 넘긴다.
이 글은 그 입력으로 다음을 결정한다.
SLI ↓ SLO Target ↓ Window ↓ Error Budget ↓ Budget Consumption ↓ Policy State ↓ Release / Change Policy ↓ Reliability Work / Exception / Owner
그다음 문제는 다시 갈라진다.
Budget 소비를 언제 사람에게 알려야 하는가는 Alert 설계다. 장애가 발생했을 때 로그·메트릭·트레이스·프로파일 중 무엇부터 볼 것인가는 Signal Selection이다. 탐지·완화·복구·커뮤니케이션은 Incident Runbook이 소유한다.
그리고 Policy가 Pause, Rollback, Traffic 회수를 요구했을 때 이를 실제로 안전하게 수행할 수 있는 아키텍처는 Rollback Design의 문제다. Code만 이전 Version으로 되돌리는 것으로 끝나지 않고 Config, DB, Data, Feature Flag와 Traffic의 호환성까지 준비해야 한다.
SLO와 Error Budget이 실제 기준이 됐는지는 Dashboard 수로 판단할 수 없다.
Budget이 줄었을 때 팀의 행동이 달라지고 그 행동이 사전에 합의돼 있으며 위험을 줄이는 변경과 위험을 추가하는 변경을 구분하고 예외와 책임까지 기록할 수 있어야 한다.
Budget이 아무 결정도 바꾸지 않는다면 SLO는 보고용 숫자에 가깝다. 반대로 Budget이 줄었다는 이유만으로 모든 변경을 똑같이 막는다면 정책이 지나치게 거칠다.
실제 운영 기준은 그 사이에 있다.
사용자에게 약속한 Reliability, 현재 남은 Error Budget, 변경이 추가하는 위험, 그리고 그 결정을 책임질 사람을 하나의 Policy로 연결하는 것이다.