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

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

🎚️ धडा 06 — Progressive delivery आणि feature flags: exposure आणि rollback चा वेग

📍 तुम्ही इथे आहात: 12 पैकी धडा 06 · मागे: lesson-05-canary-analysis · पुढे: lesson-07-capacity-planning

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

धडा 05, अधिक वाईट बदलाचे गणित. वाईट बदल किती requests ना त्रास देतो हे तीन गोष्टींवर अवलंबून असते: तो किती users ना दिसतो (exposure), तुम्हाला तो किती लवकर लक्षात येतो (detection) आणि तुम्ही तो किती वेगाने उलटवता (rollback). Progressive rollouts पहिली गोष्ट लहान करतात; feature flags शेवटची. sre/crew.py मधील rollout_damage आणि sre/demo.py मधील rollout().

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

पथक शाळेतले दिवे बदलते. 💡 नव्या दिव्यांमध्ये एक दोष आहे: 10 पैकी 3 बल्ब विझतात.

पहिला आराखडा: प्रत्येक वर्ग एकदम बदला. प्रत्येक खोलीत विझलेले बल्ब. लक्षात यायला 5 मिनिटे लागतात, मग नवे दिवे काढून जुने परत लावायला 15 मिनिटे.

दुसरा आराखडा: तेच, पण प्रत्येक नव्या दिव्याला एक switch आहे जो जुना दिवा परत चालू करतो. 5 मिनिटांत लक्षात येते, 1 मिनिटात switch फिरवला जातो. खूपच चांगले.

तिसरा आराखडा: आधी फक्त शंभरातला एक वर्ग बदला. फक्त त्याच खोलीत विझलेले बल्ब. लक्षात यायला थोडा जास्त वेळ लागतो (फक्त थोड्याच तक्रारी), पण फारच कमी विद्यार्थिनींना त्रास झाला.

चौथा आराखडा: शंभरातली एक खोली, आणि switch. सगळ्यांत कमी विद्यार्थिनी अंधारात.

🗺️ आकृती

flowchart LR
    d["💥 bad change<br/>fails 30% of its requests<br/>1,000 requests/min"] --> bb["big bang + redeploy<br/>300 bad/min × (5 + 15) min<br/>6,000 failed"]
    d --> bf["big bang + flag off<br/>300 × (5 + 1)<br/>1,800"]
    d --> cr["1% canary + redeploy<br/>3 × (10 + 15)<br/>75"]
    d --> cf["1% canary + flag off<br/>3 × (10 + 1)<br/>33"]

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

❓ काय

Big-bang deploy — प्रत्येक user ला नवी version एकदम मिळते. पूर्ण व्हायला सर्वात वेगवान, सर्वात मोठा blast radius.
Progressive delivery — traffic चा वाटा टप्प्याटप्प्याने वाढवा (उदाहरणार्थ 1% → 5% → 25% → 100%), टप्प्यांच्या मध्ये automatic check (धडा 05) सह, आणि check fail झाला तर थांबा आणि rollback करा.
Exposure — नव्या version वरचा traffic चा वाटा. मिनिटामागचे नुकसान = मिनिटामागच्या requests × exposure × failure rate.
Detection time — check उलटेपर्यंत किती वेळ. कमी exposure वर दिसणारी अपयशे कमी असतात, म्हणून detection हळू होते; lab ला 30 अपयशांनंतर लक्षात येते, पण 5 मिनिटांपेक्षा आधी कधीच नाही.
Rollback — जुन्या वर्तनाकडे परत जाणे. जुन्या build चे redeploy अनेक मिनिटे घेऊ शकते; traffic परत वळवणे किंवा flag बंद करणे काही सेकंदांत होऊ शकते.
Feature flag (feature toggle) — code मधील runtime switch: if flag("new-engine"): new path else: old path. यामुळे तुम्ही code अंधारात deploy करू शकता आणि तो वेगळा release करू शकता, users च्या ठराविक टक्क्यांना, आणि deploy न करता बंद करू शकता. Kill switch म्हणजे आणीबाणीत feature पटकन बंद करण्यासाठी मुद्दाम ठेवलेला flag.
Flag debt — प्रत्येक flag एक if आहे जो test करायचे मार्ग दुप्पट करतो. Feature पूर्णपणे बाहेर आल्यावर flags काढून टाका. (एक प्रसिद्ध प्रकरण: 2012 मध्ये Knight Capital ने एक जुना flag पुन्हा वापरला; एका deploy मध्ये आठपैकी एक server सुटला होता, flag ने तिथला खूप पूर्वी मेलेला code जागा केला, आणि कंपनीने 45 मिनिटांत सुमारे $440 million गमावले.)
Rollback-safe बदल — जुनी version data सोबत अजूनही चालत असेल तरच rollback उपयोगी पडतो. Database बदलांसाठी expand and contract वापरतात: आधी नवा column जोडा, दोन्हीत लिहा, reads बदला, आणि जुना column नंतरच्या release मध्ये काढून टाका.

