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

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

📈 धडा 07 — Capacity planning: विद्यार्थिनी येण्याआधीच पुढच्या सत्रासाठी खुर्च्या

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 · मागे: lesson-06-progressive-delivery · पुढे: lesson-08-incident-command

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

धडा 06, अधिक नियोजन. खऱ्या peaks वरून वाढीची रेषा काढा, तिचा forecast करा, headroom ठेवा, बिघाडांसाठी जास्तीचे servers जोडा (N+1, N+2), संपूर्ण zone गेला तरी टिका, आणि ठाऊक असलेल्या events (निकालाचा दिवस) चा आराखडा वेगळा करा. sre/crew.py मधील CapacityPlan आणि sre/demo.py मधील capacity(). Load कसा मोजायचा आणि autoscale कसे करायचे हे Scaling school मध्ये शिकवले आहे; हा धडा म्हणजे पथकाचा आराखडा.

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

दर आठवड्याला ऐश्वर्या सर्वात गर्दीच्या क्षणी सभागृहात किती विद्यार्थिनी आहेत ते मोजते. 🪑 आठवडा 1: 1,206. आठवडा 12: 1,707. आकडा आठवड्याला साधारण 48 ने वाढतो.

"सहा महिन्यांनी तो कुठे असेल?" ती या आकड्यांमधून एक सरळ रेषा काढते आणि ती पुढे नेते: साधारण 2,963.

खुर्च्यांच्या एका रांगेत 300 जण बसतात, पण पूर्ण भरलेली रांग अवघडलेली असते, म्हणून ती प्रत्येक रांगेचा आराखडा 210 साठी करते (70% भरलेली). म्हणजे 15 रांगा.

"आणि एखादी रांग मोडली तर?" एक जोडा: 16. "एका रांगेची दुरुस्ती चालू असताना आणि दुसरी मोडली तर?" दोन जोडा: 17. "सभागृहाची संपूर्ण पूर्व बाजू बंद असली तर?" उरलेल्या दोन बाजूंनी सगळ्यांना बसवायला हवे: 24 रांगा, तीन बाजूंमध्ये विभागलेल्या.

आणि निकालाचा दिवस वेगळा असतो: नेहमीच्या गर्दीच्या 2.5 ×. त्याला 36 रांगा लागतात — म्हणून त्या त्या दिवसाच्या आधीच खुर्च्या उसन्या आणतात, पालक उभे असताना नाही.

🗺️ आकृती

flowchart LR
    peaks["📊 12 weekly peaks<br/>1,206 → 1,707 req/s"] --> fit["📈 straight line<br/>+47.8 req/s per week"]
    fit --> fc["forecast +26 weeks<br/>2,963 req/s"]
    fc --> n["N = 15<br/>210 req/s each (70% of 300)"]
    n --> n1["N+1 = 16"]
    n --> n2["N+2 = 17"]
    n --> z["lose 1 of 3 zones: 24"]
    fc --> ev["results day × 2.5<br/>7,408 req/s → 36"]

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

❓ काय

