Google में SRE का विकास क्रम

 (usenix.org)
4 पॉइंट द्वारा GN⁺ 2025-01-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google के उत्पाद विश्वभर के अरबों लोगों द्वारा उपयोग किए जाते हैं, इसलिए उनका स्थिर और भरोसेमंद चलना बेहद महत्वपूर्ण है। Google की SRE टीम ने सेवाओं की reliability बढ़ाने के लिए कई तरीके विकसित किए हैं।
  • पारंपरिक SRE तरीके जैसे error budget, postmortem आदि ने Google के web service स्केल को बढ़ाने में बड़ा योगदान दिया।
  • हाल के समय में AI/ML आदि के कारण सिस्टम की जटिलता काफी बढ़ गई है, इसलिए नए दृष्टिकोण की जरूरत महसूस हो रही है।
  • सिस्टम थ्योरी और कंट्रोल थ्योरी जटिल परस्पर क्रियाओं को व्यवस्थित तरीके से समझने में उपयोगी हैं।
  • केवल “समस्या होने के बाद समाधान करने” के तरीके से हटकर, सिस्टम स्तर पर मूल डिजाइन से ही सुरक्षा सुनिश्चित करने वाला दृष्टिकोण अब अनिवार्य हो गया है।

STAMP का अवलोकन

  • MIT की प्रोफेसर Nancy Leveson द्वारा प्रस्तावित STAMP (System-Theoretic Accident Model and Processes) अकेले किसी एक हिस्से के खराब होने पर नहीं, बल्कि जटिल सिस्टम इंटरैक्शन के नजरिए से दुर्घटना (incident) का विश्लेषण करता है।
  • पारंपरिक कारण-परिणाम सोच (जैसे “bug था इसलिए failure हुआ”) के बजाय यह पूछता है: “पूरे सिस्टम में कौन सा गलत कंट्रोल फ्लो फंस गया?”
  • Causal Analysis based on Systems Theory (CAST) के साथ दुर्घटना को दोबारा समझा जाता है, और System-Theoretic Process Analysis (STPA) से पहले से ही जोखिम कारकों की पहचान की जाती है।

कंट्रोल थ्योरी की बुनियाद – चार शर्तें

  • कंट्रोल थ्योरी के अनुसार प्रभावी नियंत्रण के लिए चार शर्तें जरूरी हैं:
    • लक्ष्य शर्त: कोई स्पष्ट goal हो (जैसे किसी खास metric को स्थिर रखना)।
    • क्रिया शर्त: लक्ष्य हासिल करने के लिए सिस्टम की state को बदल पाने की क्षमता हो।
    • मॉडल शर्त: सिस्टम को समझने के लिए internal और external दोनों प्रकार के models मौजूद हों।
    • निरीक्षण शर्त: वर्तमान सिस्टम state को जानने के लिए sensors आदि की observability व्यवस्था हो।

दुर्घटना (Outage) को एक कंट्रोल समस्या के रूप में देखना

  • पहले हादसों को समझाने में अक्सर “chain of failures” पर ज़ोर दिया जाता था।
  • STAMP इसे “गलत नियंत्रण और गलत इंटरैक्शन” के नज़रिए से देखता है और सिस्टम स्तर पर safety सुनिश्चित करता है।
  • यह सिर्फ यह खोजने पर केंद्रित नहीं होता कि “पहली failure कहाँ से शुरू हुई”, बल्कि यह समग्र रूप से देखता है कि “कौन सा control/feedback flow असामान्य था”।

Hazards state से समय निकालना

  • पारंपरिक कारण मॉडल में सिस्टम सीधे normal state से अचानक accident state में चला जाता है, इसलिए प्रतिक्रिया का समय बहुत कम होता है।
  • STAMP में “hazard state” की अवधारणा जोड़कर पूर्ण दुर्घटना होने से पहले उस बिंदु की पहचान की जाती है जहां system जोखिम में प्रवेश करता है।
  • hazard state का पता चलने के बाद तुरंत intervention करने पर, वास्तविक accident बनने से पहले ही उसे रोकने की संभावना बनती है।

