Google Cloud ने GCVE घटना के विस्तृत विवरण साझा किए

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2024-05-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Cloud की मई 2024 की घटना में ऑस्ट्रेलियाई ग्राहक UniSuper के GCVE environment का एक हिस्सा हट गया था; internal review के बाद अब कारण और recovery actions सार्वजनिक किए गए हैं
  • प्रभाव का दायरा एक ग्राहक·एक region·एक service तक सीमित था, और ग्राहक के कई GCVE Private Cloud में से सिर्फ एक तक; अन्य ग्राहक और Google Cloud services प्रभावित नहीं हुए
  • शुरुआती deployment के दौरान internal tool में एक input value खाली रह गई, और system ने इसे स्थिर 1 वर्ष की अवधि के रूप में लिया; अवधि समाप्त होने पर Private Cloud अपने-आप delete हो गया
  • ग्राहक और Google team ने कई दिनों तक 24x7 recovery चलाई, और GCS में मौजूद backups तथा third-party backup software का उपयोग restoration में किया गया
  • Google Cloud ने उस internal tool को retire कर दिया, सभी GCVE Private Cloud की manual जांच की, और delete behavior में बदलाव किए ताकि इसी तरह की घटना दोबारा न हो

घटना का दायरा

  • इस घटना का असर Google Cloud ग्राहक UniSuper पर पड़ा, और Google Cloud ने ग्राहक के systems restore होने के बाद internal review पूरा किया
  • प्रभाव Google द्वारा managed service के संदर्भ में सीमित था
    • एक ग्राहक
    • एक cloud region
    • ग्राहक का Google Cloud VMware Engine(GCVE) उपयोग
    • ग्राहक के कई GCVE Private Cloud में से दो zones में फैला एक Private Cloud
  • जो चीजें प्रभावित नहीं हुईं, उन्हें भी अलग से बताया गया
    • अन्य Google Cloud services
    • GCVE या अन्य Google Cloud services इस्तेमाल करने वाले दूसरे ग्राहक
    • उसी ग्राहक के अन्य GCVE Private Cloud, Google Account, Orgs, Folders, Projects
    • उसी region में मौजूद Google Cloud Storage(GCS) data backups

कारण: internal tool में खाली parameter

  • 2023 की शुरुआत में Google operator ने एक खास capacity placement requirement को पूरा करने के लिए internal tool से ग्राहक के GCVE Private Cloud में से एक deploy किया
  • यह tool capacity management के exception process में इस्तेमाल होता था, और 2023 की चौथी तिमाही में इसे retire कर पूरी तरह automate कर दिया गया, इसलिए अब human intervention की जरूरत नहीं रही
  • operator ने internal control procedures का पालन किया, लेकिन Private Cloud provisioning प्रक्रिया के दौरान एक input parameter खाली था
  • इसी खाली parameter की वजह से system ने उस parameter को उस समय के अज्ञात default value, यानी स्थिर 1 वर्ष की अवधि, दे दी
  • system द्वारा तय की गई 1 वर्ष की अवधि समाप्त होते ही ग्राहक का GCVE Private Cloud delete हो गया

ग्राहक को सूचना क्यों नहीं मिली

  • deletion ग्राहक के request से नहीं, बल्कि Google operator द्वारा internal tool इस्तेमाल करते समय छोड़े गए खाली parameter से शुरू हुआ था
  • यदि ग्राहक ने खुद deletion request किया होता तो advance notification जाता, लेकिन इस deletion के लिए ग्राहक को कोई notification नहीं भेजा गया
  • Google Cloud का कहना है कि उसने घटना को trigger करने वाली conditions और subsystem behavior को बदल दिया है ताकि यह दोबारा न हो

recovery process

  • ग्राहक और Google teams ने कई दिनों तक 24x7 मिलकर recovery का काम किया
    • ग्राहक के GCVE Private Cloud की recovery
    • network और security configuration की बहाली
    • applications की बहाली
    • पूरे operations को restore करने के लिए data recovery
  • ग्राहक के मजबूत और resilient architecture approach ने recovery में मदद की
  • उसी region के Google Cloud Storage में रखे data backups deletion से प्रभावित नहीं हुए
  • उन्हीं backups और third-party backup software ने तेज restoration में अहम भूमिका निभाई