Demand forecast — भविष्यातील एखाद्या तारखेला अपेक्षित peak load, इतिहास आणि ठाऊक असलेल्या योजनांवरून (नवी शाळा जोडली जाते, marketing मोहीम). Lab 12 आठवड्यांच्या peaks मधून एक सरळ रेषा (least squares) काढते. खरी मागणी बहुतेक वेळा सरळ रेषेत नसते — आठवड्याची आणि वर्षाची चक्रे, अचानक उड्या — म्हणून दर महिन्याला forecast ची प्रत्यक्ष आकड्यांशी तुलना करा.
Peak, average नाही — आठवड्यातील सर्वात गर्दीच्या मिनिटासाठी आराखडा करा, कारण त्याच वेळी users परत पाठवले जातात.
Load-tested limit — latency किंवा errors मुळे SLO तुटण्याआधी एक server जास्तीत जास्त किती करू शकतो, ते load test ने मोजलेले, CPU वरून अंदाजलेले नाही. इथे: 300 requests/s.
Headroom (target utilisation) — प्रत्येक server त्याच्या limit च्या, समजा, 70% वर चालेल असा आराखडा करा. उरलेला भाग अचानक वाढ, हळू dependencies आणि forecast मधील चूक शोषून घेतो. जास्त target मुळे पैसे वाचतात आणि सुरक्षितता कमी होते.
N+1 / N+2 — N servers peak सांभाळतात; N+1 एक बिघाड झेलतो; N+2 एक बिघाड झेलतो तेव्हा दुसरा नियोजित maintenance साठी बंद असतो (Google SRE चा एक नेहमीचा नियम).
Zone (failure domain) — एकत्र बंद पडणारा गट: एक rack, एक data center, एक cloud availability zone. 3 पैकी एक zone गेला तरी टिकण्यासाठी उरलेल्या 2 नी संपूर्ण peak सांभाळायला हवा, म्हणून प्रत्येक zone ला N ÷ 2 (वर पूर्णांक केलेले) लागतात — एकूण 3 × ⌈N/2⌉. हे बहुतेक वेळा N+2 पेक्षा जास्त असते.
Lead time — "आणखी मागवा" पासून "traffic सेवा देत आहे" पर्यंतचा वेळ. Cloud autoscaling साठी मिनिटे; नवे hardware, नवा region किंवा quota वाढीसाठी आठवडे किंवा महिने. किमान एका lead time इतका पुढचा forecast करा.
Event capacity — ठाऊक असलेल्या अचानक वाढी (निकालाचा दिवस, sale, launch) यांचा आराखडा हाताने केला जातो: आधीच scale करा, quotas वाढवा, caches गरम करा. Autoscaling load आल्यानंतर प्रतिसाद देते; spike त्याच्या scale होण्यापेक्षा वेगाने आला तर ते मदत करू शकत नाही.

🤔 का

कारण capacity संपणे हे असे outage आहे जे तुम्हाला महिनोन्महिने आधी येताना दिसू शकते. आणि गरजेपेक्षा खूप जास्त विकत घेणे म्हणजे दर महिन्याला वाया जाणारे पैसे. आराखडा दोन्हीवर आकडे ठेवतो, म्हणून "मार्चपर्यंत आपल्याला आणखी 9 servers लागतील" हा पुराव्यासह केलेला युक्तिवाद ठरतो. तो लपलेली गरजही उघड करतो: बिघाडाचा आराखडा (एक zone बंद) बहुतेक वेळा वाढीच्या आराखड्यापेक्षा जास्त मागतो.

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

sre/crew.py मध्ये CapacityPlan(per_server_rps=300, target_util=0.7, zones=3). weekly_peaks() 12 seeded साप्ताहिक peaks बनवते (वाढ अधिक noise), fit(ys) least-squares slope आणि intercept परत देते, servers(peak) म्हणजे ⌈peak ÷ (300 × 0.7)⌉ आणि zone_safe(n) म्हणजे 3 × ⌈n ÷ 2⌉. capacity() आठवडा 12 नंतर 26 आठवडे पुढचा forecast करते.

🧪 करून पाहा

python3 sre/demo.py capacity
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import CapacityPlan
plan = CapacityPlan()
peaks = plan.weekly_peaks(12); slope, icpt = plan.fit(peaks)
for ahead in (4, 13, 26, 52):
    fc = round(icpt + slope * (11 + ahead)); n = plan.servers(fc)
    print(f"{ahead:>2} weeks ahead: {fc:>5,} req/s → N {n:>2} · N+2 {n + 2:>2} · zone-safe {plan.zone_safe(n):>2}")
for util in (0.5, 0.7, 0.9):
    print(f"target utilisation {util:.0%} → N = {CapacityPlan(target_util=util).servers(2963)} for 2,963 req/s")
EOF

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

capacity हे छापते:

