Microsoft 365 का वैश्विक आउटेज: क्या गड़बड़ी हुई और हर व्यवसाय को इससे क्या सीखना चाहिए

Microsoft 365 का वैश्विक आउटेज: क्या गड़बड़ी हुई और हर व्यवसाय को इससे क्या सीखना चाहिए

नेटवर्क-अपग्रेड की एक छिपी समस्या ने 74 देशों में ईमेल और सहयोग सेवाओं को ठप कर दिया। यहाँ जानें कि क्या हुआ, कौन प्रभावित हुआ, और अगले आउटेज के लिए एक व्यावहारिक योजना।

दो कार्यदिवसों तक, Microsoft के नेटवर्क के भीतर एक ही खराबी ने सरकारों, बैंकों, एयरलाइनों और शिपिंग कंपनियों के लिए सामान्य ईमेल को एक वैश्विक समस्या में बदल दिया। समाधान के कुछ ही घंटों के भीतर अधिकांश लोगों के लिए ईमेल सेवा बहाल हो गई थी, लेकिन वास्तविक सुधार और समाधान में बहुत अधिक समय लगेगा।

आज 14 नवंबर, 2026 है, और Microsoft ने अभी-अभी स्पष्ट किया है कि उसके दुनिया भर में हुए Microsoft 365 आउटेज का कारण क्या था। कंपनी का कहना है कि इसका कारण कोई साइबर हमला नहीं था और न ही यह AI या AI एजेंट्स से संबंधित था। घटना के बाद की पूरी रिपोर्ट (post-incident report) अभी आनी बाकी है। इस आउटेज का अभी अध्ययन करना उपयोगी है, जब विवरण बिल्कुल ताज़ा हैं, क्योंकि लगभग हर संगठन इसी प्रकार की साझा सेवा पर निर्भर करता है और कल उसे भी इन्हीं सवालों का सामना करना पड़ सकता है।

Microsoft के अनुसार क्या हुआ

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

शुरुआती अपडेट्स में दिखने वाले लक्षण का विवरण दिया गया था। एक प्रक्रिया जो स्थापित करने के लिए जिम्मेदार थी सुरक्षित कनेक्शन , अत्यधिक दबाव में आ गई, और प्रभावित सर्वरों ने अनुरोधों को प्रोसेस करना बंद कर दिया। 17:57 GMT पर, EX1550543 और MO1550821 के रूप में ट्रैक की गई घटनाओं को अभी भी सेवा में गिरावट के रूप में वर्गीकृत किया गया था, जिसका अगला अपडेट 20:00 GMT पर आना था।

यहाँ तीन चरणों (milestones) में भ्रमित होना आसान है, लेकिन वे एक ही बात नहीं हैं:

  1. मूल खराबी को ठीक करना।
  2. प्रत्येक ग्राहक के लिए सेवा बहाल करना।
  3. विलंबित संदेशों और अधूरे कार्यों के बैकलॉग को निपटाना।

पहला काम पूरा हो सकता है जबकि तीसरे में अभी भी कई दिन लग सकते हैं।

बहाली में इतना समय क्यों लगा

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

Microsoft ने कहा कि उसने प्रत्येक चरण में स्थिरता की जाँच करते हुए धीरे-धीरे सेवा बहाल की। यह संतुलन (trade-off) बताता है कि कुछ क्षेत्रों में दूसरों की तुलना में घंटों बाद बहाली क्यों हुई।

कौन प्रभावित हुआ, और कैसे

