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

• Google SRE ने सेवा का पैमाना बढ़ने पर भी outages को कम किया है, लेकिन privacy breach या data loss जैसी ऐसी हानियों जिन्हें हर हाल में रोकना चाहिए के लिए सिर्फ मौजूदा तरीके पर्याप्त नहीं माने, इसलिए STAMP अपनाया
• STAMP अलग-अलग component failures के बजाय system interactions और control failures पर ध्यान देता है; CAST का उपयोग incident investigation में और STPA का उपयोग risk analysis में होता है
• data flow models और linear cause chains, 100 से अधिक nodes वाले RPC diagrams, पुराने architecture models, और missing requirements के सामने analysis की बड़ी सीमाएँ दिखाते हैं
• 2021 के internal quota rightsizer incident में resource usage का गलत feedback और deliver न हुआ pending change कई हफ्तों तक risky state बनाते रहे, और अंततः outage हुआ
• Google STPA analysis में engineer-weeks स्तर का प्रयास लगाकर सैकड़ों scenarios खोज रहा है, और Google Cloud, internal networks और कई products के safety design तक SRE का दायरा बढ़ा रहा है

---

मौजूदा SRE तरीकों की सीमाएँ

• Google products दुनिया भर में अरबों लोग रोज़ इस्तेमाल करते हैं, और पिछले 25 वर्षों में services का scale काफी बढ़ा है, लेकिन outages अब अधिक दुर्लभ हो गए हैं
• SRE ने अब तक SLO, error budgets, isolation strategies, गहन postmortems और gradual rollouts के जरिए reliability को scale किया है
• अब चुनौती सिर्फ outage frequency घटाने की नहीं, बल्कि ऐसी हानियों से निपटने की है जिनका होना ही रोकना जरूरी है
  • privacy breach
  • data loss
  • regulatory compliance failure
• मौजूदा error budgets कम state वाली web services के लिए आम तौर पर ठीक रहे, लेकिन zero error budget के करीब वाली हानियों से निपटने के लिए पर्याप्त नहीं हैं
• AI और ML लगभग हर product के core में आ रहे हैं, और automation scalability को संभव बना रहा है, इसलिए cost और energy efficiency भी user features जितनी ही महत्वपूर्ण हो गई है

मौजूदा SRE सोच की संरचना

• पारंपरिक risk analysis मोटे तौर पर तीन तत्वों से बनता है
  • system को model करने का तरीका
  • problem कैसे होती है, यह बताने वाली causal theory
  • risks खोजने वाला search algorithm
• Google SRE का मौजूदा तरीका किसी explicit theory के रूप में formalize नहीं किया गया था, लेकिन software architecture और data flow models के आधार पर risk analysis करता रहा है
• data flow model दिखाता है कि network requests या data system के अलग-अलग हिस्सों के बीच कैसे move करते हैं
• यह model स्वाभाविक रूप से linear cause-effect reasoning की ओर ले जाता है
  • हर component के SLO को देखकर reliability guarantees समझना
  • यह जांचना कि caller की requirements पूरी होती हैं या उनसे आगे जाती हैं
• postmortem analysis में अलग-अलग incidents से general patterns निकालने वाली inductive reasoning का उपयोग होता है
  • एक incident ठीक करने पर ही नहीं रुकते, बल्कि उसी तरह की पूरी category के incidents रोकने का तरीका ढूंढते हैं
  • repeat alerts को engineering solutions में बदलकर root causes हटाने की कोशिश करते हैं

data flow models और linear causal analysis की सीमाएँ

• system complexity हर साल बढ़ने के साथ, data flow models के लिए Google-scale complexity संभालना मुश्किल होता जा रहा है
• RPC diagrams और software architecture models अगर abstractions को consistently इस्तेमाल न करें, तो वे बहुत complex हो जाते हैं, और अक्सर incomplete या outdated रह जाते हैं
• ये models system की dynamics को पर्याप्त रूप से नहीं दिखा पाते
  • कौन सा RPC flow शुरू कर सकता है
  • errors कैसे propagate होते हैं
  • कौन सा component serious outage बना सकता है, और कौन सा component सिर्फ छोटी problem बना सकता है
  • कोई specific interaction किस context में safe है लेकिन दूसरे context में unsafe है
  • पूरे system का goal क्या है
  • हर component की overall goal के प्रति क्या responsibility है