🤔 का

कारण detection कधीच तात्काळ नसते आणि काही वाईट बदल canary पार करतात. तुमच्या हातात हे आहे की तुम्हाला कळेपर्यंत शाळेच्या किती भागाला बदल दिसतो, आणि तुम्ही तो किती वेगाने उलटवू शकता. Reliability चुका कधीच न करण्यातून नव्हे, तर चुका लहान आणि स्वस्त ठेवण्यातून येते.

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

sre/crew.py मधील rollout_damage(rpm, exposure, fail_rate, rollback_min, detect_errors=30, min_detect_min=5) (bad per minute, minutes to detect, total bad requests) परत देते: detection = 5 मिनिटे आणि 30 अपयशे दिसायला लागणारी मिनिटे यांपैकी जे मोठे ते; total = मिनिटामागच्या bad × (detection + rollback). rollout() मिनिटाला 1,000 requests आणि 30% failure rate वर चार आराखड्यांची तुलना करते.

🧪 करून पाहा

python3 sre/demo.py rollout
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import rollout_damage
for exposure in (1.0, 0.25, 0.05, 0.01):
    row = []
    for rb in (15, 5, 1):
        bad, det, total = rollout_damage(1000, exposure, 0.30, rb)
        row.append(f"rollback {rb:>2} min → {total:>5,}")
    print(f"exposure {exposure:>4.0%} · noticed after {det:>2} min · " + " · ".join(row))
EOF

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

rollout हे print करते:

   big bang, rollback = redeploy (15 min)     300 bad/min · noticed after  5 min → 6,000 failed requests
   big bang, flag off (1 min)                 300 bad/min · noticed after  5 min → 1,800 failed requests
   canary at 1%, rollback = redeploy            3 bad/min · noticed after 10 min →    75 failed requests
   canary at 1%, flag off                       3 bad/min · noticed after 10 min →    33 failed requests
   stages 1% → 5% → 25% → 100%, 30 min each: a full rollout takes 2 hours instead of 1 minute — that is the price

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

exposure 100% · noticed after  5 min · rollback 15 min → 6,000 · rollback  5 min → 3,000 · rollback  1 min → 1,800
exposure  25% · noticed after  5 min · rollback 15 min → 1,500 · rollback  5 min →   750 · rollback  1 min →   450
exposure   5% · noticed after  5 min · rollback 15 min →   300 · rollback  5 min →   150 · rollback  1 min →    90
exposure   1% · noticed after 10 min · rollback 15 min →    75 · rollback  5 min →    45 · rollback  1 min →    33

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

100% वरून 1% exposure वर गेल्याने नुकसान 80 × कमी झाले (6,000 → 75), detection ला दुप्पट वेळ लागला तरीही. वेगवान rollback ने ते 3.3 × पर्यंत कमी केले (6,000 → 1,800). दोन्ही मिळून: 6,000 → 33, म्हणजे सुमारे 180 × कमी failed requests. Exposure हा सर्वात मोठा lever आहे; rollback चा वेग त्यानंतरचा. किंमत म्हणजे वेळ: 30 मिनिटांचे चार टप्पे म्हणजे पूर्ण rollout ला 2 तास — म्हणूनच teams हे टप्पे automate करतात, म्हणजे त्या थांबण्यात कोणाचेही लक्ष खर्च होत नाही.

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

कधीच वापरून न पाहिलेला rollback चा आराखडा
जुनी version चालूच शकणार नाही असे database बदल — मग rollback चे बटण खोटे ठरते
कधीच काढून न टाकलेले flags, जोपर्यंत new_engine_v2_final काय करतो हे कोणालाच माहीत नसते
मध्ये कोणताही check न करता timer वर पुढच्या टप्प्यावर जाणे
feature बंद करणारा पण त्याने सुरू केलेले नवे background job बंद न करणारा flag
1% टप्प्याला फक्त एकाच प्रकारचे users मिळणे (सगळे अंतर्गत, सगळे एकाच region मधले)

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

Argo Rollouts — canary steps असलेला Rollout, आणि पार्श्वभूमीत धडा 05 मधील analysis चालू. खऱ्या account वर:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: {name: timetable}
spec:
  strategy:
    canary:
      analysis:
        templates: [{templateName: error-rate}]
        startingStep: 1
        args: [{name: service-name, value: timetable}]
      steps:
        - setWeight: 1
        - pause: {duration: 30m}
        - setWeight: 5
        - pause: {duration: 30m}
        - setWeight: 25
        - pause: {duration: 30m}

