20 साल की साइट रिलायबिलिटी इंजीनियरिंग से मिले सबक
(sre.google)- Google SRE ने छोटे data center और Python script-आधारित operations से शुरुआत कर, ऐसे environment में reliability बढ़ाने के अपने अनुभव को संक्षेपित किया है जहाँ computing scale 1,000 गुना से अधिक और network scale 10,000 गुना से अधिक बढ़ चुका है
- incident response में तेज़ कार्रवाई से पहले mitigation की safety आती है, क्योंकि गलत recovery procedure outage कम करने के बजाय cascading failure बढ़ा सकता है
- YouTube और Google Calendar के उदाहरण दिखाते हैं कि global changes को सीमित करने के लिए canary deployment, तुरंत rollback के लिए Big Red Button, और actual path को validate करने वाले integration tests कितने ज़रूरी हैं
- 2017 के OAuth token outage की तरह, जब कोई core dependency टूटती है तो सिर्फ users ही नहीं बल्कि internal response system भी प्रभावित होता है, इसलिए backup communication channel और graceful degradation ज़रूरी हैं
- frequent rollout, automated mitigation, disaster recovery drills, और hardware diversity जटिल distributed systems में MTTR कम करने और single point of failure से बचने के व्यावहारिक सिद्धांत हैं
Google SRE ने 20 साल में scale में आए बदलाव कैसे देखे
- 20 साल पहले Google दो छोटे data center चलाता था, हर data center में हज़ारों server थे, और दो 2.4G network links ring के रूप में जुड़े हुए थे
- उस समय operations काफी हद तक
Assigner,Autoreplacer,Babysitterजैसी Python scripts और individual server names वाले configuration files पर निर्भर थे - MDB नाम का एक छोटा machine database individual server information को व्यवस्थित और लगातार maintain करने के लिए इस्तेमाल होता था
- आज computing power 1,000 गुना से अधिक और network 10,000 गुना से अधिक बढ़ चुके हैं, लेकिन per-server operational effort कम हुआ है और service stack की reliability बेहतर हुई है
- operational tools scripts के संग्रह से service ecosystem में, और फिर base reliability देने वाले integrated platform में विकसित हुए हैं
YouTube outage से निकले response principles
- 2016 में YouTube ने distributed memory caching system bug के कारण 15 मिनट का global outage झेला, जिससे video delivery रुक गई
- outage mitigation को outage की severity के अनुरूप होना चाहिए
- YouTube outage के दौरान risky load-shedding procedure ने outage को ठीक नहीं किया और cascading failures पैदा किए
- risky mitigation best case में outage सुलझा सकती है, लेकिन worst case में गलत तरीके से काम कर outage duration बढ़ा सकती है
- अगर स्थिति ऐसी हो कि standard procedure को bypass करना पड़े, तब भी पहले severity को observe और assess करके ही कदम चुनना चाहिए
- recovery mechanism को वास्तविक emergency से पहले पर्याप्त रूप से test किया जाना चाहिए
- outage के दौरान पहली बार कोई risky mitigation procedure चलाना ऐसा है जैसे ऊँची इमारत में आग लगने पर evacuate करते समय पहली बार सीढ़ी इस्तेमाल करना
- पहले से verify करना चाहिए कि recovery procedure वास्तव में ज़रूरी काम करता है या नहीं, और responsible people उसे चलाना जानते हैं या नहीं
- testing खुद भी उस action को करते समय जोखिम कम करने का असर डालती है
- हर बदलाव में canary deployment से blast radius सीमित किया जाना चाहिए
- caching configuration change ने अनचाहे परिणामों के कारण YouTube service को 13 मिनट तक गंभीर रूप से प्रभावित किया
- अगर global change को canary strategy के साथ धीरे-धीरे deploy किया जाता, तो global impact से पहले outage सीमित किया जा सकता था
- संबंधित सामग्री: canary strategy paper और SREcon talk video
Calendar outage से सीखे rollback और testing के सबक
- risky changes के लिए पहले से परिभाषित Big Red Button होना चाहिए
- Big Red Button एक सरल और आसानी से चलाया जा सकने वाला safety mechanism है जो unwanted state पैदा करने वाले कारण को rollback करता है
- एक engineer ने propagation से पहले desktop computer का power plug निकालकर एक बड़े outage को मुश्किल से टाल दिया था
- बड़े rollout की योजना बनाते समय यह सोचना चाहिए: “मेरा Big Red Button क्या है?”, और हर service dependency के लिए emergency में चलाने लायक mechanism होना चाहिए
- संबंधित लेख: Generic Mitigations
- सिर्फ unit test काफ़ी नहीं हैं; integration test भी ज़रूरी हैं
- unit test यह जाँचते हैं कि individual component उम्मीद के मुताबिक काम कर रहा है या नहीं, लेकिन वे runtime environment और production requirements को पूरी तरह reproduce नहीं करते
- integration test यह verify करने के लिए इस्तेमाल होते हैं कि jobs और tasks cold start कर सकते हैं या नहीं, और components मिलकर इच्छित system बनाते हैं या नहीं
- Calendar outage में test path actual usage path से अलग था, इसलिए बहुत से tests होने के बावजूद वे यह आकलन करने में मदद नहीं कर सके कि बदलाव वास्तविक दुनिया में कैसे काम करेगा
2017 OAuth token outage और operational continuity
- फ़रवरी 2017 में unusable OAuth tokens की वजह से लाखों users अपने devices और services से log out हो गए, और 32,000 OnHub तथा Google WiFi devices ने factory reset कर लिया
- login failures के कारण manual account recovery requests 10 गुना बढ़ गईं, और Google को outage से पूरी तरह recover होने में लगभग 12 घंटे लगे
- outage response के लिए primary communication channel से अलग backup channel होना चाहिए
- उस समय teams को उम्मीद थी कि वे Google Hangouts और Google Meet के जरिए outage manage कर लेंगी
- लेकिन जब 35 करोड़ users devices और services से log out हो चुके हों, तब Google services पर निर्भर रहना उचित नहीं था
- dependency से अलग backup communication channel तैयार और test किए जाने चाहिए
- services को exceptional situations में भी graceful degradation के साथ काम करते रहना चाहिए
- availability को सिर्फ “पूरी तरह normal” या “पूरी तरह down” में बाँटना पर्याप्त नहीं है
- degraded mode में भी minimum functionality बनाए रखने से अधिक consistent user experience दिया जा सकता है
- degradation users को दिखे भी नहीं, और services को असाधारण परिस्थितियों में भी चलते रहने के लिए design किया जाना चाहिए
disaster, automation, rollout, और hardware diversity
- disaster resilience और recovery testing business continuity strategy के मुख्य तत्व हैं
- resilience testing यह verify करती है कि failure, latency, और disruption की स्थिति में service या system टिक सकता है या नहीं
- recovery testing यह जाँचती है कि complete shutdown के बाद service normal state में लौट सकती है या नहीं
- Weathering the Unexpected की तरह, natural disaster या cyber attack जैसी extreme situations को भी मानकर चलना चाहिए
- tabletop game शैली में यह देखना भी उपयोगी है कि “अगर network connectivity का कोई हिस्सा अचानक कट जाए तो क्या होगा?”
- जहाँ स्पष्ट signal हो, वहाँ failure के लिए automated mitigation MTTR घटाने का साधन बन सकती है
- मार्च 2023 में कई data centers में कई network devices लगभग एक साथ fail हो गए, जिससे व्यापक packet loss हुआ
- इस 6 दिन के outage के दौरान लगभग 70% services location, service load, और network failure के समय configuration के अनुसार अलग-अलग स्तर पर प्रभावित हुईं
- प्रभावित services का अनुपात: {p:70}
- अगर यह signal स्पष्ट हो कि कोई specific failure हुआ है, तो manual mitigation actions को automatically शुरू कर MTTR कम किया जा सकता है
- कभी-कभी user impact से पहले बचना और बाद में root cause analysis करना बेहतर होता है
- rollout interval जितना लंबा होगा, change की safety का आकलन उतना कठिन होगा
- मार्च 2022 में payment system outage ने customers को transactions complete करने से रोका, और Pokémon GO Community Day टालना पड़ा
- कारण एक single database field का removal था, और code में उस field का उपयोग हट चुका था, इसलिए यह change सुरक्षित लग रही थी
- लेकिन system के कुछ हिस्सों के धीमे rollout cycle की वजह से live system अब भी उस field का उपयोग कर रहा था
- जटिल multi-component systems में लंबी rollout delay किसी खास change की safety को समझना बहुत कठिन बना देती है
- उचित testing के साथ frequent rollout इस तरह की unexpected failures कम कर सकती है
- एक single global hardware version single point of failure बन सकता है
- किसी महत्वपूर्ण function को केवल एक model के equipment पर छोड़ देने से operations और maintenance सरल हो सकते हैं
- लेकिन अगर उस model में समस्या आ जाए, तो वह महत्वपूर्ण function फिर नहीं चल पाएगा
- मार्च 2020 में एक network device, जिसमें एक undiscovered zero-day bug था, traffic pattern change के कारण bug उजागर हो गया, और वही model तथा version पूरे network में इस्तेमाल होने से बड़ा regional outage हुआ
- कई network backbones होने के कारण high-priority traffic को अब भी काम कर रहे alternate paths पर भेजा जा सका और complete outage टल गया
- critical infrastructure में छिपे संभावित bugs तब तक नज़र नहीं आते जब तक कोई दिखने में harmless event उन्हें trigger न कर दे, और infrastructure diversity बनाए रखना problematic outage और complete outage के बीच का फ़र्क बन सकता है
1 टिप्पणियां
Hacker News की राय
लेख शानदार है और व्यापक रूप से लागू होता दिखता है। “यह तो सिर्फ Google में ही काम आने वाली बात है” जैसा कोई हिस्सा खास नहीं है
communication channel, backup channel, और उस backup channel का भी backup वाकई बहुत अहम है। Netflix में, outage के दौरान इस्तेमाल होने वाले system का vendor चुनते समय हमेशा यह देखा जाता था कि वह AWS पर न हो, और reddit में, मुख्य रूप से इस्तेमाल होने वाला IRC न चले तो उसके लिए office server पर backup IRC रखा गया था
मैंने सुना है कि Google के पास भी AWS पर backup IRC server है, लेकिन हो सकता है वह बस एक किस्सा हो। मुख्य बात यह है कि अपनी infrastructure से जितना हो सके स्वतंत्र secondary contact channel रखना चाहिए
वह team critical path में थी, इसलिए अगर हमारे system की वजह से call आया हो, तो Google Meet के साथ-साथ Google.com भी down हो चुका हो, इसकी संभावना बिल्कुल कम नहीं थी। Gmail की वजह से email भी नहीं चलता, Google Fi होने से work phone भी नहीं चलता, और घर का ISP भी Google Fiber/Webpass था, इसलिए backup layers और चाहिए थीं
इसलिए Google में सचमुच communication के लिए backup IRC server है। उसकी location नहीं बताऊंगा, लेकिन ठीक इसी वजह से उसे Google infrastructure के बाहर स्पष्ट रूप से रखा गया है
“व्यापक रूप से लागू और सिर्फ Google वाली बात नहीं” के संदर्भ में, दूसरी जगहों पर जो चीज़ मैंने लगभग नहीं देखी, वह operations panic room थी। इसका मतलब एक secure room है जिसमें production environment तक जाने वाला backup VPN होता है
एक दिन production SAN में गड़बड़ी आई और on-premises datacenter down हो गया, और उसके साथ Atlassian भी मर गया। Jira नहीं, Confluence नहीं, शायद CI/CD भी नहीं, और व्यवस्थित recovery runbook भी नहीं—बस tribal knowledge बची थी
लोग भड़क गए, और भड़कना जायज़ था। customer-facing systems और infrastructure-related systems को एक ही टोकरी में रखना वाकई खतरनाक है
कम-से-कम 2 साल पहले, जब मैं अभी वहां काम कर रहा था, तब ऐसा ही था
कभी complete cold start समस्या का समाधान सुनना चाहूंगा। जिन कंपनियों के पास विशाल in-house stack है, उनकी core infrastructure में circular dependencies होती हैं
software-defined networking में packet routing फिर से शुरू करने के लिए कुछ software का running होना ज़रूरी है, diskless machines को boot करने के लिए storage चाहिए, और authentication service को security authorization bootstrap करने के लिए storage access चाहिए
अभी इसे कई independent regions चलाकर संभाला जाता है, यानी पूरी तरह बंद datacenter को मौजूदा infrastructure से bootstrap किया जाता है। लेकिन मैंने कभी नहीं सुना कि किसी ने पूरी stack को पूरी power-off state से फिर से ऊपर उठाया हो
कुछ साल पहले जब Facebook ने अपना production network पूरी तरह बिगाड़ दिया था, तब भी machines powered on थीं और internal connectivity कुछ हद तक बची हुई थी। अगर बड़े solar storm जैसी घटना से power grid दुनिया भर में लंबे समय तक down हो जाए और generators तक सब खत्म हो जाएं, तो इसकी कोई guarantee नहीं कि AWS या GCP जैसे clouds ज़रूर वापस जिंदा हो जाएंगे
शायद ऐसे छोटे dedicated datacenters होंगे जिनके पास बेहतरीन backup power और power-grid surge से पूरी तरह isolate करने की क्षमता हो
stack के ऊपरी हिस्से में यह library authors द्वारा चुपचाप जोड़ दी गई dependencies track करने में उपयोगी था, और निचले हिस्से में यह सुनिश्चित करने में मदद करता था कि जिन्हें bottom layer पर होना चाहिए, वे सच में bottom पर ही हैं
documented procedures पुराने न पड़ें, इसके लिए virtual automated cluster startup/shutdown भी किए जाते थे, और SRE के रूप में 6 साल के दौरान मैंने देखा कि वह प्रक्रिया 90 दिनों से घटकर 1 घंटे से कम हो गई
global encryption key management जैसी चीज़ों को भी, जिनमें physical objects चाहिए होते हैं, शून्य से restart करने की drills नियमित रूप से होती थीं, और annual DiRT drills यह सुनिश्चित करने की कोशिश करती थीं कि कोई individual, team या office system को लगातार चलाए रखने की अनिवार्य शर्त न बन जाए
देर से शुरू करेंगे तो बहुत दर्दनाक होगा, लेकिन शुरू से ऐसा करें तो जल्दी आदत हो जाती है और breaking changes या अजीब dependencies जल्दी पकड़ में आ जाती हैं
यह hardware पर भी लागू हो सकता है। architecture इस तरह बदलती है कि कुछ unplug या reset हो जाए तो भी संभल सके। इससे ज़्यादा automation, version management और change management की ज़रूरत पड़ती है, और उसी के चलते outage prevention और fast recovery के साथ-साथ पूरा काम भी तेज़ और सरल हो जाता है। यह बड़ा cultural change है
जहां तक याद है, approach के कुछ हिस्से sensitive information माने जाते हैं, इसलिए और detail में नहीं बताऊंगा
यह भी दिलचस्प है कि किस power grid ने सबसे ज्यादा cold starts किए हैं। आदर्श रूप से ऐसी जगह पहले से इसमें अच्छी होनी चाहिए। शायद Caribbean या Africa में कहीं
हालांकि छोटा power grid cold start, जैसे किसी दूरस्थ island पर एक diesel generator और solar power, इतना आसान हो सकता है कि अच्छी case study न बने
यह साफ है कि internet खुद AC power grid की तरह cold start नहीं हो सकता। AS बहुत ज़्यादा हैं। AS का मतलब क्या है, इस पर पल भर सोचें तो समझ आ जाएगा कि coordinated और rehearsed cold start क्यों असंभव है
इस विषय को और गहराई से समझने के लिए मैं Google की Building Secure and Reliable Systems लगभग पूरी पढ़ चुका हूँ; यह हल्का-फुल्का पढ़ने वाला कंटेंट नहीं, बल्कि ठीक-ठाक पाठ्यपुस्तक जैसी है
किताब काफ़ी दिलचस्प है, और कई बातें common sense जैसी लगती हैं, लेकिन जैसा कि “common sense” अपने-आप में विरोधाभासी शब्द है, पूरी जानकारी को एक बार में refresh करने के लिए यह उपयोगी रही
हाल में सुना कि कुछ कंपनियों ने अपने SRE संगठन बंद करके सदस्यों को SWE टीमों में भेज दिया है। अफ़वाह है कि LinkedIn, Adobe, Robinhood ने ऐसा किया है
इसलिए सोचने लगा कि क्या SRE आसान पैसे वाली bubble economy का byproduct है। क्या बड़े खर्च पर अलग SRE टीम रखे बिना operations नहीं चल सकते
जैसे system administrator या QA tester ज़्यादातर गायब हो गए और उनकी कई ज़िम्मेदारियाँ software development team में चली गईं, वैसा ही 10 साल बाद SRE के साथ भी होगा या नहीं, यह सोचने वाली बात है
लेकिन अभी layoffs चल रहे हैं, इसलिए बहुत-सी कंपनियाँ इस बात की परवाह नहीं कर रहीं। developer की expertise न होने पर भी उन्हें समस्या में लगा देने का trend industry से जाने वाला नहीं है, और मंदी के दौर में यह और साफ़ दिखेगा
full-stack developer इसका अच्छा उदाहरण है: दो roles जोड़ दिए जाते हैं, लेकिन compensation दोगुना नहीं दिया जाता
फिर भी बाकी मुख्य बात मुझे सही लगती है। आजकल DevOps की वजह से developers से अपेक्षित skill set काफी फैल गया है और SRE से काफी overlap करता है। कंपनियाँ SRE teams कम करके जिम्मेदारियाँ developers में बाँट सकती हैं
एक और बड़ा कारण automation है। लिंक की गई साइट को लंबे समय तक पढ़ने पर पता चलता है कि Google के शुरुआती दिनों में SRE बहुत-सा manual काम करते थे, जैसे graphs को manually देखकर deployments करना
उस समय Google तक में system automation पर्याप्त नहीं था, इसलिए SRE ज़रूरी था। Sisyphus वाली कहानी https://www.usenix.org/sites/default/files/conference/protec... देखें तो कुछ हद तक समझ आता है कि standardized automation को पहली बार लागू करने में Google की विफलता ने SRE की job security कैसे सुनिश्चित की
अपने लिखे software की operations जिम्मेदारी किसी और को सौंपना logical नहीं है। SWE को on-call पर रख दीजिए। अगर कोई सोचता है कि manual work ही सबसे अच्छा तरीका है, तो उसे खुद करने दीजिए; और अगर स्तर ऐसा है, तो उसे खराब engineer मानकर निकाल देना चाहिए
interviews इतने कठिन रखना और फिर यह न जानना कि जिस computer पर वे programming करते हैं वह कैसे काम करता है—यह अजीब है। operating system का कामकाज जैसी चीज़ें undergraduate curriculum में भी होती हैं, फिर उन्हें ज़्यादातर self-taught system administrator background वाले लोगों की roles और titles पर डाल देना भी अजीब है
जिन अच्छे SWE को मैं जानता हूँ, वे सभी जानते थे कि operating systems, computers और networks कैसे काम करते हैं
SRE आज जो general automation, developer tools उपलब्ध कराना, developer experience सुधारना जैसे काम कर रहा है, वे platform teams में जा रहे हैं। मुझे लगता है आगे यह role काफी बदलेगा
एक SRE team कई development teams को support कर सकती है, और development teams अक्सर complex infrastructure या distributed systems वाले aspects पर बहुत कम समय लगाती हैं, क्योंकि वे रोज़मर्रा की चिंता का हिस्सा नहीं होते
इसलिए specialized development teams से अलग unit के रूप में चलने वाला infrastructure organization होना उचित है। उसे SRE कहें, SRE SWE team कहें या सिर्फ infrastructure, एक निश्चित scale के बाद teams के across concerns इतने बढ़ जाते हैं कि अलग करना सस्ता पड़ता है
dedicated SRE होने पर operations और संबंधित systems, tools, alerts आदि में असली experts होते हैं और outcomes की clear responsibility भी बनती है। लेकिन वे जिन systems को maintain करते हैं, उन्हें पूरी तरह own नहीं करते, इसलिए organizational समस्याएँ पैदा हो सकती हैं
“हम X launch करना चाहते हैं लेकिन SRE विरोध कर रहा है” या उल्टा हो सकता है, और non-SRE लोग ऐसे code की जिम्मेदारी लेने से बच सकते हैं जिसे support करना मुश्किल हो
इसके उलट बिना SRE वाली engineering team ऐसी organizational/social समस्याएँ कम कर सकती है, लेकिन operational reliability कई priorities में से सिर्फ एक बन जाती है
असल में मुझे लगता है कि कई कंपनियाँ business outcome के रूप में reliability को बहुत महत्वपूर्ण न मानने का फैसला कर रही हैं। खासकर तब, जब feature development की opportunity cost बढ़ जाती है
ऑटोमैटिक mitigation के बारे में सचमुच बहुत सोच-विचार करना चाहिए। 30 साल के करियर में मैंने कई बार देखा है कि ऑटोमैटिक mitigation ने समस्या को और खराब किया। इसलिए सावधानी से तय करना चाहिए कि self-healing वाकई ज़रूरी है या नहीं
2014 में मैंने कंपनी के अंदरूनी इस्तेमाल के लिए एक मोबाइल crash reporting solution बनाया था, और backend का कुछ हिस्सा एक ऐसे server पर चलता था जिसमें Redis single point of failure था। failover प्रक्रिया अर्ध-स्वचालित थी, यानी किसी व्यक्ति को पहले यह पुष्टि करनी होती थी कि alert वैध है, उसके बाद ही उसे शुरू करना होता था
इसके down होने पर असल में कोई आर्थिक नुकसान नहीं होता था, और सबसे खराब स्थिति में मोबाइल app developers को थोड़ी देर असुविधा होती थी। 10 साल तक इसे चलाते हुए failover करने की नौबत जितनी बार आई, वह दो उंगलियों पर गिनी जा सकती थी
यह बिना SLA वाला system था, फिर भी इसका uptime कहीं ज़्यादा महत्वपूर्ण internal systems से बेहतर था
इसके उलट GitHub के उदाहरण देख लें: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
बेशक GitHub बहुत बड़े scale पर operate करता है। मुद्दा यह है कि redundancy और automatic mitigation complexity बढ़ाते हैं, और परिभाषा के अनुसार वे लगभग बिना test हुई स्थिति में, अप्रत्याशित परिस्थितियों में काम करते हैं
इसलिए SLA और outage cost को तौलना चाहिए, और outage रोकने के लिए जो complexity जोड़नी है, उसके साथ उसका संतुलन बनाना चाहिए। लगभग 1998 में मैंने दो NetApp machines को high-availability configuration में जोड़ा था; एक machine fail हुई और उसने दूसरी machine की सारी disks भी खराब कर दीं—यह मेरा पहला सबक था
लगभग उसी समय दो Cisco PIX firewalls के साथ भी यही हुआ, और उसके बाद से मैं high availability और automatic failover/mitigation को लेकर हमेशा सतर्क रहा हूं
मुझे उत्सुकता है कि production में big red button और intentional graceful degradation को कैसे handle किया जाता है। खासकर यह कि जब system खुद समस्या झेल रहा हो, तब भी इनके काम करने की गारंटी कैसे दी जाती है
उदाहरण के लिए, क्या database-based feature flags इस्तेमाल किए जाते हैं, और अगर हां, तो database खुद या access API overload हो जाए तो क्या किया जाता है
या फिर environment variables जैसे static startup flags इस्तेमाल किए जाते हैं, और उस स्थिति में उन्हें पर्याप्त तेज़ी से deploy होना कैसे सुनिश्चित किया जाता है। या क्या कोई बिल्कुल अलग तरीका है
critical path के कुछ हिस्सों में redundancy न भी हो, लेकिन अगर system इतना simple हो कि सभी maintainers के दिमाग में पूरा फिट हो जाए और उसे आसानी से reboot या rollback किया जा सके, तो वह बेहतर हो सकता है
लेकिन जब company “five nines uptime” जैसी guarantees देना शुरू करती है, तो development और improvements जारी रखते हुए उन guarantees को बनाए रखने वाला system design करने के लिए कुछ complexity ज़रूरी हो जाती है
Google में जब किसी खास cluster को unhealthy माना जाता था, तो routinely “backend drain” किया जाता था, और API/load balancer layer में इसे तेजी से handle करने वाला system था
दूसरी जगहों पर मैंने application-level flags से इसे handle होते भी देखा है।
kubectl editकरने जैसा तरीका था, इसलिए यह साफ तौर पर ideal नहीं था, लेकिन काम करता थापहली, इसे simple रखना चाहिए। sophisticated logic या complex data store के बिना बस flag check करने जितना simple होना अच्छा है
दूसरी, इसे जितना हो सके source के करीब रखें, लेकिन client पर बहुत भरोसा नहीं करना चाहिए। पुराने versions, propagation delay और bugs हो सकते हैं, इसलिए बेहतर है कि client और server दोनों तरफ degradation mode चुना जा सके; और अगर सिर्फ एक तरफ संभव हो, तो server side बेहतर है
तीसरी, real traffic के साथ बार-बार test करना चाहिए। test environment पर भरोसा न करें; 0.1% जैसे छोटे scale पर periodic tests और scheduled large-scale tests करें। अगर test नहीं किया है तो ज़रूरत पड़ने पर यह काम नहीं करेगा, और अगर 1 साल पहले काम करता था तो संभावना है कि अब न करे। untested mechanism समाधान से ज्यादा नुकसान बढ़ा सकता है
उदाहरण के लिए मान लें कि Hacker News में comments के बगल में profile photos दिखाने वाला नया feature जोड़ा गया। जाहिर है, हमने सब कुछ microservices बना दिया है, तो मान लेते हैं कि frontend page generator profile service को call भेजता है, और profile service lookup करके image location वापस करती है
launch plan के हिस्से के रूप में, अगर नया component profile service या image store को overload कर दे, तो अपनाई जाने वाली big red button procedure document की जाती है। यानी network layer पर मेरी service के external request rate को limit करने वाला command चलाना, और emergency में शायद उसे 0 कर देना
lookup fail होंगे, लेकिन page generator को ऐसे design किया गया है कि वह profile photo के बिना comment text render करता रहे और धीरे-धीरे degrade हो
यह कोई असली design doc नहीं है, न ही यह सलाह है कि क्या और कैसे बनाना चाहिए; यह सिर्फ बात समझाने के लिए crayon drawing भर है
djb के CDB(constant database) से भी किया है, और JSON config files को API से poll करना या dbm/gdbm/Berkeleydb/leveldb इस्तेमाल करना भी देखा है
यह तरीका दूसरे big red buttons तक भी scale हो सकता है। elegant नहीं है, लेकिन मैंने कई बार ऐसी services चलाई हैं जो health check देना है या नहीं, यह तय करने के लिए file के मौजूद होने की जांच करती थीं। load balancer rotation से node निकालना एक file बनाने जितना आसान था
मुख्य बात यह है कि database failure होने पर system last known good config को default के रूप में इस्तेमाल करे
“recovery mechanisms को emergency से पहले पूरी तरह test किया जाना चाहिए” वाली बात पर मैं सचमुच ज़ोर देना चाहता हूं। Google में अनपेक्षित रूप से SRE बन जाने वाले और double negative का गलत इस्तेमाल करके पूरी company में मशहूर हो चुके व्यक्ति के रूप में, यह ऐसी बेहद महत्वपूर्ण चीज़ है जिसे शुरू से सही करना चाहिए
अगर कोई Googler उत्सुक हो, तो internally मेरा username search करके देखे; आप पता लगा सकते हैं कि मैंने माप से परे बड़ा impact कैसे पैदा किया
घटनाओं को रोकने का सबसे सस्ता तरीका है उन्हें lifecycle की शुरुआती अवस्था में पकड़ना। Software bugs असली कीड़ों जैसे होते हैं। शुरुआत अंडे से होती है, यानी change idea, और उससे निकला nymph पहला POC होता है। जब तक वह production environment तक पहुंचता है, वह adult बन चुका होता है
क्या adult से पहले और stages नहीं होते? सही है। Application को mature होने से पहले कई stages से गुजरना पड़ता है। Bug के पूरी तरह बड़ा होकर अंडे देने से पहले उसे ढूंढना कहीं ज्यादा सस्ता पड़ता है
अगर canary deployment मुश्किल है और rollback भी समस्या है, तो production deployment से पहले और tests जोड़ने चाहिए। Linters, unit tests, end-to-end tests, profilers, synthetic monitors, read-only production replicas, performance tests आदि जितने संभव हों उतने तरीकों से bugs को जल्दी पकड़ना चाहिए
Feature flags, backward compatibility वगैरह भी उपयोगी हैं, लेकिन Shift Left को मात नहीं दे सकते
अगर आप FinTech, banking, hedge funds और cryptocurrency क्षेत्रों में 15 साल SRE करने के नजरिए से ऐसी ही सूची में रुचि रखते हैं, तो यह लेख सुझाऊंगा: https://x.com/alexpotato/status/1432302823383998471?s=20
एक झलक: “25. अगर आपके पास ऐसा rules engine है जिसमें filter conditions से मौजूदा rules ढूंढने की तुलना में नया rule बनाना आसान है, तो आखिरकार ढेर सारे duplicate rules बन जाएंगे”
“जिस engineer ने ऐसा change submit किया था जो outage करा सकता था, उसने change propagate होने से पहले अपने desktop computer की power unplug करके किसी तरह बड़े outage से बचा लिया” — इसका आखिर मतलब क्या है?
नतीजा यह हुआ कि infra SWEs असली buttons बनाने के बजाय दिन भर बेवकूफाना CLI लिखते रहे। मेरे जाने तक इसमें काफी बदलाव हो रहा था
मेरा मानना है कि Google को internal outages के बारे में ज्यादा public करना चाहिए। यह outage तो internal तौर पर खासा मशहूर था
विशाल scale पर भी shell tools और RPC client CLIs दुनिया भर की सभी machines तक काफी तेजी से पहुंच सकते हैं
pssh-style utility के जरिए चलाया थायह 10 साल पहले की बात है, इसलिए पता नहीं आज भी ऐसा इस्तेमाल होता है या नहीं, लेकिन वह तरीका हैरान कर देने वाला तेज था। शायद यह उसी तरह की चीज रही होगी
लेकिन 20 साल पहले यह ज्यादा आम रहा होगा, और आज भी छोटी organizations में ऐसा हो सकता है