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

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

🔢 धडा 09 — Reliability math: साखळ्या, प्रती आणि प्रत्येक nine ची किंमत

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागे: lesson-08-incident-command · पुढे: lesson-10-overload

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

भाग 3 सुरू होतो: अपयश गृहीत धरून design. काहीही बांधण्याआधी गणित करा. रांगेतील (serial) भाग त्यांची availability गुणाकाराने कमी करतात; स्वतंत्र प्रती (parallel) nines वाढवतात. आणि प्रत्येक जास्तीचा nine दहापट कमी downtime ठेवतो — लवकरच तो एखाद्या व्यक्तीला प्रतिसाद द्यायला लागणाऱ्या वेळेपेक्षाही कमी होतो. sre/design.py मधील serial, parallel आणि downtime आणि sre/demo.py मधील nines().

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

वेळापत्रकापर्यंत पोहोचायला विद्यार्थिनी रांगेतील तीन दारांतून जाते: फाटक, सभागृहाचे दार आणि office चे दार. 🚪🚪🚪 कोणतेही एक दार अडकले, तर ती आत जाऊ शकत नाही.

फाटक 99.99% वेळ चालते, सभागृहाचे दार 99.95%, office चे दार 99.9%. तिन्ही मिळून? तुम्ही गुणाकार करता: 99.84%. हे सर्वात वाईट दारापेक्षाही वाईट आहे. तुम्ही जोडलेले प्रत्येक दार प्रवास कमी विश्वासार्ह करते.

आता पथक पहिल्या दाराच्या अगदी शेजारी office चे दुसरे दार बांधते. एक अडकले, तर तुम्ही दुसरे वापरता. दोन्ही एकाच क्षणी अडकली तरच दोन्ही बंद — आणि हे फार क्वचित घडते (जोपर्यंत त्यांना एकच कुलूप नाही!). Office 99.9999% होते, आणि संपूर्ण प्रवास 99.94% होतो.

🗺️ आकृती

flowchart LR
    u["👩‍🎓 pupil"] --> g["gateway<br/>99.99%"] --> a["timetable app<br/>99.95%"] --> d["database<br/>99.9%"]
    d --> r1["serial: 99.84%<br/>14.0 h a year"]
    a --> d1["db copy 1<br/>99.9%"]
    a --> d2["db copy 2<br/>99.9%"]
    d1 & d2 --> r2["parallel: 99.9999%<br/>chain 99.94%"]

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

❓ काय

Availability — service चालू असण्याचा वेळेतील (किंवा requests मधील) वाटा. एक "nine" म्हणजे एक अंक: 99% म्हणजे दोन nines, 99.9% तीन, 99.99% चार.
Serial (साखळीत) — प्रत्येक भाग आवश्यक: A = a1 × a2 × a3. साखळी नेहमी तिच्या सर्वात कमकुवत भागापेक्षा वाईट असते. प्रत्येकी 99.9% असलेल्या 10 services ना स्पर्श करणारी request साधारण 99.0% मिळवते.
Parallel (redundant प्रती) — कोणतीही एक प्रत पुरेशी: A = 1 − (1 − a)ⁿ. 99.9% च्या दोन प्रती 99.9999% देतात, जर त्या स्वतंत्रपणे बिघडत असतील आणि त्यांच्यातील switch चालत असेल तर.
Independence (स्वातंत्र्य) — मोठे गृहीतक. एकाच rack, zone, region मधील, किंवा एकाच config आणि एकाच bug असलेल्या दोन प्रती एकत्र बिघडतात. परस्परसंबंधित बिघाडांमुळेच खऱ्या systems सूत्रातील आकड्यापर्यंत क्वचितच पोहोचतात. सूत्राला कमाल मर्यादा समजा.
Failover स्वतः — दुसऱ्या प्रतीकडे switch करायला वेळ लागतो आणि ते अयशस्वीही होऊ शकते; सूत्र ते विचारात घेत नाही.
प्रत्येक nine मागे downtime — एका वर्षात: 99% ≈ 87.6 h, 99.9% ≈ 8.76 h, 99.95% ≈ 4.38 h, 99.99% ≈ 52.6 min, 99.999% ≈ 5.3 min. 28 दिवसांच्या window मध्ये 99.99% फक्त 4.0 मिनिटे देते.
प्रत्येक nine ची किंमत — प्रत्येक जास्तीचा nine म्हणजे 10 × कमी downtime, आणि त्यासाठी सहसा जास्त मेहनत नाही तर वेगळे design लागते: multi-zone, मग automatic failover, मग multi-region, मग प्रत्येक बदलाचा automatic rollback. चार nines वर budget हे page आलेल्या व्यक्तीला उठून login करायला लागणाऱ्या वेळेपेक्षा कमी असते, म्हणून recovery automatic असायलाच हवी.
Dependencies मर्यादा घालतात — service प्रत्येक request वर वापरत असलेल्या hard dependency पेक्षा जास्त available असू शकत नाही, जोपर्यंत ती तिच्याशिवाय काम करू शकत नाही (cache, default, graceful degradation — धडा 10).