वास्तविक उदाहरण से समझना

  • Google के अंदर का “Quota Rightsizer” service usage के आधार पर संसाधनों का realloc कर देता है।
  • STPA के नजरिए से “गलत usage data लेने के कारण वास्तविक जरूरत से कम resources दे देना” जैसी स्थिति पहले ही पहचानी जा सकती है।
  • डिजाइन चरण में आमतौर पर केवल “सही control logic” पर ध्यान था, लेकिन STPA लागू करने पर feedback path (जैसे resource usage गणना प्रक्रिया) में समस्या मिली।
  • 2021 में गलत feedback लगातार जमा होकर बड़ा issue बन गया था, और कई हफ्तों तक सिस्टम hazard state में रहा पर किसी को पता नहीं चला।

आगे का रास्ता

  • Google SRE अब STAMP, STPA, CAST जैसी सिस्टम थ्योरी आधारित approaches के साथ अधिक उन्नत सुरक्षा और complexity management की दिशा में बढ़ रहा है।
  • केवल छोटे स्तर की engineering investment (कुछ हफ्तों) से ही बड़े systems में कई संभावित जोखिम scenarios खोजे गए।
  • मौजूदा reliability संस्कृति के साथ यदि control theory-आधारित analysis जोड़ी जाए, तो AI/ML युग में भी स्थिर सेवाएं देने की संभावना काफी बढ़ जाती है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-05
Hacker News टिप्पणी

  • Google का engineering approach startups के लिए नुकसानदायक हो सकता है; कई SREs में hero syndrome दिखता है और वे अक्सर अन्य टीमों की तकनीकी डिज़ाइन दोबारा बदलने की कोशिश करते हैं

    • यह कुछ वैसा ही है जैसे कोई legal टीम कंपनी चलाने की कोशिश करे

  • Sidney Dekker की किताब से मिलता-जुलता

    • यह पूरे सिस्टम को assess करके और accident में involved लोगों की mental state समझकर यह खोजता है कि उन्होंने क्यों सोचा कि सही निर्णय लिया
    • यह दिखाता है कि जटिल सिस्टम में अलग-अलग बदलाव सुरक्षा पर कैसे असर डाल सकते हैं

  • CAST approach आकर्षक लगता है

    • इसमें failures और near-miss का काफी analysis चाहिए, और इसे लागू करने का सबसे कठिन हिस्सा लोग ही हैं

  • CAST और mechanistic explanation work में दिलचस्प समानता है

    • यह एक framework देता है जो सिस्टम components के interaction को समझने में मदद करता है

  • क्या formal safety engineering framework को neural network analysis में apply करने का कोई example है?

    • यह complex causal relationships और system-level behavior को track करने में बहुत useful हो सकता है

  • अगर 'rightsizer' example पारंपरिक तरीके से analyze किया गया होता, तब भी शायद वही परिणाम मिलते

    • नया approach शायद ज्यादा आसान और लागू करने योग्य है

  • software testing को dislike करने की वजह अक्सर external कारणों से आने वाले defects हैं

    • यह approach इसमें मदद कर सकता है

  • CAST multicausal root-cause analysis जैसा ही लगता है

    • MIT के प्रोफेसर Nancy Leveson द्वारा प्रस्तावित CAST का मैं समर्थन करता हूँ

  • क्या SRE/DevOps सामान्य day-to-day roles का हिस्सा हैं?

    • कई बार यह सिर्फ पुराने operations role का rebranding लगता है

  • Google SRE का सबसे बड़ा फर्क यह है कि नए products launch करते समय SRE support की जरूरत पड़ती है

    • सीमित SRE संख्या अच्छे ideas को बेहतर बनाने में मदद करती है

  • article लंबा है और इसमें मुख्य बिंदु पकड़ना मुश्किल है

    • CAST और STPA का उल्लेख शायद सबसे important और valuable है

  • क्या यह approach FAANG के बाहर के scale पर भी value रखता है?

    • इसमें risk-avoidance पर heavy investment करने की प्रवृत्ति दिखती है

  • DevOps की तरह SRE की परिभाषा भी expand हो रही है

    • SRE कई काम करता है, जैसे software लिखना या system failures handle करना