ट्राफिक अन्तर्गत माइक्रोसफ्टको आउटलुक रिकभरी असफल भइरह्यो

यो भिडियोले के समेट्छ

• प्रत्येक कार्यको ब्याकइन्ड निर्भरता जाँच गर्नुहोस्: अधिकांश मुख्य Teams कार्यक्षमता र प्रत्यक्ष SharePoint फाइल पहुँच कार्यात्मक रह्यो, जबकि Exchange-निर्भर सुविधाहरू बिग्रिएका थिए।
• माइक्रोसफ्टले रिपोर्ट गर्यो कि फर्काइएका सर्भरहरू ट्राफिक पुग्दा फेरि अनुत्तरदायी हुन सक्छन्; यसको स्वास्थ्य-प्रक्रिया-घटकको व्याख्या एक परिकल्पना नै रह्यो।
• विस्तारित अठ्चालीस-घण्टा इमेल टाइमआउट क्यु र ब्याकलॉग प्रोसेसिङको क्रममा ढिलाइ भएको मेल सुरक्षित राख्नको लागि थियो। यो कुनै मर्मतको समयसीमा वा विश्वव्यापी डेलिभरी ग्यारेन्टी थिएन।
• साधारण Graph थ्रोटलिंग मार्गदर्शनले Retry-After र एक्सपोनेन्सियल ब्याकअफलाई सम्मान गर्न सिफारिस गर्दछ जब त्यो हेडर अनुपस्थित हुन्छ; यसले यो घटनाको निदान वा मर्मत गर्दैन।

अनुवादित ट्रान्सक्रिप्ट

मूल अंग्रेजी कथाबाट अनुवादित। उपलब्ध अडियो र क्याप्सनहरू YouTube द्वारा नियन्त्रित हुन्छन्।

फर्काइएका सर्भरहरू किन फेरि असफल भए?

0:00 माइक्रोसफ्टले मेल सर्भरहरू सेवामा फर्कायो। ट्राफिक फर्कदा तिनीहरू फेरि प्रतिक्रियाविहीन हुन सक्थे। यहाँ विकासकर्ता फलो-अप छ। यस भिडियोमा, रिकभरी किन असफल भइरह्यो? र तपाईंको एपका कुन भागहरू अझै काम गरिरहेका थिए? माइक्रोसफ्टले ढिलाइ भएको इमेललाई अठ्चालीस घण्टा पनि दियो। त्यसले वास्तवमा तपाईंलाई के दिन्छ? आज शुक्रबार, नोभेम्बर तेह्र तारिख हो, र यो The Daily Diff हो।

0:18 Exchange Online माइक्रोसफ्टको होस्ट गरिएको इमेल सेवा हो, र अन्य माइक्रोसफ्ट तीन

कुन सुविधाहरू Exchange मा निर्भर थिए?

0:22 सट्ठी-पाँच सुविधाहरू यसमा निर्भर छन्। यहाँ माइक्रोसफ्टको स्थिति पृष्ठबाट उपयोगी भिन्नता छ। Teams कल र समूह च्याटहरू प्रायः काम गरे। क्यालेन्डर सुविधाहरू र मेलबक्स डेटाको लागि अनुरोधहरू असफल हुन सक्थे। तपाईंको अनुप्रयोगले वास्तवमा प्रयोग गर्ने निर्भरता जाँच गर्नुहोस्। यसको मतलब क्यालेन्डरले सहयोग गर्न अस्वीकार गर्दा पनि बैठक अझै हुन सक्छ। SharePoint मा फाइलहरूमा सीधा पहुँच पनि कार्यात्मक रह्यो, जबकि केही साझेदारी सुविधाहरू प्रभावित भए।

