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

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

🛠️ धडा 01 — SRE म्हणजे काय: पन्हाळ दुरुस्त करणारे पथक

📍 तुम्ही इथे आहात: 12 पैकी धडा 01 · पुढे: lesson-02-error-budget-policy

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

हा संपूर्ण कोर्स ज्या कामाबद्दल आहे ते काम. शाळेत अनेक इमारती (services) आहेत: timetable, निकालांचे portal, ग्रंथालयाचा catalogue. शाळेकडे एक देखभाल पथक आहे — कतरिना, दीपिका आणि ऐश्वर्या — ज्या इमारती चालू ठेवतात. या पथकाचा एक नियम त्यांना साध्या दुरुस्ती team पेक्षा वेगळे बनवतो: त्या tools लिहितात, फक्त जास्त बादल्या वाहत नाहीत. संपूर्ण कोर्सभर तुम्ही वापराल त्या खऱ्या files:

sre/crew.py — पथकाचे कामाचे नियम, छोट्या deterministic models च्या रूपात (धडे 01–08), शुद्ध Python, शून्य dependencies
sre/design.py — अपयशासाठी इमारत बांधण्याचे नियम (धडे 09–12)
sre/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 sre/demo.py <section>; sections: job budget toil oncall canary rollout capacity command nines overload chaos prr)
sre/test_sre.py — पथकाच्या नियमांवरील 12 checks
demo-output.txt — निरोगी run काय print करतो

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 लागेल, बाकी काही नाही — cloud account नाही, pip install नाही. crew.py आणि design.py हे शिकवण्यासाठीचे models आहेत: ते खऱ्या SRE पद्धतीचे गणित आणि नियम ठेवतात आणि बाकी सगळे वगळतात. Randomness ला seed दिलेला आहे, म्हणून प्रत्येक run तीच गोष्ट print करतो. Signals, SLO चे गणित, burn-rate alerts आणि postmortems हे शेजारच्या Observability school मध्ये शिकवले आहेत; हा कोर्स ते पुन्हा शिकवण्याऐवजी त्यांच्याकडे link देतो.

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

पाऊस पडला की timetable इमारतीचे छप्पर गळते. 🌧️

साधी दुरुस्ती team गळतीखाली एक बादली ठेवते. पुढच्या आठवड्यात जास्त पाऊस, जास्त गळती, जास्त बादल्या. शाळा वाढते, म्हणून छपरे वाढतात — आणि बादल्याही. लवकरच ती team बादल्या वाहण्याशिवाय दुसरे काहीच करत नाही. फक्त त्या वाहण्यासाठी त्यांना जास्त लोक लागतात.

कतरिना, दीपिका आणि ऐश्वर्या हे वेगळ्या पद्धतीने करतात. आज त्या बादली वाहतात, हो. पण त्या पन्हाळसुद्धा दुरुस्त करतात, म्हणजे पुढच्या आठवड्यात गळती नाही आणि बादलीही नाही. 🔧

आणि त्या एक नियम पाळतात: आमच्या आठवड्याचा जास्तीत जास्त अर्धा वेळ बादल्यांसाठी. उरलेला अर्धा पन्हाळ दुरुस्त करण्यासाठी. जर बादल्यांनी अर्ध्यापेक्षा जास्त आठवडा घेतला, तर त्या इमारत बांधणाऱ्या लोकांना सांगतात: "तुमची इमारत खूप गळते — वाहायला मदत करायला या, किंवा दुरुस्त करायला मदत करायला या."

🗺️ आकृती

flowchart LR
    rain["🌧️ more pupils,<br/>more buildings"] --> ops["🪣 ops work<br/>tickets, pages, manual fixes"]
    ops --> cap{"more than 50%<br/>of the crew's week?"}
    cap -->|"no"| eng["🔧 engineering<br/>tools, automation, fixes"]
    cap -->|"yes"| back["↩️ extra ops goes back<br/>to the dev team"]
    eng -->|"less ops next week"| ops
    back --> eng

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

