- 12 जून 2025 को Google Cloud और Google Workspace सेवाओं में बाहरी API requests के दौरान 503 errors वैश्विक स्तर पर बढ़ गए
- आउटेज का कारण Service Control सिस्टम में code change और policy data में खाली field शामिल होने के साथ गलत policy deployment था
- core binary में error handling की कमी और feature flag लागू न होने जैसी समस्याओं ने असर को बढ़ाया
- recovery में 2–3 घंटे लगे, जबकि us-central-1 region में infrastructure overload के कारण recovery में अधिक समय लगा
- Google ने architectural separation, error handling improvements, और stronger data validation जैसे पुनरावृत्ति-रोधी उपायों की घोषणा की
पूरे आउटेज का अवलोकन
Google Cloud और Google Workspace सेवा आउटेज सारांश
- 12 जून 2025 को सुबह 10:49 बजे (PDT) से, Google Cloud, Google Workspace, और Google Security Operations सहित कई सेवाओं में external API requests पर 503 errors तेजी से बढ़ने लगे
- Google ने स्वीकार किया कि इससे customer services और trust पर गंभीर प्रभाव पड़ा, और इसके लिए गहरी क्षमा व्यक्त की
- Google API management और control plane हर request के policy और quota checks को संभालते हैं, और मुख्य checking system
Service Control नाम की binary के रूप में चलता है
आउटेज के कारण का विश्लेषण
बदला हुआ सिस्टम आर्किटेक्चर – Service Control
- 29 मई 2025 को Service Control में quota policy checks को मजबूत करने वाला नया feature जोड़ा गया
- इसे region के हिसाब से चरणबद्ध rollout किया गया, लेकिन समस्याग्रस्त code केवल तब चलता था जब policy वास्तव में apply होती थी, इसलिए यह पहले trigger नहीं हुआ और pre-release testing पर्याप्त नहीं थी
- इस नए feature path में उचित error handling और feature flag नहीं थे, जिसके कारण null pointer स्थिति में binary क्रमिक रूप से crash होने लगी
आउटेज कैसे हुआ
- 12 जून 2025 को सुबह 10:45 बजे (PDT), एक policy change को Regional Spanner table में insert किया गया
- इस policy data में अनजाने में एक blank field शामिल था, और यह लगभग real time में वैश्विक स्तर पर replicate हो गया
- जब Service Control ने इस policy को process किया, तो null pointer के कारण crash हुआ, और हर region की instances वैश्विक crash loop में चली गईं
- 2 मिनट के भीतर SRE team ने स्थिति पहचान ली, 10 मिनट के भीतर root cause पता कर लिया, फिर अस्थायी रूप से binary path को block किया (red-button), और 40 मिनट के भीतर अधिकांश regions recover हो गए
अतिरिक्त recovery issues
- कुछ बड़े regions, खासकर us-central-1 में, Service Control tasks के restart के दौरान herd effect की वजह से infrastructure (Spanner table) overload हो गया
- Service Control ने randomized exponential backoff लागू नहीं किया था, जिससे infrastructure पर और दबाव बढ़ा
- उस region में recovery 2 घंटे 40 मिनट तक delayed रही; traffic rerouting आदि से प्रभाव कम किया गया, और अंततः पूरी service recovery पूरी हुई
ग्राहक प्रभाव और आउटेज का दायरा
- ग्राहकों को API और user interface access failures का सामना करना पड़ा, जबकि streaming और IaaS resources प्रभावित नहीं हुए
- latency और backlog का प्रभाव कुछ services में 1 घंटे से अधिक समय तक बना रहा
- आउटेज से प्रभावित Google Cloud और Google Workspace products की सूची बहुत व्यापक थी
- उदाहरण: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive आदि दर्जनों सेवाएँ
आगे के सुधारात्मक उपाय
- service architecture को modular बनाया जाएगा ताकि हर function अलग हो और failure की स्थिति में fail open processing लागू की जा सके
- global data replication को चरणबद्ध तरीके से propagate किया जाएगा और वास्तविक validation process को मजबूत किया जाएगा
- सभी प्रमुख binary changes के लिए feature flagging और default disabled handling की नीति लागू की जाएगी
- static analysis और testing improvements के जरिए error detection बेहतर किया जाएगा और failure के समय fail open behavior को संभव बनाने वाले design की समीक्षा होगी
- randomized exponential backoff policy तथा monitoring/communication reliability को मजबूत किया जाएगा
- आउटेज की स्थिति में भी ग्राहकों तक तेज़ monitoring और information delivery सुनिश्चित करने के लिए infrastructure redundancy और automated communication को बेहतर किया जाएगा
आउटेज नोटिस और communication
- incident के 1 घंटे के भीतर Cloud Service Health पर सूचना दी गई, लेकिन monitoring infrastructure स्वयं भी प्रभावित था
- कुछ ग्राहक outage signals और impact को ठीक से समझ नहीं पाए क्योंकि Google Cloud आधारित monitoring systems स्वयं सामान्य रूप से काम नहीं कर रहे थे
- Google ने भविष्य में monitoring और customer communication infrastructure को मजबूत करने का वादा किया
प्रमुख आउटेज timeline (mini report summary)
- आउटेज शुरू: 12 जून 2025, 10:49 (PDT)
- अधिकांश regions recover: 12 जून 2025, 12:48 (PDT)
- आउटेज समाप्त: 12 जून 2025, 13:49 (PDT)
- कुल अवधि: लगभग 3 घंटे
- प्रभावित क्षेत्र: वैश्विक
postmortem action items सारांश
- API management platform में data errors या corruption की स्थिति में failure prevention safeguards जोड़े जाएंगे
- global metadata propagation से पहले validation, testing, और monitoring को मजबूत किया जाएगा
- invalid data के लिए system error handling और comprehensive testing का विस्तार किया जाएगा
प्रभावित सेवाओं की सूची (चयनित)
Google Cloud की प्रमुख सेवाएँ
- Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine आदि
Google Workspace की प्रमुख सेवाएँ
- AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar आदि
निष्कर्ष
- यह आउटेज policy/quota management system architecture, data integrity validation की कमी, और error handling framework की अनुपस्थिति के संयुक्त प्रभाव का परिणाम था
- Google ने architecture level improvements और incident response क्षमता को मजबूत करने का वादा किया है
2 टिप्पणियां
यह GN+ नहीं वाला वर्ज़न पोस्ट का लिंक है.
Hacker News राय
मैं अंदरूनी व्यक्ति हूं इसलिए अस्थायी अकाउंट इस्तेमाल कर रहा हूं; इस घटना की जड़ में यह था कि leadership ने गति बढ़ाने के लिए सिद्धांतों की अनदेखी की, और यह प्रथा वर्षों तक चलती रही, अंततः सीमा पर पहुंच गई। इस बार हुआ ‘query of death’ उस तरह की सामान्य विफलता है जो पुराने C++ सर्वरों में, किसी खास query से सर्वर crash होने पर, लगभग अनिवार्य रूप से दिखती है। Service Control C++ में लिखा गया था, और ऐसी विफलताओं को कम करने के लिए कई engineering guidelines का उपयोग करता था। 10 साल तक यह बिना किसी बड़े हादसे के चला, लेकिन हाल में leadership के दबाव में जल्दी-जल्दी बनाई गई global quota policy समस्या बन गई। ऐसे नए features या तो अलग service के रूप में विकसित होने चाहिए थे, या कम से कम मौजूदा guidelines का पालन करना चाहिए था। आधिकारिक रिपोर्ट में बताए गए उपायों से कहीं ऊंचे standards टीम पहले से मानती थी। टीम अपनी क्षमता भर पुराने standards बनाए रखने की कोशिश कर रही है。
मुझे incident report काफ़ी दिलचस्प लगी। SRE टीम ने 2 मिनट में तेज़ प्रतिक्रिया दी और ‘red button’ rollout शुरू हुआ। समस्या यह थी कि us-central-1 जैसे बड़े region में जब Service Control tasks restart हुए, तो infrastructure (Spanner tables) पर ‘herd effect’ के कारण overload आ गया। Service Control में random exponential backoff लागू नहीं था, इसलिए पूरी recovery 2 घंटे 40 मिनट तक टल गई। ऐसी स्थिति में सामान्य quota जल्दी exceed हो जाते हैं और इससे नई failures शुरू हो सकती हैं। ऐसे मामलों में, अगर infrastructure संभाल सके, तो quota को अस्थायी रूप से रोकना या recovery work को धीमा करके limit करना अच्छा हो सकता है।
यह सचमुच बहुत amateur तरह की गलती लगती है। NPE, error handling नहीं, exponential backoff नहीं, test coverage नहीं, staging environment में test नहीं, gradual rollout नहीं — ये सब गंभीर विफलताएं हैं। यह सब SRE किताबों में पहले से लिखा है: Google SRE Book TOC, Building Secure and Reliable Systems TOC। समझ नहीं आता standards बहुत नीचे आ गए हैं, या फिर किताब सिर्फ marketing के लिए है।
मेरे हिसाब से, चाहे इंसान हो या automation, safeguards में पूर्णता जैसी कोई चीज़ नहीं होती; अंततः यह लगातार trade-offs की श्रृंखला है। चाहे आप कितने भी unit tests, integration tests, static analysis, और phased deployment कर लें, scale बढ़ने पर अप्रत्याशित gaps आ ही जाते हैं। यही वजह है जिसकी बात किताब में “एक और 9 जोड़ने में बहुत ज़्यादा मेहनत लगती है” कहकर की गई है। सबसे बुरे मामले में, आपको पूरी stack की copy बनाकर कई महीनों का traffic replay करना पड़ सकता है, और इस स्तर की cost/benefit कोई नहीं उठा सकता। OpenZFS पर काम करते समय भी ऐसा हुआ कि code अपने-आप में ठीक लग रहा था, लेकिन 10 साल पहले लिखे गए data edge case में समस्या निकली। जब systems पर्याप्त जटिल हो जाते हैं, तो हर variation को test करना असंभव हो जाता है, इसलिए व्यावहारिक रूप से cost-effectiveness के आधार पर ही फैसले लेने पड़ते हैं। संदर्भ के लिए, मैं Google SRE हूं लेकिन इस incident से संबंधित टीम में नहीं हूं; यह निजी राय है।
लगभग हर Google global outage इसी तरह unfold होता है: तेजी से global deploy हुई custom system में गलत configuration पहुंच जाती है। सामान्य binary rollout या config push में gradual rollout आम तौर पर लागू होता है। Google Cloud में पहले कई systems global तौर पर tightly coupled थे, लेकिन अब वे काफ़ी regionalized और अधिक reliable हो गए हैं। पहले global outages अक्सर होते थे, लेकिन वे public नहीं होते थे, इसलिए ज़्यादातर users उन्हें अपने ISP की समस्या समझते थे। मुझे नहीं लगता कि हालात विशेष रूप से बदतर हुए हैं। अतिरिक्त संदर्भ: मेरे पास भी SRE अनुभव है।
बाहर से देखने पर लगता है कि बड़े पैमाने की layoffs और CEO के ‘आलस्य’ वाले बयान के बाद, सब लोग quality से ज़्यादा speed और visible outcomes पर केंद्रित हो गए। धीरे-धीरे ऐसा माहौल बन गया जहां इस culture पर सवाल उठाने वाले उलटे अलग-थलग पड़ने लगे।
मैं चाहता हूं कि और विस्तृत जानकारी सार्वजनिक हो। मेरे अनुसार यहां समस्या यह नहीं थी कि testing हुई ही नहीं, बल्कि policy के empty field (समस्या पैदा करने वाला input) के लिए test नहीं था। यह भी नहीं कहा गया कि staging environment में test नहीं हुआ; बल्कि संकेत यह है कि अगर flag होता, तो शायद यह पकड़ा जाता। निजी राय।
इससे 1864 की gunpowder magazine report की यह बात याद आती है: “सबसे ख़तरनाक औज़ारों के साथ भी, एक बार आदमी अभ्यस्त हो जाए तो सावधानी खो देता है, और निर्देश अनावश्यक रूप से कठोर लगने लगते हैं।”
मैं Cloud की एक दूसरी टीम में हूं। सामान्यतः हर code के लिए unit और integration tests होते हैं। binary या config changes कई दिनों में, task-दर-task और region-दर-region, gradual तरीके से किए जाते हैं। इसके साथ canary analysis भी होता है। यहां तक कि rollback भी अगर बहुत तेज़ी से किया जाए तो स्थिति और बिगड़ सकती है, इसलिए उसे भी धीरे किया जाता है। उदाहरण के लिए, किसी global database को एकदम overload करने के बजाय 40 मिनट का outage, 4 घंटे की disruption से बेहतर माना जा सकता है। मैं इस incident में सीधे शामिल नहीं था, लेकिन PM के आधार पर लगता है कि code tested था, बस यह edge case छूट गया। समस्या यह थी कि quota policy setting binary या config file के रूप में नहीं, बल्कि database update के रूप में लागू हुई, और बदलाव कुछ ही सेकंड में दुनिया भर के databases तक फैल गया। null pointer वाली समस्या दूसरी languages में भी assert() के कारण हो सकती थी। ऐसे core service को किसी दूसरी language में फिर से लिखने के जोखिम की तुलना में, हर policy check पर flag guard लगाना, quota policy checks को fail open बनाना, और DB changes को region-by-region धीरे फैलाना ज़्यादा व्यावहारिक लगता है। निजी राय।
assert को policy के तौर पर प्रतिबंधित करना कहीं आसान है।
अगर code tested था लेकिन यह edge case छूट गया, तो जवाब यह है कि अंततः इसका मतलब हुआ testing नहीं हुई।
सिर्फ इसलिए कि DB change binary या config change नहीं था, समस्या का स्वभाव नहीं बदलता। अगर बदलाव एक साथ global स्तर पर फैलता है, तो चाहे उसका प्रकार कुछ भी हो, वह disaster का बीज है। यह Crowdstrike घटना जैसा ही pattern है।
अगर राय यह है कि “language बदलकर rewrite करना बहुत जोखिम भरा है”, तो सवाल यह उठता है कि क्या service requirements ठीक से समझी ही नहीं गईं, या फिर service इतनी critical नहीं मानी गई कि उसके लिए बहुत सावधानी से migration की जाए।
रिपोर्ट के अनुसार, उचित error handling के बिना null pointer के कारण binary crash हो गई। इस स्तर पर ‘trillion dollar mistake’ वाला मज़ाक आना स्वाभाविक है।
सोच रहा हूं इस incident ने साल भर के कितने SLA उड़ा दिए होंगे।
/s के साथ यह सोचने वाली बात है कि काश कोई ऐसी language होती जो ऐसी समस्या रोक पाती।
Service Control (Chemist) काफ़ी पुरानी service है और कई GCP APIs में authentication, authorization, monitoring, quota जैसी core भूमिकाएं निभाती है। request flow में ज़्यादातर GCP APIs Chemist से होकर गुजरती हैं, इसलिए मुझे नहीं लगता कि fail open mitigation यहां प्रभावी होती। Chemist और proxy दोनों C++ में लिखे गए हैं और वर्षों से इनमें बहुत legacy code जमा हो चुका है। हर टीम के पास static analysis, testing, gradual deployment, feature flags, red button, और मजबूत monitoring व alerting systems हैं; खासकर SRE टीमें बहुत मजबूत हैं। चूंकि Chemist में IAM, quota जैसी कई policies validate होती हैं, कई टीमें इस codebase में योगदान देती हैं। समय के साथ, हर बदलाव पर Chemist approval process से न गुजरना पड़े इसलिए कई shortcut paths बनाए गए। हाल के वर्षों में organizational restructuring और offshore विस्तार के कारण L8/L9 स्तर पर चलने वाले flashy नए projects पर ज़ोर बढ़ा, जबकि quality, maintenance, और reliability पीछे छूट गए — इसी cultural shift की वजह से मैंने Cloud छोड़ा। Google के सामान्य server/service best practices यहां अक्सर लागू नहीं किए जाते। इस बार की समस्या code और code review की कमज़ोरी के अधिक करीब लगती है; दोषपूर्ण code को approve कर दिया गया और Spanner के ज़रिए config changes तुरंत reflect होने लगे, जिससे समस्या बढ़ गई।
service policy data में अनजाने में empty field शामिल हो गया, और Service Control ने हर region में quota check के दौरान उस empty field (null) को पढ़कर exception पैदा कर दी। यह Hoare की ‘billion dollar mistake’ का एक और उदाहरण है जो Google के कई systems में दोहराया गया। मूल समस्या यह थी कि ऐसी ‘empty field’ (null) को प्रवेश की अनुमति ही क्यों थी; schema में null निषिद्ध, यानी ‘NOT NULL’, घोषित होना चाहिए था। दुर्भाग्य से Spanner में default nullable होता है, इसलिए इसे अलग से specify करना पड़ता है। application code स्तर पर भी type system या schema language के ज़रिए invalid state को असंभव बनाने का अवसर था। datastore से app object में deserialization करते समय schema-enforced validation जोड़ना भी एक तरीका है। चूंकि मुख्य issue नए code path में फूटा, संभव है कि data layer में इसे filter ही नहीं किया गया। यह भी समस्या है कि Service Control program ऐसी language में लिखा गया है जो null pointer dereference की अनुमति देती है। अगर मैं इसका maintainer होता, तो app code में policies को ‘tagged enum type’ जैसी ऐसी संरचना में बदलने की न्यूनतम-हस्तक्षेप योजना सोचता जिसमें null को व्यक्त ही न किया जा सके। proto3 में ऐसी पाबंदी नहीं है, लेकिन ऐसा एक उदाहरण मौजूद है।
multi-region को अक्सर resilience और availability के साधन के रूप में पेश किया जाता है, लेकिन यह देखना दिलचस्प है कि outage की स्थिति में बड़े cloud providers भी regions के बीच काफ़ी मज़बूती से जुड़े होते हैं।
यह खास तौर पर GCP में ज़्यादा दिखता है, क्योंकि GCP regions को दूसरे vendors से अलग तरीके से संभालता है। resilience के नज़रिए से GCP को कई zones वाले एक single region की तरह देखना चाहिए।
इसके बावजूद, “ऐसी outages जिनके बारे में हमें पता ही नहीं चलता” अभी भी हो सकती हैं, इसलिए region/zone sharding के प्रभाव को बहुत कम करके नहीं आंकना चाहिए।
multi-region deployment की वजह से incidents टले भी होंगे, इसलिए निष्कर्ष निकालने से पहले ऐसे cases समझना ज़रूरी है।
Google postmortems की detail देखकर मैं हमेशा चकित रह जाता हूं — यह भावना कंपनी के अंदर और बाहर, दोनों जगह होती है। लोग सीखते हैं ताकि वही गलती दोबारा न हो, protocol और error handling को मजबूत करते हैं, और systems को और robust बनाते हैं। Google जैसे scale पर हमेशा कुछ-न-कुछ गलत होता रहता है, लेकिन असली बात यह है कि उसका असर customers/users और दूसरे systems तक न पहुंचे। अंदर होने पर भी, टीम के हिसाब से बहुत तरह की समस्याएं नज़र से ओझल रह सकती हैं। मुझे लगता है कि यह इंसानों द्वारा बनाए गए सबसे जटिल systems में से एक वर्ग है। AGI न हो, तो शायद इंसान इससे बेहतर नहीं कर सकते।
लेकिन इस incident में junior-level की गलतियां लगातार हुईं। null data को ठीक से handle न करना, testing की कमी, नए feature के लिए test coverage का अभाव, full rollout से पहले छोटे production scope में verify न करना — ये सब समस्याएं हैं। मुझे पूरा यक़ीन है कि 10 साल पहले Google में ऐसी गलतियों पर सब हंसते।
मेरी समझ के अनुसार इस outage के कारण थे: 1) global feature एक साथ पूरी दुनिया में deploy हुआ, 2) null pointer dereference हुआ, 3) उचित retry policy की कमी ने 'thundering herd' समस्या पैदा की। ये सब उद्योग के लोगों के लिए जानी-पहचानी गलतियां हैं। यह कोई अनोखा या अत्यंत जटिल distributed systems logic नहीं था; यह कई क्लासिक ‘beginner mistakes’ का संयुक्त विस्फोट था।
“हम वही गलती दोबारा नहीं दोहराते” कहा जाता है, लेकिन असल में changes feature flags के बिना rollout हुए, clients में exponential backoff नहीं था, और servers पर load shedding लागू नहीं थी। यह सब कई सालों से Google SRE book में लिखा हुआ है।
यह error एक अनपकड़े null pointer issue की वजह से हुआ। Google जैसी scale और quality वाली company का इस तरह stack के बड़े हिस्से को नीचे गिरा देना इस बात का संकेत माना जा सकता है कि गंभीर issue recurrence prevention पर्याप्त नहीं है।
यह वही गलती है जो अनगिनत बार दोहराई गई है। “नया feature सावधानी से deploy किया गया, लेकिन bug तभी सामने आया जब नया data अंदर आया” — यह वाक्य ज़्यादातर global outages का सार है। पूर्ण system जैसी कोई चीज़ नहीं होती; FAANG outages की बहस में सिर्फ ‘HN के armchair experts’ ही त्रुटिहीन होते हैं।
आम तौर पर जब हम किसी और का downtime देखते हैं, तो उसे आसानी से ‘junior-level mistake’ कह देते हैं, लेकिन अपने काम में वही चीज़ ‘अपरिहार्य’ या ‘पूर्वानुमान से बाहर’ कहकर टाली जाती है। मानवीय गलती अपरिहार्य है, और हमारी अपेक्षाएं ही शायद बहुत ऊंची हैं। अगर कोई offline दुकान अचानक बंद मिले, तो “माफ़ कीजिए” पर बात खत्म हो जाती है। सिर्फ IT industry ही कुछ घंटों के outage पर असाधारण तनाव लेती है; काश सब लोग थोड़ा ज़्यादा सहज रह पाते।