पुनरावृत्ति रोकने के उपाय

  • Google Cloud ने ऐसी घटना दोबारा न हो, इसके लिए कई कदम उठाए
    • घटना के flow को trigger करने वाले internal tool को retire कर दिया गया
    • अब, भले ही खास capacity management की जरूरत हो, नियंत्रण ग्राहक के पास user interface के जरिए रहता है, और संबंधित हिस्सा पूरी तरह automate है
    • system database को साफ किया गया और सभी GCVE Private Cloud की manual review करके यह पुष्टि की गई कि अन्य GCVE deployments किसी जोखिम में नहीं हैं
    • उस deployment workflow में GCVE Private Cloud को deletion target के रूप में सेट करने वाले system behavior को बदल दिया गया
  • Google Cloud के अनुसार इस तरह की घटना पहले कभी नहीं हुई थी और यह systemic issue नहीं था
  • Google Cloud services में जरूरत के अनुसार soft delete, advance notification, और human-in-the-loop जैसी protections मौजूद हैं, और यह पुष्टि की गई कि वे protections अब भी लागू हैं
  • ग्राहक के साथ करीबी सहयोग तेज recovery के लिए महत्वपूर्ण रहा, और अप्रत्याशित घटनाओं के लिए resilient risk management तथा fail-safe तेज recovery के लिए जरूरी हैं
  • Google Cloud ने कहा कि इस one-off घटना के बावजूद उसका uptime और resilience प्रमुख cloud providers में सर्वोत्तम स्तर पर है, जैसा कि independent verification में बताया गया है

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