Downdetector ने 74 देशों और क्षेत्रों में प्रभावित उपयोगकर्ताओं को दर्ज किया। यह दर्शाता है कि आउटेज कितना व्यापक था, हालांकि ऐसी रिपोर्टें प्रभावित खातों की सटीक संख्या नहीं देती हैं। यह व्यवधान गुरुवार को अमेरिका (Americas) में शुरू हुआ और शुक्रवार को एशिया-प्रशांत और यूरोप में जारी रहा। अधिक उपयोगी सबक यह है कि इसने विभिन्न संगठनों को कितने अलग-अलग तरीकों से प्रभावित किया।

  • संयुक्त राज्य अमेरिका: हाउस ऑफ रिप्रेजेंटेटिव्स (House of Representatives) ने कहा कि उसके उपयोगकर्ता प्रभावित हुए थे। इलेक्ट्रिक ट्रक निर्माता Workhorse Group ने आउटेज से हुए व्यावसायिक व्यवधान का हवाला देते हुए अपने त्रैमासिक परिणामों को 12 नवंबर से बढ़ाकर 16 नवंबर कर दिया।
  • यूरोप: Euronext ने चेतावनी दी कि ईमेल में देरी हो सकती है, जबकि इसके प्रतिभूति (securities) सिस्टम सामान्य रूप से चलते रहे। इसकी Corporate Actions और Listing टीमें ईमेल प्राप्त नहीं कर सकीं, इसलिए सूचीबद्ध कंपनियों को तत्काल मामलों के लिए फोन करने को कहा गया।
  • एशिया: जापान सरकार ने अपने सूचना बुनियादी ढांचे (information infrastructure) में व्यवधान की सूचना दी, और सिंगापुर की Government Technology Agency ने सरकारी ईमेल में समस्याओं की सूचना दी। Intellectual Property Office of Singapore ने 13 नवंबर को उन निर्दिष्ट कार्यों के लिए एक बहिष्कृत दिन (excluded day) घोषित किया जिनकी अंतिम तिथि उस दिन थी। भारत में, IndiGo और Akasa Air ने ईमेल सहायता में व्यवधान की सूचना दी, जबकि Air India ने कहा कि उड़ान संचालन अप्रभावित रहा। थाईलैंड के Krungthai Bank ने तत्काल पूछताछ को फोन सहायता पर भेज दिया।
  • ऑस्ट्रेलिया: कृषि विभाग ने निरीक्षण अनुरोधों, बुकिंग पुष्टिकरणों और आयात से संबंधित संदेशों में समस्याओं की सूचना दी, साथ ही कुछ सिस्टम संचारों में लगभग 45 से 60 मिनट की देरी हुई। ग्राहक अभी भी इसके Biosecurity Portal के माध्यम से निरीक्षण का प्रबंधन कर सकते थे।
  • शिपिंग: Maersk ने चेतावनी दी कि सूचनाओं और ईमेल्स में देरी हो सकती है, तत्काल प्रश्नों को फोन द्वारा स्थानीय कार्यालयों में भेजा, और ग्राहकों से कहा कि वे आउटेज से संबंधित असामान्य संदेशों की पुष्टि अपने स्थानीय प्रतिनिधि से करें।
  • सार्वजनिक सेवाएं: ऑस्ट्रेलिया के Bureau of Meteorology ने कहा कि पूर्वानुमान और चेतावनियाँ उसकी वेबसाइट और ऐप पर उपलब्ध रहीं। यूके की एक काउंसिल ने बताया कि ईमेल-आधारित साइन-इन कुछ सेवा पोर्टल्स तक पहुँच को रोक रहा था, जबकि फोन और फॉर्म काम करते रहे।

इस पैटर्न पर ध्यान दें। अधिकांश मामलों में मुख्य संचालन चलता रहा: ट्रेडिंग, उड़ानें, कार्गो, मौसम पूर्वानुमान। जो चीज़ ठप हुई, वह थी इसके इर्द-गिर्द का संचार: पुष्टिकरण, स्वीकृतियां, सहायता संबंधी उत्तर और साइन-इन कोड। और जहाँ लॉग इन करने के लिए ईमेल का उपयोग किया जाता था, उसके बंद होने से लोग पूरी तरह से बाहर हो सकते थे।

AI सहायक भी इसकी चपेट में आए

Microsoft 365 से डेटा लेने वाले AI टूल्स भी लड़खड़ा गए। Anthropic ने अपने Microsoft 365 कनेक्टर के माध्यम से मेल, कैलेंडर और सर्च में तथा Claude for Outlook में विफलताओं की सूचना दी। शुक्रवार को 15:40 GMT पर इसने इस घटना को निगरानी में डाल दिया और बहाली के संकेत दिए, हालांकि कुछ SharePoint सर्च में अभी भी त्रुटियां आ रही थीं।

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

आउटेज के बाद होने वाले घोटालों से सावधान रहें

यूके के National Cyber Security Centre (NCSC) ने लोगों और संगठनों से सतर्क रहने का आग्रह किया है। अपराधी अक्सर एक बड़े आउटेज का इस्तेमाल ढाल के रूप में करते हैं, और Microsoft, IT सहायता या किसी विश्वसनीय कंपनी होने का नाटक करते हैं। "अपने खाते को ठीक करने" के बारे में लिंक वाले अप्रत्याशित कॉल, ईमेल और संदेशों को संदेह की दृष्टि से देखें, और उनकी पुष्टि उस माध्यम से करें जिस पर आप पहले से भरोसा करते हैं।

एक व्यावहारिक योजना: Rohit Acme में क्या करता है

Rohit तीन टाइम ज़ोन में कार्यालयों वाली एक मध्यम आकार की ट्रेडिंग कंपनी Acme के लिए IT का संचालन करता है। आउटेज के दौरान उसके कर्मचारी ईमेल द्वारा सप्लायर पुष्टिकरण प्राप्त नहीं कर सके, और एक कार्यालय ऐसे पोर्टल पर साइन इन नहीं कर सका जो ईमेल द्वारा लॉगिन कोड भेजता है। यहाँ वह योजना दी गई है जो वह अगली सुबह लिखता है।