🤔 का

कारण SLOs (धडा 02) ही वचने आहेत, आणि वचन देण्याच्या आधी ते शक्य तरी आहे का हे असे तपासतात. गुणाकाराने 99.84% होणाऱ्या साखळीवर 99.9% SLO म्हणजे design पाळू शकत नाही असे वचन — धडा 12 चा आढावा ते अडवेल. आणि downtime चे table स्पष्ट करते की पाचवा nine इतका महाग का आहे: ते "जास्त मेहनत करा" नाही, ते "loop मध्ये कोणताही माणूस नाही" आहे.

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

sre/design.py मध्ये: serial(avails) गुणाकार करते, parallel(a, n) 1 − (1 − a)ⁿ परत देते, आणि downtime(avail, period_h) एखाद्या कालावधीत परवानगी असलेली downtime ची मिनिटे परत देते. sre/demo.py मधील nines() साखळी, दुसरी database प्रत आणि table करते.

🧪 करून पाहा

python3 sre/demo.py nines
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from design import serial, parallel, downtime
for n in (1, 2, 3):
    print(f"{n} app cop{'y' if n == 1 else 'ies'} at 99.5% → {parallel(0.995, n):.5%}")
for parts in (3, 10, 30):
    a = serial([0.999] * parts)
    print(f"{parts:>2} services in a row, each 99.9% → {a:.2%} · {downtime(a, 24 * 28):6.0f} min down in 28 days")
EOF

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

nines हे छापते:

── a request needs all three: gateway 99.99% × timetable app 99.95% × database 99.90% = 99.840%
   the chain is worse than its weakest part: 14.0 h a year of downtime allowed by the math
   two independent database copies: 1 − (1 − 0.999)² = 99.9999% → chain 99.940%
        99% →   87.60 h a year ·  403.2 min in 28 days
      99.9% →    8.76 h a year ·   40.3 min in 28 days
     99.95% →    4.38 h a year ·   20.2 min in 28 days
     99.99% →    0.88 h a year ·    4.0 min in 28 days
    99.999% →    0.09 h a year ·    0.4 min in 28 days

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

1 app copy at 99.5% → 99.50000%
2 app copies at 99.5% → 99.99750%
3 app copies at 99.5% → 99.99999%
 3 services in a row, each 99.9% → 99.70% ·    121 min down in 28 days
10 services in a row, each 99.9% → 99.00% ·    401 min down in 28 days
30 services in a row, each 99.9% → 97.04% ·   1192 min down in 28 days

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

रांगेतील तीन चांगले भाग (99.84%) 99.9% SLO पूर्ण करू शकत नाहीत — code ची एक ओळ लिहिण्याआधीच design चुकलेले आहे. दुसऱ्या, स्वतंत्र database प्रतीने ते दुरुस्त झाले (99.94%). 99.5% च्या दोन स्वस्त प्रती एका महाग 99.9% भागापेक्षा सरस ठरतात — जर त्या खरोखर स्वतंत्र असतील. आणि प्रत्येकी तीन nines असलेल्या 30 services मधून पसरणारी request महिन्याला साधारण 20 तास बंद असते: म्हणूनच खोल call chains ना timeouts, fallbacks आणि कमी hard dependencies लागतात.

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

availabilities चा गुणाकार करण्याऐवजी बेरीज करणे
एकाच zone मधील (किंवा एकाच config push असलेल्या) दोन प्रतींना स्वतंत्र मानणे
failover विसरणे: ज्या प्रतीकडे कोणी switch करत नाही, ती काहीच वाढवत नाही
fallback शिवाय, hard dependency पेक्षा जास्त SLO चे वचन देणे
ज्या service चे users साडेतीन nines सुद्धा लक्षात घेणार नाहीत, तिच्यासाठी पाच nines मागणे
provider चा SLA त्याची खरी availability म्हणून वापरणे — SLA म्हणजे पैसे परत करण्याचे वचन, मोजमाप नाही

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