❓ काय

Site Reliability Engineering (SRE) — production services चालवणे हा एक software engineering प्रश्न म्हणून हाताळणे. 2003 मध्ये Google ची SRE team सुरू करणारे Ben Treynor Sloss यांनी हे असे मांडले: "software engineer ला operations team design करायला सांगितल्यावर जे घडते ते."
Operations (ops) काम — गोष्टी हाताने चालू ठेवणे: tickets, pages, हाताने केलेले deploys, restarts, "ते बंद आहे का?" याला उत्तर देणे. आवश्यक, पण त्याने पुढचा आठवडा सोपा होत नाही.
Engineering काम — कायमची सुधारणा मागे ठेवणारे काम: एखादे tool, automation, design मधला बदल, अधिक चांगला alert. ते पुढच्या आठवड्याचे ops कमी करते.
50% cap — Google SRE पुस्तकाचा नियम: SREs आपल्या वेळेपैकी जास्तीत जास्त 50% वेळ ops कामावर घालवतात, म्हणजे किमान अर्धा वेळ engineering. Ops cap च्या वर गेले की जास्तीचे काम development team कडे परत पाठवले जाते (ते tickets घेतात, on-call rotation मध्ये सामील होतात) जोपर्यंत service अधिक निरोगी होत नाही. Cap काही काळातील सरासरीवर मोजला जातो, तासा-तासाला त्यावर पहारा दिला जात नाही.
पारंपरिक ops team — service सोबतच आपली माणसांची संख्या वाढवते: दुप्पट servers, जवळपास दुप्पट लोक. SRE चे ध्येय अशी team आहे जी service पेक्षा हळू वाढते.
DevOps — एक संस्कृती आणि तत्त्वांचा संच: developers आणि operations जबाबदारी वाटून घेतात, automate करतात, मोजतात, छोट्या टप्प्यांत release करतात. Google चे Site Reliability Workbook SRE ला या कल्पनांची एक ठोस अंमलबजावणी म्हणते ("class SRE implements interface DevOps"). ते प्रतिस्पर्धी नाहीत; SRE त्यात ठराविक आकडे आणि पद्धती जोडते (SLOs, error budgets, ops cap, toil budgets).
सामायिक जबाबदारी — developers अजूनही आपल्या service चे मालक असतात. SRE हा pager आणि तयार नसलेल्या launches वर veto असलेला भागीदार आहे (धडा 12), भिंतीवरून फेकलेले काहीही ताब्यात घेणारी team नाही.

🤔 का

कारण हाताने केलेले operations वाढत्या प्रमाणात टिकत नाहीत. प्रत्येक नव्या इमारतीसाठी बादल्या वाहायला आणखी एक माणूस लागत असेल, तर देखभालीचा खर्च शाळेइतकाच वेगाने वाढतो. त्याहून वाईट: जी team फक्त बादल्या वाहते तिच्याकडे छप्पर का गळते हे विचारायला वेळच नसतो. 50% cap तो वेळ वाचवतो जो प्रश्न लहान करतो. आणि जास्तीचे काम developers कडे परत पाठवणे हा एक feedback loop आहे: जे लोक गळके design दुरुस्त करू शकतात त्यांना गळती जाणवते.

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

sre/crew.py मधील ops_share(weeks, cap=0.5) दर आठवड्याच्या (ops_hours, total_hours) ची यादी घेते आणि प्रत्येकासाठी (share, over_cap) परत देते. sre/demo.py मधील job() तीन जणांच्या पथकाचे सहा आठवडे चालवते: 3 × 40 तास = आठवड्याला 120 तास.

🧪 करून पाहा

python3 sre/demo.py job
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import ops_share
# a quarter where the timetable service keeps growing and nobody automates anything
weeks = [(40 + 4 * w, 120) for w in range(8)]
for i, (share, over) in enumerate(ops_share(weeks), 1):
    print(f"week {i}: ops {share:5.1%}" + (" → over the cap" if over else ""))
