- Railway प्लेटफ़ॉर्म-व्यापी आउटेज 19 मई 2026 22:20 UTC से लगभग 8 घंटे तक जारी रहा, और इसका सीधा कारण Google Cloud के प्रोडक्शन अकाउंट का सस्पेंड होना था
- डैशबोर्ड और API ने तुरंत 503 errors लौटाने शुरू कर दिए, और Google Cloud पर होस्ट किए गए compute, database, control plane, और burst-compute infrastructure ऑफ़लाइन हो गए
- Railway Metal और AWS workloads चलते रहे, लेकिन edge proxy Google Cloud के control plane API पर निर्भर था, इसलिए route cache expire होने के बाद 404 errors फैलने लगे
- अकाउंट एक्सेस बहाल होने के बाद भी persistent disks, compute instances, और networking को अलग-अलग restore करना पड़ा, और GitHub OAuth तथा webhook rate limiting ने login और builds को अतिरिक्त रूप से रोका
- Railway ने स्वीकार किया कि architectural decisions की वजह से एक upstream provider की एकल कार्रवाई पूरे आउटेज में बदल गई, और अब Google Cloud को data plane के hot path से हटाने के लिए redesign किया जा रहा है
- 19 मई 2026 22:20 UTC से 20 मई 06:14 UTC के आसपास तक लगभग 8 घंटे के लिए Railway पर प्लेटफ़ॉर्म-व्यापी आउटेज हुआ
- Google Cloud ने Railway की production account service सस्पेंड कर दी, जिससे API, control plane, database, और Google Cloud पर होस्ट किया गया compute infrastructure ऑफ़लाइन हो गया
- उपयोगकर्ताओं को डैशबोर्ड और API पर तुरंत 503 errors मिले, और
"no healthy upstream" तथा "unconditional drop overload" संदेशों के साथ login असंभव हो गया
- Google Cloud compute पर होस्ट किए गए सभी workloads ऑफ़लाइन हो गए
- Railway Metal और AWS burst-cloud environment के workloads स्वयं चलते रहे, लेकिन Railway का edge proxy routing table भरने के लिए Google Cloud पर होस्ट किए गए control plane API पर निर्भर था
- cached network routes expire होने पर Google Cloud के बाहर के workloads भी unreachable हो गए, और network control plane active instances के routes resolve नहीं कर सका, जिससे 404 errors लौटे
- अधिकतम प्रभाव के समय सभी regions में Railway workloads unreachable हो गए
- Google Cloud environment की recovery के दौरान individual services restore होते समय प्लेटफ़ॉर्म-व्यापी builds और deployments blocked रहे
- पूरी infrastructure recovery के बाद pending deployment jobs के बड़े backlog को प्लेटफ़ॉर्म पर overload डाले बिना धीरे-धीरे process किया गया
- इसी दौरान GitHub ने Railway के OAuth और webhook integrations को rate limit कर दिया, जिससे login और builds अस्थायी रूप से blocked रहे
- call volume में वृद्धि Google Cloud आउटेज के कारण cache empty हो जाने का परिणाम थी
- terms of service consent records भी reset हो गए, इसलिए अगली बार डैशबोर्ड खोलने पर उपयोगकर्ताओं को फिर से सहमति देनी पड़ी
- Railway ने स्वीकार किया कि architectural decisions की वजह से एक single upstream provider की कार्रवाई पूरे प्लेटफ़ॉर्म आउटेज में बदल गई
- 19 मई 22:10 UTC: automated monitoring ने API health check failures detect किए और on-call engineer को alert किया
- 19 मई 22:11 UTC: डैशबोर्ड ने 503 errors लौटाने शुरू किए और उपयोगकर्ता login नहीं कर सके
- 19 मई 22:19 UTC: पुष्टि हुई कि Google Cloud Platform द्वारा Railway के production account को सस्पेंड करना root cause था
- 19 मई 22:22 UTC: Google Cloud को P0 ticket submit किया गया और Railway का GCP account manager सीधे शामिल हुआ
- 19 मई 22:29 UTC: आउटेज घोषित किया गया
- 19 मई 22:29 UTC: GCP account access restore हो गया, लेकिन सभी compute instances बंद रहे और persistent disks inaccessible थीं
- 19 मई 22:35 UTC: cached network routes expire होने लगे, और Railway Metal तथा AWS workloads ने 404 errors लौटाने शुरू किए
- 19 मई 23:09 UTC: पहली persistent disk फिर से online आई
- 19 मई 23:54 UTC: सभी persistent disks ready state में restore हो गईं, लेकिन network अभी भी down था
- 20 मई 00:39 UTC: disk ready state की पुष्टि हुई, और recovery Google Cloud networking recovery पर अटकी रही
- 20 मई 01:30 UTC: compute instances restore होना शुरू हुए
- 20 मई 01:38 UTC: edge traffic फिर से serve होना शुरू हुआ और networking restore हो गई
- 20 मई 01:57 UTC: orchestration और build infrastructure restore हो गए, और queued jobs के एक साथ चलकर system को overwhelm करने से रोकने के लिए deployments अस्थायी रूप से pause किए गए
- 20 मई 02:04 UTC: compute hosts धीरे-धीरे फिर से online हुए
- 20 मई 02:47 UTC: GitHub ने Railway के OAuth और webhook integrations को rate limit करना शुरू किया, जिससे कुछ उपयोगकर्ता login नहीं कर सके और builds blocked हो गए
- 20 मई 02:55 UTC: डैशबोर्ड फिर से accessible हो गया
- 20 मई 03:59 UTC: सभी tiers में deployment processing फिर से शुरू हुई
- 20 मई 04:00 UTC: पुष्टि हुई कि API, dashboard, और OAuth endpoints काम कर रहे हैं, और बाकी workloads की recovery जारी रही
- 20 मई 06:14 UTC: आउटेज monitoring phase में चला गया
- 20 मई 07:58 UTC: आउटेज resolve हो गया
-
Google Cloud अकाउंट सस्पेंशन
- 19 मई 22:20 UTC पर Google Cloud ने automated enforcement के हिस्से के रूप में गलती से Railway के production account को suspended state में डाल दिया
- इस कार्रवाई ने Google Cloud के भीतर कई accounts को प्रभावित किया
- क्योंकि यह प्लेटफ़ॉर्म-स्तरीय कार्रवाई थी, इसलिए restriction से पहले individual customers को कोई advance contact नहीं किया गया
- suspended state ने Railway Dashboard, API, network infrastructure के कुछ हिस्सों, और Google Cloud पर होस्ट किए गए अतिरिक्त burst-compute infrastructure सहित GCP-संबंधित infrastructure को disable कर दिया
-
control plane dependency
- Railway का control plane वह मुख्य dependency set है जो dashboard serve करता है, builds और deployments process करता है, और edge द्वारा उपयोग की जाने वाली routing tables populate करता है
- Google Cloud के सभी workloads पर प्रभाव तुरंत पड़ा
- Railway के edge proxies Google Cloud के अंदर होस्ट किए गए network control plane की routing table cache बनाए रखते थे
- जब तक cache valid रही, Railway Metal और AWS के workloads traffic serve करते रहे
- cache expire होते ही edge active instances के routes resolve नहीं कर सका, और Metal तथा AWS सहित सभी regions के workloads ने 404 errors लौटाने शुरू किए
- workloads स्वयं online थे, लेकिन network failure का असर Google Cloud के बाहर के regions तक फैल गया
-
high availability design की सीमाएँ
- Railway infrastructure को high availability के लक्ष्य से design किया गया है, जहाँ databases कई availability zones में चलती हैं और network AWS, GCP, और Railway Metal के बीच redundant links का उपयोग करता है
- account access restore होने के बाद भी individual services अपने-आप restore नहीं हुईं
- persistent disks, compute instances, और networking को अलग-अलग recovery की ज़रूरत पड़ी, और recovery की इसी प्रकृति ने आउटेज को कई घंटे और लंबा कर दिया
- disks 23:54 UTC पर ready state में लौट आईं, लेकिन core networking और edge routing 20 मई लगभग 01:30 UTC तक पूरी तरह restore नहीं हुए
- Railway अभी यह पुष्टि होने का इंतज़ार कर रहा है कि यह delay और संबंधित errors Google की तरफ़ से हुए थे या नहीं
-
phased recovery और secondary impact
- networking restore होने पर Railway core services और end-user workloads का validation tier-by-tier किया गया
- build system overload रोकने के लिए deployments को अस्थायी रूप से pause किया गया, और बाद में धीरे-धीरे resume किया गया
- core system recovery के समानांतर GitHub ने Railway के OAuth और webhook integrations को rate limit कर दिया
- सभी retry requests के volume और burst characteristics के कारण user logins और builds अस्थायी रूप से blocked हो गए
- 20 मई लगभग 04:00 UTC तक यह पुष्टि हो गई कि API, dashboard, और OAuth endpoints काम कर रहे हैं, जबकि बाकी workloads की recovery जारी रही
-
मौजूदा resilience design
- Railway का network control plane multi-AZ, multi-zone configuration में design किया गया है, ताकि कई machines और components खोने पर भी यह बिना user impact के चलता रहे
- इस design को launch से कुछ महीने पहले staging और real traffic पर test किया गया था
- पिछली outages के बाद Railway resilience में निवेश करता रहा है, और उसी का परिणाम था कि उसने पहले user GitHub installs को बिना secondary rate limiting के स्थिर रूप से restore किया था
-
single dependency को हटाना
- Railway network, Metal <> GCP <> AWS के बीच high-availability fiber interconnects से बने mesh ring पर आधारित है
- लेकिन इस ring के भीतर भी workload discoverability Google Cloud machines पर चल रहे network control plane API पर एक मज़बूत dependency से बंधी हुई थी
- mesh लगभग एक घंटे तक चलता रहा, लेकिन route cache expire होते ही routing tables फिर से populate नहीं हो सकीं और यह fail हो गया
- Railway इस dependency को तुरंत हटाकर इसे वास्तविक mesh बनाने पर काम कर रहा है
- लक्ष्य यह है कि कोई भी interconnect fail हो जाए, फिर भी clouds के बीच हमेशा कोई route उपलब्ध रहे
-
database और failover में सुधार
- Railway अपने high-availability database shards को AWS और Metal में और विस्तार देगा
- भविष्य में, यदि किसी एक cloud के सभी instances तुरंत गायब हो जाएँ, तब भी database quorum service चालू रख सके और जो workloads अब नहीं चल रहे हैं, उन्हें तुरंत fail over किया जा सके
-
data plane और control plane का redesign
- Google Cloud services को data plane के hot path से हटाकर केवल secondary या failover उपयोग के लिए रखने की योजना पर काम चल रहा है
- यह उस नए architecture के implementation के साथ समानांतर चलेगा जो host connectivity सक्षम करने वाले data plane और वह dashboard चलाने वाले control plane, जिसके ज़रिए उपयोगकर्ता Railway तक पहुँचते और उसे manage करते हैं, दोनों को कवर करेगा
- इस upgrade का उद्देश्य यह सुनिश्चित करना है कि core services, खासकर user-facing components, किसी एक vendor या platform पर निर्भर न रहें
ज़िम्मेदारी और निष्कर्ष
- vendor selection की ज़िम्मेदारी Railway की है, और यह चयन भी अंततः Railway की ही ज़िम्मेदारी है
- ग्राहकों के लिए यह कम मायने रखता है कि failure Google का था या Railway का; वे उत्पाद को देखते हैं, और Railway का uptime Railway की ज़िम्मेदारी है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
दिलचस्प और अब तक अनसुलझा हिस्सा यह है कि Google ने अकाउंट को फ्लैग क्यों किया
पोस्टमॉर्टम में चाहे जितने भी देखे गए timestamps डाल दिए जाएँ, मूल कारण पर बात ही नहीं की गई
कहानी में जो हिस्सा “समझ से बाहर” लगता है, उसके पीछे शायद असली वजह है जिसे अभी कोई सार्वजनिक नहीं करना चाहता
Google ने बिना किसी चेतावनी के अकाउंट बंद कर दिया, और उस समय हम लगभग $10k प्रति माह खर्च कर रहे थे
यहाँ तक कि premium support अकाउंट भी लॉक हो गया था, इसलिए support टीम को यह बताना भी संभव नहीं था कि “हम लॉक हो गए हैं”
लगभग 8 घंटे बाद किसी random Google support engineer ने कहा कि हमने Bitcoin mining की थी, जो पूरी तरह बकवास था
हमारे पास पूरे समय के CPU usage graph और logs थे, और कोई spike भी नहीं था
लगभग 12 घंटे बाद उन्होंने अकाउंट फिर चालू किया और कहा कि यह “abuse detection misconfiguration” था, और credit के रूप में लगभग $100 दे दिए
AWS के बारे में जो भी कहो, AWS में कोई account manager पहले संपर्क किए बिना ग्राहक के साथ ऐसा नहीं करता
तब से मैं GCP पर भरोसा नहीं करता
automation systems गलती करते हैं, लेकिन बड़ी समस्या यह है कि वे पूरी तरह opaque होते हैं
संभव है कि खुद Google को भी ठीक-ठीक न पता हो कि वह system कैसे काम करता है
अगर मतलब यह है कि Railway को GCP छोड़ने के बजाय इसी पर मेहनत करनी चाहिए, तो जब तक वह brand damage और long-term customer loss की भरपाई के लिए GCP पर मुकदमा करने वाला नहीं है, मुझे नहीं दिखता कि उसे ऐसा क्यों करना चाहिए
GCP ने बिना किसी advance warning के जिस क्षण सब बंद किया, उसी क्षण खेल खत्म हो गया, और मेरे हिसाब से उससे आगे पूछताछ की खास ज़रूरत भी नहीं है
लगता है इस महीने tech media में Railway की छवि अच्छी नहीं रही
दोनों मामलों में दूसरी तरफ की automated process वजह बनी और उसकी reputation को नुकसान पहुँचा
मैं मूल Google contact को Gemini CLI को मार देने वाली बात बताने वाला था, लेकिन यह मामला उससे कहीं ज़्यादा चिंताजनक है
AI में admin account credentials डालने वाले वही लोग थे
और उन्होंने व्यक्तिगत ज़िम्मेदारी भी नहीं ली, जिससे reputation का नुकसान तय था
इस बार कम से कम वे कुछ हद तक ज़िम्मेदारी स्वीकार कर रहे हैं, इसलिए इसे सुधार कहना होगा
और GCP की reliability समस्या तथा Google की customer support समस्या वास्तव में गंभीर हैं
सुधार: नीचे पता चला कि शुरुआती दो पैराग्राफ़ गलत तरीके से जोड़े गए थे और वह Railway नहीं बल्कि Railway के एक customer का मामला था. माफ़ करना, Railway!
हमारी company पहले एक hosting provider इस्तेमाल करती थी जो AWS के ऊपर कुछ अतिरिक्त guarantees देता था
अब AWS वही features सीधे देता है, इसलिए हमने plain AWS पर migration पूरा कर लिया
अफसोस की बात है कि इस वजह से हमें कल Azure पर emergency migration करना पड़ा
शुक्र है कि database Railway पर नहीं था, इसलिए कुछ घंटों में recovery हो गई
Railway जो simplicity देता था, वह सचमुच अच्छा था, लेकिन B2B enterprise app को उसकी infra पर चलाते रहने के लिए incidents और limitations बहुत ज़्यादा हो गए थे
दुखद दिन है :(
मैं service को बहुत अच्छी तरह नहीं जानता, तो क्या आपने किसी unique feature की वजह से चुना था या वह मूलतः virtual machine use case जैसा था?
अगर unique features की वजह से चुना था, तो बाहर निकलने वाला migration कितना मुश्किल था, यह भी जानना चाहूँगा
छोटे SaaS tools या internal products के लिए, अगर टीम AWS या किसी दूसरे IaaS provider को सीधे manage नहीं करना चाहती, तो अगला सबसे अच्छा विकल्प क्या होगा?
AWS जैसी चीज़ इस्तेमाल करने पर भी अगर आप कई availability zones में redundancy नहीं बनाते, तो कभी-कभी downtime होगा
और कई availability zones में redundancy बना लेने पर भी AWS पूरी तरह isolated architecture नहीं है, इसलिए कुछ services fail हो सकती हैं और downtime हो सकता है
इसलिए downtime स्वीकार करें और अपने लिए सबसे उपयुक्त tool इस्तेमाल करें. बस GitHub-स्तर की बेहद खराब स्थिति को छोड़कर
अगर आप downtime बिल्कुल स्वीकार नहीं कर सकते, तो उस स्तर का भरोसा पाने के लिए जहाँ downtime न होने की उम्मीद की जा सके, आपको कई million dollars और कई महीनों का काम चाहिए होगा
Netflix का Chaos Monkey और उस स्तर का infra शायद पर्याप्त होगा
कम से कम पूरी operational क्षमता वाले दो providers चाहिए
pay-as-you-go billing के बिना भी आप काफ़ी दूर तक जा सकते हैं
बड़े cloud providers ऐसी services देते हैं जो Railway की services से बस थोड़ा ही ज़्यादा कठिन हैं, और ज़रूरत बढ़ने पर आप उन्हें अधिक advanced features तक बढ़ा सकते हैं
feature, security, और availability को नियंत्रित करने वाले किसी third party को जोड़ने की ज़रूरत नहीं पड़ती
उदाहरण के लिए, इस timeline के अनुसार GCP ने 7 मिनट में response दिया
अगर आप Cloud Run इस्तेमाल कर रहे होते, तो downtime 7 घंटे से भी ज़्यादा कम हो सकता था, और अगर यह अज्ञात trigger किसी दूसरे customer activity या Railway के किसी अजीब behavior से जुड़ा था, तो शायद शुरुआत से outage होता ही नहीं
इसमें complexity भी है
Railway ने जिन complex infra हिस्सों को ठीक करने की बात की, उनमें से काफ़ी कुछ सिर्फ अपना अकाउंट इस्तेमाल करने पर ज़रूरी ही नहीं होता
वह code निश्चित रूप से उपयोगी काम करता होगा, लेकिन hosting provider के लिए उसमें ऐसे बहुत से moving parts हैं जो आम user के लिए ज़रूरी नहीं होते
इस outage ने सबको एक साथ गिराया, लेकिन अलग-अलग AWS users या bare metal users पर मूलतः इसका असर नहीं पड़ता
सबके लिए एक जैसी global optimum solution नहीं होती, लेकिन developers अक्सर deployment के कुछ steps बचाकर जो समय बचता है, उसके मुकाबले direct cost और किसी और के environment में काम करने की छिपी हुई cost को बहुत कम आँकते हैं
“19 मई 22:10 UTC - automated monitoring ने API health check failures पकड़े, on-call को पेज किया गया, और responders ने जाँच शुरू की”
“19 मई 22:20 UTC - Google Cloud ने automated action के हिस्से के रूप में Railway के production account को गलती से suspended state में डाल दिया”
अगर timestamps सही हैं, तो अकाउंट suspension से 10 मिनट पहले वाली error किस वजह से हुई?
सबसे सरल व्याख्या यह है कि दोनों में से किसी एक timestamp में गलती है, और अपने आप में यह कोई बड़ी बात नहीं
लेकिन अगर timestamps के बारे में पक्का भरोसा नहीं है, तो उनका एक-दूसरे से साफ टकराना और फिर भी उन्हें report में final facts की तरह डालना काफ़ी अजीब है
timeline section, जहाँ 22:10 दिया गया है, अपने आप में consistent है, और उसमें यह भी शामिल है
“19 मई 22:19 UTC - root cause identified: Google Cloud Platform suspended Railway का production account”
किसी घटना के होने से पहले root cause identify नहीं किया जा सकता
उदाहरण के लिए, किसी Google employee ने configuration गलत छेड़ दी हो और उससे ऐसा signal बना हो कि suspension चाहिए, जैसा पहले incidents में हुआ था, और suspension process में जाने में 10 मिनट लगे हों
या Railway के किसी customer ने कोई fraudulent या fraud-जैसी activity की हो, और Google system ने access restriction शुरू करने के बाद 10 मिनट तक यह तय किया हो कि suspension तक बढ़ाना है या नहीं
अगर approval flow में कोई इंसान शामिल था, तो यह और भी plausible है
लेकिन जाहिर है उस व्यक्ति ने इतना गहराई से नहीं देखा कि समझ पाता कि ऐसा नहीं करना चाहिए
GCP चलाने वाले किसी भी व्यक्ति के लिए यह चेतावनी होनी चाहिए
लगता है GCP बिना सोचे-समझे अकाउंट्स को इधर-उधर suspend करता रहता है
ऐसा लगता है जैसे production फैसले Gemini 3.1 Pro से करवाए जा रहे हों
TK का OCI में organizational culture को पूरी तरह बिगाड़ने का इतिहास रहा है, और सुना है GCP में भी कुछ वैसा ही हुआ
GCP और Google पूरी तरह अलग तरह से काम करने वाले संगठन हैं
सिर्फ नाम देखकर Google quality की उम्मीद नहीं करनी चाहिए
यह कुछ वैसा है जैसे Nokia, जो अब एक पुराना brand है जो सस्ते licensed products पर चिपका मिलता है. यह अतिशयोक्ति है, लेकिन सच्चाई से बहुत दूर नहीं
इतना ही नहीं, यह services को random तरीके से बंद करने और लगभग 6 महीने का migration period देने के लिए भी जाना जाता है
वहाँ बहुत से engineers के पास करने को कुछ खास नहीं होता, इसलिए वे internal users को उस service से निकालने में लगा दिए जाते हैं, लेकिन अधिकतर customers ऐसा नहीं कर सकते
एक शानदार लेख था जो किसी पूर्व GCP employee ने लिखा था, लेकिन अभी मिल नहीं रहा
अगर आप business को गंभीरता से लेते हैं, तो GCP से plague की तरह बचना चाहिए
सुधार: विडंबना यह है कि Gemini ने ही वह लेख ढूँढ दिया. पढ़ने लायक है: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
इसका नाम इतना बड़ा है कि HN front page के ऊपर तक पहुँच गया, और किसी न किसी मोड़ पर Google में कोई intervene करने वाला मिल सकता था
अगर यह मेरा बनाया कोई छोटा product होता, तो मेरे पास शायद कोई उपाय ही नहीं होता
असली product quality अच्छी है, इसलिए यह और भी दुखद है
यह आराम से नंबर 2 provider बन सकता था, लेकिन Azure बेहद unstable है और उसकी documentation भी कमजोर है
GCP का नंबर 3 होना काफी हद तक उसकी अपनी बनाई हुई स्थिति है
मेरा पूरी तरह अप्रमाणित आकलन यह है कि उसे Google की ढीली enterprise approach को ठीक करने के लिए disciplined adult की तरह लाया गया
जैसा यह incident दिखाता है, अभी भी बहुत काम बाकी है, लेकिन “serious” enterprise organization बनने के लिए शायद यह ज़रूरी रहा हो
हालाँकि इस प्रक्रिया में उसने Google के बाकी हिस्सों से टकराने वाली culture बनाई हो सकती है
फिर भी, क्या OCI में पहले से ऐसी culture थी जिसे नष्ट किया जा सके? इसके उलट यह संभव लगता है कि TK वही culture Google में लेकर आया हो
इन्हें कभी किसी महत्वपूर्ण काम के लिए इस्तेमाल नहीं करना चाहिए
Google Cloud ने ग्राहक अकाउंट्स को बुरी तरह बिगाड़ा हो, यह पहली बार नहीं है: https://cloud.google.com/blog/products/infrastructure/detail...
“Railway vendor selection की ज़िम्मेदारी लेता है, और अंततः यह फैसला भी हमारी ज़िम्मेदारी है. customers को इससे फर्क नहीं पड़ता कि outage Google की वजह से था या Railway की वजह से. customers के लिए दिखने वाला product हमारा है. आपका uptime हमारी ज़िम्मेदारी है, और हम इसे देते रहेंगे”
यह अच्छी बात है कि इसे सिर्फ PR भाषा की तरह नहीं, बल्कि सच में स्वीकार किया गया
GCP पर भरोसा करना Railway की ओर से architectural failure था, और इससे दिखता है कि वे इसे ठीक करने की कोशिश कर रहे हैं
क्या उन्हें यह पहले से देख लेना चाहिए था? हाँ. फिर भी, कभी न करने से देर से करना बेहतर है
“अंत में, हम Google Cloud services को data plane के hot path से हटाने और उन्हें केवल backup/failover use के लिए रखने की योजना बना रहे हैं”
बात काफ़ी स्पष्ट है
अब Google पर B2B service provider के रूप में भरोसा नहीं किया जा सकता
एक company का Meta OAuth app पूरी तरह unusable हो गया सिर्फ इसलिए कि developers में से एक के personal Facebook account को Meta ने बिना वजह block कर दिया
कई बार escalation की गई, लेकिन कहीं कोई सुनवाई नहीं हुई
Meta और भी खराब है क्योंकि account “personal” होना चाहिए
Business Manager होने पर भी उसमें जोड़े गए users, सभी personal Meta/Facebook accounts से बंधे रहते हैं
यह हास्यास्पद है
Google बार-बार साबित कर चुका है कि ठीक इसी तरह की समस्याओं के कारण उस पर service provider के रूप में भरोसा नहीं किया जा सकता
इसलिए उन्हें दर्जनों टुकड़ों में तोड़ देना चाहिए
अक्सर यह तभी पलटता है जब users सार्वजनिक रूप से गुस्सा जताते हैं और मामला फैल जाता है
Google हमेशा ऐसे बर्ताव करता रहा है जैसे paid customers के प्रति उसकी कोई ज़िम्मेदारी ही न हो
मेरे हिसाब से यही सबसे महत्वपूर्ण हिस्सा है
कोई cloud provider बिना वजह पूरा अकाउंट suspend नहीं करता