Traffic router नसेल तर Argo Rollouts pods च्या संख्येने weight अंदाजे साधते; router असेल (Istio, NGINX, AWS ALB आणि इतर) तर ते नेमकी टक्केवारी ठरवू शकते. Rollout थांबवा आणि लगेच परत जा:

kubectl argo rollouts abort timetable        # traffic back to the stable version
kubectl rollout undo deployment/timetable    # plain Deployment: back to the previous ReplicaSet

OpenFeature Python SDK वापरून code मधील feature flag (provider — LaunchDarkly, Unleash, flagd आणि इतर — start-up ला एकदाच configure केला जातो):

from openfeature import api
client = api.get_client()
if client.get_boolean_value("new-timetable-engine", False):   # default False if the flag service is down
    plan = new_engine(week)
else:
    plan = old_engine(week)

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: तुमच्या खऱ्या rollback ची वेळ मोजा. आराखडा नव्हे — घड्याळ, एका test मध्ये, "निर्णय" पासून "users जुन्या version वर परत आले" पर्यंत. हा आकडा 5 मिनिटांपेक्षा जास्त असेल, तर पुढे दुरुस्त करायची गोष्ट तीच आहे.

⏭️ पुढे

आता बदल सुरक्षित आहेत. पण पुढच्या सत्रात इमारती पुरेशा मोठ्या असतील का? पुढचा धडा capacity संपण्याआधीच तिचा आराखडा करतो.

git checkout lesson-07-capacity-planning

🎚️ Lesson 06 — Progressive delivery and feature flags: exposure and rollback speed

📍 You are here: Lesson 06 of 12 · Previous: lesson-05-canary-analysis · Next: lesson-07-capacity-planning

📦 What's in this branch

Lesson 05, plus the arithmetic of a bad change. How many requests a bad change hurts depends on three things: how many users see it (exposure), how fast you notice (detection) and how fast you undo it (rollback). Progressive rollouts shrink the first; feature flags shrink the last. rollout_damage in sre/crew.py and rollout() in sre/demo.py.

🧒 Explain like I'm 5

The crew changes the lights in the school. 💡 The new lights have a fault: 3 bulbs in 10 go dark.

Plan one: change every classroom at once. Every room has dark bulbs. It takes 5 minutes to notice, then 15 minutes to take the new lights out and put the old ones back.

Plan two: same, but every new light has a switch that turns the old light back on. Notice in 5 minutes, flip the switch in 1 minute. Much better.

Plan three: change just one classroom in a hundred first. Only that room has dark bulbs. It takes a bit longer to notice (only a few complaints), but very few pupils were bothered.

Plan four: one room in a hundred, and a switch. The fewest pupils in the dark of all.

🗺️ Diagram

flowchart LR
    d["💥 bad change<br/>fails 30% of its requests<br/>1,000 requests/min"] --> bb["big bang + redeploy<br/>300 bad/min × (5 + 15) min<br/>6,000 failed"]
    d --> bf["big bang + flag off<br/>300 × (5 + 1)<br/>1,800"]
    d --> cr["1% canary + redeploy<br/>3 × (10 + 15)<br/>75"]
    d --> cf["1% canary + flag off<br/>3 × (10 + 1)<br/>33"]

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

❓ What

Big-bang deploy — every user gets the new version at once. Fastest to finish, biggest blast radius.
Progressive delivery — raise the share of traffic step by step (for example 1% → 5% → 25% → 100%), with an automatic check (lesson 05) between steps, and stop and roll back on a failed check.
Exposure — the share of traffic on the new version. Damage per minute = requests per minute × exposure × failure rate.
Detection time — how long until the check trips. At low exposure there are fewer failures to see, so detection is slower; the lab notices after 30 failures, never sooner than 5 minutes.
Rollback — getting back to the old behaviour. A redeploy of the old build can take many minutes; switching traffic back or turning a flag off can take seconds.
Feature flag (feature toggle) — a runtime switch in the code: if flag("new-engine"): new path else: old path. Lets you deploy code dark and release it separately, to a percentage of users, and turn it off without a deploy. A kill switch is a flag kept on purpose to turn a feature off fast in an emergency.
Flag debt — every flag is an if that doubles the paths to test. Remove flags once a feature is fully out. (A well-known case: in 2012 Knight Capital reused an old flag; a deploy had missed one of eight servers, the flag woke long-dead code there, and the firm lost about $440 million in 45 minutes.)
Rollback-safe changes — a rollback only helps if the old version still works with the data. Database changes use expand and contract: add the new column first, write both, switch reads, and remove the old one in a later release.

