27 अगस्त 2026 के शुरुआती घंटों में, Proton को एक व्यापक सेवा बाधा का सामना करना पड़ा, जिसने कई उपयोगकर्ताओं की सेवाओं को प्रभावित किया। मूल कारण हमारे फ्रैंकफर्ट डेटासेंटर में कूलिंग सिस्टम की पूर्ण विफलता थी। हालांकि Proton के सभी सिस्टम रिडंडेंट हैं और हमारे पास पूर्ण डेटा सेंटर विफलता झेलने की पर्याप्त क्षमता है, फिर भी कुछ ही परिदृश्य ऐसे हैं जिनमें फेलओवर में ज़्यादा समय लग सकता है और उपयोगकर्ताओं के सामने बाधा आ सकती है।

यहां इस बात की टाइमलाइन दी गई है कि क्या हुआ, घटना के दौरान हमने क्या विकल्प चुने और क्यों, और इसे कैसे सुलझाया गया।

टाइमलाइन

बुधवार, 26 अगस्त को रात 11 बजे के ठीक बाद (मध्य यूरोपीय समय के अनुसार), हमारे फ्रैंकफर्ट डेटासेंटर के मुख्य कमरे में कूलिंग सिस्टम में विफलता आ गई। रात करीब 11:15 बजे, तापमान लगभग 21.8°C (सामान्य तापमान) से बढ़कर आधे घंटे से भी कम समय में 51.9°C हो गया, और कुछ मापन प्रोब ने कमरे में हवा का तापमान 60°C बताया। तापमान बढ़ने के साथ, सुविधा के भीतर मौजूद सर्वर और नेटवर्किंग उपकरण एक-एक करके बंद होने लगे।

उपयोगकर्ताओं को प्रभावित करने वाली घटना 27 अगस्त की आधी रात के करीब शुरू हुई, जब विफलताएं इस स्तर तक बढ़ गईं कि अहम रिडंडेंसी खो गई। ऐसा तब हुआ जब एक अहम रैक पर मौजूद मुख्य और बैकअप नेटवर्क स्विच दोनों विफल हो गए, और इस रैक में दुर्भाग्य से कई मुख्य डेटाबेस कॉपियां मौजूद थीं। हालांकि लगभग सभी Proton सिस्टम रिडंडेंट हैं और अपने-आप/तुरंत फेलओवर हो जाएंगे, मुख्य डेटाबेस का फेलओवर बिना किसी इंसानी निगरानी के अपने-आप नहीं किया जाता।

हमें यह नियंत्रण इसलिए रखना होता है ताकि तथाकथित “split brain” स्थितियों से बचा जा सके, जिनमें मुख्य डेटाबेस की अस्थायी अनुपलब्धता का मतलब है कि रेप्लिका कॉपियां कुछ अपडेट खो देती हैं और अन-सिंक हो जाती हैं, जिन्हें बाद में मिलाना मुश्किल हो सकता है। इसके अलावा, जब मुख्य डेटाबेस का फेलओवर होता है, तो लैटेंसी और परफॉर्मेंस की वजह से उसी डेटासेंटर में मौजूद किसी रेप्लिका पर फेलओवर करना मानक प्रक्रिया होती है। लेकिन समस्या की खास प्रकृति के चलते ऐसा करना अनुचित हो सकता था, क्योंकि हम ऐसी चीज़ पर फेलओवर कर सकते थे जो भी बंद हो जाती।

फैसले

इस स्थिति में, Proton के ऑन-कॉल इंजीनियरों को अत्यधिक दबाव में काम करते हुए कुछ अहम फैसले लेने थे।

  • क्या वे सेवा को वापस ऑनलाइन लाने को प्राथमिकता दें, या कूलिंग की समस्या दूर करने और डेटासेंटर के अंदर मौजूद हार्डवेयर को बचाने को?
  • हम उसी बिल्डिंग यानी फ्रैंकफर्ट के भीतर मौजूद रेप्लिका पर फेलओवर करें (जल्दी और कम बाधा वाला विकल्प, लेकिन अगर गर्मी को काबू नहीं किया जा सका तो शायद अस्थायी समाधान), या ज़्यूरिख पर फेलओवर करें?
  • हम सब कुछ फेलओवर करें या सिर्फ जो उस वक्त बंद है? पूर्ण डेटा सेंटर विफलता के लिए हमारे पास योजनाएं मौजूद हैं, जिनमें चीजें पूरी तरह और ज़्यादातर अपने-आप काफी जल्दी फेलओवर हो जाती हैं, लेकिन यादृच्छिक सर्वर एक-एक करके बंद होने वाली स्थिति को हमारा फेलओवर लॉजिक ठीक से हैंडल नहीं कर पाता।

