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

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

🪣 धडा 03 — Toil: आधी बादल्या मोजा, मग त्यांना automate करा

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

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

धडा 02, अधिक पथकाची toil ची नोंदवही. Toil म्हणून काय मोजले जाते (आणि काय नाही), ते कसे मोजायचे, आणि कोणते automation आधी बनवायचे हे त्याच्या payback time वरून कसे ठरवायचे — नव्या tool ला स्वतःला लागणाऱ्या upkeep सकट. sre/crew.py मधील ToilLedger आणि sre/demo.py मधील toil().

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

दीपिका एक वही ठेवते. 📒 पथक प्रत्येक वेळी एखादे कंटाळवाणे काम हाताने करते, तेव्हा ती ते लिहून ठेवते: काम काय होते, किती वेळ लागला, ते किती वेळा होते.

महिन्याभराने ती बेरीज करते. "आपण विद्यार्थिनींची locked accounts आठवड्याला 60 वेळा reset करतो. प्रत्येकी दहा मिनिटे. म्हणजे आठवड्याला 10 तास — कतरिनाच्या आठवड्यातला एक पूर्ण दिवस, दर आठवड्याला."

मग ती विचारते: "विद्यार्थिनींनी आपले account स्वतः reset करावे असे बटण बनवायला किती वेळ लागेल?" कतरिना म्हणते: "16 तास." म्हणजे दोन आठवड्यांपेक्षा कमी काळात बटणाने आपली किंमत वसूल केली. त्यानंतर तो मोकळा वेळ आहे.

पण काही कामे क्वचितच येतात. Certificate चे नूतनीकरण वर्षातून चार वेळा होते. त्यासाठी tool बनवायला 12 तास लागतात आणि ते जवळपास काहीच वाचवत नाही. वहीनुसार ते फायद्याचे नाही. (तरीही दीपिका ते करते — कारण ते एकदा जरी विसरले, तर संपूर्ण इमारत अंधारात जाते. वही हीच एकमेव मोजण्याची गोष्ट नाही.)

🗺️ आकृती

flowchart LR
    ledger["📒 toil ledger<br/>24.2 h/week"] --> rank["📊 rank by payback<br/>build ÷ (saved − upkeep)"]
    rank --> a["backups 1.2 wk"]
    rank --> b["account resets 1.6 wk"]
    rank --> c["disk resize 2.8 wk"]
    rank --> d["print queue 3.5 wk<br/>(next quarter)"]
    rank --> e["TLS cert 137 wk<br/>(use ACME anyway)"]
    a & b & c --> done["🔧 40 h budget spent: 30 h<br/>toil 24.2 → 6.2 h/week"]

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

❓ काय

Toil — Google SRE पुस्तकाची व्याख्या: production service चालवण्याशी जोडलेले असे काम जे हाताने केलेले, पुन्हा पुन्हा होणारे, automate करता येणारे, तात्कालिक (व्यत्ययांवर चालणारे) असते, ज्याला टिकाऊ मूल्य नसते, आणि जे service वाढेल तसे रेषीय प्रमाणात वाढते. Accounts हाताने reset करणे हे toil आहे. तुम्हाला न आवडणारे प्रत्येक काम toil नसते.
Overhead — service चालवण्याशी न जोडलेले काम: बैठका, नियोजन, प्रशिक्षण, reviews. आवश्यक, पण toil नाही. नोंदवही ते वेगळे ठेवते म्हणजे ते आकड्यांमध्ये लपत नाही.
Engineering — टिकाऊ मूल्य असलेले काम: tools, design मधील बदल, automation.
Toil budget — SRE पुस्तकाचे ध्येय म्हणजे प्रत्येक SRE च्या वेळेच्या 50% पेक्षा कमी toil ठेवणे (तो धडा 01 मधील ops share चा भाग आहे).
Payback time — build hours ÷ (hours saved per week − upkeep hours per week). Automation ने त्याला लागलेला वेळ परत करेपर्यंतचे आठवडे. Upkeep महत्त्वाचा आहे: दर महिन्याला बिघडणारी script मोफत नसते.
Automate करण्याआधी काढून टाका — सर्वात चांगला उपाय गरजच काढून टाकतो: print queue का अडकते ते शोधा. Restart automate केल्याने bug लपतो आणि upkeep चा खर्च तरीही लागतो.
Self-service — बहुतेक वेळा सर्वात चांगले automation म्हणजे ज्याने मागितले त्यालाच ते स्वतः करू देणे (एक "माझे account reset करा" बटण), संरक्षक कठड्यांसह.

