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

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

📟 धडा 04 — On-call: ड्युटीचा फोन, आणि तो टिकाऊ ठेवणे

📍 तुम्ही इथे आहात: 12 पैकी धडा 04 · मागे: lesson-03-toil · पुढे: lesson-05-canary-analysis

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

धडा 03, अधिक ड्युटीचा फोन. Rotations, एक shift किती pages सहन करू शकते, रात्रीचे pages, follow-the-sun, आणि on-call ने आठवडा खाऊन टाकण्याआधी rotation मध्ये किती लोक हवेत. Alert design (मुळात कशासाठी page यावा) हा Observability धडा 08 चा विषय आहे; हा धडा उत्तर देणाऱ्या लोकांबद्दल आहे. sre/crew.py मधील page_times, shift_load, night_pages आणि oncall_share, आणि sre/demo.py मधील oncall().

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

पथकाकडे एक ड्युटीचा फोन आहे. 📟 तो ज्याच्याकडे असेल तिने एखादी इमारत बिघडली की उत्तर द्यायलाच हवे — दिवसा किंवा रात्री.

सुरुवातीला फक्त कतरिना, दीपिका आणि ऐश्वर्या तो वाटून घेतात. प्रत्येक जण तो एक आठवडा ठेवते, मग पुढे देते. म्हणजे प्रत्येकीकडे तो तीन आठवड्यांतून एक आठवडा असतो. हे खूप आहे. फोन हातात असताना तुम्ही मोठे काम सुरू करू शकत नाही, आणि झोपही नीट लागत नाही.

चार आठवड्यांत फोन रात्री 17 वेळा वाजला. थकलेली माणसे चुका करतात.

म्हणून पथक दोन बदल करते. पहिला, rotation मध्ये जास्त लोक सामील होतात: आठ जण असले, तर प्रत्येक जण आठ आठवड्यांतून फक्त एक आठवडा फोन ठेवते. दुसरा, त्यांना जगाच्या दुसऱ्या बाजूला एक sister crew मिळते. पुण्यात रात्र असते तेव्हा तिथे दिवस असतो. पुणे आपल्या दिवसा फोन ठेवते, sister crew आपल्या दिवसा. आता कोणाचाही फोन रात्री वाजत नाही.

🗺️ आकृती

flowchart LR
    pages["📟 55 pages in 4 weeks<br/>0.98 per 12-hour shift"] --> one["one Pune crew, 24 h<br/>17 night pages"]
    pages --> fts["follow-the-sun<br/>Pune 07–19 · sister crew 19–07<br/>0 night pages"]
    pages --> busy["4 of 56 shifts<br/>had more than 2 pages"]
    rot["rotation size"] --> r3["3 people: 33.3% of weeks ✗"]
    rot --> r8["8 people: 12.5% of weeks ✓"]

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

❓ काय