── weekly peak requests/s, 12 weeks: [1206, 1226, 1276, 1373, 1365, 1448, 1474, 1533, 1600, 1613, 1684, 1707]
   straight-line fit: +47.8 req/s per week · forecast 26 weeks ahead: 2,963 req/s
   one server: 300 req/s at its load-test limit; plan at 70% = 210 → N = 15 servers for the forecast peak
   N+1 = 16 (one server can fail) · N+2 = 17 (one in maintenance AND one fails) · survive losing 1 of 3 zones: 24
   results day (2.5 × the normal peak = 7,408 req/s) needs 36 — plan it as an event, pre-scale, don't wait for autoscaling

तुमचा snippet हे छापतो:

 4 weeks ahead: 1,912 req/s → N 10 · N+2 12 · zone-safe 15
13 weeks ahead: 2,342 req/s → N 12 · N+2 14 · zone-safe 18
26 weeks ahead: 2,963 req/s → N 15 · N+2 17 · zone-safe 24
52 weeks ahead: 4,204 req/s → N 21 · N+2 23 · zone-safe 33
target utilisation 50% → N = 20 for 2,963 req/s
target utilisation 70% → N = 15 for 2,963 req/s
target utilisation 90% → N = 11 for 2,963 req/s

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

त्याच forecast साठी, zone-loss आराखड्याला (24) N+2 (17) पेक्षा 7 servers जास्त लागतात — तुम्ही कोणत्या बिघाडासाठी design करता ते वाढीपेक्षा जास्त खर्च ठरवते. Utilisation target मुळे N 11 पासून 20 पर्यंत बदलतो: ती headroom ची किंमत आहे, आणि ती निवड आहे, नियम नाही. आणि तुम्ही जितका पुढचा forecast करता, तितका सरळ-रेषेचा अंदाज महत्त्वाचा ठरतो: दर महिन्याला पुन्हा fit करा आणि मागच्या महिन्याच्या forecast ची प्रत्यक्ष घडलेल्याशी तुलना करा.

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

peak ऐवजी average वरून आराखडा करणे
load test ऐवजी CPU च्या अंदाजावरून काढलेला per-server आकडा
एकाच zone मध्ये N+1 — zone बिघडला की सगळेच जाते
lead time पेक्षा कमी कालावधीचा forecast (quota requests, hardware orders)
काही सेकंदांत येणाऱ्या spike साठी autoscaling वर विसंबणे
जुन्या forecast ची प्रत्यक्ष घडलेल्याशी कधीच तुलना न करणे

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

Per-server limit शोधण्यासाठी load-test करा — उदाहरणार्थ k6 ने. खऱ्या account वर (test environment, सहमतीशिवाय production कधीच नाही):

k6 run --vus 300 --duration 10m load-timetable.js    # raise VUs until p99 or errors break the SLO

Kubernetes वर replicas zones मध्ये पसरवा आणि maintenance दरम्यान त्यांचे रक्षण करा:

# in the Deployment's pod template
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector: {matchLabels: {app: timetable}}
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: timetable}
spec:
  minAvailable: 22            # voluntary disruptions (node drains) may not go below this
  selector: {matchLabels: {app: timetable}}

ठाऊक असलेल्या event साठी आधीच scale करा, उदाहरणार्थ Auto Scaling group वरील AWS scheduled action ने:

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name timetable \
  --scheduled-action-name results-day --start-time 2026-10-15T04:00:00Z --min-size 36 --desired-capacity 36

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: प्रत्येक service साठी एक ओळ लिहा: 6 महिन्यांनंतरचा forecast peak, load test मधून per-server limit, target utilisation, N, आणि zone-loss आकडा. त्याच्या शेजारी पुढच्या ठाऊक असलेल्या event ची तारीख लिहा.

⏭️ पुढे

पुरेशी capacity असली तरी गोष्टी बिघडतात. तेव्हा जबाबदारी कोणाची? पुढचा धडा आहे पथकाचे incident command.