🤔 का

कारण toil म्हणजेच बादल्या. ते शाळेसोबत वाढते, आणि ज्या engineering ने ते कमी झाले असते तिला बाजूला सारते. ते लोकांसाठीही वाईट आहे: पुन्हा पुन्हा होणारे, व्यत्ययांवर चालणारे काम थकवणारे आणि चुकांना आमंत्रण देणारे असते — 60 पैकी 58 वे account reset करणारी व्यक्ती चुकीचे account reset करण्याची शक्यता जास्त असते. आणि कोणी मोजल्याशिवाय ते दिसत नाही. नोंदवही "आम्ही नेहमी व्यस्त असतो" याला आधी काय दुरुस्त करायचे याच्या क्रमवार यादीत बदलते.

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

sre/crew.py मधील ToilLedger(tasks) (name, minutes each, times per week, kind, hours to automate, upkeep hours per week) च्या rows घेते. hours(kind) आठवड्याच्या तासांची बेरीज करते; roi() toil rows ना payback नुसार क्रम लावते; plan(budget_hours, max_payback_weeks=26) build budget संपेपर्यंत payback क्रमाने automations निवडते, आणि ज्याचा payback 26 आठवड्यांपेक्षा जास्त असेल ते वगळते.

🧪 करून पाहा

python3 sre/demo.py toil
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import ToilLedger
L = ToilLedger([("reset locked pupil accounts", 10, 60, "toil", 16, 0.25),
                ("restart the stuck print queue", 15, 24, "toil", 20, 0.25),
                ("answer 'is it down?' chat questions", 5, 40, "toil", 10, 0.5),
                ("weekly crew meeting", 60, 3, "overhead", 0, 0)])
print(f"toil {L.hours('toil'):.2f} h/week · overhead {L.hours('overhead'):.1f} h/week")
for name, saved, build, upkeep, pay in L.roi():
    print(f"{name:<36} saves {saved:5.2f} h/week · pays back in {pay:4.1f} weeks")
for budget in (16, 30, 50):
    print(f"budget {budget:>2} h →", L.plan(budget))
EOF

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

toil हे print करते:

── the toil ledger: toil 24.2 h/week · overhead 3.0 h · engineering 8.0 h
   copy grades to the backup drive   5.00 h/week · build  6 h · upkeep 0.10 h/week → pays back in    1.2 weeks
   reset locked pupil accounts      10.00 h/week · build 16 h · upkeep 0.25 h/week → pays back in    1.6 weeks
   grow a full disk by hand          3.00 h/week · build  8 h · upkeep 0.10 h/week → pays back in    2.8 weeks
   restart the stuck print queue     6.00 h/week · build 20 h · upkeep 0.25 h/week → pays back in    3.5 weeks
   renew a TLS certificate by hand   0.19 h/week · build 12 h · upkeep 0.10 h/week → pays back in  137.1 weeks
   toil falls from 24.2 to 6.2 h/week, plus 0.45 h/week of upkeep for the new tools

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

toil 19.33 h/week · overhead 3.0 h/week
reset locked pupil accounts          saves 10.00 h/week · pays back in  1.6 weeks
restart the stuck print queue        saves  6.00 h/week · pays back in  3.5 weeks
answer 'is it down?' chat questions  saves  3.33 h/week · pays back in  3.5 weeks
budget 16 h → (['reset locked pupil accounts'], 16)
budget 30 h → (['reset locked pupil accounts', "answer 'is it down?' chat questions"], 26)
budget 50 h → (['reset locked pupil accounts', 'restart the stuck print queue', "answer 'is it down?' chat questions"], 46)

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