1 टिप्पणियां

 
GN⁺ 2024-05-26
Hacker News टिप्पणियाँ

  • इस घटना के प्रभाव के पैमाने को देखते हुए हैरानी है कि सुधारात्मक कदम और गहरे नहीं हैं। बस इतना किया गया लगता है कि वही समस्या उसी तरह दोबारा न हो; इसलिए आगे कहीं बराबर की कोई खामी आई तो नतीजे वैसे ही या उससे भी बदतर हो सकते हैं।
    उदाहरण के लिए, सेवा बंद होते ही तुरंत मिटाने के बजाय कुछ दिनों तक डेटा सुरक्षित रखते हुए एक बटन से रिकवर होने वाली स्थिति में रखा जा सकता था; या सभी सेवाओं के deletion flow का audit करके किसी भी वजह से बंद करने से पहले ग्राहक को सूचित करना अनिवार्य किया जा सकता था; या एक निश्चित आकार से बड़ी सक्रिय सेवा को बंद करने पर manual review जोड़ा जा सकता था।
    ऐसे व्यापक कदमों के बिना यह postmortem बिल्कुल आश्वस्त नहीं करता। इतनी बेतुकी घटना के बाद, कोई भी provider जिसे अपनी service पर ज़रा भी गर्व हो या जो अपनी reputation बचाना चाहता हो, यह दिखाने में शायद हद से ज़्यादा आगे जाता कि ऐसा फिर कभी नहीं होगा; लेकिन Google Cloud ने बस न्यूनतम किया लगता है।

    • सेवा बंद करते समय डेटा तुरंत न मिटाना इतना साफ़-साफ़ enterprise software की बुनियादी बात है कि Google के पास 2024 में यह मौजूद नहीं था, यह अपने आप में बहुत कुछ कहता है।
      करियर की शुरुआत से ही, अब ज़रूरत न रहने वाले डेटा को तुरंत delete कर देने का विचार भी बेतुका लगता था। Databases में deletion marker वाली column रखकर soft delete किया जाता था; disk पर डेटा को तब तक move या rename किया जाता था जब तक पक्का भरोसा न हो जाए कि उसे सचमुच मिटाया जा सकता है; और फिर भी backups रखे जाते थे—यही basic तरीका था।
    • पूरी तरह सहमत। ऐसा लगा कि GCP operators यह रेखांकित करने में ज़्यादा रुचि रखते थे कि platform को manage करने के तरीके में कोई systemic problem नहीं है; और इसी वजह से पढ़ते समय उल्टा यह भावना और मज़बूत व असहज हुई कि systemic problem है। Postmortem में common-sense steps का न होना ऐसा लगता है जैसे उन्हें ठीक करने का इरादा ही नहीं है।
    • वास्तविक deletion को delete flag में बदल देने से “Google Cloud ग्राहक डेटा delete नहीं कर पाया और EU regulations का उल्लंघन कर बैठा” जैसे एक और मज़ेदार bug पैदा हो सकते हैं। Google शायद accidental non-deletion के बजाय accidental deletion को चुनेगा, कम से कम EU में तो ऐसा लगता है।
    • ऐसा न करना मज़ाक जैसा है। एक विशाल cloud provider data deletion में safeguards लगाने के बारे में नहीं सोचता, यह समझ से बाहर है। हकीकत में शायद उन्होंने कई बार सोचा होगा, लेकिन लागत आती है इसलिए implement नहीं किया।
    • Google का “postmortem” सच में समझ नहीं आता। जिसने भी online services चलाई हैं, वह देख सकता है कि यह साफ़ तौर पर अपर्याप्त है; ऊपर से निष्कर्ष भी अहंकार से भरा है। अंदाज़ कुछ ऐसा है: “यह one-off incident था, फिर नहीं होगा, सच में sorry, लेकिन हम शानदार हैं और शानदार बने रहेंगे।” यह Google Cloud के लिए सिर पकड़ लेने वाली स्थिति की भरपाई बिल्कुल नहीं करता।

  • अगर आप GCP customer हैं और आपके पास TAM है, तो यह पूछने पर वे असहज हो जाएंगे: जब GCP कोई operational mistake करता है, तो मेरे account के bulk resources को गलती से delete होने से रोकने के लिए कौन-से protections हैं?
    वे शायद जवाब देंगे कि उस specific problem को उस tool को retire करके और अधिक automation से mitigate कर दिया गया है; तब आगे पूछिए: “यह तो मुझे पता है कि वह ठीक किया गया। तो क्या बड़े पैमाने पर deletion से पहले कोई इंसान review करता है?”
    पहले GCP में काम कर चुका हूँ और AWS को उससे कहीं ज़्यादा समय से actively use करता रहा हूँ; मेरी नज़र में GCP में human-based safeguards बहुत कम हैं और AWS से काफी कम लगते हैं। जो भी हो, TAM से इस वास्तविक risk के बारे में पूछना पूरी तरह वाजिब है।

    • ठीक से pressure डालना चाहिए। ऐसा करने से TAM लोग internal systems से बेहतर तरीके से निपटना सीखते हैं। वे अकेले बदलाव नहीं करा पाएंगे, लेकिन कभी-कभी escalation path का वादा या informal agreement मिल सकता है।
      अगर पर्याप्त TAM शोर मचाएँ, तो शायद किसी दिन ऊपर का कोई व्यक्ति कदम उठाए।
    • इसे ऐसे पेश किया जाए कि जब customer assets deletion के लिए scheduled हों, तो Google employee को संपर्क करके customer retention की कोशिश करने का मौका मिले—तो internal तौर पर बात शायद ज़्यादा असर करेगी। साथ में सबको साफ़-साफ़ पता भी चल जाएगा कि जल्द ही कुछ उड़ने वाला है।

  • “Google team ने कई दिनों तक 24x7 काम किया” कहा गया है, लेकिन लगता है उन्हें नहीं पता कि इसमें 7 का मतलब क्या है।

    • शायद मतलब यह था कि 24 engineers ने दिन में 7 घंटे काम किया। Massage और chef-made free cafeteria food सहित।
    • बिल्कुल literal लें तो हाँ, यह थोड़ा बेतुका है। लेकिन x7 का मतलब साफ़ तौर पर सप्ताह के 7 दिन काम करना है, इसलिए गुरुवार दोपहर से मंगलवार सुबह तक भी 24x7 काम किया जा सकता है। मतलब weekend off नहीं लिया।
    • शायद इतना ज़्यादा काम किया कि कुछ दिन कई हफ्तों जैसे लगे।
    • अगर mitigation work weekend पर पड़ा हो, तो फिर यह बात चल सकती है।
    • इसका मतलब यह भी हो सकता है कि team members ने shifts में रात या weekend में interruption के बिना लगातार काम किया। व्यक्तिगत रूप से, ऐसे बड़े projects में मुझे लगता है कि यह हमेशा standard होना चाहिए।

  • वाह, मैं गलत था। मैंने सोचा था Terraform जैसी किसी चीज़ में recovery period के बिना immediate deletion default रहा होगा, और UniSuper की तरफ़ से किसी ने testing करते हुए deletion scope गलत set कर दिया होगा। फिर भी default issue ही होता, लेकिन मुझे लगा था कि third-party tool और UniSuper की गलती होगी।
    असल में यह Google-side issue था, यह पागलपन है। UniSuper ने जरूर सोचा होगा, “ये क्या हो रहा है?”

    • लेख में बताया गया है कि क्या हुआ था और इसका UniSuper से कोई लेना-देना नहीं है। Google ने internal tool से private cloud deploy किया, और उसी Google internal tool ने उसे 1 साल बाद automatically delete होने के लिए set कर दिया।
    • मुझे लगता है Google ने GCP bill में भारी credits दिए होंगे, या फिर अलग से compensation paid किया होगा।

  • संबंधित लेख: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • किसी खास टूल या प्रक्रिया की जांच पर ही नहीं रुके, बल्कि बाकी हिस्सों में भी automatic deletion issue तो नहीं है, यह देखा और soft deletion behavior भी confirm किया—इस लिहाज से यह काफी thorough review लगता है।
    एक कदम और आगे बढ़कर वे सभी default cases भी review कर सकते थे कि कहीं कोई चौंकाने वाला default behavior तो नहीं है। हालांकि क्या “चौंकाने वाला” है, यह तय करना मुश्किल हो सकता है, क्योंकि अक्सर वही लोग defaults को जस-का-तस इस्तेमाल करते हैं जिन्हें tool या API की सबसे कम जानकारी होती है।

    • “soft deletion behavior भी confirm किया” वाला हिस्सा ठीक-ठीक कहां आता है? इसमें बस यह कहा गया है कि इस खास automatic deletion scenario को दोबारा न होने की guarantee दी गई है, और मुख्य वजह भी “अब deployment automated है” जैसी लगती है।
      पहले भी automated था और अब और ज्यादा automated हो गया है, लेकिन इससे यह भरोसा बिल्कुल नहीं मिलता कि deletion mechanism लगातार सुरक्षित है। इसका मतलब सिर्फ इतना है कि driver’s seat पर operator नहीं रहा।
    • ऐसे हादसे AWS इस्तेमाल करने का बहुत अच्छा कारण बन जाते हैं, इसलिए अंदरखाने लोग काफी घबरा गए होंगे।
      “system द्वारा दी गई 1 साल की अवधि खत्म होने के बाद ग्राहक का GCVE Private Cloud delete हो गया। Google operator ने internal tool इस्तेमाल करते समय parameter खाली छोड़ दिया, जिसके परिणामस्वरूप deletion trigger हुआ, और क्योंकि यह ग्राहक का deletion request नहीं था, इसलिए customer notification नहीं भेजी गई। अगर deletion ग्राहक ने खुद शुरू किया होता, तो पहले से notification मिला होता।”
      लो जी! हम इतने अयोग्य हैं कि बिना human review के इतनी बड़ी deletion होने देते हैं। शुक्र है इस customer ने हम पर भरोसा नहीं किया और GCP के बाहर backup रखा था, इसलिए पूरी तरह बर्बाद नहीं हुआ।
      “Google Cloud में इस तरह का incident पहले कभी नहीं हुआ। यह systemic issue नहीं है।”
      अनुवाद करें तो मतलब है: “हे भगवान, AWS और Azure के salespeople ने हमारी इस भारी नाकामी का हवाला देकर हर prospect को तीन-तीन emails भेज दिए।”

  • यह मानना मुश्किल है कि ऐसा incident पहली बार जिस पर हुआ, वह कई अरब डॉलर का mutual fund था। UniSuper की समस्या सुलझ गई, यह अच्छी बात है, लेकिन शायद कुछ और इतने छोटे cases रहे होंगे जिन्हें ignore किया जा सके।
    बस उम्मीद है कि यह घटना GCP के लिए जरूरी wake-up call बने।

    • GCVE, यानी managed VMware, काफी obscure service है। इसे वही कई अरब डॉलर वाली companies इस्तेमाल करती हैं जो अपने existing VMware setup को जैसे-का-तैसा cloud में lift-and-shift करना चाहती हैं।
    • इस incident का core यह था कि एक special customization मौजूद थी जो ज्यादातर customers के पास नहीं होती या वे इस्तेमाल नहीं करते, और उसने कुछ safety checks bypass कर दिए। इसलिए यह “typical” छोटे customer को affect नहीं कर सकता था।
    • छोटे customer भी इसे media तक ले जाते, और media इसे जरूर cover करता, इसलिए ऐसा मानना मुश्किल है।
      “Google ने हमारी cloud service delete कर दी” किसी भी size की company के लिए बड़ी खबर है।

  • “ग्राहक के CIO और technical team Google Cloud team के साथ closely collaborate करते हुए 24x7 recovery को तेज और सटीक तरीके से execute करने के लिए praise के हकदार हैं” कहा गया है, लेकिन जिज्ञासा है कि क्या उन्हें सिर्फ blog post में praise मिला, या उन्होंने ढेर सारे Google Cloud credits भी निकलवा लिए।

    • कोई competent customer हो तो Google से यह cost न दिलवाने वाली reality नहीं है। इस साल का bill बिल्कुल zero हो तो भी मुझे हैरानी नहीं होगी।
    • punitive damages भी होने चाहिए थे।

  • मैं Australia में UniSuper customer हूं। उस समय समझ नहीं आया था कि क्या हुआ है, लेकिन fix करने की कोशिश के दौरान हर दिन emails मिल रहे थे। असल में क्या हुआ था, यह news से पता चला। पूरे मामले को system downtime जैसा छोटा करके बताया गया लगा।
    लोगों के पैसे और pension funds में जमा कई अरब dollars के साथ सचमुच कुछ हो गया होता, यह सोचकर ही डर लगता है।

    • क्या आपको वही emails मिले जो बाकी लोगों को मिले थे? लगभग हर दिन email आया और “disruption”, “apologies”, “frustration” जैसे शब्द कई बार इस्तेमाल हुए।
      कुछ दिनों बाद “A letter from the CEO” subject वाला email भी आया।
      “हम service outage पर update देना चाहते हैं।”
      “सबसे पहले, इस outage के लिए मैं व्यक्तिगत रूप से माफी मांगता हूं, और हमारी teams systems को चरणबद्ध तरीके से फिर से online लाने के लिए दिन-रात काम कर रही हैं—इस दौरान धैर्य रखने के लिए आपका धन्यवाद।”
      उस वक्त की स्थिति में इससे ज्यादा clear communication या Google Cloud के अंदर क्या हुआ था इसकी और स्पष्ट explanation मांगना मुश्किल लगता है।

  • इस incident पर शुरुआती announcement काफी misleading थी। ऐसा लगा जैसे Google ने गलती से पूरा GCP account delete कर दिया हो। यह post पढ़कर थोड़ी तसल्ली हुई। लगता है जो खोया वह सिर्फ एक region-size set of virtual machines था, और ऐसी चीज सच में हो सकती है; मेरा system इसे बड़ी समस्या के बिना संभाल सकता है।
    original post से ऐसा लगा था जैसे सभी regions के GCS buckets, SQL databases आदि सब गायब हो गए हों, जो पूरी तरह अलग समस्या है, और उम्मीद है कि Google ऐसा नहीं करता, इस पर भरोसा किया जा सके।

    • जब UniSuper ने कहा कि account नहीं बल्कि subscription delete हुई थी, तभी red flag था। बहुत लोगों ने वहीं से जल्दबाजी में निष्कर्ष निकाल लिया।