घटना रिपोर्ट: Google Cloud द्वारा ब्लॉक किया गया Railway [समाधान हो गया]

 (status.railway.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Railway की व्यापक सेवा बाधा का समाधान हो गया है, और इसका कारण Railway के Google Cloud अकाउंट का ब्लॉक होना पाया गया
  • बाधा के दौरान उपयोगकर्ताओं को "no healthy upstream", "unconditional drop overload", लॉगिन विफलता, और डैशबोर्ड तक पहुंच न होने की समस्या हो सकती थी
  • Railway ने Google Cloud support team से सीधे संपर्क करके अकाउंट एक्सेस बहाल किया और control plane व workloads की बहाली की
  • बहाली की प्रक्रिया के दौरान Google Cloud की networking issues बनी रहीं, जिससे कुछ सेवाएं शुरू नहीं हो सकीं, और non-enterprise builds को अस्थायी रूप से सीमित किया गया
  • सेवाएं पूरी तरह बहाल हो गई हैं, लेकिन असामान्य रूप में पहचाने गए कुछ workloads का auto-redeployment चल रहा है, और जरूरत पड़ने पर उपयोगकर्ताओं को खुद redeploy करना पड़ सकता है

बाधा का सारांश और अंतिम स्थिति

  • Railway ने व्यापक सेवा बाधा को हल कर लिया है, और postmortem विश्लेषण Incident Report में देखा जा सकता है
  • बाधा की अवधि के दौरान उपयोगकर्ताओं को "no healthy upstream", "unconditional drop overload", लॉगिन विफलता, और डैशबोर्ड तक पहुंच न होने की समस्या हो सकती थी
  • इसका कारण Railway के Google Cloud अकाउंट का ब्लॉक होना था, जिससे Railway की कुछ सेवाएं अनुपलब्ध हो गईं
  • Railway ने Google Cloud support team से सीधे संपर्क कर अकाउंट एक्सेस बहाल किया और workloads की रिकवरी की
  • सेवाएं पूरी तरह बहाल हो गई हैं, लेकिन असामान्य स्थिति में पहचाने गए कुछ workloads का auto-redeployment चल रहा है, और जिन सेवाओं का response सामान्य नहीं है उन्हें उपयोगकर्ताओं को खुद redeploy करना पड़ सकता है

बहाली की प्रगति और उपयोगकर्ता प्रभाव

  • शुरुआती जांच और कारण की पुष्टि

    • Railway ने Google Cloud इन्फ्रास्ट्रक्चर को बहाल किया जो डैशबोर्ड, API, और आंतरिक नेटवर्क के control plane को चलाता है
    • ऊपरी cloud provider तक पहुंच बहाल होने के बाद भी Railway डैशबोर्ड और cloud इन्फ्रास्ट्रक्चर पर चलने वाली सेवाएं corrective deployment से पहले तक प्रभावित रह सकती थीं
    • Google Cloud अकाउंट ब्लॉक होने के बाद Railway platform team ने Google Cloud पर होस्ट किए गए कुछ इन्फ्रास्ट्रक्चर तक पहुंच की पुष्टि की और बाकी सेवाओं की पहुंच बहाल की

  • Google Cloud और नेटवर्क समस्याएं

    • Railway ने Google Cloud पर compute को बहाल कर लिया, लेकिन Google Cloud की ओर की networking issues बनी रहीं, जिससे कुछ सेवाएं शुरू नहीं हो सकीं
    • बहाली के दौरान Google Cloud पर होस्ट किए गए workloads को रुक-रुक कर समस्याएं आती रह सकती थीं
    • Railway infrastructure team प्रभावित सेवाओं को फिर से online लाने के लिए alternative paths पर भी विचार कर रही थी

  • build और deployment पर सीमाएं

    • Railway metal workloads धीरे-धीरे बहाल होना शुरू हुए
    • बहाली के दौरान build इन्फ्रास्ट्रक्चर पर overload से बचने के लिए सभी non-enterprise builds को अस्थायी रूप से सीमित किया गया
    • इसके बाद non-enterprise deployments अस्थायी रूप से निलंबित रहे, जबकि enterprise deployments प्रभावित नहीं हुए
    • deployments फिर से संभव होने के बाद भी Google Cloud में बचे हुए workloads पूरी बहाली से पहले तक रुक-रुक कर समस्याएं झेल सकते थे

  • वर्तमान कार्रवाई

    • Railway सेवाएं पूरी तरह बहाल हो गई हैं, और जिन सेवाओं का response सामान्य नहीं है उन्हें डैशबोर्ड या CLI से redeploy करना चाहिए
    • अतिरिक्त संदर्भ FAQ में देखा जा सकता है, और यदि सीधे support की जरूरत हो तो Railway Station पर thread खोला जा सकता है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • Railway ने इस आउटेज को ठीक कर दिया है और postmortem प्रकाशित किया है
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    20 मई 07:57 UTC तक status page भी पोस्ट की गई थी
    https://status.railway.com/incident/I23M92U0

    • ऐसे मामले में Google से हर्जाना वसूला जा सकना चाहिए। यह network outage या service failure जैसी वह समस्या नहीं है जो terms में शामिल हो सकती है
    • Railway कहता है कि आउटेज हल हो गया, लेकिन अभी भी कई सेवाएँ 502 लौटा रही हैं और डाउन हैं। हमारी तरफ़ recovery तभी हुई जब हमने manually redeploy trigger किया, और मेरा मानना है कि Railway को यह अपने-आप करना चाहिए था
      कुल मिलाकर हमारा downtime 11 घंटे से ज़्यादा था

  • GCP ने फिर एक startup गिरा दिया, और काउंटर फिर 0 दिनों पर आ गया
    लगता है ऐसी चीज़ कम से कम साल में एक बार तो दिख ही जाती है, और AWS या Azure के बारे में ऐसा सुना नहीं
    गंभीरता से कहूँ तो इसी वजह से मैं GCP इस्तेमाल नहीं करता। Big 3 में यह सबसे आसान cloud है, लेकिन ऐसी reputation की वजह से खुद को ही बर्बाद कर लेता है

    • उल्टा मुझे GCP पर कोई गंभीर outage याद नहीं आता। AWS/Azure तो साल में कई बार विनाशकारी तरीके से गिरते लगते हैं
    • AWS इसे ज़्यादा efficiently करता है। us-east-1 डाउन हो जाए तो कई startups को एक साथ गिरा देता है
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure ने भी पिछले साल Azure और O365 सेवाओं के पूरे front door को तोड़ दिया था
      इन कंपनियों की अपनी-अपनी मज़बूतियाँ हैं, लेकिन कभी-कभी बुरी तरह गड़बड़ कर देती हैं
    • AWS ने कभी हमारी सेवा को इतना बुरी तरह throttle किया था कि उसे चलाना ही संभव नहीं था। मैं इस पर लिखना चाहता था कि उन्होंने एक महीने तक हमारी growth रोक दी, लेकिन अब वह उतना मायने नहीं रखता
    • हम भी इसी वजह से GCP को हाथ नहीं लगाते

  • सब Google को दोष देना चाहते हैं, लेकिन मैंने Railway काफ़ी समय तक इस्तेमाल किया है, इसलिए निष्कर्ष पर पहुँचने से पहले मैं GCP का पक्ष भी सुनना चाहूँगा। Railway में पहले भी ऐसी समस्याएँ रही हैं, और उनकी टीम जिस तरह उन्हें handle करती है, उससे भरोसा नहीं बनता
    जो भी हो, मेरे लिए यह आख़िरी सीमा थी

    • यह सिर्फ़ anecdotal है, लेकिन मैं भी सहमत हूँ। Railway की dev team का अंदाज़ काफ़ी ढीला-ढाला लगता है, जैसे जगह-जगह vibe coding मिलाकर काम चल रहा हो। “हम अभी startup हैं, थोड़ा ढील दो” वाली एक सीमा होती है, और Railway उस सीमा के पार चला जाता है
    • सही। दूसरे threads में cloud provider को ज़ोरदार तरीके से कोसने वाले कई अकाउंट दिखते हैं, लेकिन यह अजीब है कि इस गुस्से की धारा में root cause को जानने या उसकी संभावना पर विचार करने की इच्छा लगभग नहीं दिखती
    • 2 साल पहले मुझे support चाहिए था, लेकिन अनुभव इतना खराब था कि मैं बस Vercel पर migrate करके उन्हें भूल गया
      दूसरी सेवा के लिए कुछ ऐसा ही ढूँढते हुए मुझे coolify मिला। अगर आप coolify इस्तेमाल कर सकते हैं, तो Railway इस्तेमाल करने की कोई वजह नहीं है
    • अगर आप कुछ ठोस पुराने उदाहरण बता सकें तो मैं पढ़ना चाहूँगा
    • मैंने ऐसे विवरण सुने हैं जो शायद मुझे नहीं पता होने चाहिए थे। मैं पूरे भरोसे से कह सकता हूँ कि इस बार 100% Google की गलती थी, और अगर Railway इससे ज़्यादा साझा नहीं कर सकता तो मुझे निराशा होगी
      GCP से पूरी तरह बचने के अलावा Railway के पास इसे रोकने का वास्तव में कोई तरीका नहीं था

  • मई 2024 का UniSuper outage भी था: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    UniSuper CEO Peter Chun और Google Cloud CEO Thomas Kurian के संयुक्त बयान के अनुसार, UniSuper की Private Cloud service को provision करते समय एक लापरवाह configuration error हुआ, और अंततः UniSuper की Private Cloud subscription delete हो गई
    Google Cloud ने कहा कि यह दुनिया भर के किसी भी Google Cloud customer के लिए अभूतपूर्व, अलग-थलग पड़ा “एक बार होने वाला incident” था, लेकिन इस subscription deletion ने दोनों regions में deletion trigger कर दिया, और recovery के लिए सैकड़ों virtual machines, databases और applications को restore करना पड़ा

    • मैंने उस समय UniSuper समस्या पर लिखा था: https://danielcompton.net/google-cloud-unisuper
      यह काफ़ी गंभीर bug था, और उनका VMWare environment 1 साल की expiry date के साथ बनाया गया था, जिसे Google Cloud की नज़र में एक ही “resource” माना गया
    • “Private Cloud subscription deletion ने दोनों regions में deletion trigger कर दिया” — इसे ही single point of failure कहते हैं, और जिसने भी safety की ज़िम्मेदारी उठाई है, उसके लिए यह किसी दुःस्वप्न से कम नहीं
    • subscription बंद या delete होते ही दुनिया भर में chain deletion होना तो आपदा का नुस्खा लगता है। समझ नहीं आता वे बस delete-mark करके एक दिन या एक हफ़्ते बाद क्यों नहीं हटाते

  • समझ नहीं आता कि इतना बड़ा monthly spend करने वाली कंपनी के साथ ऐसा कैसे हो सकता है। मेरी पिछली नौकरी में AWS पर जब कोई संदिग्ध workload चल रहा था, तो TAM ने कार्रवाई से पहले हमसे संपर्क किया था
    मुझे लगता है यहाँ कोई ग़लत AI automation था, और GCP शायद इंसानों से वास्तव में संपर्क कर जवाब लेना पसंद नहीं करता, इसलिए शायद कई घंटे बाद किसी outsourced स्टाफ ने support queue में देखकर एक canned reply भेज दिया

    • GCP support से जुड़ी कोई भी बात अब मुझे चौंकाती नहीं। पिछले 6 साल में, जबकि हमें इसकी बिल्कुल ज़रूरत नहीं थी, हमारे Account Executive 12 से भी ज़्यादा बार बदले गए, और सभी पूरी तरह बेकार थे
      हर बार वे अपना परिचय देते, engineering staff के साथ मीटिंग सेट करने को कहते, हमारे लिए बिल्कुल अप्रासंगिक canned slide deck लेकर आते और बस हँसी आती, फिर अगली बार संपर्क तब होता जब कोई नया AE assign हो जाता
      मुझे GCP और उसकी services पसंद हैं और सालों से संतुष्ट भी रहा हूँ, लेकिन लोगों वाला पक्ष सचमुच बहुत खराब है, और समझ नहीं आता इसे चलाने की ज़रूरत ही क्यों है
    • शायद दूसरे thread में भी कुछ सार्थक जवाब थे। हम भी आख़िरकार अपना account वापस पा गए, लेकिन Account Rep और CSM होने के बावजूद यह समझने में समय लगा कि हुआ क्या था
      अगर कोई assigned व्यक्ति न होता, तो स्थिति शायद और खराब होती
    • क्योंकि यह Google है। वे तुम्हें service इस्तेमाल करने देते हैं, और जैसे ही तुम उनकी norm से बाहर जाते हो, suspend कर देते हैं

  • एक public API चलाने वाले के नज़रिए से देखें तो Railway IP से आने वाला spam बेहिसाब है। abuse prevention बहुत खराब है, और उम्मीद है यह घटना operations सुधारने का कारण बनेगी

    • hosting company चलाते समय मूल टकराव यही होता है। signup आसान बनाओ तो नए users बहुत आते हैं, लेकिन abuse भी उतना ही आता है
      abuse prevention लगाओ तो शोरभरे false positives आते हैं, और यह GCP मामला भी वैसा हो सकता है
      hosting company चलाने वालों से मुझे ईर्ष्या नहीं होती। सतह के नीचे internet सचमुच बहुत गंदा है
      और जोड़ूँ तो AWS यह काम वास्तव में बहुत अच्छे से करता है। शायद retail fraud और abuse से निपटने के लगभग 30 साल के अनुभव की वजह से

  • एक मिनट, Railway तो GCP के ऊपर चल रहा था? क्या उन्होंने ज़ोर-शोर से यह नहीं कहा था कि “हम दूसरे cloud के ऊपर cloud नहीं बनाते”?
    या उनका मतलब यह था कि वे VPS किराए पर नहीं लेते, बल्कि cloud provider से सिर्फ़ bare metal लेते हैं?
    कम-से-कम मुझे लगा था कि कोई ऐसा provider उभरा है जो सिर्फ़ hyperscaler में से किसी एक को पैसे देने के बजाय colocation करता है और stack का बड़ा हिस्सा खुद own करता है
    https://blog.railway.com/p/heroku-walked-railway-run

    • Wayback Machine में linked लेख में यह लिखा है
      “पहले दिन से ही हमने इस विचार को सबसे आगे रखा।
      और एक और बात जो हमें सहज रूप से समझ आई, वह यह थी कि आप दूसरे cloud के ऊपर cloud नहीं बना सकते। Railway का business, और अंततः हमारे customers के business को यथासंभव मज़बूत बनाने के लिए, हमने अपने servers चलाने और दूसरे clouds के साथ अच्छी तरह coexist करने वाली operational practice पर वर्षों लगाए।”
    • हाँ, और इसी वजह से गुस्सा आता है। उन्होंने झूठ बोला। वे GCP पर पूरी तरह निर्भर थे
      अब मुझे थोड़ा और शोध करना पड़ेगा। मुझे इससे ज़्यादा stable और एक कंपनी की मनमर्ज़ी पर कम निर्भर कुछ चाहिए
      Railway के लिए भी यह बुरी बात है, क्योंकि यह उनके बड़े दावे peaceful software deployment के मूल पर चोट करता है। यह तो chaos है

  • मुझे लगा था Railway अपना data center बना रहा है [0]
    “असल में, आप किसी और के cloud के ऊपर cloud नहीं बना सकते।”
    सच में...
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel तो ऐसा करते हुए दिखता है। PlanetScale भी कम-से-कम databases तक तो करता है, और वैसे भी आख़िरकार सब कुछ database ही है

  • Railway में signup करते समय system abuse, crypto mining वगैरह पर terms को पढ़कर समझ लेने की पुष्टि कराने का तरीका थोड़ा अलग है
    मेरा अंदाज़ा है कि बहुत से users free tier का दुरुपयोग करके service provider के लिए समस्याएँ खड़ी करते हैं
    competitor होने के नाते भी Railway को ऐसी चोट खाते देखना अच्छा नहीं लगता, लेकिन free compute हर तरह के अजीब users को खींच लाता है। हमने भी यह झेला है, और top-of-funnel कम होने के बावजूद हमने शुरुआती दौर में free compute से बचने का फ़ैसला किया

  • मुझे नहीं लगता कि सिर्फ़ Google को दोष दिया जा सकता है। Railway को platform stability बनाए रखने में बढ़ती मुश्किलें होती दिख रही हैं
    ऐसी घटना से पूरी service डाउन नहीं होनी चाहिए। अगर आपका business सचमुच stable backend देना है, तो backup होना चाहिए। मेरी नज़र में यह खराब planning लगती है

    • समझ नहीं आया आपका मतलब क्या है। क्या आप सच में उम्मीद करते हैं कि Railway सभी customer projects host करने के लिए multi-cloud architecture इस्तेमाल करे? कुल मिलाकर तो उससे availability और कम हो सकती है
    • disaster recovery काफ़ी महँगा नहीं होता? खासकर Railway के पैमाने पर तो और भी ज़्यादा लगता है