आखिरकार, तापमान के बढ़ने की रफ्तार ने हमें सेवाओं को वापस ऑनलाइन लाने की बजाय हार्डवेयर बचाने को प्राथमिकता देने पर मजबूर किया। यह ऐसा विकल्प नहीं है जिसे आम तौर पर चुनना पड़ता हो, क्योंकि कूलिंग सिस्टम आम तौर पर रिडंडेंट होते हैं, और कूलिंग का पूरी तरह खो जाना काफी दुर्लभ है, जिसका मतलब है कि तापमान के चिंताजनक स्तर तक पहुंचने से पहले काफी समय मिल जाता है। हाल के सालों में AI के लिए ज़्यादा पावर वाले CPU और GPU के साथ सर्वर पावर डेंसिटी में भारी वृद्धि ने इस समस्या को और बढ़ा दिया है। नतीजतन, जिस चीज़ को चिंताजनक स्तर तक पहुंचने में पहले 3-4 घंटे लगते थे, वो 20 मिनट में ही चिंताजनक हो गई।

इसलिए ऑन-कॉल टीम ने अपना ध्यान ऑन-साइट डेटासेंटर ऑपरेशन टीम से संपर्क करके कूलिंग रीस्टोर करने पर लगाया, साथ ही जितने सर्वर हो सकें बंद करके उन्हें बचाया। चालू AI बूम से जुड़ी सर्वर उपकरणों की कमी के चलते, इनमें से बहुत से उपकरण खो जाएं तो उन्हें कम समय में बदलना संभव नहीं था। इसलिए उन्हें बचाना प्राथमिकता होनी ही थी, चाहे इसकी कीमत डाउनटाइम बढ़ने की हो।

00:45 CEST तक, हम कूलिंग रीस्टोर करने में सफल रहे और सुविधा के भीतर तापमान गिरना शुरू हो गया, और ऑन-कॉल टीम ने सेवा रिकवरी पर ध्यान देना शुरू किया। इस स्थिति में, हमने फैसला किया कि अगर कोई रेप्लिका जीवित था तो मुख्य डेटाबेस को फ्रैंकफर्ट पर फेलओवर किया जाए, और जिन मामलों में फ्रैंकफर्ट में कोई रेप्लिका जीवित नहीं था, वहां ज़्यूरिख पर फेलओवर किया जाए, ताकि हमारे ट्रैफिक फ्लो को ज़्यादा बदलकर नई अस्थिरता पैदा न हो। यह विकल्प इसलिए चुना गया, क्योंकि हमें लगा कि अब जब कूलिंग काबू में थी, फ्रैंकफर्ट को वापस ऑनलाइन लाना काफी आसान होगा और ज़्यूरिख पर स्विच करने से जल्दी होगा।

दुर्भाग्य से, ऐसा नहीं हुआ। घटना के दौरान, फ्रैंकफर्ट इंफ्रास्ट्रक्चर में कई नेटवर्क कार्ड 105C तापमान तक पहुंच गए (सामान्य ऑपरेटिंग तापमान 45C है), जो एक विशेष तापमान सुरक्षा मोड को सक्रिय कर देता है और नेटवर्क कार्डों को कोल्ड सिस्टम रीसेट होने तक अक्षम कर देता है। हमारी सुरक्षा नीति अपने सिस्टम के आउट-ऑफ-बैंड कंट्रोलर को एक्सेस करने की क्षमता को सीमित करती है, जिसकी वजह से हमें रिकवरी में मदद के लिए अतिरिक्त स्टाफ को जगाना पड़ा।

