13 अगस्त को, हमें एक बड़ी सेवा बाधा का सामना करना पड़ा, जिसने कई Spaceship सेवाओं को प्रभावित किया।
इसका कारण RadiusDC: Phoenix डेटा सेंटर में कूलिंग सिस्टम की विफलता थी, जहां कुछ आवश्यक Spaceship संचालन होस्ट किए जाते हैं। इससे हमें ग्राहकों के इन्फ्रास्ट्रक्चर को अधिक गर्म होने और संभावित क्षति से बचाने के लिए सेवाओं को ऑफलाइन करना पड़ा।
घटना से प्रभावित सब कुछ अब बहाल कर दिया गया है, और हमारी टीमें यह सुनिश्चित करने के लिए सिस्टम की कड़ी निगरानी जारी रखे हुए हैं कि वे स्थिर बने रहें।
हम उन ग्राहकों पर पड़े प्रभाव के लिए गहराई से क्षमा चाहते हैं जो अपनी वेबसाइटों, ईमेल और अन्य ऑनलाइन सेवाओं के लिए हम पर निर्भर हैं। इससे हुई बाधा और इसके पीछे की परिस्थितियों को अत्यंत गंभीरता से लिया जा रहा है।
क्या हुआ
यह घटना तब शुरू हुई जब एक बड़े तूफान के कारण Phoenix डेटा सेंटर में कूलिंग सिस्टम विफल हो गए, जिससे हमारे इन्फ्रास्ट्रक्चर के आसपास का तापमान गंभीर स्तर तक पहुंच गया।
ऐसी परिस्थितियों में सिस्टम का संचालन जारी रखने से उपकरणों के अधिक गर्म होने और दीर्घकालिक तथा विनाशकारी क्षति होने का जोखिम था। सेवाओं को ऑफलाइन करने से काफी बाधा हुई, लेकिन हमारे ग्राहकों के इन्फ्रास्ट्रक्चर की सुरक्षा के लिए यह आवश्यक था।
कूलिंग सिस्टम के फिर से ऑनलाइन होने तक उपकरणों को ऑफलाइन रखने से रिकवरी शुरू होने से पहले तापमान को सुरक्षित स्तरों पर लौटने का समय भी मिला। इससे आगे और समस्याएं पैदा होने से बचने में मदद मिली, जो पहले से ही गंभीर घटना को और लंबा कर सकती थीं।
ग्राहक कैसे प्रभावित हुए
इस बाधा ने Shared, VPS, email forwarding और Spacemail सहित सेवाओं को प्रभावित किया। पूरी घटना के दौरान Spaceship.com ऑनलाइन रहा।
यहां बताया गया है कि इस स्थिति ने प्रमुख उत्पादों और सेवाओं को कैसे प्रभावित किया:
होस्टिंग संचालन
वेबसाइटों और होस्टिंग सेवाओं तक ग्राहकों की पहुंच प्रभावित हुई, जिसमें कई ग्राहकों की वेबसाइटें अनुपलब्ध थीं, धीमी थीं, या त्रुटियां दिखा रही थीं। इस घटना के दौरान उन्हें प्रोसेस करने वाली प्रणाली को ऑफलाइन किए जाने के बाद कुछ बिलिंग संचालन भी अनुपलब्ध हो गए थे।
EasyWP
EasyWP का Dashboard और ग्राहकों की वेबसाइटें बाधित हुईं। रिकवरी के दौरान, EasyWP.com और Dashboard बहाल होने के बाद भी कुछ ग्राहकों की वेबसाइटें अनुपलब्ध रहीं, जिनमें से कुछ में डेटाबेस कनेक्शन त्रुटियां दिखाई दे रही थीं।
Spacemail
ईमेल सेवाएं भी बाधित हुईं। प्रभावित ग्राहक ईमेल भेजने में असमर्थ थे, और संबंधित सर्वरों के ऑफलाइन रहने के दौरान आने वाले ईमेल वितरित नहीं किए जा सके।
महत्वपूर्ण बात यह है कि इसका मतलब यह नहीं था कि आने वाले संदेश अपने आप खो गए थे। जब कोई प्राप्त करने वाला सर्वर अस्थायी रूप से अनुपलब्ध होता है, तो मेल प्रदाता सामान्यतः डिलीवरी के लिए आगे भी प्रयास करते हैं। इसलिए संदेश पहुंचते, लेकिन सामान्य से देर से।
हमने सेवाओं को कैसे बहाल किया
RadiusDC ने यथाशीघ्र अपनी कूलिंग क्षमता बहाल करना शुरू कर दिया, जबकि अस्थायी चिलर लगाए गए और तापमान कम करने में मदद के लिए उन्हें डेटा सेंटर में हमारे क्षेत्र की ओर निर्देशित किया गया।
हमारी टीमों ने कूलिंग बहाल करने के लिए RadiusDC के साथ साइट पर लगातार काम किया। हमने सेवाओं को फिर से ऑनलाइन लाना तभी शुरू किया जब तापमान सुरक्षित परिचालन स्तरों पर लौट आया, और हमें विश्वास हो गया कि अधिक गर्म होने या दीर्घकालिक क्षति का कोई जोखिम नहीं है।
सुरक्षित परिचालन स्थितियां बहाल होने के बाद, हमने अपने इन्फ्रास्ट्रक्चर में नियंत्रित रिकवरी शुरू की। यह क्रमिक रूप से होना आवश्यक था, इसलिए ग्राहकों ने अलग-अलग सेवाओं को अलग-अलग समय पर वापस आते देखा।
सेवाओं को चरणों में क्यों बहाल किया गया
घटना के पैमाने का मतलब था कि हमारे प्लेटफ़ॉर्म के अलग-अलग हिस्से एक ही समय में बाधित हुए। हालांकि ग्राहक इन्हें अलग-अलग सेवाओं के रूप में अनुभव करते हैं, डेटा सेंटर की घटना ने उनमें से कई को उपलब्ध कराने वाले इन्फ्रास्ट्रक्चर को प्रभावित किया।
होस्टिंग और ईमेल जैसी सेवाएं तकनीक की कई परतों पर निर्भर करती हैं, जिनमें सर्वर, नेटवर्क, स्टोरेज और डेटाबेस शामिल हैं। उन्हें बहाल करने का मतलब था कि इन अलग-अलग तत्वों को सही क्रम में फिर से ऑनलाइन लाया जाए, न कि बस एक साथ सब कुछ फिर से चालू कर दिया जाए।
आगे क्या होगा
हम इस बाधा और हमारे ग्राहकों पर इसके प्रभाव को बहुत गंभीरता से लेते हैं।
हमारी टीमें हमारे सिस्टम को मजबूत करने और यह सुनिश्चित करने के लिए स्थिति की गहन समीक्षा कर रही हैं कि ऐसी घटनाएं फिर से न हों।
हम जो सीखेंगे उसके बारे में पूरी तरह पारदर्शी रहेंगे और जो कदम हम उठा रहे हैं, उनके साथ परिणाम भी आपके साथ साझा करेंगे।
सुधार: हमारा डेटा सेंटर ऑपरेटर RadiusDC है, PhoenixNAP नहीं, जैसा कि 13 अगस्त को X पर कई शुरुआती पोस्टों में उल्लेख किया गया था। PhoenixNAP इस घटना में शामिल नहीं है।
अपने विचार साझा करें