चरण 1: उस काम की सूची बनाएं जो जारी रहना चाहिए

हर चीज़ के लिए बैकअप की आवश्यकता नहीं होती। Rohit उन मुट्ठी भर कार्यों को चुनता है जो एक दिन के लिए भी नहीं रुक सकते: ग्राहक ऑर्डर, सप्लायर पुष्टिकरण, पेरोल स्वीकृतियां और तत्काल ग्राहक सहायता। प्रत्येक कार्य के लिए वह लिखता है कि यह किन प्रणालियों पर निर्भर है, जिसमें छिपी हुई प्रणालियां जैसे कि ईमेल-आधारित साइन-इन कोड भी शामिल हैं।

चरण 2: सिंगल पॉइंट्स ऑफ फेल्योर का पता लगाएं

वह ऐसी किसी भी चीज़ की तलाश करता है जो केवल तभी काम करती है जब Microsoft 365 काम करता है। आपातकालीन संपर्क सूची एक साझा मेलबॉक्स में संग्रहीत थी, इसलिए वह पहुंच से बाहर हो जाती। दो आंतरिक उपकरण केवल ईमेल द्वारा लॉगिन कोड भेजते थे। इन्हें सुधार सूची में सबसे ऊपर रखा जाता है।

चरण 3: एक ऐसा फ़ॉलबैक सेट करें जो एक ही विफलता को साझा न करे

Rohit प्रमुख संपर्कों की एक ऑफ़लाइन या मुद्रित प्रति रखता है, ईमेल-आधारित उपकरणों में एक दूसरा साइन-इन तरीका (जैसे एक ऑथेंटिकेटर ऐप) जोड़ता है, और एक ऐसा फोन नंबर तय करता है जिस पर ग्राहक तत्काल मामलों के लिए कॉल कर सकते हैं। वह जाँचता है कि क्या फ़ॉलबैक वास्तव में अलग है: एक बैकअप चैट टूल जो उसी Microsoft खाते से साइन इन करता है, उसी समय विफल हो जाएगा।

चरण 4: क्षेत्रीय हैंडओवर और भागीदारों के लिए योजना बनाएं

चूंकि Acme विभिन्न टाइम ज़ोन के बीच काम सौंपता है, इसलिए वह एक सरल नियम लिखता है: यदि कोई हैंडओवर संदेश नहीं आता है, तो प्राप्त करने वाली टीम कार्रवाई करने से पहले भेजने वाली टीम को कॉल करती है। वह प्रमुख आपूर्तिकर्ताओं से भी पूछता है कि यदि ईमेल विफल हो जाता है तो वे Acme तक कैसे पहुंचेंगे, क्योंकि किसी भागीदार का सिस्टम आपके अपने सिस्टम की तुलना में बाद में बहाल हो सकता है।

चरण 5: बहाली के बाद मिलान करें

जब ईमेल सेवा बहाल होती है, तो विलंबित संदेश फोन द्वारा पहले ही संभाले जा चुके निर्देशों के साथ आते हैं। Rohit प्रत्येक टीम से आउटेज के दौरान फोन निर्देशों को लॉग करने के लिए कहता है, फिर देर से आए ईमेल्स के साथ उनका मिलान करता है ताकि कोई भी काम दोबारा न हो या छूट न जाए।

चरण 6: जो हुआ उसे दर्ज करें

जब तक यादें ताज़ा हैं, वह यह रिकॉर्ड करता है कि क्या रुका, किन वैकल्पिक उपायों (workarounds) ने मदद की और कहाँ कर्मचारियों या ग्राहकों को बिना जानकारी के छोड़ दिया गया था। वह रिकॉर्ड साल में दो बार किए जाने वाले एक छोटे परीक्षण का आधार बनता है।

अंतिम रिपोर्ट को किन सवालों के जवाब देने चाहिए

Microsoft की पूरी समीक्षा में यह स्पष्ट करना होगा कि अपग्रेड की मूल समस्या कब उत्पन्न हुई थी, किस बदलाव ने इसे उजागर किया, परीक्षण में यह क्यों छूट गई और रिकवरी कठिन क्यों थी। ग्राहक यह भी जानना चाहेंगे कि कौन से वर्कफ़्लो कब और कैसे विफल हुए, न कि केवल घटना का एक व्यापक समय-अंतराल। सबसे उपयोगी रिपोर्ट प्रत्येक कारण को परीक्षण, परिनियोजन नियंत्रण (deployment controls), निगरानी और रिकवरी चरणों में एक ठोस सुधार से जोड़ेगी।

निष्कर्ष