Request च्या प्रत्येक hard dependency ची यादी करा, तिच्या मोजलेल्या availability सह (तिचा SLA नाही). खऱ्या account वर — Prometheus मधून, 28 दिवसांतील database ला केलेल्या calls चे success ratio (metric आणि label ची नावे तुमची):

curl -s http://prometheus:9090/api/v1/query --data-urlencode \
  'query=sum(increase(db_client_requests_total{outcome="success"}[28d])) / sum(increase(db_client_requests_total[28d]))' \
  | jq -r '.data.result[0].value[1]'

मग service repo मध्ये SLO च्या शेजारी साखळी लिहून ठेवा:

slo: 99.9
hard_dependencies:        # measured over the last 28 days
  gateway: 99.99
  timetable-app: 99.95
  database: 99.9          # → add a replica in another zone with automatic failover
chain_ceiling: 99.84      # serial product — below the SLO: must fix
soft_dependencies: [recommendations, photos]   # have fallbacks, not in the chain

स्वातंत्र्य design करावे लागते: वेगवेगळ्या zones मधील प्रती (धडा 07 चा topology spread), वीज आणि network साठी वेगवेगळे failure domains, आणि टप्प्याटप्प्याने केलेले config pushes, म्हणजे एक वाईट push एकदम प्रत्येक प्रतीपर्यंत पोहोचू शकत नाही.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: तुमच्या service चा SLO घ्या आणि तिच्या hard dependencies च्या मोजलेल्या availability चा गुणाकार करा. गुणाकार SLO पेक्षा कमी असेल, तर तुम्हाला तुमचा पुढचा project सापडला आहे — किंवा तुमचा SLO चुकीचा आहे.

⏭️ पुढे

गणिताने असे गृहीत धरले की मागणी capacity मध्ये बसते. इमारत सामावू शकेल त्यापेक्षा जास्त आले, तर तुम्ही नीट अपयशी कसे होता?

git checkout lesson-10-overload

🔢 Lesson 09 — Reliability math: chains, copies and what each nine costs

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-incident-command · Next: lesson-10-overload

📦 What's in this branch

Part 3 begins: designing for failure. Before building anything, do the arithmetic. Parts in a row (serial) multiply their availability down; independent copies (parallel) add nines. And each extra nine leaves ten times less downtime — soon less than a person needs to react. serial, parallel and downtime in sre/design.py and nines() in sre/demo.py.

🧒 Explain like I'm 5

To get to the timetable, a pupil walks through three doors in a row: the gate, the hall door and the office door. 🚪🚪🚪 If any door is stuck, the pupil cannot get in.

The gate works 99.99% of the time, the hall door 99.95%, the office door 99.9%. Together? You multiply: 99.84%. That is worse than even the worst door. Every door you add makes the trip less reliable.