git checkout lesson-08-incident-command

📈 Lesson 07 — Capacity planning: chairs for next term, before the pupils arrive

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-progressive-delivery · Next: lesson-08-incident-command

📦 What's in this branch

Lesson 06, plus planning. Fit the growth from real peaks, forecast it, keep headroom, add spare servers for failures (N+1, N+2), survive the loss of a whole zone, and plan known events (results day) separately. CapacityPlan in sre/crew.py and capacity() in sre/demo.py. How to measure load and autoscale is taught in the Scaling school; this lesson is the crew's plan.

🧒 Explain like I'm 5

Every week Aishwarya counts how many pupils are in the hall at the busiest moment. 🪑 Week 1: 1,206. Week 12: 1,707. It goes up about 48 a week.

"Where will it be in six months?" She draws a straight line through the counts and follows it: about 2,963.

One row of chairs seats 300, but a full row is uncomfortable, so she plans each row for 210 (70% full). That is 15 rows.

"And if one row breaks?" Add one: 16. "If one row is being repaired and another breaks?" Add two: 17. "If the whole east wing of the hall is closed?" The other two wings must seat everyone: 24 rows, spread over three wings.

And results day is different: 2.5 × the normal crowd. That needs 36 rows — so they borrow chairs before that day, not while the parents are standing.

🗺️ Diagram

flowchart LR
    peaks["📊 12 weekly peaks<br/>1,206 → 1,707 req/s"] --> fit["📈 straight line<br/>+47.8 req/s per week"]
    fit --> fc["forecast +26 weeks<br/>2,963 req/s"]
    fc --> n["N = 15<br/>210 req/s each (70% of 300)"]
    n --> n1["N+1 = 16"]
    n --> n2["N+2 = 17"]
    n --> z["lose 1 of 3 zones: 24"]
    fc --> ev["results day × 2.5<br/>7,408 req/s → 36"]

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

❓ What

Demand forecast — expected peak load at a future date, from history plus known plans (a new school joins, a marketing push). The lab fits a straight line (least squares) through 12 weekly peaks. Real demand is often not a straight line — weekly and yearly cycles, step changes — so check the forecast against reality every month.
Peak, not average — plan for the busiest minute of the week, because that is when users are turned away.
Load-tested limit — the most one server can do before latency or errors break the SLO, measured with a load test, not guessed from CPU. Here: 300 requests/s.
Headroom (target utilisation) — plan each server to run at, say, 70% of its limit. The rest absorbs bursts, slow dependencies and forecast error. Higher targets save money and cost safety.
N+1 / N+2 — N servers carry the peak; N+1 survives one failure; N+2 survives one failure while another is down for planned maintenance (a common Google SRE rule).
Zone (failure domain) — a group that fails together: a rack, a data center, a cloud availability zone. To survive losing one of 3 zones, the other 2 must carry the whole peak, so each zone needs N ÷ 2 (rounded up) — 3 × ⌈N/2⌉ in total. That is often more than N+2.
Lead time — the time from "order more" to "serving traffic". For cloud autoscaling, minutes; for new hardware, a new region or a quota increase, weeks or months. Forecast at least one lead time ahead.
Event capacity — known spikes (results day, a sale, a launch) are planned by hand: pre-scale, raise quotas, warm caches. Autoscaling reacts after the load arrives; it cannot help if the spike is faster than it scales.

🤔 Why

Because running out of capacity is an outage you could see coming for months. And buying far too much is money wasted every month. The plan puts numbers on both, so "we need 9 more servers by March" is an argument with evidence. It also exposes the hidden requirement: the failure plan (a zone down) usually needs more than the growth plan.

🔧 How (in this repo)

CapacityPlan(per_server_rps=300, target_util=0.7, zones=3) in sre/crew.py. weekly_peaks() makes 12 seeded weekly peaks (growth plus noise), fit(ys) returns the least-squares slope and intercept, servers(peak) is ⌈peak ÷ (300 × 0.7)⌉ and zone_safe(n) is 3 × ⌈n ÷ 2⌉. capacity() forecasts 26 weeks ahead of week 12.