🤔 Why

Because detection is never instant and some bad changes pass the canary. What you control is how much of the school sees the change while you find out, and how fast you can undo it. Reliability comes from making mistakes small and cheap, not from never making them.

🔧 How (in this repo)

rollout_damage(rpm, exposure, fail_rate, rollback_min, detect_errors=30, min_detect_min=5) in sre/crew.py returns (bad per minute, minutes to detect, total bad requests): detection = the larger of 5 minutes and the minutes needed to see 30 failures; total = bad per minute × (detection + rollback). rollout() compares four plans at 1,000 requests a minute and a 30% failure rate.

🧪 Try it

python3 sre/demo.py rollout
python3 - <<'EOF'
import sys; sys.path.insert(0, "sre"); from crew import rollout_damage
for exposure in (1.0, 0.25, 0.05, 0.01):
    row = []
    for rb in (15, 5, 1):
        bad, det, total = rollout_damage(1000, exposure, 0.30, rb)
        row.append(f"rollback {rb:>2} min → {total:>5,}")
    print(f"exposure {exposure:>4.0%} · noticed after {det:>2} min · " + " · ".join(row))
EOF

✅ Verify — what you should see

rollout prints:

   big bang, rollback = redeploy (15 min)     300 bad/min · noticed after  5 min → 6,000 failed requests
   big bang, flag off (1 min)                 300 bad/min · noticed after  5 min → 1,800 failed requests
   canary at 1%, rollback = redeploy            3 bad/min · noticed after 10 min →    75 failed requests
   canary at 1%, flag off                       3 bad/min · noticed after 10 min →    33 failed requests
   stages 1% → 5% → 25% → 100%, 30 min each: a full rollout takes 2 hours instead of 1 minute — that is the price

Your snippet prints:

exposure 100% · noticed after  5 min · rollback 15 min → 6,000 · rollback  5 min → 3,000 · rollback  1 min → 1,800
exposure  25% · noticed after  5 min · rollback 15 min → 1,500 · rollback  5 min →   750 · rollback  1 min →   450
exposure   5% · noticed after  5 min · rollback 15 min →   300 · rollback  5 min →   150 · rollback  1 min →    90
exposure   1% · noticed after 10 min · rollback 15 min →    75 · rollback  5 min →    45 · rollback  1 min →    33

🏁 What you just proved

Going from 100% to 1% exposure cut the damage 80 × (6,000 → 75), even though detection took twice as long. A fast rollback cut it by up to 3.3 × (6,000 → 1,800). Together: 6,000 → 33, about 180 × fewer failed requests. Exposure is the biggest lever; rollback speed is the next. The price is time: four 30-minute stages mean 2 hours to full rollout — which is why teams automate the steps, so the wait costs nobody's attention.

⚠️ Common mistakes

a rollback plan that has never been tried
database changes that make the old version unable to run — the rollback button is fake
flags that are never removed, until nobody knows what new_engine_v2_final does
moving to the next stage on a timer with no check in between
a flag that switches the feature but not the new background job it started
the 1% stage getting only one kind of user (all internal, all one region)

🏭 In production

Argo Rollouts — a Rollout with canary steps and the analysis from lesson 05 running in the background. On a real account:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: {name: timetable}
spec:
  strategy:
    canary:
      analysis:
        templates: [{templateName: error-rate}]
        startingStep: 1
        args: [{name: service-name, value: timetable}]
      steps:
        - setWeight: 1
        - pause: {duration: 30m}
        - setWeight: 5
        - pause: {duration: 30m}
        - setWeight: 25
        - pause: {duration: 30m}

Without a traffic router, Argo Rollouts approximates the weight with the number of pods; with one (Istio, NGINX, AWS ALB and others) it can set the exact percentage. Stop a rollout and go back at once:

kubectl argo rollouts abort timetable        # traffic back to the stable version
kubectl rollout undo deployment/timetable    # plain Deployment: back to the previous ReplicaSet

A feature flag in code, with the OpenFeature Python SDK (the provider — LaunchDarkly, Unleash, flagd and others — is configured once at start-up):

from openfeature import api
client = api.get_client()
if client.get_boolean_value("new-timetable-engine", False):   # default False if the flag service is down
    plan = new_engine(week)
else:
    plan = old_engine(week)

🏭 Why this matters in production: time your real rollback. Not the plan — the clock, in a test, from "decide" to "users are back on the old version". If the number is over 5 minutes, that is the next thing to fix.

⏭️ Next

Changes are safe now. But will the buildings be big enough next term? The next lesson plans capacity before it runs out.

git checkout lesson-07-capacity-planning

← Previouscanary analysis Next →capacity planning

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