On-call — नाव ठरलेली व्यक्ती जिने ठरलेल्या वेळेत pages ना प्रतिसाद द्यायलाच हवा (उदाहरणार्थ, सर्वात तातडीच्या page ची 5 मिनिटांत पोचपावती). सहसा एक primary आणि एक secondary (primary ने उत्तर दिले नाही तर backup).
Page — आत्ता एखाद्या व्यक्तीला अडवणारा alert. प्रत्येक page ला माणसाची कृती लागायला हवी; बाकीचे ticket असू शकते.
Shift — on-call वेळेचा एक तुकडा (एक आठवडा, किंवा 12 तासांच्या shifts).
प्रत्येक shift मधील pages — Google SRE पुस्तकाचा ढोबळ नियम: नीट हाताळलेल्या incident ला follow-up सकट सुमारे 6 तास लागतात, म्हणून 12 तासांच्या shift मध्ये जास्तीत जास्त 2 incidents हे लक्ष्य ठेवा. त्याहून जास्त झाले की लोक घाई करतात आणि कामात कोपरे कापतात.
25% नियम — त्याच पुस्तकातून: SRE च्या वेळेपैकी जास्तीत जास्त 25% on call (धडा 01 मधील 50% ops cap च्या आत). आठवड्याच्या primary rotation साठी याला किमान 4 लोक लागतात — आणि प्रत्येक आठवड्याला primary आणि secondary दोन्ही असतील, तर एका site साठी सुमारे 8 (किंवा दोन sites असतील तर प्रत्येक site ला 6), हाच पुस्तकातला आकडा आहे.
Follow-the-sun — time zones मध्ये एकमेकांपासून दूर असलेल्या दोन किंवा जास्त sites प्रत्येक site चा दिवस संपल्यावर pager पुढे सोपवतात, म्हणजे प्रत्येक site फक्त आपल्या दिवसा उत्तर देते. यासाठी स्वच्छ handoff (धडा 08) आणि दोन्ही sites वापरू शकतील असे runbook लागते.
Runbook (playbook) — प्रत्येक page साठी: त्याचा अर्थ काय, कसे तपासायचे, आधी काय करायचे. ते पहाटे 3 वाजताच्या कोड्याला checklist मध्ये बदलते.
मोबदला आणि सुट्टी — पुस्तक on-call साठी मोबदला देण्याची शिफारस करते (सुट्टी किंवा पैसे). थकलेले आणि मोबदला न मिळालेले on-call लोक सोडून जातात.

🤔 का

कारण on-call म्हणजे जिथे reliability आणि माणसे भेटतात. खूप लहान rotation लोकांना थकवून टाकते, आणि थकलेले लोक पुढचे outage अधिक वाईट करतात. रात्रीचे pages कित्येक दिवस झोप बिघडवतात. एका shift मध्ये खूप pages म्हणजे कोणत्याच page कडे खरे लक्ष जात नाही, फक्त एक झटपट restart — आणि कारण तसेच राहते. इथले आकडेच तुम्हाला पुराव्यासह "आपल्याला आणखी चार लोक हवेत" किंवा "हे alerts दुरुस्त व्हायलाच हवेत" असे म्हणू देतात.

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

sre/crew.py मधील page_times(weeks=4, rate=0.07, seed=11) page च्या तासांची seed दिलेली यादी बनवते (hour 0 = पुण्यात सोमवार 00:00; एका तासात जास्तीत जास्त एक page). shift_load(pages) प्रत्येक 12 तासांच्या shift मधील pages मोजते (07:00–19:00 आणि 19:00–07:00); night_pages(pages, offset_h) offset_h तास दूर असलेल्या crew साठी 22:00 ते 07:00 मधील pages मोजते; oncall_share(people) म्हणजे आठवड्याच्या rotation मध्ये प्रत्येक व्यक्ती किती टक्के आठवडे on call असते. oncall() मधील follow-the-sun ची ओळ पुण्याला 07–19 चे pages देते आणि sister crew ला (12 तास दूर) उरलेले.

🧪 करून पाहा

python3 sre/demo.py oncall
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import page_times, shift_load, night_pages
for rate in (0.03, 0.07, 0.15):
    pages = page_times(weeks=4, rate=rate)
    load = shift_load(pages)
    over = sum(1 for n in load.values() if n > 2)
    print(f"rate {rate:.2f}/h → {len(pages):>3} pages · busiest shift {max(load.values())} · shifts over 2: {over:>2} · night pages (one site): {night_pages(pages):>2}")
EOF

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

oncall हे print करते:

── 4 weeks of pages for the timetable service: 55 pages · 0.98 per 12-hour shift on average
   busiest shift 3 pages · shifts with more than 2 pages: 4 of 56
   one Pune crew, 24 h on call: 17 pages between 22:00 and 07:00
   follow-the-sun: Pune takes 07:00–19:00, a sister crew 12 h away takes the rest in its own daytime → night pages 0 + 0
   weekly rotation of 3: each person is on call 33.3% of weeks  ← over 25%: no time left for engineering
   weekly rotation of 5: each person is on call 20.0% of weeks
   weekly rotation of 8: each person is on call 12.5% of weeks

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

