🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📜 धडा 02 — करार म्हणून SLOs: error budget POLICY

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-what-is-sre · पुढे: lesson-03-toil

📦 या ब्रँचमध्ये काय आहे

धडा 01, अधिक तो करार जो ठरवतो की शाळा आपल्या इमारतींमध्ये किती वेगाने बदल करू शकते. Observability school SLIs, SLOs आणि budget चे गणित शिकवते. हा धडा policy बद्दल आहे: काहीही बिघडण्याच्या आधी सही केलेला एक दस्तऐवज, जो सांगतो की budget खर्च होत जाईल तसे product, developers आणि पथक काय करतील. sre/crew.py मधील BudgetPolicy आणि sre/demo.py मधील budget().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

सत्राच्या सुरुवातीला पथक आणि मुख्याध्यापक एक करार करतात. ✍️

"Timetable इमारत थोडीशी बिघडलेली राहू शकते — 1,000 पैकी 1 request. ती थोडीशी मुभा म्हणजे दुरुस्तीचे बजेट. बजेट शिल्लक असेपर्यंत शिक्षिका हवे तितक्या वेगाने बदल करू शकतात: नव्या खोल्या, नवे timetables, नवी features."

"बजेट कमी झाले, तर आम्ही वेग कमी करतो आणि आधी गोष्टी दुरुस्त करतो."

"बजेट पूर्ण संपले, तर आम्ही बदल करणे थांबवतो — फक्त तातडीच्या दुरुस्त्या — जोपर्यंत इमारत पुन्हा निरोगी होत नाही."

महत्त्वाचा भाग: त्यांनी हे गळती सुरू होण्याच्या आधी लिहून ठेवले आणि त्यावर सही केली. म्हणून दिवस 24 ला बजेट संपते तेव्हा कोणीच वाद घालत नाही. काय होते ते कागदावर आधीच लिहिलेले आहे.

🗺️ आकृती