• 100 से अधिक nodes वाला data flow diagram, defect exploration की शुरुआत से ही overwhelming होता है
• requirements definition stage में safety requirements छूट जाएँ या गलत हों, तो design requirements को पूरी तरह implement करने के बावजूद system safety टूट सकती है
• outage data से सीखने का तरीका उन losses को predict और prevent करने में सीमित है जो अभी एक बार भी नहीं हुए हैं

STAMP सोच को कैसे बदलता है

• Google SRE ने systems theory और control theory को अपनाते हुए, MIT की Nancy Leveson द्वारा विकसित STAMP framework अपनाया
• STAMP accidents को component failures की chain नहीं, बल्कि system control के पर्याप्त रूप से काम न करने का result मानता है
• CAST का उपयोग incident के बाद investigation में, और STPA का उपयोग risk analysis में किया जाता है
• STAMP safety को individual component property नहीं, बल्कि system-level emergent property मानता है
• analysis questions भी बदल जाते हैं
  • मौजूदा सवाल: कौन सी software service fail हुई?
  • STAMP सवाल: system के हर हिस्से की कौन सी interactions पर्याप्त रूप से controlled नहीं थीं?
• complex systems में कई accidents ऐसे हो सकते हैं जिनमें हर component design के अनुसार काम कर रहा था, लेकिन साथ मिलकर unsafe state बना रहा था

control theory की चार शर्तें

• W.R. Ashby की 『An Introduction to Cybernetics』 में दी गई control conditions को Leveson की STAMP methodology में शामिल किया गया है
• किसी process को control करने के लिए चार conditions जरूरी हैं
  • goal condition: controller के पास goal होना चाहिए
  • action condition: controller system state को प्रभावित कर सके
  • model condition: controller के पास system model होना चाहिए
  • observability condition: controller system state को समझ सके
• SRE practice में इन conditions को complex systems को effectively control करने के लिए जरूरी elements जांचने के criteria के रूप में इस्तेमाल किया जा सकता है

risky state से मिलने वाली response window

• linear cause-chain model आम तौर पर सिर्फ दो states दिखाता है: normal operation और loss operation
• normal operation से loss operation में transition आम तौर पर sudden होता है, और loss रोकने के लिए response time लगभग नहीं होता
• SRE fast burn और slow burn SLO को साथ में इसलिए भी इस्तेमाल करता है ताकि actual damage से पहले की problems detect हो सकें, लेकिन ऐसे SLO आम तौर पर individual component properties होते हैं
• STAMP इसे system-level risky state के रूप में formalize करता है
  • risky state ऐसी system state या conditions का set है, जो कुछ worst-case environmental conditions के साथ मिलकर एक या अधिक stakeholders को loss पहुंचाता है
• risky state individual event या individual component-level phenomenon नहीं है
• system accident होने से पहले लंबे समय तक risky state में रह सकता है
  • bug introduce हो गया है लेकिन अभी trigger नहीं हुआ
  • alert आया है लेकिन किसी को मिला नहीं
  • server under-provisioned है लेकिन अचानक popular feature से traffic मिल गया
• engineering goal हर single failure को हटाना नहीं, बल्कि system को risky state में जाने से रोकना या risky state से normal operation में वापस लाना है

2021 का quota rightsizer case

• Google internal infrastructure में कुछ software के resource quota set और enforce करता है
• efficiency बढ़ाने के लिए, हर service quota में से कितना use करती है इसे monitor किया जाता है, और अगर वह लगातार कम use करे तो quota automatically घटा दिया जाता है
• STPA perspective से quota rightsizer के पास service quota घटाने वाली control action होती है
• यह action तब unsafe होती है जब rightsizer service की actual जरूरत से कम quota कर देता है
  • service resource shortage state में चली जाती है
  • STPA में इसे unsafe control action, यानी UCA कहा जाता है
