Google Cloud आउटेज रिपोर्ट – 2025-06-13

 (status.cloud.google.com)
3 पॉइंट द्वारा GN⁺ 2025-06-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 12 जून 2025 को Google Cloud, Google Workspace और Google Security Operations में बाहरी API requests पर 503 errors बढ़ गए, जिससे दुनिया भर के ग्राहक प्रभावित हुए
  • Service Control की नई quota policy check ऐसे policy data से टकराई जिसमें खाली fields थे, जिससे null pointer crash loop हुआ; rollout के दौरान यह path execute नहीं हुआ था
  • policy change regional Spanner table से कुछ ही सेकंड में दुनिया भर में replicate हो गया, और हर region में Service Control deployment उसी failure path पर चला गया, जिससे यह global outage बन गया
  • SRE team ने 2 मिनट के भीतर response शुरू किया, 10 मिनट के भीतर root cause पहचाना, और लगभग 40 मिनट में red-button rollout पूरा किया, लेकिन us-central1 को recover होने में अधिकतम लगभग 2 घंटे 40 मिनट लगे
  • रोकथाम के उपाय Service Control changes को freeze करने, feature flags को default रूप से disabled रखने, globally replicated data को चरणबद्ध तरीके से propagate करने, error handling और randomized exponential backoff सुधारने पर केंद्रित हैं

आउटेज का दायरा और timeline

  • Google Cloud, Google Workspace और Google Security Operations products में बाहरी API requests पर 503 errors बढ़े, जिससे ग्राहक प्रभावित हुए
  • मुख्य समय सभी US/Pacific समय के अनुसार हैं
    • outage शुरू: 12 जून 2025 10:49
    • us-central1 को छोड़कर सभी regions में mitigation: 12:48
    • outage समाप्त: 13:49
    • कुल duration: 3 घंटे
    • प्रभाव का दायरा: Global
  • ग्राहकों को प्रभावित services में API और user interface access से जुड़ी intermittent समस्याएं हुईं
  • मौजूदा streaming और IaaS resources प्रभावित नहीं हुए

Service Control जिस check path को संभाल रहा था

  • Google और Google Cloud APIs, Google API management और control plane के जरिए प्रदान किए जाते हैं
  • यह management और control plane हर API request के लिए ये checks करता है
    • क्या request authorized है
    • क्या वह policy और quota जैसे checks पास करके endpoint तक जा सकती है
  • policy check system का core binary Service Control है
  • Service Control region-level service है, और quota व policy information पढ़ने के लिए regional datastore का उपयोग करता है
  • इस datastore का metadata Google Cloud और ग्राहकों के quota policy management के लिए लगभग तुरंत दुनिया भर में replicate किया जाता है

सीधा कारण: खाली policy field और null pointer

  • 29 मई 2025 को additional quota policy checks के लिए Service Control में एक नया feature जोड़ा गया
  • code change और binary release का region-wise rollout हुआ, लेकिन असफल हुआ code path केवल किसी specific policy change के होने पर execute होता था, इसलिए rollout के दौरान validate नहीं हुआ
  • समस्या वाले code में उस policy serving path को बंद करने के लिए red-button था, लेकिन सही error handling और feature flag protection नहीं था
  • null pointer सही तरीके से handle नहीं हुआ, जिससे Service Control binary crash हुआ
  • Google ने कहा कि अगर यह feature flag से protected होता, तो internal projects से शुरू करके regions में gradual enablement के दौरान staging में समस्या पकड़ ली जाती

global spread की प्रक्रिया

  • 12 जून 2025 को लगभग 10:45 PDT पर Service Control द्वारा policies के लिए इस्तेमाल की जाने वाली regional Spanner table में एक policy change insert किया गया
  • इस policy data में अनजाने में empty field शामिल था
  • quota management globally operate करता है, इसलिए यह metadata कुछ ही सेकंड में दुनिया भर में replicate हो गया
  • हर region में Service Control ने regional datastore की policy पर quota check करते हुए empty field पढ़ा, और null pointer से मिलने वाला code path execute हो गया
  • परिणामस्वरूप हर regional deployment में binary crash loop में फंस गया