तीस तासांच्या बांधणीने दर आठवड्याचे 18 तास toil काढून टाकले (24.2 → 6.2), त्याबदल्यात आठवड्याला 0.45 तास upkeep. क्रम "सर्वात मोठे काम आधी" असा नाही — account resets सर्वात जास्त वाचवतात, पण backup copy सर्वात लवकर वसूल होते. 30 तासांत planner ने print queue (20 h) वगळली आणि त्याऐवजी स्वस्त "is it down?" item घेतला; 50 तासांत त्याने तिन्ही घेतले. आणि certificate नोंदवहीची मर्यादा दाखवते: तासांच्या हिशोबाने वसुलीला 137 आठवडे, तरीही एकदा विसरलेले नूतनीकरण म्हणजे outage. धोकाही मोजला जातो.

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

सगळ्या ops कामाला toil म्हणणे — overhead आणि खरे incident काम toil नाही
काही आठवडे नोंद ठेवण्याऐवजी आठवणीतून toil चा अंदाज लावणे
बिघडलेली प्रक्रिया काढून टाकण्याऐवजी ती automate करणे ("दर तासाला restart करा")
upkeep कडे दुर्लक्ष — असे tool ज्याला दर आठवड्याला एक माणूस लागतो
संरक्षक कठडे नसलेले automation: चुकीची disk resize करणारी script, वेगाने, सगळीकडे
पुन्हा कधीच न मोजणे, म्हणजे toil परत आलेले कोणालाच दिसत नाही

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

काम जिथे आधीच होते तिथेच toil नोंदवा. Tickets ना लागलेल्या मिनिटांसह toil tag लावा; महिन्यातून एकदा कामानुसार बेरीज करा. खऱ्या account वर — उदाहरणार्थ, तुमच्या ticket system च्या CSV export मधून:

# columns: task,minutes
awk -F, 'NR > 1 { m[$1] += $2 } END { for (t in m) printf "%6.1f h  %s\n", m[t] / 60, t }' toil-2026-09.csv | sort -rn