• UCA के चार types होते हैं
  • जरूरी control action provide नहीं की जाती
  • incorrect या insufficient control action provide की जाती है
  • control action गलत timing या order में provide की जाती है
  • control action बहुत जल्दी रोक दी जाती है या बहुत लंबे समय तक लागू रहती है
• quota को actual जरूरत से कम करना दूसरे type का UCA है

feedback path में दिखी vulnerability

• safety requirement को “quota rightsizer को current service needs से कम quota नहीं करना चाहिए” के रूप में summarize किया जा सकता है
• यह requirement future design, test plans और system understanding के लिए उपयोगी है
• STPA analysis को इस तरह structure करता है कि इस safety requirement का उल्लंघन कराने वाले concrete scenarios खोजे जाएँ
• rightsizer case में चार representative scenarios की जांच की जा सकती है
  • rightsizer खुद गलत काम कर रहा है
  • rightsizer को गलत feedback मिल रहा है या feedback बिल्कुल नहीं मिल रहा
  • rightsizer ने action भेजने की कोशिश की लेकिन quota system ने receive नहीं किया
  • quota system खुद गलत काम कर रहा है
• वास्तव में जो scenario प्रमुख रूप से दिखा, वह था current resource usage feedback का बहुत कम calculate होना
  • resource usage calculation में कई data collectors और complex aggregation logic शामिल हैं
  • अगर calculation result actual से कम हो, तो rightsizer design के अनुसार काम करते हुए भी quota गलत तरीके से घटा देता है
• पहले quota adjustment algorithm और output accuracy पर काफी ध्यान था, लेकिन feedback path को कम समझा गया था
• STPA control path के साथ-साथ feedback path की problems भी खोजने में मदद करता है, और Google के कई system analyses में भी feedback paths अक्सर कम समझे गए थे

incident से loss तक का flow

• 2021 के incident में Google infrastructure की एक important service द्वारा उपयोग हो रहे resources के बारे में गलत feedback rightsizer को भेजा गया
• rightsizer ने नया quota calculate किया, और actual usage से काफी कम resources allocate होने वाले थे
• preventive measure के रूप में quota reduction तुरंत लागू नहीं हुआ, बल्कि किसी को intervene करने का समय देने के लिए कई हफ्तों तक hold पर रखा गया
• लेकिन pending change के बारे में feedback किसी तक नहीं पहुंचा
• system कई हफ्तों तक risky state में था, लेकिन क्योंकि कोई इसे खोज नहीं रहा था, loss रोकने का मौका चूक गया
• कुछ हफ्तों बाद quota reduction लागू हुआ और काफी बड़ा outage हुआ
• Google ने STPA का उपयोग करके ऐसे ही problems को कई systems में पहले से predict किया

Google SRE किस दिशा में जा रहा है

• Google SRE complexity को bug नहीं मानता, और control theory, STPA और CAST का उपयोग करके अधिक comprehensive और proactive reliability approach की ओर बढ़ रहा है
• goal सिर्फ outages पर react करना नहीं, बल्कि शुरुआत से ही अधिक safe systems design करना है
• Google ने अपने कुछ सबसे complex systems का STPA से analysis किया, और प्रति analysis engineer-weeks के करीब effort से अलग-अलग impact range वाले सैकड़ों scenarios खोजे
• मिले हुए scenarios को outages में बदलने से पहले mitigate किया गया
  • quick temporary fixes
  • ज्यादा सावधानी से planned software engineering
  • Google के regular planning processes का उपयोग करके cost और disruption को minimize करना
• मौजूदा काम बहुत complex Google Cloud systems, बड़े internal network systems और कई Google products पर focused है
• SRE की system safety methodology में shift engineers को उनके बनाए systems को समझने का नया तरीका देता है, और उनके operation के बारे में stronger guarantees देने की दिशा में है