print("the same weeks with a 3-person crew grown to 4 (160 h):")
print([f"{s:.0%}" for s, _ in ops_share([(o, 160) for o, _ in weeks])])
EOF
python3 sre/test_sre.py

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

job हे print करते:

   week 3:  63 h ops = 52.5%  ← over the 50% cap: extra tickets and pages go back to the dev team
   week 4:  71 h ops = 59.2%  ← over the 50% cap: extra tickets and pages go back to the dev team
   week 5:  58 h ops = 48.3%
   week 6:  45 h ops = 37.5%
   six-week average 47.1% · the rest of the week is ENGINEERING: tools that make next week's ops smaller

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

week 6: ops 50.0%
week 7: ops 53.3% → over the cap
week 8: ops 56.7% → over the cap
the same weeks with a 3-person crew grown to 4 (160 h):
['25%', '28%', '30%', '32%', '35%', '38%', '40%', '42%']

Tests शेवटी 12/12 passed दाखवतात.

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

Ops दर आठवड्याला 4 तासांनी वाढत असेल आणि कोणीच automate करत नसेल, तर पथक आठवडा 7 मध्ये cap ओलांडते. चौथी व्यक्ती भरती केल्याने share परत 42% वर येतो — सध्यापुरता. Ops चे तास वाढतच राहिले (40 → 68); नव्या व्यक्तीने फक्त वेळ विकत घेतला. हाच पारंपरिक ops चा सापळा आहे: जास्त बादल्यांवर उपाय म्हणजे जास्त लोक. SRE चा उपाय म्हणजे 68 लहान करणे, आणि तोच भाग 1 चा उरलेला भाग आहे. Demo च्या आठवडे 3 आणि 4 मध्ये पथकाने जास्तीचे काम developers कडे परत दिले; आठवडा 6 पर्यंत ते 37.5% वर आले.

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

ops team चे नाव बदलून "SRE" ठेवणे आणि बाकी काहीच न बदलणे
मोजमाप नाही: ops share कोणालाच माहीत नाही, म्हणून cap फक्त एक घोषणा उरते
SRE team service ताब्यात घेते आणि developers ना तिचा त्रास जाणवणेच बंद होते
50% ला भरायचे लक्ष्य समजणे ("आपल्याकडे मोकळा वेळ आहे, आणखी tickets घ्या")
engineering चा वेळ जो नेहमी "पुढच्या sprint मध्ये" असतो

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

Ops share मोजा. सर्वात स्वस्त मार्ग: tickets आणि pages ना label लावा, आणि प्रत्येकाने आठवड्यातून एकदा ops चे तास नोंदवावेत. खऱ्या account वर — GitHub CLI वापरून, पथकाच्या repo मधील या आठवड्यातले ops label असलेले issues मोजा:

gh issue list --label ops --state all --search "created:>=2026-09-21" --json number --jq length

SRE आणि एखाद्या service च्या developers मधली एक छोटी "engagement" नोंद काम परत देणे स्पष्ट करते (service repo मधील एक साधी YAML file पुरेशी आहे):

service: timetable
sre_owner: katrina
dev_owner: timetable-team
ops_cap: 0.5              # measured over 4 weeks
over_cap_action: dev team joins the on-call rotation and takes ops tickets until under the cap
review: quarterly

पुढे वाचा: https://sre.google/books/ वरील मोफत SRE पुस्तके — Site Reliability Engineering (2016) ची प्रकरणे 1 आणि 5, आणि The Site Reliability Workbook (2018) मधील SRE चा DevOps शी संबंध सांगणारे प्रकरण.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: तुमच्या team ला विचारा "गेल्या महिन्यातला किती भाग ops होता?" कोणालाच माहीत नसेल, तर या आठवड्यापासून नोंदवायला सुरुवात करा. तुम्ही SRE team आहात की बादली team, हे तो आकडा ठरवतो.

⏭️ पुढे