Kubernetes वर cert-manager (ACME, Let's Encrypt) वापरून certificate चे नूतनीकरण कायमचे काढून टाका; ते expiry च्या आधीच नूतनीकरण करते:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata: {name: timetable-tls, namespace: timetable}
spec:
  secretName: timetable-tls
  dnsNames: [timetable.school.example]
  issuerRef: {name: letsencrypt-prod, kind: ClusterIssuer}
  renewBefore: 720h            # renew 30 days before the certificate expires

संरक्षक कठड्यांसह self-service म्हणजे बहुतेक वेळा एक छोटे runbook-automation job (Rundeck, एखादे अंतर्गत portal, किंवा chat command) जे कोण मागत आहे ते तपासते, प्रत्येक run log करते आणि फक्त एकच काम करते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: या आठवड्यात toil ची नोंदवही सुरू करा. महिन्याभराने वरच्या तीन rows हा तुमचा automation चा आराखडा असेल, आधीच क्रम लावलेला, आणि ते आकडे तुमच्या manager समोर त्या वेळेचे समर्थन करतात.

⏭️ पुढे

काही बादल्या पहाटे 3 वाजता येतात. पुढचा धडा ड्युटीच्या फोनबद्दल आहे: तो कोण सांभाळते, तो किती वेळा वाजतो, आणि ते टिकाऊ कसे ठेवायचे.

git checkout lesson-04-on-call

🪣 Lesson 03 — Toil: measure the buckets, then automate them

📍 You are here: Lesson 03 of 12 · Previous: lesson-02-error-budget-policy · Next: lesson-04-on-call

📦 What's in this branch

Lesson 02, plus the crew's toil ledger. What counts as toil (and what does not), how to measure it, and how to decide which automation to build first by its payback time — including the upkeep the new tool itself will need. ToilLedger in sre/crew.py and toil() in sre/demo.py.

🧒 Explain like I'm 5

Dipika keeps a notebook. 📒 Every time the crew does a boring job by hand, she writes it down: what it was, how long it took, how often it happens.

After a month she adds it up. "We reset locked pupil accounts 60 times a week. Ten minutes each. That is 10 hours a week — a whole day of Katrina's week, every week."

Then she asks: "How long to build a button so pupils reset their own account?" Katrina says: "16 hours." So in less than two weeks the button has paid for itself. After that, it is free time.

But some jobs are rare. Renewing the certificate happens four times a year. Building a tool for it takes 12 hours and saves almost nothing. By the notebook, it is not worth it. (Dipika does it anyway — because if they forget it once, the whole building goes dark. The notebook is not the only thing that counts.)

🗺️ Diagram

flowchart LR
    ledger["📒 toil ledger<br/>24.2 h/week"] --> rank["📊 rank by payback<br/>build ÷ (saved − upkeep)"]
    rank --> a["backups 1.2 wk"]
    rank --> b["account resets 1.6 wk"]
    rank --> c["disk resize 2.8 wk"]
    rank --> d["print queue 3.5 wk<br/>(next quarter)"]
    rank --> e["TLS cert 137 wk<br/>(use ACME anyway)"]
    a & b & c --> done["🔧 40 h budget spent: 30 h<br/>toil 24.2 → 6.2 h/week"]

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

❓ What

Toil — the Google SRE book's definition: work tied to running a production service that is manual, repetitive, automatable, tactical (interrupt-driven), has no enduring value, and grows linearly as the service grows. Resetting accounts by hand is toil. Not every piece of work you dislike is toil.
Overhead — work that is not tied to running a service: meetings, planning, training, reviews. Needed, not toil. The ledger keeps it apart so it does not hide in the numbers.
Engineering — work with lasting value: tools, design changes, automation.
Toil budget — the SRE book's goal is to keep toil below 50% of each SRE's time (it is part of the ops share from lesson 01).
Payback time — build hours ÷ (hours saved per week − upkeep hours per week). The weeks until the automation has returned the time it cost. Upkeep matters: a script that breaks every month is not free.
Eliminate before you automate — the best fix removes the need: find why the print queue sticks. Automating a restart hides the bug and still costs upkeep.
Self-service — often the best automation is to let the person who asked do it themselves (a "reset my account" button), with guard rails.

🤔 Why

Because toil is the buckets. It grows with the school, and it crowds out the engineering that would shrink it. It is also bad for people: repetitive, interrupt-driven work is tiring and error-prone — a person resetting account 58 of 60 is more likely to reset the wrong one. And it is invisible unless someone measures it. The ledger turns "we are always busy" into a ranked list of what to fix first.

🔧 How (in this repo)

ToilLedger(tasks) in sre/crew.py takes rows of (name, minutes each, times per week, kind, hours to automate, upkeep hours per week). hours(kind) sums the weekly hours; roi() ranks the toil rows by payback; plan(budget_hours, max_payback_weeks=26) picks automations in payback order until the build budget runs out, and skips anything that would take longer than 26 weeks to pay back.

🧪 Try it

python3 sre/demo.py toil
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import ToilLedger
L = ToilLedger([("reset locked pupil accounts", 10, 60, "toil", 16, 0.25),
                ("restart the stuck print queue", 15, 24, "toil", 20, 0.25),
                ("answer 'is it down?' chat questions", 5, 40, "toil", 10, 0.5),
                ("weekly crew meeting", 60, 3, "overhead", 0, 0)])
print(f"toil {L.hours('toil'):.2f} h/week · overhead {L.hours('overhead'):.1f} h/week")
for name, saved, build, upkeep, pay in L.roi():
    print(f"{name:<36} saves {saved:5.2f} h/week · pays back in {pay:4.1f} weeks")
for budget in (16, 30, 50):
    print(f"budget {budget:>2} h →", L.plan(budget))
EOF

✅ Verify — what you should see

toil prints:

── the toil ledger: toil 24.2 h/week · overhead 3.0 h · engineering 8.0 h
   copy grades to the backup drive   5.00 h/week · build  6 h · upkeep 0.10 h/week → pays back in    1.2 weeks
   reset locked pupil accounts      10.00 h/week · build 16 h · upkeep 0.25 h/week → pays back in    1.6 weeks
   grow a full disk by hand          3.00 h/week · build  8 h · upkeep 0.10 h/week → pays back in    2.8 weeks
   restart the stuck print queue     6.00 h/week · build 20 h · upkeep 0.25 h/week → pays back in    3.5 weeks
   renew a TLS certificate by hand   0.19 h/week · build 12 h · upkeep 0.10 h/week → pays back in  137.1 weeks
   toil falls from 24.2 to 6.2 h/week, plus 0.45 h/week of upkeep for the new tools

Your snippet prints:

toil 19.33 h/week · overhead 3.0 h/week
reset locked pupil accounts          saves 10.00 h/week · pays back in  1.6 weeks
restart the stuck print queue        saves  6.00 h/week · pays back in  3.5 weeks
answer 'is it down?' chat questions  saves  3.33 h/week · pays back in  3.5 weeks
budget 16 h → (['reset locked pupil accounts'], 16)
budget 30 h → (['reset locked pupil accounts', "answer 'is it down?' chat questions"], 26)
budget 50 h → (['reset locked pupil accounts', 'restart the stuck print queue', "answer 'is it down?' chat questions"], 46)

🏁 What you just proved

Thirty hours of building removed 18 hours of toil every week (24.2 → 6.2), for 0.45 hours a week of upkeep. The ranking is not "the biggest task first" — the account resets save the most, but the backup copy pays back fastest. With 30 hours the planner skipped the print queue (20 h) and took the cheaper "is it down?" item instead; with 50 it took all three. And the certificate shows the ledger's limit: 137 weeks to pay back by hours, yet one forgotten renewal is an outage. Risk counts too.

⚠️ Common mistakes

calling all ops work toil — overhead and real incident work are not toil
estimating toil from memory instead of logging it for a few weeks
automating a broken process instead of removing it ("restart it every hour")
ignoring upkeep — the tool that needs a person every week
automation with no guard rails: a script that resizes the wrong disk, fast, everywhere
never measuring again, so nobody sees the toil come back

🏭 In production

Log toil where the work already happens. Tag tickets toil with minutes spent; once a month, sum by task. On a real account — for example, from a CSV export of your ticket system:

# columns: task,minutes
awk -F, 'NR > 1 { m[$1] += $2 } END { for (t in m) printf "%6.1f h  %s\n", m[t] / 60, t }' toil-2026-09.csv | sort -rn

Remove a certificate renewal for good with cert-manager on Kubernetes (ACME, Let's Encrypt), which renews before expiry:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata: {name: timetable-tls, namespace: timetable}
spec:
  secretName: timetable-tls
  dnsNames: [timetable.school.example]
  issuerRef: {name: letsencrypt-prod, kind: ClusterIssuer}
  renewBefore: 720h            # renew 30 days before the certificate expires

Self-service with guard rails is often a small runbook-automation job (Rundeck, an internal portal, or a chat command) that checks who asks, logs every run and does one thing only.

🏭 Why this matters in production: start a toil ledger this week. After a month, the top three rows are your automation roadmap, already ranked, and the numbers justify the time to your manager.

⏭️ Next

Some of the buckets arrive at 3 a.m. The next lesson is about the duty phone: who holds it, how often it rings, and how to keep that sustainable.

git checkout lesson-04-on-call

← Previouserror budget policy Next →on call

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