flowchart LR
    n["🟢 normal<br/>under 75% used<br/>release freely"] -->|"day 20: 83.9%"| c["🟡 caution<br/>75–100%<br/>reliability first"]
    c -->|"day 24: 101.8%"| f["🔴 freeze<br/>100% or more<br/>P0 + security only"]
    f -->|"day 34: day-6 incident<br/>leaves the window → 80.4%"| c
    c -->|"day 43: 57.1%"| n
    big["💥 one incident > 20%<br/>→ P0 action in its postmortem"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/sre/lesson-diagrams.html#l02

❓ काय

SLO (service level objective) — users ना दिसणाऱ्या एका मापाचे (SLI चे) लक्ष्य, उदाहरणार्थ "timetable च्या 99.9% requests यशस्वी होतात, सरकत्या 28 दिवसांत मोजलेले". SLI कसा निवडायचा आणि कसा मोजायचा: Observability धडा 09.
Error budget — window मधील requests च्या 1 − SLO. इथे: दिवसाला 1,000,000 requests × 28 दिवस × 0.1% = 28 दिवसांत service ला मुभा असलेल्या 28,000 failed requests.
Error budget policy — खर्चाच्या प्रत्येक पातळीवर करायच्या कृतींबद्दल लिखित करार. तो नसेल, तर संपलेले budget म्हणजे dashboard वरचा फक्त एक दुःखी आकडा.
Rolling window — budget नेहमी मागील 28 दिवसांवर मोजले जाते. जुनी अपयशे window मधून बाहेर पडतात आणि budget परत येते. महिन्याच्या 1 तारखेला काहीही reset होत नाही.
Release freeze — budget संपलेले असताना feature releases थांबवा; फक्त P0 दुरुस्त्या आणि security patches ना परवानगी. Site Reliability Workbook मधील Google ची उदाहरण policy मागील चार आठवडे budget च्या वर असलेल्या service साठी नेमके हेच सांगते.
एकाच incident चा नियम — त्याच उदाहरण policy मधून: चार आठवड्यांच्या budget पैकी 20% पेक्षा जास्त जाळणाऱ्या incident चे postmortem होते आणि त्यात किमान एक P0 action item असतो. (Postmortem कसे लिहायचे: Observability धडा 12.)
Caution पातळी — या कोर्सचे उदाहरण 75% वर एक मधली पायरी जोडते: आधी reliability चे काम आणि प्रत्येक release वर एक जास्तीचा reviewer. तुमची policy वेगळ्या पातळ्या निवडू शकते; मुद्दा असा की पातळ्या आणि कृती आधीच लिहून सही केलेल्या असतात.
Escalation — policy बद्दल बाजूंमध्ये मतभेद झाले (product owner ला freeze मध्ये आणखी एक launch हवे असेल), तर दस्तऐवज सांगतो की निर्णय कोण घेणार — सहसा आधीच नाव ठरवलेला एखादा वरिष्ठ नेता, त्या दिवशी सर्वात मोठ्या आवाजात बोलणारा नाही.

🤔 का

कारण नाहीतर "reliability विरुद्ध features" हा निर्णय मते आणि ज्येष्ठतेवरून पुन्हा पुन्हा घेतला जातो, बहुतेक वेळा एखाद्या outage च्या मध्यात. Budget त्याला data बनवते, आणि policy त्या data ला कृतीत बदलते. ते वेगाचेही रक्षण करते: budget शिल्लक असताना कोणीही "सुरक्षिततेसाठी म्हणून" release अडवू शकत नाही. 100% हे चुकीचे लक्ष्य आहे: SRE पुस्तकातले उदाहरण असे user चे आहे ज्याचा स्वतःचा phone आणि network 99% वेळ चालतो — तो 99.99% service आणि 99.999% service यांतील फरक ओळखू शकत नाही, आणि प्रत्येक जास्तीचा nine जास्त महाग पडतो (धडा 09).

🔧 कसे (या repo मध्ये)

sre/crew.py मधील BudgetPolicy(slo, window_days, daily_requests, slow=0.75, single=0.20) budget मोजते. run(days, baseline, incidents) दररोज baseline failures आणि त्या दिवसाचा incident जोडते, दररोज rolling window मधला खर्च मोजते, आणि प्रत्येक state change आणि एकाच-incident च्या रेषेवरचा प्रत्येक incident परत देते. budget() चार incidents सह (दिवस 6, 15, 20, 24) 45 दिवस चालवते.

🧪 करून पाहा

python3 sre/demo.py budget
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import BudgetPolicy
for slo in (0.999, 0.9995, 0.99):
    pol = BudgetPolicy(slo=slo)
    changes, big = pol.run(45, baseline=250, incidents={6: 7000, 15: 6500, 20: 5000, 24: 4000})
    print(f"SLO {slo:.2%} → budget {pol.budget:>7,} · states: " + " → ".join(f"{s}@{d}" for d, _, s in changes) + f" · P0 postmortems: {len(big)}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

budget हे print करते:

── timetable service · SLO 99.9% over a rolling 28 days · 1,000,000 requests a day → budget 28,000 failed requests
   day  1:   0.9% of the budget used → normal
   day 20:  83.9% of the budget used → caution
   day 24: 101.8% of the budget used → freeze
   day 34:  80.4% of the budget used → caution
   day 43:  57.1% of the budget used → normal
   day  6 incident burned 7,000 = 25.0% (> 20%) → its postmortem must carry a P0 action item
   day 15 incident burned 6,500 = 23.2% (> 20%) → its postmortem must carry a P0 action item

तुमचा snippet हे print करतो:

SLO 99.90% → budget  28,000 · states: normal@1 → caution@20 → freeze@24 → caution@34 → normal@43 · P0 postmortems: 2
SLO 99.95% → budget  14,000 · states: normal@1 → caution@14 → freeze@15 · P0 postmortems: 4
SLO 99.00% → budget 280,000 · states: normal@1 · P0 postmortems: 0

🏁 तुम्ही आत्ताच काय सिद्ध केले

तेच चार incidents तीन अगदी वेगळ्या तिमाही देतात. 99.9% वर policy दिवस 24 ला releases freeze करते आणि दिवस 34 ला तो उठवते — कोणी वाद घातला म्हणून नाही, तर दिवस 6 चा incident 28 दिवसांच्या window मधून बाहेर पडला म्हणून. 99.95% वर service दिवस 15 ला freeze होते आणि दिवस 45 ला अजूनही freeze असते — प्रत्येक incident चे P0 postmortem होते. 99% वर policy कधीच काहीच करत नाही. म्हणून SLO हा दात असलेला व्यावसायिक निर्णय आहे: users ना काय हवे त्यावरून तो निवडा, आणि मग policy ला कृती करू द्या.

⚠️ नेहमीच्या चुका

policy नसलेला SLO — budget संपते आणि काहीच बदलत नाही
outage चालू असताना, सर्वात थकलेल्या आणि सर्वात चिडलेल्या लोकांनी लिहिलेली policy
बाहेर पडण्याचा नियम नसलेला freeze ("बरे वाटेपर्यंत")
budget शिल्लक असताना "सुरक्षिततेसाठी" releases अडवणे — त्याने developers चा विश्वास खर्च होतो
नियोजित maintenance budget च्या बाहेर मोजणे, म्हणजे SLO दुर्लक्षित करतो तो downtime users ना जाणवतो
प्रत्येक service साठी एकच policy, तिच्या users ना काहीही हवे असले तरी

🏭 प्रत्यक्ष वापरात

Policy SLO शेजारीच, service repo मध्ये ठेवा, नावानिशी ठरलेल्या लोकांच्या सहीसह. एक छोटे उदाहरण (साधी YAML, जी माणसे आणि release gate दोघेही वाचतात):

service: timetable
slo: {sli: "successful requests / all requests", target: 99.9, window: 28d}
policy:
  - when: "budget_used < 75%"
    do: "release normally"
  - when: "75% <= budget_used < 100%"
    do: "reliability items first; second reviewer on every release"
  - when: "budget_used >= 100%"
    do: "freeze: only P0 fixes and security patches until back inside the SLO"
  - when: "one incident > 20% of the budget"
    do: "postmortem with at least one P0 action item"
escalation: "disagreements go to the head of engineering"
signed: [product: aishwarya, dev: timetable-team, sre: katrina]

खऱ्या account वर — CI मधील release gate deploy च्या आधी Prometheus मधून budget वाचू शकते. इथले recording rule चे नाव तुम्ही स्वतः ठरवायचे आहे (Observability school ते तयार करते):

used=$(curl -s "http://prometheus:9090/api/v1/query" \
  --data-urlencode 'query=slo:timetable:budget_used_ratio:28d' | jq -r '.data.result[0].value[1]')
awk -v u="$used" 'BEGIN { exit (u >= 1.0) }' || { echo "error budget spent — release frozen"; exit 1; }

तुमच्यासाठी SLOs आणि budgets चा मागोवा घेणाऱ्या tools मध्ये Sloth आणि Pyrra (open source, Prometheus rules तयार करतात), Google Cloud आणि Datadog ची SLO features, आणि Nobl9 यांचा समावेश आहे.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: तुमच्या सर्वात महत्त्वाच्या service चा SLO शोधा. मग त्याचे budget संपल्यावर काय होते हे सांगणारे पान शोधा. असे पान नसेल, तर तो SLO फक्त सजावट आहे — policy लिहा आणि या महिन्यातच तिच्यावर सही घ्या.

⏭️ पुढे

Policy म्हणते "आधी गोष्टी दुरुस्त करा". पण पथक बादल्या वाहण्यात व्यस्त आहे. पुढचा धडा त्या बादल्या मोजतो.

git checkout lesson-03-toil

📜 Lesson 02 — SLOs as an agreement: the error budget POLICY

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-what-is-sre · Next: lesson-03-toil

📦 What's in this branch

Lesson 01, plus the agreement that decides how fast the school may change its buildings. The Observability school teaches SLIs, SLOs and the budget arithmetic. This lesson is about the policy: a document, signed before anything breaks, that says what product, developers and the crew will do as the budget is spent. BudgetPolicy in sre/crew.py and budget() in sre/demo.py.

🧒 Explain like I'm 5

The crew and the head teacher make a deal at the start of term. ✍️

"The timetable building may be broken for a little bit — 1 request in 1,000. That little bit is the repair budget. While there is budget left, the teachers can change things as fast as they like: new rooms, new timetables, new features."

"If the budget gets low, we slow down and fix things first."

"If the budget is all used up, we stop changing things — only urgent fixes — until the building is healthy again."

The important part: they wrote this down and signed it before the leaks. So when the budget runs out on day 24, nobody argues. The paper already says what happens.

🗺️ Diagram

flowchart LR
    n["🟢 normal<br/>under 75% used<br/>release freely"] -->|"day 20: 83.9%"| c["🟡 caution<br/>75–100%<br/>reliability first"]
    c -->|"day 24: 101.8%"| f["🔴 freeze<br/>100% or more<br/>P0 + security only"]
    f -->|"day 34: day-6 incident<br/>leaves the window → 80.4%"| c
    c -->|"day 43: 57.1%"| n
    big["💥 one incident > 20%<br/>→ P0 action in its postmortem"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/sre/lesson-diagrams.html#l02

❓ What

SLO (service level objective) — the target for a user-facing measure (the SLI), for example "99.9% of timetable requests succeed, measured over a rolling 28 days". How to pick the SLI and compute it: Observability lesson 09.
Error budget — 1 − SLO of the window's requests. Here: 1,000,000 requests a day × 28 days × 0.1% = 28,000 failed requests the service may have in 28 days.
Error budget policy — a written agreement about actions at each level of spending. Without one, a spent budget is just a sad number on a dashboard.
Rolling window — the budget is always measured over the last 28 days. Old failures leave the window and the budget comes back. Nothing resets on the 1st of the month.
Release freeze — while the budget is spent, stop feature releases; allow only P0 fixes and security patches. Google's example policy in the Site Reliability Workbook says exactly this for a service over budget for the preceding four weeks.
The single-incident rule — from the same example policy: an incident that burns more than 20% of the four-week budget gets a postmortem with at least one P0 action item. (How to write a postmortem: Observability lesson 12.)
The caution tier — this course's example adds a middle step at 75%: reliability work first and an extra reviewer on each release. Your policy may pick other levels; the point is that the levels and actions are written and signed in advance.
Escalation — when the parties disagree about the policy (the product owner wants one more launch during a freeze), the document names who decides — usually a senior leader named in advance, not whoever is loudest that day.

🤔 Why

Because "reliability vs features" is otherwise decided by opinion and seniority, again and again, usually in the middle of an outage. A budget turns it into data, and a policy turns the data into action. It also protects speed: while budget is left, nobody may block a release "just to be safe". 100% is the wrong target: the SRE book's example is a user whose own phone and network work 99% of the time — they cannot tell a 99.99% service from a 99.999% one, and every extra nine costs more (lesson 09).

🔧 How (in this repo)

BudgetPolicy(slo, window_days, daily_requests, slow=0.75, single=0.20) in sre/crew.py computes the budget. run(days, baseline, incidents) adds baseline failures every day plus the incident on its day, measures the spend over the rolling window each day, and returns every state change and every incident above the single-incident line. budget() runs 45 days with four incidents (days 6, 15, 20, 24).

🧪 Try it

python3 sre/demo.py budget
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import BudgetPolicy
for slo in (0.999, 0.9995, 0.99):
    pol = BudgetPolicy(slo=slo)
    changes, big = pol.run(45, baseline=250, incidents={6: 7000, 15: 6500, 20: 5000, 24: 4000})
    print(f"SLO {slo:.2%} → budget {pol.budget:>7,} · states: " + " → ".join(f"{s}@{d}" for d, _, s in changes) + f" · P0 postmortems: {len(big)}")
EOF

✅ Verify — what you should see

budget prints:

── timetable service · SLO 99.9% over a rolling 28 days · 1,000,000 requests a day → budget 28,000 failed requests
   day  1:   0.9% of the budget used → normal
   day 20:  83.9% of the budget used → caution
   day 24: 101.8% of the budget used → freeze
   day 34:  80.4% of the budget used → caution
   day 43:  57.1% of the budget used → normal
   day  6 incident burned 7,000 = 25.0% (> 20%) → its postmortem must carry a P0 action item
   day 15 incident burned 6,500 = 23.2% (> 20%) → its postmortem must carry a P0 action item

Your snippet prints:

SLO 99.90% → budget  28,000 · states: normal@1 → caution@20 → freeze@24 → caution@34 → normal@43 · P0 postmortems: 2
SLO 99.95% → budget  14,000 · states: normal@1 → caution@14 → freeze@15 · P0 postmortems: 4
SLO 99.00% → budget 280,000 · states: normal@1 · P0 postmortems: 0

🏁 What you just proved

The same four incidents give three very different quarters. At 99.9%, the policy freezes releases on day 24 and lifts it on day 34 — not because anyone argued, but because the day-6 incident left the 28-day window. At 99.95%, the service freezes on day 15 and is still frozen on day 45 — every incident is a P0 postmortem. At 99%, the policy never does anything. So the SLO is a business decision with teeth: pick it from what users need, then let the policy act.

⚠️ Common mistakes

an SLO with no policy — the budget runs out and nothing changes
a policy written during the outage, by the people most tired and most angry
a freeze with no exit rule ("until we feel better")
blocking releases while budget is left, "to be safe" — that spends the developers' trust
counting planned maintenance outside the budget, so users feel downtime the SLO ignores
one policy for every service, whatever its users need

🏭 In production

Keep the policy next to the SLO, in the service repo, signed by named people. A short example (plain YAML, read by humans and by a release gate):

service: timetable
slo: {sli: "successful requests / all requests", target: 99.9, window: 28d}
policy:
  - when: "budget_used < 75%"
    do: "release normally"
  - when: "75% <= budget_used < 100%"
    do: "reliability items first; second reviewer on every release"
  - when: "budget_used >= 100%"
    do: "freeze: only P0 fixes and security patches until back inside the SLO"
  - when: "one incident > 20% of the budget"
    do: "postmortem with at least one P0 action item"
escalation: "disagreements go to the head of engineering"
signed: [product: aishwarya, dev: timetable-team, sre: katrina]

On a real account — a CI release gate can read the budget from Prometheus before a deploy. The recording rule name here is yours to define (the Observability school builds it):

used=$(curl -s "http://prometheus:9090/api/v1/query" \
  --data-urlencode 'query=slo:timetable:budget_used_ratio:28d' | jq -r '.data.result[0].value[1]')
awk -v u="$used" 'BEGIN { exit (u >= 1.0) }' || { echo "error budget spent — release frozen"; exit 1; }

Tools that track SLOs and budgets for you include Sloth and Pyrra (open source, generate Prometheus rules), Google Cloud's and Datadog's SLO features, and Nobl9.

🏭 Why this matters in production: find your most important service's SLO. Then find the page that says what happens when its budget is spent. If there is no such page, the SLO is a decoration — write the policy and get it signed this month.

⏭️ Next

The policy says "fix things first". But the crew is busy carrying buckets. The next lesson measures those buckets.

git checkout lesson-03-toil

← Previouswhat is sre Next →toil

This page is the lesson's README from the lesson-02-error-budget-policy branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.