rate 0.03/h →  20 pages · busiest shift 2 · shifts over 2:  0 · night pages (one site):  5
rate 0.07/h →  55 pages · busiest shift 3 · shifts over 2:  4 · night pages (one site): 17
rate 0.15/h → 114 pages · busiest shift 5 · shifts over 2: 21 · night pages (one site): 48

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

Shift मागे 0.98 pages ची सरासरी ठीक दिसते, पण तरीही 4 shifts 2 च्या वर गेल्या — pages घोळक्याने येतात, म्हणून सरासरी नव्हे तर सर्वात व्यस्त shifts बघा. तासाला 0.15 pages वर 56 पैकी 21 shifts वर जास्त भार असतो: हा alert चा प्रश्न आहे (alerts आणि कारणे दुरुस्त करा), माणसांच्या संख्येचा नाही. Follow-the-sun ने रात्रीचे 17 pages शून्यावर आणले, आणि 8 जणांच्या rotation ने तीनपैकी-एक-आठवडा याला आठपैकी-एक केले. दोन्हींचा खरा खर्च आहे — दुसरी site, जास्त प्रशिक्षित लोक — आणि दोन्ही पथक गमावण्यापेक्षा स्वस्त आहेत.

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

"सध्यापुरते" 2 किंवा 3 जणांचे rotation, वर्षानुवर्षे
shift मागच्या pages ची सरासरी मोजणे आणि वाईट shifts चुकवणे
runbook नसलेले pages, किंवा कोणीच वापरून न पाहिलेले runbooks
"तू on call आहेस, तर तुझे नेहमीचे कामही कर" — मग दोन्हीपैकी काहीच होत नाही
handoff नसलेले follow-the-sun, म्हणजे नवी site प्रत्येक incident शून्यापासून सुरू करते
on-call साठी मोबदला न देणे, किंवा सुट्टीवर असताना लोकांनी on call राहावे अशी अपेक्षा

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

बहुतेक teams PagerDuty, Opsgenie, Grafana OnCall किंवा incident.io वापरून pages चे वेळापत्रक आणि routing करतात. वेळापत्रक म्हणजे data: एक rotation, handoff ची वेळ, एक primary आणि एक secondary. खऱ्या account वर — PagerDuty चा REST API आत्ता कोण on call आहे ते दाखवतो:

curl -s -H "Authorization: Token token=$PD_TOKEN" -H "Accept: application/vnd.pagerduty+json;version=2" \
  "https://api.pagerduty.com/oncalls?schedule_ids[]=$SCHEDULE_ID" | jq -r '.oncalls[].user.summary'

Prometheus Alertmanager चा route फक्त तातडीचे alerts pager ला आणि बाकीचे ticket रांगेकडे पाठवू शकतो, आणि पुनरावृत्ती रोखू शकतो:

route:
  receiver: tickets
  group_by: [alertname, service]
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: pagerduty-timetable
receivers:
  - name: pagerduty-timetable
    pagerduty_configs: [{routing_key: "<secret>"}]
  - name: tickets
    webhook_configs: [{url: "https://tickets.school.example/hook"}]

आठवड्याचा on-call review (15 मिनिटे) प्रत्येक page पाहतो: त्यावर कृती करता येण्यासारखी होती का, runbook बरोबर होते का, त्याऐवजी ते ticket असायला हवे होते का?

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: गेल्या महिन्यातले shift मागचे pages, आणि व्यक्तीमागचे रात्रीचे pages मोजा. Team समोर सरासरी नव्हे, तर सर्वात व्यस्त shifts ठेवा. मग भरती करण्याआधी सर्वात गोंगाट करणारा alert दुरुस्त करा.

⏭️ पुढे

बरेच pages एखाद्या बदलापासून सुरू होतात. पुढचा धडा एखादा बदल आधी शाळेच्या छोट्या भागावर करून पाहतो, आणि आकड्यांवरून त्याचा निर्णय घेतो.

