भाग 1: काम (लाल, 1–4) · भाग 2: बदल सुरक्षितपणे करणे (निळा, 5–8) · भाग 3: अपयशासाठी आराखडा (हिरवा, 9–12). प्रत्येक आकृती खऱ्या, deterministic lab मधून काढलेली आहे — sre/demo.py जे आकडे print करते तेच — आणि प्रत्येकीखाली एक lab आहे जिथे तुम्ही स्वतः आकडे बदलू शकता. वर्तुळातील आकडे 1 → 2 → 3 या क्रमाने पाहा.
1 🛠️ SRE म्हणजे काय
पन्हाळ दुरुस्त करा, जास्त बादल्या वाहू नका — SRE, ops आणि DevOps यांतील फरक, आणि ops कामावरची 50% मर्यादा.
🧒 सोप्या शब्दांत
पाऊस पडला की timetable इमारतीचे छप्पर गळते. साधे दुरुस्ती पथक प्रत्येक गळतीखाली बादली ठेवते, आणि पुढच्या आठवड्यात आणखी बादल्या वाहते. कतरिना, दीपिका आणि ऐश्वर्या आजची बादलीही वाहतात, पण मग त्या पन्हाळ दुरुस्त करतात. त्यांचा एक नियम आहे: आठवड्याचा जास्तीत जास्त अर्धा वेळ बादल्यांसाठी. आठवडा 4 मध्ये बादल्यांनी 120 पैकी 71 तास घेतले, म्हणून जास्तीचे काम इमारत बांधणाऱ्यांकडे परत गेले.
📖 नवे शब्दSRE — services विश्वासार्ह ठेवणे हे engineering काम: जास्त बादल्या वाहण्याऐवजी tools लिहिणेops work — गोष्टी चालू ठेवण्यासाठी हाताने केलेले tickets, pages आणि दुरुस्त्या50% cap — पथकाच्या आठवड्याचा जास्तीत जास्त अर्धा वेळ ops कामाला, जसे 120 पैकी 60 तासDevOps — सामायिक जबाबदारी, automation आणि मोजमाप यांची संस्कृती; SRE ती आचरणात आणण्याचा एक मार्ग
⏪ आधी
साधी ops team शाळा वाढेल तशा जास्त बादल्या वाहत असे, आणि फक्त त्या वाहण्यासाठी जास्त लोक भरती करत असे.
💡 काय
SRE म्हणजे देखभाल पथक: कतरिना, दीपिका आणि ऐश्वर्या tools लिहून शाळेच्या इमारती चालू ठेवतात.
⚙️ कसे
पथकाकडे आठवड्याला 3 × 40 h = 120 h असतात; आठवडा 4 मध्ये 71 h ops झाले, म्हणजे 59.2%, 60 h च्या 50% cap च्या वर.
🎯 का
Cap च्या वरचे ops काम dev team कडे परत जाते, म्हणून आठवड्याचा किमान अर्धा वेळ पुढचा आठवडा हलका करणाऱ्या engineering साठी राहतो.
🚀 पुढे
पुढचा धडा SLO ला सही केलेला करार बनवतो: 28,000-request error budget संपत आला की शाळा काय करते.
🧪 इथे करून पाहा — पथकाचा आठवडा — ops तास, पथक आणि मर्यादा बदला
दुरुस्तीचे बजेट, गळती होण्याआधीच सही केलेले — error budget चे 75% आणि 100% वापरले गेल्यावर काय होते.
🧒 सोप्या शब्दांत
सत्राच्या सुरुवातीला पथक आणि मुख्याध्यापक एका करारावर सही करतात. Timetable थोडे अयशस्वी होऊ शकते: 1,000 पैकी 1 request. 28 दिवसांत ते 28,000 failed requests, म्हणजे दुरुस्ती budget. Budget शिल्लक असेपर्यंत शिक्षक मोकळेपणाने बदल करतात. 75% वापरला की त्या सावकाश होतात आणि आधी दुरुस्ती करतात. दिवस 24 ला budget संपतो, म्हणून बदल थांबतात. कोणी वाद घालत नाही, कारण कागदावर आधीच तसे लिहिले आहे.
📖 नवे शब्दSLO — विश्वासार्हतेचे लक्ष्य, जसे 28 दिवसांत 99.9% requests चालणेerror budget — SLO ने दिलेली अपयशांची मुभा, जसे 28,000 failed requestspolicy — budget च्या प्रत्येक पातळीसाठी आधीच ठरवलेल्या कृतीfreeze — service पुन्हा SLO मध्ये येईपर्यंत फक्त तातडीच्या P0 आणि security दुरुस्त्या
⏪ आधी
Reliability विरुद्ध नवीन features यावर प्रत्येक बैठकीत वाद होत, आणि बहुतेक वेळा सर्वात मोठ्या आवाजाचा माणूस जिंकत असे.
💡 काय
Error budget policy: 28 दिवसांत 99.9% SLO, दिवसाला 1,000,000 requests, म्हणून 28,000 failed requests ची मुभा.
⚙️ कसे
75% पेक्षा कमी वापर: normal. 75–100%: caution. 100% किंवा जास्त: freeze. दिवस 20 ला 83.9%, दिवस 24 ला 101.8%.
🎯 का
गळती सुरू होण्याआधीच त्यावर सही झाली होती, म्हणून दिवस 24 ला कोणी वाद घालत नाही: कागदावर आधीच freeze लिहिले आहे.
🚀 पुढे
पुढचा धडा बादल्या मोजतो: toil ची नोंदवही, जी प्रत्येक हाताने केलेले काम automation किती लवकर वसूल होते त्यानुसार लावते.
🧪 इथे करून पाहा — error budget धोरण — SLO, traffic आणि incidents बदला
बादल्या मोजा — toil म्हणजे काय, toil ची नोंदवही, आणि payback नुसार क्रम लावलेले automation.
🧒 सोप्या शब्दांत
दीपिका हाताने केलेल्या प्रत्येक कंटाळवाण्या कामाची वही ठेवते. Locked accounts reset करणे आठवड्याला 60 वेळा होते, प्रत्येकी 10 मिनिटे: 10 तास. कतरिना सांगते की reset button बनवायला 16 तास लागतील, म्हणून ते दोन आठवड्यांपेक्षा कमी काळात वसूल होते. पथकाकडे या सत्रात 40 तास आहेत, आणि ते सर्वात लवकर फायदा देणारी कामे आधी बनवते. कंटाळवाणे काम आठवड्याला 24.2 वरून 6.2 तासांवर येते.
📖 नवे शब्दtoil — हाताने, पुन्हा पुन्हा केले जाणारे काम जे tool करू शकते आणि ज्यातून काहीच टिकाऊ उरत नाहीtoil ledger — कामांची यादी, किती वेळ आणि किती वेळा, जशी दीपिकाची वहीpayback — tool बनवायला लागलेल्या वेळेपेक्षा जास्त वेळ वाचवायला किती आठवडे लागतात, जसे 1.6 आठवडेupkeep — tool ला स्वतःला दर आठवड्याला लागणारा वेळ, जसे 0.25 तास
⏪ आधी
पथक हाताने accounts reset करत, queues restart करत आणि disks वाढवत असे, पण त्याला किती वेळ लागतो हे कधीच नोंदवले नाही.
💡 काय
Toil म्हणजे हाताने, पुन्हा पुन्हा केले जाणारे, automate करता येणारे आणि टिकाऊ मूल्य नसलेले काम: दीपिकाच्या नोंदवहीत आठवड्याला 24.2 h.
⚙️ कसे
Payback = build ÷ (वाचलेले तास − upkeep). Account reset: 16 h ÷ आठवड्याला 9.75 h = 1.6 आठवडे. सर्वात चांगले आधी.
🎯 का
40 h च्या automation मधून 30 h मध्ये तीन tools बनतात, आणि toil आठवड्याला 24.2 वरून 6.2 h वर येते, अधिक 0.45 h upkeep.
🚀 पुढे
पुढचा धडा duty phone सोपवतो: एका shift मध्ये किती pages जास्त आहेत, आणि rotation किती मोठे हवे.
🧪 इथे करून पाहा — दीपिकाची toil नोंदवही — build चे बजेट आणि कामे बदला
ड्युटीचा फोन — प्रत्येक shift मधील pages, रात्रीचे pages, rotation चा आकार आणि follow-the-sun.
🧒 सोप्या शब्दांत
पथकाकडे एक duty phone आहे, जो इमारत बिघडली की वाजतो. चार आठवड्यांत तो 55 वेळा वाजला, आणि त्यापैकी 17 वेळा रात्री. फक्त तिघी असल्याने प्रत्येकीकडे तीनपैकी एक आठवडा phone असतो, हे फारच वारंवार आहे. म्हणून आणखी लोक सामील होतात, आणि आठ जणांत प्रत्येकाकडे आठपैकी एक आठवडा. जगाच्या दुसऱ्या बाजूचे sister crew रात्र सांभाळते. आता कोणाचाही phone रात्री वाजत नाही.
📖 नवे शब्दon-call — duty phone सांभाळणे आणि service बिघडली की दिवसा किंवा रात्री उत्तर देणेpage — on-call व्यक्तीला उठवणारा alert, जसे चार आठवड्यांतील 55rotation — phone आळीपाळीने घेणारे लोक; 8 जणांत प्रत्येकाला 8 पैकी एक आठवडाfollow-the-sun — दूरच्या time zones मधील दोन पथके, प्रत्येक फक्त आपल्या दिवसा on call
⏪ आधी
एकच व्यक्ती सतत pager सांभाळत असे, रात्रीचा प्रत्येक call उचलत असे, आणि थकून शेवटी ती सोडून गेली.
💡 काय
On-call: 4 आठवड्यांत 55 pages आले, 12 तासांच्या shift ला 0.98; 56 पैकी 4 shifts मध्ये पुस्तकातील 2 च्या मर्यादेपेक्षा जास्त.
⚙️ कसे
Follow-the-sun: पुणे 07:00–19:00 घेते आणि 12 h दूरचे sister crew उरलेले घेते, म्हणून 17 रात्रीचे pages 0 होतात.
🎯 का
3 जणांच्या rotation मध्ये प्रत्येकजण 33.3% आठवडे on call असते, 25% च्या वर; 8 जणांत ते 12.5%, म्हणून बांधायला वेळ उरतो.
🚀 पुढे
पुढचा धडा बदल सुरक्षितपणे करतो: एका वर्गाला आधी नवा boiler मिळतो, आणि judge आकड्यांनी त्याची तुलना करतो.
🧪 इथे करून पाहा — duty फोन — page चा दर, rotation आणि sites बदला
नवा boiler आधी एकाच वर्गात बसवला जातो — canary विरुद्ध ताजी baseline, आकड्यांवरून निर्णय.
🧒 सोप्या शब्दांत
पथकाला प्रत्येक वर्गात नवा boiler बसवायचा आहे, पण तो वाईट निघाला तर? त्या आधी एकाच वर्गात तो बसवतात. शेजारच्या वर्गात त्या एक ताजा जुना boiler बसवतात, तेवढाच मोठा वर्ग आणि तेवढेच विद्यार्थी. एका दिवसानंतर ऐश्वर्या तक्रारी मोजते: जुना 11, नवा 42. हा वाईट boiler आहे, म्हणून तो काढला जातो. दुसऱ्या वेळी 11 विरुद्ध 13 येते, हा सामान्य चढउतार, म्हणून नवा boiler सगळीकडे जातो.
📖 नवे शब्दcanary — traffic च्या छोट्या भागावरची नवी version, सगळ्यांना देण्याआधी तपासलेलीbaseline — जुन्या version ची ताजी copy, canary इतकीच मोठी आणि तेवढ्याच traffic चीz-score — canary चे errors खरोखर जास्त आहेत याची खात्री किती; 3.0 च्या वर म्हणजे rollbackp99 — ज्या वेळेत 100 पैकी 99 requests पूर्ण होतात, जसे 180 ms
⏪ आधी
नवी version एकदम सगळ्या servers वर जात असे, आणि लोक graph कडे बघून ठीक दिसते असे म्हणून निर्णय घेत.
💡 काय
Canary analysis: नवी version एका छोट्या भागावर, आणि त्याच आकाराच्या जुन्या version च्या ताज्या copy शी तुलना.
⚙️ कसे
Baseline ला 10,000 मध्ये 11 errors. Canary B ला 42: z 4.26 > 3.0, ROLLBACK. Canary C चा p99 ×1.44 > ×1.2: ROLLBACK.
🎯 का
Canary A चे 11 विरुद्ध 13 हे सामान्य चढउतार आहे (z 0.41), म्हणून ती promote होते; D कडे फक्त 400 requests, म्हणून judge थांबतो.
🚀 पुढे
पुढचा धडा वाईट बदल निसटला तर होणारे नुकसान मर्यादित करतो: टप्प्याटप्प्याने rollout, आणि परत जाण्यासाठी एक switch.
🧪 इथे करून पाहा — ताज्या baseline विरुद्ध canary तपासा
एकेक खोली, हातात switch ठेवून — exposure, detection आणि rollback चा वेग; feature flags.
🧒 सोप्या शब्दांत
पथक दिवे बदलते, आणि नव्या दिव्यांत दोष आहे: 10 पैकी 3 bulbs बंद पडतात. सगळ्या खोल्या एकदम बदलल्या आणि परत आणायला 15 मिनिटे लागली तर 6,000 requests अयशस्वी होतात. जुन्या दिव्याकडे परत नेणारा switch असेल तर 1,800. आधी शंभरातील फक्त एक खोली बदलली तर 75. शंभरातील एक खोली आणि switch: फक्त 33. काळजीपूर्वक पद्धतीला प्रत्येक खोलीपर्यंत पोहोचायला 2 तास लागतात.
📖 नवे शब्दprogressive delivery — बदल टप्प्याटप्प्याने users पर्यंत पोहोचतो, 1% → 5% → 25% → 100%exposure — एका वेळी किती users ना बदल दिसतो; नुकसानावरचा सर्वात मोठा leverfeature flag — code मधील switch जो नवा build न करता सुमारे 1 मिनिटात feature बंद करतोrollback — जुन्या version कडे परत जाणे; redeploy ला 15 मिनिटे लागतात
⏪ आधी
सगळ्यांना नवी version एकदम मिळत असे, आणि rollback म्हणजे नवा build आणि 15 मिनिटांचे redeploy.
💡 काय
Progressive delivery: बदल 1% → 5% → 25% → 100% पर्यंत पोहोचतो, प्रत्येकी 30 min; feature flag तो बंद करतो.
⚙️ कसे
मिनिटाला 1,000 requests पैकी 30% अयशस्वी करणारा बदल: big bang + redeploy मध्ये 6,000; 1% canary + flag मध्ये 33.
🎯 का
Exposure हा सर्वात मोठा lever आहे, त्यानंतर rollback चा वेग; किंमत अशी की पूर्ण rollout ला 1 मिनिटाऐवजी 2 तास लागतात.
🚀 पुढे
पुढचा धडा पुढच्या सत्राच्या खुर्च्यांचा आराखडा करतो: peak चा अंदाज, headroom, आणि संपूर्ण zone गेला तरी टिकणे.
🧪 इथे करून पाहा — exposure × detection × rollback चा वेग — एखादा वाईट बदल किती requests अयशस्वी करतो
पुढच्या सत्रासाठी खुर्च्या — forecast, headroom, N+1, N+2 आणि संपूर्ण zone गमावणे.
🧒 सोप्या शब्दांत
दर आठवड्याला ऐश्वर्या सभागृहातील सर्वात गर्दीचा क्षण मोजते: आठवडा 1 मध्ये 1,206 आणि आठवडा 12 मध्ये 1,707. ती एक सरळ रेषा काढते आणि सहा महिने पुढे नेते: सुमारे 2,963. खुर्च्यांची एक रांग 300 जणांसाठी असते, पण कोणी दाटीवाटीत बसू नये म्हणून ती 210 चा आराखडा करते, म्हणून 15 रांगा. एक जास्तीची रांग म्हणजे 16, दोन म्हणजे 17. संपूर्ण wing बंद झाली तर तिला 24 लागतात. निकालाच्या दिवशी 36 लागतात, त्या आधीच उसन्या आणल्या जातात.
📖 नवे शब्दforecast — मागील आठवड्यांवरून पुढच्या load चा अंदाज, जसे 26 आठवड्यांनी 2,963 req/sheadroom — अचानक येणाऱ्या गोष्टींसाठी मोकळी ठेवलेली जागा, जसे 300 च्या 70% वर आराखडाN+1 — गरजेपेक्षा एक server जास्त, म्हणजे एक बंद पडू शकतो; N+2 maintenance सुद्धा झेलतोzone — स्वतःची वीज असलेली वेगळी इमारत; येथे 3 पैकी 1 गेला तर 24 servers लागतात
⏪ आधी
Site आधीच हळू झाल्यावर servers जोडले जात, आणि दरवर्षी निकालाचा दिवस शाळेला अचानक गाठत असे.
💡 काय
Capacity planning: 12 आठवड्यांचे peaks 1,206 ते 1,707 req/s, आठवड्याला +47.8 वाढतात, म्हणून 26 आठवड्यांनी 2,963.
⚙️ कसे
एक server 300 req/s हाताळतो; 70% = 210 नुसार आराखडा, म्हणून N = 15. N+1 = 16, N+2 = 17, 3 पैकी 1 zone गेला तर 24.
🎯 का
Headroom अचानक वाढ शोषून घेते; 2.5 × = 7,408 req/s च्या निकालाच्या दिवशी 36 servers लागतात, म्हणून आधीच वाढवा.
🚀 पुढे
पुढचा धडा तरीही बिघडल्याच्या रात्रीचा आहे: incident commander, fixer, बोलणारी व्यक्ती, scribe आणि स्वच्छ handoff.
🧪 इथे करून पाहा — पुढच्या सत्रासाठी खुर्च्या — वाढ, अंदाज, headroom आणि zones
एक commander, एक दुरुस्ती करणारी, एक आवाज आणि एक लेखनिक — भूमिका, update ची लय आणि handoff.
🧒 सोप्या शब्दांत
रात्री 23:00 ला timetable इमारत अंधारात जाते. पहिल्या रात्री कतरिना आणि दीपिका दोघीही दुरुस्ती सुरू करतात आणि एकमेकींचे काम उलटवतात. जवळजवळ दोन तास मुख्याध्यापकांना कोणीच काही सांगत नाही. दुसऱ्या रात्री दीपिका सांगते की ती incident commander आहे: ती नेतृत्व करते, दुरुस्ती करत नाही. कतरिना दुरुस्ती करते आणि ऐश्वर्या दर अर्ध्या तासाने काय चालले आहे ते सांगते. मध्यरात्री दीपिका काम सोपवते, आणि crew-5 म्हणते 'I have command.'
📖 नवे शब्दincident commander — incident चे नेतृत्व करून निर्णय घेणारी व्यक्ती, जी स्वतः दुरुस्ती करत नाहीcomms — दर 30 मिनिटांनी सगळ्यांना काय चालले आहे ते सांगणारी व्यक्तीscribe — काय आणि केव्हा घडले ते लिहून ठेवणारी व्यक्तीhandoff — भूमिका पुढच्या व्यक्तीकडे सोपवणे, जिने 'I have command' म्हणायलाच हवे
⏪ आधी
सगळे एकदम दुरुस्तीला धावत: दोघी एकमेकींचे काम उलटवत, आणि मुख्याध्यापकांना कोणीच काही सांगत नसे.
💡 काय
Incident command: ठरलेल्या भूमिका. दीपिका IC आणि scribe आहे, कतरिना दुरुस्ती करते, ऐश्वर्या दर 30 मिनिटांनी comms करते.
⚙️ कसे
00:00 ला दीपिका IC crew-5 कडे सोपवते, आणि ती जाण्याआधी crew-5 'I have command' म्हणते; रात्र 100 मिनिटांत संपते.
🎯 का
भूमिका नसताना त्याच बिघाडाला 110 मिनिटे लागली आणि 5 अडचणी आल्या, त्यात 110 मिनिटे एकही status update नव्हता.
🚀 पुढे
पुढचा धडा आधी गणित करतो: रांगेतील दारे गुणाकाराने कमी होतात, आणि copies स्वतंत्र असतील तरच nines वाढवतात.
🧪 इथे करून पाहा — रात्र चालवा — भूमिका ठरवा, लय पाळा, नीट सोपवा
ओळीतील दारे गुणाकाराने कमी करतात, प्रती nines वाढवतात — आणि प्रत्येक nine ची किंमत किती.
🧒 सोप्या शब्दांत
Timetable पर्यंत पोहोचायला एक विद्यार्थिनी रांगेतील तीन दारांतून जाते. फाटक 99.99% वेळा चालते, सभागृहाचे दार 99.95% आणि office चे दार 99.9%. कोणतेही दार अडकले तर ती आत जाऊ शकत नाही, म्हणून आकडे गुणले जातात: 99.84%. हे सर्वात वाईट दारापेक्षाही वाईट आहे. मग पथक पहिल्या दाराशेजारी office चे दुसरे दार बांधते, आणि संपूर्ण प्रवास 99.94% होतो.
📖 नवे शब्दavailability — एखादी गोष्ट चालू असण्याचा वेळेतील वाटा, जसे 99.9%serial — रांगेतील भाग जे सगळे चालायलाच हवेत; त्यांचे आकडे गुणाकाराने कमी होतातredundancy — जास्तीची copy म्हणजे कोणतीही एक पुरेशी, जशी database ची दोन दारेnines — प्रत्येक जास्तीचा 9 म्हणजे 10 × कमी downtime; 99.99% मध्ये 28 दिवसांत 4.0 मिनिटे
⏪ आधी
एका team ने 99.9% चे वचन दिले, पण request तीन भागांतून जात होती, आणि त्यांचे आकडे कधीच गुणले नाहीत.
💡 काय
Serial availability: gateway 99.99% × app 99.95% × database 99.9% = 99.840%, सर्वात कमकुवत भागापेक्षाही वाईट.
⚙️ कसे
दोन स्वतंत्र database copies मुळे 1 − (1 − 0.999)² = 99.9999% मिळते, आणि संपूर्ण chain 99.940% पर्यंत जाते.
🎯 का
99.840% chain वर्षाला 14.0 h बंद राहू देते; 99.99% वर 28 दिवसांत फक्त 4.0 min, म्हणून दुरुस्ती automatic हवी.
🚀 पुढे
पुढचा धडा overload मध्ये नीट अपयशी व्हायला शिकवतो: critical काम आधी, बाकीचे degrade, आणि प्रत्येक retry ला मर्यादा.
🧪 इथे करून पाहा — रांगेतील दरवाजे गुणाकाराने खाली नेतात, प्रती nines वाढवतात
Canteen सेकंदाला 1,000 थाळ्या देऊ शकते, पण 1,500 लोक येतात. काहीच नियोजन नसेल तर सगळे सारखे थांबतात, आणि तीनपैकी फक्त दोघांनाच जेवण मिळते, दहा मिनिटांत परीक्षा असलेल्या विद्यार्थ्यांनासुद्धा. नियोजन असेल तर परीक्षेचे विद्यार्थी आधी, मग नेहमीचे जेवण, मग दुसरे dessert. सजावट टाळल्याने थाळ्या लवकर होतात, म्हणून 357 desserts दिले जातात. परत पाठवलेले सगळे तीन वेळा पुन्हा घुसू शकत नाहीत.
📖 नवे शब्दoverload — सेवा देता येईल त्यापेक्षा जास्त काम येणे, जसे 1,000 च्या capacity साठी 1,500load shedding — critical काम पूर्ण राहावे म्हणून सर्वात कमी महत्त्वाचे काम आधी परत पाठवणेgraceful degradation — स्वस्त आवृत्ती देणे, जसे photo thumbnails वगळणेretry budget — retries जास्तीत जास्त 10% load वाढवू शकतात, म्हणून 3,000 ऐवजी 1,650
⏪ आधी
प्रत्येक request एकाच रांगेत थांबत असे, म्हणून overload मध्ये recommendations इतकेच logins सुद्धा अयशस्वी होत.
💡 काय
Capacity 1,000 req/s, आलेले 1,500: critical 400, normal 500, sheddable 600. Load shedding priority नुसार सेवा देते.
⚙️ कसे
Priority नसताना प्रत्येक वर्गाला 3 पैकी 2 (critical 267); priority नुसार 400, 500 आणि 100; degrade केल्यावर 357 sheddable.
🎯 का
प्रत्येक request वर 3 retries मुळे सेकंदाला 1,500 चे 3,000 प्रयत्न होतात; 10% retry budget ते 1,650 वर थांबवते.
🚀 पुढे
पुढचा धडा दावे मुद्दाम तपासतो: एका cell मध्ये ठरवून केलेली वीज कपात, hypothesis आणि abort line सह.
🧪 इथे करून पाहा — overload खालील कॅन्टीन — प्राधान्यक्रम, स्वस्त ताटे आणि retries
नियोजित वीज खंडित — hypothesis, blast radius, abort च्या अटी आणि game days.
🧒 सोप्या शब्दांत
पथक म्हणते की पूर्वेकडील wing ची वीज गेली तरी बाकीच्या wings सगळे वर्ग चालवू शकतात. हे कोणीच कधी करून पाहिलेले नाही. म्हणून त्या वर्गांच्या एका block वर, म्हणजे एक दशांश विद्यार्थ्यांवर, test करतात, आणि कधी थांबायचे ते आधीच लिहून ठेवतात. पहिल्या block मध्ये तीन wings आहेत आणि प्रत्येक वर्ग चालू राहतो. दुसऱ्या block मध्ये फक्त दोन wings: जवळजवळ अर्धे वर्ग थांबतात, आणि कतरिना लगेच वीज परत सुरू करते.
📖 नवे शब्दchaos engineering — खरे outage होण्याआधी एखादा दावा तपासण्यासाठी काळजीपूर्वक, मुद्दाम गोष्टी बिघडवणेhypothesis — तुमची अपेक्षा, जसे 'success 99.5% किंवा त्याहून जास्त राहते'blast radius — test किती users ना स्पर्श करू शकते, जसे 1 cell = 10%abort condition — test लगेच थांबवणारी रेषा, जसे कोणताही minute 99.0% खाली
⏪ आधी
खरे outage तपासेपर्यंत designs वर विश्वास ठेवला जात असे, पहाटे 3 वाजता, सगळ्या विद्यार्थ्यांवर एकाच वेळी.
💡 काय
Chaos engineering: hypothesis 'zone B गेला तरी success ≥ 99.5%', 99.0% खाली abort, blast radius 1 cell = 10%.
⚙️ कसे
3 zones मधील 6 replicas 100% वर राहतात. 2 zones मधील 4 replicas 57% पर्यंत घसरतात, आणि test minute 3 ला abort होते.
🎯 का
अयशस्वी run मुळे एका cell मध्ये 18,000 requests गेल्या; सगळ्या 10 cells वर एकदम केले असते तर 10 × जास्त गेल्या असत्या.
🚀 पुढे
पुढचा धडा पथक pager घेण्याआधीची checklist तपासतो, आणि सगळे बारा धडे एका नकाशावर मांडतो.
🧪 इथे करून पाहा — एका cell मध्ये नियोजित वीज कपात — hypothesis टिकते का?
पथक pager हाती घेण्याआधीची checklist — आणि SRE पद्धतीचा संपूर्ण नकाशा.
🧒 सोप्या शब्दांत
नवे timetable office तयार आहे, आणि शिक्षकांना सोमवारी तिथे जायचे आहे. पथक त्याची देखभाल करायला तयार होण्याआधी कतरिना checklist घेऊन फिरते. बहुतेक चौकटी पूर्ण आहेत, पण दोन लाल आहेत: बदल परत घ्यायला 15 मिनिटे लागतात, आणि तीन दारे मिळून 99.84% होतात, वचन दिलेल्या 99.9% पेक्षा कमी. शिक्षक एक जलद switch, दुसरे दार आणि वीज कपातीचा सराव जोडतात. आता ते तयार आहे.
📖 नवे शब्दproduction readiness review — पथक एखाद्या service चा pager घेण्याआधी checklist नुसार केलेली तपासणीblocker — अयशस्वी check जो दुरुस्त होईपर्यंत launch थांबवतोgame day — लोक आणि runbooks तपासणारा ठरवून केलेला अपयशाचा सरावrunbook — एका प्रकारच्या page ला हाताळण्याच्या लिहून ठेवलेल्या पायऱ्या
⏪ आधी
नवी service आधी launch होत असे, आणि पथकाची तिच्याशी पहिली भेट पहाटे 3 वाजता page आल्यावर होत असे.
💡 काय
Production readiness review: 12 checks, प्रत्येक धड्याचा एक, अधिक observability आणि backups, त्यापैकी 8 blockers.
⚙️ कसे
कतरिनाला 15 मिनिटांचा rollback आणि 99.9% SLO खालील 99.840% chain सापडते: NOT READY, 2 blockers आणि 1 आणखी fix.
🎯 का
1 मिनिटाचा flag rollback, दोन database copies (99.940%) आणि game day नंतर ती READY होते, आणि पथक pager घेते.
🚀 पुढे
पुढे: SLOs, burn-rate alerts आणि postmortems साठी Observability school, आणि traffic साठी Scaling school.
🧪 इथे करून पाहा — readiness review — तथ्ये बदला, निकाल पाहा