🧪 Try it

python3 sre/demo.py capacity
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import CapacityPlan
plan = CapacityPlan()
peaks = plan.weekly_peaks(12); slope, icpt = plan.fit(peaks)
for ahead in (4, 13, 26, 52):
    fc = round(icpt + slope * (11 + ahead)); n = plan.servers(fc)
    print(f"{ahead:>2} weeks ahead: {fc:>5,} req/s → N {n:>2} · N+2 {n + 2:>2} · zone-safe {plan.zone_safe(n):>2}")
for util in (0.5, 0.7, 0.9):
    print(f"target utilisation {util:.0%} → N = {CapacityPlan(target_util=util).servers(2963)} for 2,963 req/s")
EOF

✅ Verify — what you should see

capacity prints:

── weekly peak requests/s, 12 weeks: [1206, 1226, 1276, 1373, 1365, 1448, 1474, 1533, 1600, 1613, 1684, 1707]
   straight-line fit: +47.8 req/s per week · forecast 26 weeks ahead: 2,963 req/s
   one server: 300 req/s at its load-test limit; plan at 70% = 210 → N = 15 servers for the forecast peak
   N+1 = 16 (one server can fail) · N+2 = 17 (one in maintenance AND one fails) · survive losing 1 of 3 zones: 24
   results day (2.5 × the normal peak = 7,408 req/s) needs 36 — plan it as an event, pre-scale, don't wait for autoscaling

Your snippet prints:

 4 weeks ahead: 1,912 req/s → N 10 · N+2 12 · zone-safe 15
13 weeks ahead: 2,342 req/s → N 12 · N+2 14 · zone-safe 18
26 weeks ahead: 2,963 req/s → N 15 · N+2 17 · zone-safe 24
52 weeks ahead: 4,204 req/s → N 21 · N+2 23 · zone-safe 33
target utilisation 50% → N = 20 for 2,963 req/s
target utilisation 70% → N = 15 for 2,963 req/s
target utilisation 90% → N = 11 for 2,963 req/s

🏁 What you just proved

For the same forecast, the zone-loss plan (24) needs 7 more servers than N+2 (17) — the failure you design for decides the bill more than growth does. The utilisation target moves N from 11 to 20: that is the price of headroom, and it is a choice, not a law. And the further ahead you forecast, the more the straight-line guess matters: re-fit every month and compare last month's forecast with what really happened.

⚠️ Common mistakes

planning from the average instead of the peak
a per-server number from CPU guesses, not a load test
N+1 in one zone — a zone failure takes all of it
forecasting shorter than the lead time (quota requests, hardware orders)
trusting autoscaling for a spike that arrives in seconds
never checking the old forecast against what really happened

🏭 In production

Load-test to find the per-server limit — for example with k6. On a real account (a test environment, never production without agreement):

k6 run --vus 300 --duration 10m load-timetable.js    # raise VUs until p99 or errors break the SLO

Spread replicas across zones and protect them during maintenance on Kubernetes:

# in the Deployment's pod template
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector: {matchLabels: {app: timetable}}
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: timetable}
spec:
  minAvailable: 22            # voluntary disruptions (node drains) may not go below this
  selector: {matchLabels: {app: timetable}}

Pre-scale for a known event, for example with an AWS scheduled action on an Auto Scaling group:

aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name timetable \
  --scheduled-action-name results-day --start-time 2026-10-15T04:00:00Z --min-size 36 --desired-capacity 36

🏭 Why this matters in production: write one line per service: forecast peak in 6 months, per-server limit from a load test, target utilisation, N, and the zone-loss number. Put the date of the next known event next to it.

⏭️ Next

Even with enough capacity, things break. When they do, who is in charge? The next lesson is the crew's incident command.

git checkout lesson-08-incident-command

← Previousprogressive delivery Next →incident command

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