git checkout lesson-05-canary-analysis

📟 Lesson 04 — On-call: the duty phone, and keeping it sustainable

📍 You are here: Lesson 04 of 12 · Previous: lesson-03-toil · Next: lesson-05-canary-analysis

📦 What's in this branch

Lesson 03, plus the duty phone. Rotations, how many pages a shift can take, night pages, follow-the-sun, and how many people a rotation needs before on-call eats the week. Alert design (what should page at all) belongs to Observability lesson 08; this lesson is about the people who answer. page_times, shift_load, night_pages and oncall_share in sre/crew.py and oncall() in sre/demo.py.

🧒 Explain like I'm 5

The crew has one duty phone. 📟 Whoever holds it must answer when a building breaks — day or night.

At first, only Katrina, Dipika and Aishwarya share it. Each holds it for a week, then passes it on. So each of them holds it one week in three. That is a lot. When you hold the phone, you cannot start big work, and you sleep badly.

The phone rang 17 times at night in four weeks. Tired people make mistakes.

So the crew makes two changes. First, more people join the rotation: with eight, each person holds the phone only one week in eight. Second, they find a sister crew on the other side of the world. When it is night in Pune, it is day there. Pune holds the phone in its day, the sister crew in theirs. Now nobody's phone rings at night.

🗺️ Diagram

flowchart LR
    pages["📟 55 pages in 4 weeks<br/>0.98 per 12-hour shift"] --> one["one Pune crew, 24 h<br/>17 night pages"]
    pages --> fts["follow-the-sun<br/>Pune 07–19 · sister crew 19–07<br/>0 night pages"]
    pages --> busy["4 of 56 shifts<br/>had more than 2 pages"]
    rot["rotation size"] --> r3["3 people: 33.3% of weeks ✗"]
    rot --> r8["8 people: 12.5% of weeks ✓"]

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

❓ What

On-call — a named person who must respond to pages within an agreed time (for example, acknowledge in 5 minutes for the most urgent). Usually a primary and a secondary (backup if the primary does not answer).
Page — an alert that interrupts a person now. Every page should need a human action; the rest can be a ticket.
Shift — a block of on-call time (a week, or 12-hour shifts).
Pages per shift — the Google SRE book's rule of thumb: an incident, handled well, takes about 6 hours including the follow-up, so aim for at most 2 incidents per 12-hour shift. Above that, people rush and cut corners.
The 25% rule — the same book: at most 25% of an SRE's time on call (inside the 50% ops cap from lesson 01). With a weekly primary rotation, that needs at least 4 people — and with a primary and a secondary each week, about 8 for one site (or 6 per site for two sites), which is the book's figure.
Follow-the-sun — two or more sites far apart in time zones hand the pager over at the end of each site's day, so each site answers only in its daytime. Needs a clean handoff (lesson 08) and a runbook both sites can use.
Runbook (playbook) — for each page: what it means, how to check, what to do first. It turns a 3 a.m. puzzle into a checklist.
Compensation and time off — the book recommends paying for on-call (time off or money). Tired and unpaid on-call people leave.

🤔 Why

Because on-call is where reliability meets people. A rotation that is too small burns people out, and burned-out people make the next outage worse. Night pages damage sleep for days. Too many pages per shift means none gets real attention, only a quick restart — and the cause stays. The numbers here are what let you say "we need four more people" or "these alerts must be fixed" with evidence.

🔧 How (in this repo)

page_times(weeks=4, rate=0.07, seed=11) in sre/crew.py makes a seeded list of page hours (hour 0 = Monday 00:00 in Pune; at most one page per hour). shift_load(pages) counts pages per 12-hour shift (07:00–19:00 and 19:00–07:00); night_pages(pages, offset_h) counts pages between 22:00 and 07:00 for a crew offset_h hours away; oncall_share(people) is the share of weeks each person is on call in a weekly rotation. The follow-the-sun line in oncall() gives Pune the 07–19 pages and the sister crew (12 hours away) the rest.