Now the crew builds a second office door right next to the first. If one is stuck, you use the other. Both are stuck only if both are stuck at the same moment — which is very rare (as long as they don't share the same lock!). The office becomes 99.9999%, and the whole trip becomes 99.94%.

🗺️ Diagram

flowchart LR
    u["👩‍🎓 pupil"] --> g["gateway<br/>99.99%"] --> a["timetable app<br/>99.95%"] --> d["database<br/>99.9%"]
    d --> r1["serial: 99.84%<br/>14.0 h a year"]
    a --> d1["db copy 1<br/>99.9%"]
    a --> d2["db copy 2<br/>99.9%"]
    d1 & d2 --> r2["parallel: 99.9999%<br/>chain 99.94%"]

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

❓ What

Availability — the share of time (or of requests) a service works. A "nine" is one digit: 99% is two nines, 99.9% three, 99.99% four.
Serial (in a chain) — every part is needed: A = a1 × a2 × a3. The chain is always worse than its weakest part. A request that touches 10 services at 99.9% each gets about 99.0%.
Parallel (redundant copies) — any one copy is enough: A = 1 − (1 − a)ⁿ. Two copies at 99.9% give 99.9999%, if they fail independently and the switch between them works.
Independence — the big assumption. Two copies in the same rack, zone, region, or with the same config and the same bug, fail together. Correlated failures are why real systems rarely reach the formula's number. Treat the formula as a ceiling.
The failover itself — switching to the second copy takes time and can fail; the formula leaves that out.
Downtime per nine — over a year: 99% ≈ 87.6 h, 99.9% ≈ 8.76 h, 99.95% ≈ 4.38 h, 99.99% ≈ 52.6 min, 99.999% ≈ 5.3 min. Over a 28-day window, 99.99% allows 4.0 minutes.
What each nine costs — each extra nine is 10 × less downtime, and usually needs a different design, not more effort: multi-zone, then automatic failover, then multi-region, then automatic rollback of every change. At four nines, the budget is shorter than the time a paged person needs to wake up and log in, so recovery must be automatic.
Dependencies set a limit — a service cannot be more available than a hard dependency it calls on every request, unless it can work without it (a cache, a default, graceful degradation — lesson 10).

🤔 Why

Because SLOs (lesson 02) are promises, and this is how you check a promise is even possible before you make it. A 99.9% SLO on top of a chain that multiplies to 99.84% is a promise the design cannot keep — lesson 12's review will block it. And the downtime table explains why the fifth nine is so expensive: it is not "work harder", it is "no human in the loop".

🔧 How (in this repo)

In sre/design.py: serial(avails) multiplies, parallel(a, n) returns 1 − (1 − a)ⁿ, and downtime(avail, period_h) returns the allowed minutes of downtime in a period. nines() in sre/demo.py does the chain, the second database copy and the table.

🧪 Try it

python3 sre/demo.py nines
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from design import serial, parallel, downtime
for n in (1, 2, 3):
    print(f"{n} app cop{'y' if n == 1 else 'ies'} at 99.5% → {parallel(0.995, n):.5%}")
for parts in (3, 10, 30):
    a = serial([0.999] * parts)
    print(f"{parts:>2} services in a row, each 99.9% → {a:.2%} · {downtime(a, 24 * 28):6.0f} min down in 28 days")
EOF

✅ Verify — what you should see

nines prints:

── a request needs all three: gateway 99.99% × timetable app 99.95% × database 99.90% = 99.840%
   the chain is worse than its weakest part: 14.0 h a year of downtime allowed by the math
   two independent database copies: 1 − (1 − 0.999)² = 99.9999% → chain 99.940%
        99% →   87.60 h a year ·  403.2 min in 28 days
      99.9% →    8.76 h a year ·   40.3 min in 28 days
     99.95% →    4.38 h a year ·   20.2 min in 28 days
     99.99% →    0.88 h a year ·    4.0 min in 28 days
    99.999% →    0.09 h a year ·    0.4 min in 28 days

Your snippet prints:

1 app copy at 99.5% → 99.50000%
2 app copies at 99.5% → 99.99750%
3 app copies at 99.5% → 99.99999%
 3 services in a row, each 99.9% → 99.70% ·    121 min down in 28 days
10 services in a row, each 99.9% → 99.00% ·    401 min down in 28 days
30 services in a row, each 99.9% → 97.04% ·   1192 min down in 28 days

🏁 What you just proved

Three good parts in a row (99.84%) cannot meet a 99.9% SLO — the design is wrong before a line of code is written. A second, independent database copy fixed it (99.94%). Two cheap 99.5% copies beat one expensive 99.9% part — if they are really independent. And a request that fans out through 30 services at three nines each is down about 20 hours a month: that is why deep call chains need timeouts, fallbacks and fewer hard dependencies.

⚠️ Common mistakes

adding up availabilities instead of multiplying them
counting two copies in the same zone (or with the same config push) as independent
forgetting the failover: a copy nobody switches to adds nothing
promising an SLO higher than a hard dependency's, with no fallback
asking for five nines for a service whose users would not notice three and a half
using a provider's SLA as its real availability — an SLA is a refund promise, not a measurement

🏭 In production

List every hard dependency of a request, with its measured availability (not its SLA). On a real account — from Prometheus, the success ratio of calls to the database over 28 days (the metric and label names are yours):

curl -s http://prometheus:9090/api/v1/query --data-urlencode \
  'query=sum(increase(db_client_requests_total{outcome="success"}[28d])) / sum(increase(db_client_requests_total[28d]))' \
  | jq -r '.data.result[0].value[1]'

Then write the chain down next to the SLO, in the service repo:

slo: 99.9
hard_dependencies:        # measured over the last 28 days
  gateway: 99.99
  timetable-app: 99.95
  database: 99.9          # → add a replica in another zone with automatic failover
chain_ceiling: 99.84      # serial product — below the SLO: must fix
soft_dependencies: [recommendations, photos]   # have fallbacks, not in the chain

Independence is designed: copies in different zones (lesson 07's topology spread), different failure domains for power and network, and staged config pushes so one bad push cannot reach every copy at once.

🏭 Why this matters in production: take your service's SLO and multiply the measured availability of its hard dependencies. If the product is below the SLO, you have found your next project — or your SLO is wrong.

⏭️ Next

The math assumed demand fits the capacity. When more arrives than the building can hold, how do you fail well?

git checkout lesson-10-overload

← Previousincident command Next →overload

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