Cap पथकाचा वेळ वाचवतो. पुढचा धडा users चे रक्षण करतो: अपयशाचे एक ठरलेले प्रमाण, आणि ते संपल्यावर काय होते.

git checkout lesson-02-error-budget-policy

🛠️ Lesson 01 — What SRE is: the crew that fixes the gutter

📍 You are here: Lesson 01 of 12 · Next: lesson-02-error-budget-policy

📦 What's in this branch

The job this whole course is about. The school has many buildings (services): the timetable, the results portal, the library catalogue. It has a maintenance crew — Katrina, Dipika and Aishwarya — who keep the buildings running. The crew has one rule that makes it different from a plain repair team: they write tools, they do not just carry more buckets. Real files you will use all the way through:

sre/crew.py — the crew's working rules as small deterministic models (lessons 01–08), pure Python, zero dependencies
sre/design.py — the building rules for failure (lessons 09–12)
sre/demo.py — every lesson as a small program (python3 sre/demo.py <section>; sections: job budget toil oncall canary rollout capacity command nines overload chaos prr)
sre/test_sre.py — 12 checks on the crew's rules
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no cloud account, no pip install. crew.py and design.py are teaching models: they keep the arithmetic and the rules of real SRE practice and leave out everything else. Randomness is seeded, so every run prints the same story. Signals, SLO arithmetic, burn-rate alerts and postmortems are taught in the sibling Observability school; this course links to them instead of teaching them again.

🧒 Explain like I'm 5

When it rains, the roof of the timetable building leaks. 🌧️

A plain repair team puts a bucket under the leak. Next week, more rain, more leaks, more buckets. The school grows, so there are more roofs — and more buckets. Soon the team does nothing but carry buckets. They need more people just to carry them.

Katrina, Dipika and Aishwarya do it differently. They carry the bucket today, yes. But they also fix the gutter, so next week there is no leak and no bucket. 🔧

And they keep a rule: at most half of our week is buckets. The other half is for fixing gutters. If the buckets take more than half the week, they tell the people who built the building: "your building leaks too much — come and help carry, or come and help fix."

🗺️ Diagram

flowchart LR
    rain["🌧️ more pupils,<br/>more buildings"] --> ops["🪣 ops work<br/>tickets, pages, manual fixes"]
    ops --> cap{"more than 50%<br/>of the crew's week?"}
    cap -->|"no"| eng["🔧 engineering<br/>tools, automation, fixes"]
    cap -->|"yes"| back["↩️ extra ops goes back<br/>to the dev team"]
    eng -->|"less ops next week"| ops
    back --> eng

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

❓ What

Site Reliability Engineering (SRE) — running production services as a software engineering problem. Ben Treynor Sloss, who started Google's SRE team in 2003, put it as: "what happens when you ask a software engineer to design an operations team."
Operations (ops) work — keeping things running by hand: tickets, pages, manual deploys, restarts, answering "is it down?". Necessary, but it does not make next week easier.
Engineering work — work that leaves a lasting improvement: a tool, an automation, a design change, a better alert. It makes next week's ops smaller.
The 50% cap — the Google SRE book's rule: SREs spend at most 50% of their time on ops work, so at least half is engineering. When ops goes over the cap, the extra is sent back to the development team (they take tickets, join the on-call rotation) until the service is healthier. The cap is measured over time, not policed hour by hour.
Classic ops team — grows its headcount in step with the service: twice the servers, about twice the people. SRE aims for a team that grows slower than the service.
DevOps — a culture and set of principles: developers and operations share ownership, automate, measure, release in small steps. Google's Site Reliability Workbook describes SRE as one concrete implementation of those ideas ("class SRE implements interface DevOps"). They are not rivals; SRE adds specific numbers and practices (SLOs, error budgets, the ops cap, toil budgets).
Shared responsibility — the developers still own their service. SRE is a partner with a pager and a veto on launches that are not ready (lesson 12), not a team that takes over whatever is thrown over the wall.