Microsoft 365 आउटेज कोई हमला नहीं था, लेकिन कई संगठनों के लिए इसने किसी हमले जैसा ही नुकसान पहुँचाया। मुख्य संचालन काफी हद तक चलता रहा; उसके इर्द-गिर्द का संचार ठप हो गया। हम बाकी लोगों के लिए उपाय हर सिस्टम की दोहरी प्रति बनाना नहीं है। उपाय यह जानना है कि कौन सा काम जारी रहना चाहिए, यह पता लगाना है कि वह गुप्त रूप से किस पर निर्भर है, और एक ऐसे फ़ॉलबैक का परीक्षण करना है जो उसी कारण से विफल न हो।

लाभ

  • स्पष्ट रूप से दिखाता है कि कौन से व्यावसायिक कार्य ईमेल और साइन-इन कोड पर निर्भर करते हैं।
  • फोन लाइन और ऑफ़लाइन संपर्क सूचियों जैसे सस्ते, व्यावहारिक फ़ॉलबैक को प्रोत्साहित करता है।
  • टीमों को टाइम-ज़ोन हैंडओवर और भागीदार संचार की योजना बनाने के लिए प्रेरित करता है।
  • संगठनों को बहाली के बाद AI सहायकों सहित वास्तविक कार्यों का परीक्षण करने की याद दिलाता है।
  • आपातकालीन संचार चैनलों की सुरक्षा की समीक्षा करने का एक कारण देता है।

कमियां

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

सावधानी

यह लेख शैक्षिक उद्देश्यों के लिए है। कंपनी का नाम Acme और उदाहरण परिदृश्य केवल प्लेसहोल्डर हैं और इन्हें आपकी अपनी स्थिति के अनुसार बदला जाना चाहिए। यहाँ दिए गए तथ्य लेखन के समय Microsoft और उल्लिखित संगठनों के बयानों का संक्षेप हैं, और पूरी पोस्ट-इंसिडेंट रिपोर्ट प्रकाशित होने के बाद कुछ विवरण बदल सकते हैं। निर्णयों के लिए इन बिंदुओं पर भरोसा करने से पहले आधिकारिक स्रोतों से वर्तमान स्थिति और मार्गदर्शन की पुष्टि करें।

अक्सर पूछे जाने वाले प्रश्न

  • नवंबर 2026 में Microsoft 365 आउटेज का क्या कारण था? — Microsoft का कहना है कि पहले के एक नेटवर्क-क्षमता अपग्रेड के दौरान आई समस्या बाद के एक नेटवर्क बदलाव के कारण उजागर हुई थी।
  • क्या Microsoft 365 आउटेज एक साइबर हमला था? — नहीं, Microsoft ने कहा कि यह घटना साइबर गतिविधि, AI या AI एजेंट्स से संबंधित नहीं थी।
  • आउटेज से कितने देश प्रभावित हुए? — Downdetector ने 74 देशों और क्षेत्रों में प्रभावित उपयोगकर्ताओं को दर्ज किया, हालांकि यह प्रभावित खातों की पूरी संख्या नहीं है।
  • क्या आउटेज ने उड़ानों, ट्रेडिंग या शिपिंग को रोक दिया? — उद्धृत नोटिस संचार में व्यवधान का वर्णन करते हैं; Air India ने कहा कि उड़ानें अप्रभावित रहीं, और Euronext ने कहा कि इसके प्रतिभूति सिस्टम सामान्य रूप से चले।
  • सुधार के बाद बहाली में इतना समय क्यों लगा? — सेवाओं को धीरे-धीरे बहाल किया जाना था ताकि लौटने वाले उपयोगकर्ता और जमा हुए अनुरोध ठीक हो रहे सर्वरों पर अत्यधिक दबाव न डालें।
  • क्या AI सहायक आउटेज से प्रभावित हुए थे? — हाँ, Anthropic के Microsoft 365 कनेक्टर और Claude for Outlook जैसे टूल्स ने ठीक होने से पहले विफलताओं की सूचना दी।
  • कोई व्यवसाय अगले क्लाउड आउटेज के लिए कैसे तैयारी कर सकता है? — महत्वपूर्ण कार्यों की सूची बनाएं, उनकी निर्भरताओं का पता लगाएं, ऐसे फ़ॉलबैक स्थापित करें जो एक ही विफलता को साझा न करें, और नियमित रूप से उनका परीक्षण करें।
  • आउटेज के बाद मुझे किन घोटालों से सावधान रहना चाहिए? — Microsoft या IT सहायता होने का दावा करने वाले अप्रत्याशित कॉल, ईमेल या संदेशों से सावधान रहें, और किसी विश्वसनीय माध्यम से उनकी पुष्टि करें।

टैग्स

#microsoft365 #outage #businesscontinuity #itresilience #cloudoutage #disasterrecovery #incidentresponse #cybersecurity #phishingawareness #itoperations

Free field guide

Prompt-Injection Defense Checklist

The controls that actually reduce the blast radius when your app feeds untrusted text to an LLM. Enter your email — you'll get the PDF instantly, plus new posts on AI, security & Linux.