0:42 विन्डोमा रहेको लोगोले तपाईंको अर्को क्लिकलाई कुन ब्याकइन्ड चाहिन्छ भन्ने बारे धेरै कम बताउँछ। अवरोध बिहीबार सुरु भयो, माइक्रोसफ्टले सुरुमा अमेरिकामा मेलबक्स पहुँचको अनुसन्धान गर्दै थियो। त्यसपछि यसले पुष्टि गर्यो कि कुनै पनि क्षेत्रका प्रयोगकर्ताहरू प्रभावित हुन सक्छन्। CNN ले बैंक, सरकार र अदालतहरूमा समस्या रिपोर्ट गर्यो। हराइरहेको इमेल असुविधाजनक हुन्छ जबसम्म कसैको वास्तविक काम त्यसको आगमनमा निर्भर हुँदैन। माइक्रोसफ्टको प्रारम्भिक व्याख्या उपलब्ध सर्भरहरूको कमी थियो।

हराइरहेको क्षमताले सेवालाई कसरी ओभरलोड गर्छ?

1:06 ती मेसिनहरूले ह्यान्डल गर्नुपर्ने कामले बाँकी रहेको पूर्वाधारलाई दबाब दियो। तपाईंले साधारण मागले पनि सेवालाई ओभरलोड गर्न सक्नुहुन्छ जब यसको क्षमता हराउँछ। कसैले अचानक इमेल पठाउने उत्कटता फेला नपारे पनि क्यु लामो हुन्छ। क्यु लामो हुन्छ। कम्पनीले त्यसपछि स्वचालित स्वास्थ्य जाँचहरूको अनुसन्धान गर्यो। यी जाँचहरूले सर्भरले काम लिन सक्छ कि सक्दैन भनेर निर्णय गर्न मद्दत गर्छन्। माइक्रोसफ्टले सर्भर स्वास्थ्य प्रक्रिया गर्ने एक घटक संलग्न हुन सक्ने बताएको थियो। त्यो अनुसन्धान अझै जारी रहेको परिकल्पना हो।

1:29 ती सर्भरहरू सुरुमा किन अनुपलब्ध भए भनेर ठ्याक्कै व्याख्या गर्ने कुनै अन्तिम घटना रिपोर्ट छैन। अद्यावधिकहरूले अन-कल शिफ्टलाई बिहानको खानामा क्रमशः

माइक्रोसफ्टले पहिले के प्रयास गर्यो?

1:37 कम रुचि देखाएको जस्तो लाग्छ। डिप्लोयमेन्टहरू रोक्नुहोस्। ट्राफिक सार्नुहोस्। सर्भरहरू पुन: सुरु गर्नुहोस्। माइक्रोसफ्टले एक वैकल्पिक स्वास्थ्य जाँचलाई प्रमाणित गर्यो जसले एक उपसेटलाई फिर्ता ल्यायो, र अनुत्तरदायी मेसिनहरू पत्ता लगाउन र पुन: सुरु गर्न स्वचालित प्रणालीहरू तयार गर्यो। प्रत्येक अपडेटले क्षमता पुन: प्राप्त गर्ने प्रयासको वर्णन गर्यो। त्यसपछि रिकभरी लुपको व्याख्या गर्ने लाइन आयो। माइक्रोसफ्टले सेवामा फर्काइएका सर्भरहरू फेरि अनुत्तरदायी हुन सक्ने बताएको थियो एक पटक तिनीहरूले ट्राफिक प्राप्त गरेपछि।

1:59 एउटा मेसिन फर्केर, वास्तविक काम प्राप्त गरेर, र प्रतिक्रिया दिन बन्द गर्न सक्थ्यो। त्यो अवलोकन जवाफहरूमा कसैको विश्वस्त सिद्धान्त भन्दा बलियो प्रमाण हो। ती अवस्थाहरू मार्फत उही सर्भरको कल्पना गर्नुहोस्। अनुपलब्ध। सेवामा फर्काइयो। ट्राफिक लिँदै। फेरि अनुत्तरदायी। यसले माइक्रोसफ्टको खातालाई चित्रण गर्छ। त्यो अन्तिम संक्रमणले के ट्रिगर गर्छ भन्ने अझै अनुत्तरित छ। पुन: सुरुले अस्थायी सुधार