🤔 Why

Because manual operations do not scale. If every new building needs another person to carry buckets, the maintenance bill grows as fast as the school. Worse: a team that only carries buckets has no time to ask why the roof leaks. The 50% cap protects the time that makes the problem smaller. And sending the extra back to the developers is a feedback loop: the people who can fix a leaky design feel the leaks.

🔧 How (in this repo)

ops_share(weeks, cap=0.5) in sre/crew.py takes a list of (ops_hours, total_hours) per week and returns (share, over_cap) for each. job() in sre/demo.py runs six weeks of a three-person crew: 3 × 40 hours = 120 hours a week.

🧪 Try it

python3 sre/demo.py job
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import ops_share
# a quarter where the timetable service keeps growing and nobody automates anything
weeks = [(40 + 4 * w, 120) for w in range(8)]
for i, (share, over) in enumerate(ops_share(weeks), 1):
    print(f"week {i}: ops {share:5.1%}" + (" → over the cap" if over else ""))
print("the same weeks with a 3-person crew grown to 4 (160 h):")
print([f"{s:.0%}" for s, _ in ops_share([(o, 160) for o, _ in weeks])])
EOF
python3 sre/test_sre.py

✅ Verify — what you should see

job prints:

   week 3:  63 h ops = 52.5%  ← over the 50% cap: extra tickets and pages go back to the dev team
   week 4:  71 h ops = 59.2%  ← over the 50% cap: extra tickets and pages go back to the dev team
   week 5:  58 h ops = 48.3%
   week 6:  45 h ops = 37.5%
   six-week average 47.1% · the rest of the week is ENGINEERING: tools that make next week's ops smaller

Your snippet prints:

week 6: ops 50.0%
week 7: ops 53.3% → over the cap
week 8: ops 56.7% → over the cap
the same weeks with a 3-person crew grown to 4 (160 h):
['25%', '28%', '30%', '32%', '35%', '38%', '40%', '42%']

The tests end with 12/12 passed.

🏁 What you just proved

When ops grows by 4 hours a week and nobody automates, the crew crosses the cap in week 7. Hiring a fourth person pushes the share back to 42% — for now. The ops hours kept growing (40 → 68); the new person only bought time. That is the classic ops trap: the fix for more buckets is more people. The SRE fix is to make the 68 smaller, which is the rest of Part 1. In weeks 3 and 4 of the demo, the crew handed the extra back to the developers; by week 6 it was down to 37.5%.

⚠️ Common mistakes

renaming the ops team "SRE" and changing nothing else
no measurement: nobody knows the ops share, so the cap is a slogan
an SRE team that takes over a service and the developers stop feeling its pain
treating the 50% as a target to fill ("we have spare time, take more tickets")
engineering time that is always "next sprint"

🏭 In production

Measure the ops share. The cheapest way: label tickets and pages, and have each person log ops hours once a week. On a real account — with the GitHub CLI, count this week's issues labelled ops in the crew's repo:

gh issue list --label ops --state all --search "created:>=2026-09-21" --json number --jq length

A short "engagement" note between SRE and the developers of a service makes the handback explicit (a plain YAML file in the service repo is enough):

service: timetable
sre_owner: katrina
dev_owner: timetable-team
ops_cap: 0.5              # measured over 4 weeks
over_cap_action: dev team joins the on-call rotation and takes ops tickets until under the cap
review: quarterly

Read further: the free SRE books at https://sre.google/books/ — Site Reliability Engineering (2016) chapters 1 and 5, and The Site Reliability Workbook (2018) chapter on how SRE relates to DevOps.

🏭 Why this matters in production: ask your team "what share of last month was ops?" If nobody knows, start logging it this week. The number decides whether you are an SRE team or a bucket team.

⏭️ Next

The cap protects the crew's time. The next lesson protects the users: an agreed amount of failure, and what happens when it is used up.

git checkout lesson-02-error-budget-policy

← Course homeall lessons Next →error budget policy

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