🧪 Try it

python3 sre/demo.py oncall
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import page_times, shift_load, night_pages
for rate in (0.03, 0.07, 0.15):
    pages = page_times(weeks=4, rate=rate)
    load = shift_load(pages)
    over = sum(1 for n in load.values() if n > 2)
    print(f"rate {rate:.2f}/h → {len(pages):>3} pages · busiest shift {max(load.values())} · shifts over 2: {over:>2} · night pages (one site): {night_pages(pages):>2}")
EOF

✅ Verify — what you should see

oncall prints:

── 4 weeks of pages for the timetable service: 55 pages · 0.98 per 12-hour shift on average
   busiest shift 3 pages · shifts with more than 2 pages: 4 of 56
   one Pune crew, 24 h on call: 17 pages between 22:00 and 07:00
   follow-the-sun: Pune takes 07:00–19:00, a sister crew 12 h away takes the rest in its own daytime → night pages 0 + 0
   weekly rotation of 3: each person is on call 33.3% of weeks  ← over 25%: no time left for engineering
   weekly rotation of 5: each person is on call 20.0% of weeks
   weekly rotation of 8: each person is on call 12.5% of weeks

Your snippet prints:

rate 0.03/h →  20 pages · busiest shift 2 · shifts over 2:  0 · night pages (one site):  5
rate 0.07/h →  55 pages · busiest shift 3 · shifts over 2:  4 · night pages (one site): 17
rate 0.15/h → 114 pages · busiest shift 5 · shifts over 2: 21 · night pages (one site): 48

🏁 What you just proved

An average of 0.98 pages a shift looks fine, but 4 shifts still went over 2 — pages come in clumps, so look at the busiest shifts, not the mean. At 0.15 pages an hour, 21 of 56 shifts are overloaded: that is an alert problem (fix the alerts and the causes), not a staffing problem. Follow-the-sun turned 17 night pages into zero, and a rotation of 8 turned one-week-in-three into one-in-eight. Both are real costs — a second site, more trained people — and both are cheaper than losing the crew.

⚠️ Common mistakes

a rotation of 2 or 3 "for now", for years
measuring the average pages per shift and missing the bad shifts
pages with no runbook, or runbooks nobody has tried
"you're on call, so do your normal work too" — then neither gets done
follow-the-sun with no handoff, so the new site starts every incident from zero
not paying for on-call, or expecting people to be on call while on holiday

🏭 In production

Most teams schedule and route pages with PagerDuty, Opsgenie, Grafana OnCall or incident.io. The schedule is data: a rotation, a handoff time, a primary and a secondary. On a real account — PagerDuty's REST API lists who is on call now:

curl -s -H "Authorization: Token token=$PD_TOKEN" -H "Accept: application/vnd.pagerduty+json;version=2" \
  "https://api.pagerduty.com/oncalls?schedule_ids[]=$SCHEDULE_ID" | jq -r '.oncalls[].user.summary'

A Prometheus Alertmanager route can send only urgent alerts to the pager and the rest to a ticket queue, and hold back repeats:

route:
  receiver: tickets
  group_by: [alertname, service]
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: pagerduty-timetable
receivers:
  - name: pagerduty-timetable
    pagerduty_configs: [{routing_key: "<secret>"}]
  - name: tickets
    webhook_configs: [{url: "https://tickets.school.example/hook"}]

A weekly on-call review (15 minutes) looks at every page: was it actionable, was the runbook right, should it be a ticket instead?

🏭 Why this matters in production: count last month's pages per shift, and the night pages per person. Put the busiest shifts in front of the team, not the average. Then fix the top noisy alert before hiring.

⏭️ Next

Many pages start with a change. The next lesson tries a change on a small part of the school first, and judges it with numbers.

git checkout lesson-05-canary-analysis

← Previoustoil Next →canary analysis

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