01:30 CEST तक, हम ज़्यादातर सेवाओं को ज़्यादातर उपयोगकर्ताओं के लिए वापस ऑनलाइन ला सके। लेकिन कुछ कम अहम सिस्टम, जैसे पुश सूचनाएं या पेमेंट प्रोसेसिंग, करीब 02:00 CEST तक रिकवर नहीं हो पाए।

जैसा हमने शुरुआती घटना रिपोर्ट में बताया था, कोई ईमेल खो नहीं गया, लेकिन घटना के दौरान दोनों दिशाओं में ईमेल डिलीवरी में देरी हुई।

उपयोगकर्ताओं के सामने वाली सेवाएं पूरी तरह रीस्टोर हो चुकी थीं, लेकिन हमारे इंजीनियरों की रात यहीं खत्म नहीं हुई, खासकर डेटाबेस टीम की। हमारा इंफ्रास्ट्रक्चर एक बेहद असामान्य स्थिति में रह गया, जहां कुछ मुख्य डेटाबेस ज़्यूरिख में और बाकी फ्रैंकफर्ट में थे, और उनमें से कई कम रिडंडेंसी और/या कम परफॉर्मेंस के साथ चल रहे थे। हमारी टीम ने इनमें सबसे ज़रूरी समस्याओं को सुलझाने के लिए रातभर काम किया, और पूरी रिडंडेंसी रीस्टोर करने का काम 27 अगस्त के दिनभर चलता रहा।

हालांकि हम लगभग पूरे इंफ्रास्ट्रक्चर को बचा लेने में सफल रहे, कुछ सर्वर दुर्भाग्य से गर्मी से खराब हो गए, और हमें अभी नहीं पता कि गर्मी की इस घटना का बचे हुए उपकरणों की उम्र पर असर पड़ेगा या नहीं।

मूल कारण और अगले कदम

27 अगस्त को आगे की गई जांच ने कूलिंग विफलता का मूल कारण दोनों रिडंडेंट एयर कंप्रेसर पर एयर फिल्टर बदलने तक ट्रेस किया, जो कूलिंग सिस्टम को पावर देते हैं। दुर्भाग्य से, डेटासेंटर ऑपरेटर ने यह काम आधी रात को, बिना पहले से सूचित किए किया, और कूलिंग विफल होने पर उसे बताने में भी चूक गया, जिससे हमारे पास जवाब देने का समय बेहद कम हो गया। इस घटना के दोबारा होने से रोकने के लिए हम ऑपरेटर के साथ मिलकर काम कर रहे हैं।

लेकिन, हमारे मौजूदा डेटाबेस इंफ्रास्ट्रक्चर की एक ज्ञात सीमा यह भी है कि इस तरह की सेवा बाधा से सामान्य से लंबी रिकवरी प्रक्रिया हो सकती है। इस घटना तक ले जाने वाले कार्यक्रमों की श्रृंखला बेहद असंभाव्य थी, फिर भी वो घट गई।

इस विफलता मोड को दूर करने के लिए ज़रूरी डेटाबेस रेज़िलिएंस का काम पहले से चल रहा है और साल के अंत तक पूरा करने का प्लैन बना हुआ है। नए डेटासेंटर स्पेस समेत अतिरिक्त इंफ्रास्ट्रक्चर क्षमता को भी अभी चालू किया जा रहा है और उम्मीद है कि वो अगले कुछ हफ्तों में उपलब्ध हो जाएगा, जिससे हमारी सिंगल साइट निर्भरता और कम होगी।

दुर्भाग्य से, यह घटना उन सुधारों के पूरी तरह लागू होने से पहले हो गई। हम अभी समीक्षा कर रहे हैं कि अहम डेटाबेस इंफ्रास्ट्रक्चर में बदलाव के लिए ज़रूरी सावधानी बरतते हुए बाकी काम को कहां सुरक्षित तरीके से तेज किया जा सकता है।

हम समझते हैं कि हमारे उपयोगकर्ता Proton से बेहद ऊंचे भरोसेमंद स्तर की उम्मीद रखते हैं, और इस घटना ने यह काम पूरा करने और अपने रेज़िलिएंस स्टैंडर्ड बढ़ाते रहने के महत्व को और मजबूत किया है। जिन सभी उपयोगकर्ताओं को इसका सामना करना पड़ा, हम उन सभी से फिर से, बिना किसी शर्त के, क्षमा चाहते हैं।