2:18 उत्पन्न गर्न सक्छ जबकि सर्भरलाई हराउने अवस्था अपरिवर्तित रहन्छ। यसलाई बन्द गरेर फेरि अन गर्ने सल्लाहले ओभरटाइम चार्ज गर्न थाल्छ। इन्जिनियरहरूले काम फर्किएपछि के हुन्छ भनेर जाँच गर्नुपर्छ। ग्राहकहरूलाई सेवा अर्को अनुरोध मार्फत काम गरिरहन आवश्यक छ, र अर्को अनुरोध मार्फत। माइक्रोसफ्टले केही स्थानहरूमा प्रभावित पूर्वाधारमा पुग्ने निश्चित ट्राफिकलाई सीमित गर्यो। यसले पहिलेको कन्फिगरेसन प्रयोग गरेर सर्भरहरूको एक उपसेटलाई पुन: निर्माण गर्यो

2:39 तिनीहरू प्रतिक्रियाविहीन रहन्छन् कि रहँदैनन् भनेर परीक्षण गर्न। ती रिपोर्ट गरिएका न्यूनीकरण प्रयोगहरू थिए। रिकभरीको क्रममा डिप्लोयमेन्टहरू रोक्दा शुक्रबारको डिप्लोयमेन्टले मूल आउटेज निम्त्यायो भन्ने कुनै प्रमाण दिँदैन।

रिपोर्टिङ कटअफमा के थाहा थियो?

2:48 माइक्रोसफ्टको शुक्रबारको एघार शून्य चार UTC मा अद्यावधिक अनुसार, एसिया प्यासिफिकका केही भागहरूमा रिकभरी कार्यहरू समाप्त भइसकेका थिए। ट्राफिक बिस्तारै फर्किरहेको थियो, मेलबक्स पहुँच र ढिलाइ भएको इमेल प्रोसेसिङमा सुधारका साथ। केही प्रयोगकर्ताहरूलाई अझै पनि छिटपुट समस्याहरू सामना गर्नुपर्ने हुन सक्छ, र अन्यत्र रिकभरी जारी थियो। त्यो हाम्रो रिपोर्टिङ कटअफ हो। माइक्रोसफ्टले दुर्भावनापूर्ण गतिविधिको कुनै प्रमाण नभएको बताएको थियो, र न्यूनीकरण पछि पूर्ण घटना रिपोर्टको वाचा गर्यो।

3:10 म एक खलनायक नियुक्त गर्नु अघि त्यो रिपोर्टको लागि पर्खन्छु। इन्टरनेट जासूसी कामले तपाईंले पृष्ठ ताजा गरिसक्नु अघि नै दोषी दिन सक्छ। पेज ताजा गरिसक्नु अघि नै। विकासकर्ताहरूको लागि, माइक्रोसफ्ट Graph ले निर्भरतालाई विशेष गरी मिस गर्न सजिलो बनाउँछ।

एउटा Graph अनुरोध किन असफल हुन सक्छ?

3:20 यसको Exchange मेल, क्यालेन्डर र सम्पर्कहरूको लागि अनुरोधहरू टाइम आउट हुन सक्थे। तपाईंको अनुप्रयोगले एउटा कार्यको लागि Graph लाई सफलतापूर्वक कल गर्न सक्छ र अर्कोमा असफल हुन सक्छ। एक सफल असम्बन्धित अनुरोधले तपाईंको प्रयोगकर्तालाई आवश्यक मेलबक्स कार्य पूरा हुन्छ कि हुँदैन भन्ने बारे थोरै बताउँछ। स्थिति पृष्ठलाई पनि आफ्नै एस्केप रुट आवश्यक थियो। माइक्रोसफ्टले सार्वजनिक रूपमा घटना जानकारी पोस्ट गर्यो किनभने प्रशासकहरूले सेवा स्वास्थ्य पढ्नको लागि एडमिन सेन्टर लोड गर्न नसक्ने हुन सक्थे। जब के बिग्रिएको छ भनेर पत्ता लगाउने ड्यासबोर्ड के बिग्रिएको छ भन्नेमा निर्भर हुन्छ,