response और recovery में देरी

  • SRE team ने outage शुरू होने के 2 मिनट के भीतर triage और response शुरू किया
  • 10 मिनट के भीतर root cause identify कर लिया और red-button लागू करना शुरू किया
  • red-button outage शुरू होने के लगभग 25 मिनट बाद rollout के लिए तैयार हो गया
  • outage शुरू होने के 40 मिनट के भीतर red-button rollout पूरा हो गया, और छोटे regions से recovery signals दिखने लगे
  • us-central1 जैसे बड़े regions में Service Control jobs restart होने पर dependent infrastructure, खासकर Spanner tables पर herd effect बना और overload हुआ
  • इससे बचने के लिए Service Control में पर्याप्त randomized exponential backoff implement नहीं था
  • us-central1 में job creation को throttle किया गया और traffic को multi-regional database पर route करके load कम किया गया; पूर्ण resolution में अधिकतम लगभग 2 घंटे 40 मिनट लगे
  • इसके बाद Service Control और API serving सभी regions में पूरी तरह recover हो गए
  • संबंधित Google और Google Cloud products architecture के आधार पर कुछ मामलों में अधिक समय लेकर क्रमिक रूप से recover हुए

status page और customer communication

  • पहली Cloud Service Health incident report crash शुरू होने के लगभग 1 घंटे बाद publish हुई
  • देरी का कारण यह था कि इस outage की वजह से Cloud Service Health infrastructure खुद down था
  • कुछ ग्राहकों की Google Cloud पर चल रही monitoring infrastructure भी fail हो गई, इसलिए वे outage signals या business व infrastructure impact का scope समझ नहीं पाए
  • Google ने कहा कि वह automated और manual external communication को बेहतर करेगा ताकि ग्राहकों को समस्या पर response करने, systems manage करने और अपने customers को support करने के लिए जरूरी जानकारी जल्दी मिल सके
  • Google ने कहा कि Google Cloud और core monitoring products down होने पर भी monitoring और communication infrastructure ग्राहकों को service देती रहे, यह सुनिश्चित किया जाएगा

immediate actions और recurrence prevention plan

  • recovery के तुरंत बाद Service Control stack changes और manual policy pushes सभी freeze कर दिए गए
  • Google ने कहा कि वह नीचे दिए गए actions को priority पर रखकर सुरक्षित तरीके से पूरा करेगा
    • Service Control architecture को modularize कर features को isolate करना, और relevant checks fail होने पर भी API requests process होती रहें, इसके लिए fail open structure में बदलना
    • worldwide replicated data consume करने वाले सभी systems का audit
    • भले ही business requirement globally लगभग immediate consistency चाहती हो, data replication को issue validation और detection के लिए पर्याप्त समय देते हुए gradual propagation में बदलना
    • सभी critical binary changes को feature flags से protect करना और default disabled रखना
    • errors को सही तरीके से handle करने और जरूरत पड़ने पर fail open करने के लिए static analysis और testing practices सुधारना
    • systems randomized exponential backoff का उपयोग करते हैं या नहीं, इसका audit करना और इसे ensure करना
    • customer communication सुधारना
    • Google Cloud और core monitoring products के outage के दौरान भी monitoring और communication infrastructure चालू रखना

प्रभावित services और residual impact

  • Google Cloud के कई products प्रभावित हुए; सूची में Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk, Google Security Operations आदि शामिल हैं
  • Google Workspace products में AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search, Google Tasks प्रभावित हुए
  • कुछ products में main outage mitigation के बाद भी residual impact बचा रहा
    • Google Cloud Dataflow में backlog धीरे-धीरे कम हुआ, और us-central1 में delays बने रहे
    • Vertex AI Online Prediction में Model Garden के कुछ models पर high 5xx errors जारी रहे, और बाद में 18:18 PDT तक पूरी तरह recovery हो गई
    • Personalized Service Health में updates में delay था, और ग्राहकों को Cloud Service Health dashboard इस्तेमाल करने की सलाह दी गई

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

1 टिप्पणियां

 
kunggom 2025-06-16

यह GN+ नहीं वाला वर्ज़न पोस्ट का लिंक है.