3:46 ड्यासबोर्ड घटनामा सामेल भएको हुन्छ। एक आउट-अफ-ब्यान्ड स्थिति लिङ्क उपलब्ध राख्नुहोस्। साधारण Graph थ्रोटलिंगको लागि, माइक्रोसफ्टको मार्गदर्शन भन्छ कि जब एक अनुरोधलाई धेरै अनुरोध प्रतिक्रिया प्राप्त हुन्छ, Retry-After लाई सम्मान गर्न, र त्यो हेडर अनुपस्थित हुँदा एक्सपोनेन्सियल ब्याकअफ प्रयोग गर्न। त्यो मार्गदर्शनले थ्रोटलिंग व्यवस्थापन गर्छ। यसले यो आउटेजको निदान गर्दैन वा रिट्राइले सेवा पुनर्स्थापना गर्छ भनेर वाचा गर्दैन। अब अठ्चालीस घण्टा।

४८-घण्टाको मेल विन्डोले के दिन्छ?

4:05 माइक्रोसफ्टको विस्तारित स्थिति पृष्ठले भन्छ कि यसले क्यु र ब्याकलॉग प्रोसेसिङलाई प्राथमिकता दियो र ढिलाइ भएका सन्देशहरू सुरक्षित राख्न इमेल टाइमआउट विन्डो विस्तार गर्यो। त्यसले रिकभरीको क्रममा ढिलाइ भएको मेललाई थप समय दिन्छ। यसले मेल टाइमआउट विन्डो सेट गर्दछ। माइक्रोसफ्टले सेवा ठीक गर्नको लागि अठ्चालीस-घण्टाको समयसीमा दिएन, र हरेक सन्देश आइपुग्छ भन्ने कुनै ग्यारेन्टी पनि दिएन। त्यसैले डेलिभरी दाबीहरू इमानदार राख्नुहोस्। ढिलाइ भएको सूचना अनिवार्य रूपमा हराएको हुँदैन,

4:28 र क्यु गरिएको सन्देश अनिवार्य रूपमा त्यसको प्राप्तकर्तामा पुगेको हुँदैन। समय-संवेदनशील कामको लागि, अनुमोदित स्वतन्त्र च्यानल मार्फत परिणाम प्रमाणित गर्नुहोस्। ब्याकइन्ड अझै रिकभर भइरहेको बेला क्लाइन्ट विन्डो एक आशावादी डेलिभरी रसिद हो। जसले अन्ततः आउने घटना रिपोर्टमा पढ्नको लागि धेरै कुरा छोड्छ। यदि तपाईं मलाई यो भन्न सुन्नुको सट्टा यो पढ्न चाहनुहुन्छ भने, diff हरेक बिहान तपाईंको इनबक्समा आउँछ, the daily diff dot dev मा निःशुल्क, लिङ्क तल छ। त्यसैले आजको फैसला, NEEDS REVIEW।

दिगो रिकभरीले के प्रमाणित गर्न आवश्यक थियो?

4:49 म रिकभरीलाई समीक्षामा राख्नेछु किनभने माइक्रोसफ्टको आफ्नै अद्यावधिकहरूले ट्राफिक अन्तर्गत असफल भएका फर्काइएका सर्भरहरू देखाए। उपयोगी परीक्षण वास्तविक काम मार्फत आउने दिगो सेवा हो। अन्तिम रिपोर्ट नआउन्जेल, प्रारम्भिक कारण खुला रहन्छ। र आजको लागि यो diff हो। म Axrisi बाट Niko हुँ। जिम्मेवारीपूर्वक मर्ज गर्नुहोस्।

स्रोतहरू

1. ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
2. Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
3. Health-processing component investigation hypothesisMicrosoft 365 Status
4. Alternative health check returned a subset of serversMicrosoft 365 Status
5. Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
6. Unavailable servers strain remaining infrastructureMicrosoft 365 Status
7. Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
8. Users in any region may be affectedMicrosoft 365 Status
9. Email timeout extended to preserve delayed messagesMicrosoft 365 Status
10. Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
11. Independent live reporting on the Microsoft email disruptionCNN
12. Microsoft Graph throttling guidanceMicrosoft Learn
13. Exchange Online service descriptionMicrosoft Learn
14. Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
15. Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
16. WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
17. The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting