Awaria odzyskiwania programu Outlook firmy Microsoft pod wpływem ruchu
Awaria poczty e-mail firmy Microsoft w dniach 12–13 listopada ujawniła pętlę odzyskiwania: przywrócone serwery mogły ponownie stać się niedostępne pod wpływem ruchu.
Awaria poczty e-mail firmy Microsoft w dniach 12–13 listopada ujawniła pętlę odzyskiwania: przywrócone serwery mogły ponownie stać się niedostępne pod wpływem ruchu. W zatwierdzonym punkcie odcięcia 13 listopada o godzinie 11:04:50 UTC, odzyskiwanie postępowało w częściach regionu Azji i Pacyfiku, podczas gdy w innych miejscach utrzymywały się sporadyczne problemy i prace. Niniejsza kontynuacja wyjaśnia zależności i zabezpieczenia opóźnionej poczty.
Przeczytaj wydanie pisemne (angielski) ↗
Co obejmuje ten film
- Sprawdź zależność backendu każdej operacji: większość podstawowych funkcji Teams i bezpośredni dostęp do plików SharePoint pozostały funkcjonalne, podczas gdy funkcje zależne od Exchange były osłabione.
- Microsoft poinformował, że przywrócone serwery mogły ponownie stać się niedostępne, gdy dotarł do nich ruch; jego wyjaśnienie dotyczące komponentu przetwarzania stanu serwera pozostało hipotezą.
- Przedłużony czterdziestoośmiogodzinny limit czasu poczty e-mail miał na celu zachowanie opóźnionych wiadomości podczas przetwarzania kolejek i zaległości. Nie był to termin naprawy ani uniwersalna gwarancja dostarczenia.
- Zwykłe wytyczne dotyczące ograniczania przepustowości Graph zalecają przestrzeganie Retry-After i wykładniczego wycofywania, gdy ten nagłówek jest nieobecny; nie diagnozuje to ani nie naprawia tego incydentu.
Pytania i odpowiedzi
Dlaczego przywrócone serwery pocztowe Microsoftu mogły ponownie ulec awarii pod wpływem ruchu?
Microsoft poinformował, że przywrócone serwery mogły ponownie stać się niedostępne, gdy otrzymały ruch. Jego dochodzenie opisało przeciążone procesy i możliwy problem w komponencie przetwarzającym stan serwera, ale początkowy wyzwalacz nadal czekał na ostateczny raport z incydentu. Ten epizod koncepcyjnie ilustruje zgłoszoną sekwencję powrotu, pracy i nawrotu; nie twierdzi, że udowodniono wewnętrzną architekturę ani ostateczną przyczynę źródłową.
Dlaczego połączenia Teams mogły działać, podczas gdy funkcje kalendarza zawodziły?
Większość podstawowych połączeń, spotkań i czatów Teams pozostała funkcjonalna zgodnie z rozszerzonym komunikatem Microsoftu o stanie usługi. Scenariusze kalendarza i planowania zależały od Exchange Online i mogły ulec awarii podczas zakłócenia. Bezpośredni dostęp do plików SharePoint również pozostał funkcjonalny. Użytecznym rozróżnieniem na poziomie aplikacji jest zależność stojąca za operacją, a nie traktowanie każdej funkcji pod logo produktu jako dzielącej ten sam stan awarii.
Czy czterdziestoośmiogodzinny limit czasu poczty e-mail wyznaczył termin naprawy?
Microsoft wydłużył okno limitu czasu poczty e-mail, aby zachować opóźnione wiadomości, jednocześnie priorytetyzując przetwarzanie kolejek i zaległości. To dało opóźnionej poczcie więcej czasu podczas odzyskiwania. Publiczny komunikat nie podał czterdziestoośmiogodzinnego terminu naprawy ani nie zagwarantował, że każda wiadomość dotrze do odbiorcy. Oczekujące lub umieszczone w kolejce powiadomienie wymagało zatem faktycznego sprawdzenia dostarczenia lub wyniku, zanim wrażliwy na czas przepływ pracy mógł na nim polegać.
Jak zakłócenie Exchange wpłynęło na aplikacje Microsoft Graph?
Żądania poczty, kalendarza i kontaktów Exchange Online mogły przekroczyć limit czasu zgodnie z informacjami Microsoftu. Aplikacja mogła napotkać różne wyniki w różnych operacjach o różnych zależnościach bazowych. Epizod zaleca sprawdzenie rzeczywistej zależności usługi operacji. Oddzielna dokumentacja Microsoftu dotycząca zwykłego ograniczania przepustowości omawia przestrzeganie Retry-After i wykładniczego wycofywania, gdy ten nagłówek jest nieobecny; te zasady nie ustalają przyczyny tego incydentu ani nie obiecują przywróconej usługi.
Jaki był werdykt The Daily Diff w sprawie odzyskiwania Microsoftu?
Werdykt The Daily Diff brzmiał: WYMAGA PRZEGLĄDU. Niko poddał odzyskiwanie przeglądowi, ponieważ aktualizacje Microsoftu opisywały serwery, które powróciły do działania, ale ulegały awarii pod wpływem ruchu. Trwała usługa z faktycznie przepływającą pracą była użytecznym testem odzyskiwania. Początkowa przyczyna pozostała otwarta w momencie odcięcia raportowania epizodu, a Microsoft obiecał pełny raport z incydentu i działania w zakresie pogłębionej obrony po złagodzeniu problemu.
Przetłumaczona transkrypcja
Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.
Dlaczego przywrócone serwery ponownie uległy awarii?
0:00 Microsoft przywrócił serwery pocztowe do działania. Mogły one ponownie przestać odpowiadać, gdy powrócił ruch. Oto uzupełnienie dla deweloperów. W tym filmie, dlaczego odzyskiwanie ciągle zawodziło? I które części Twojej aplikacji nadal działały? Microsoft dał również opóźnionej poczcie e-mail czterdzieści osiem godzin. Co to tak naprawdę daje? Jest piątek, trzynasty listopada, i to jest The Daily Diff.
0:18 Exchange Online to usługa poczty e-mail hostowana przez Microsoft, a inne funkcje Microsoftu 365
Które funkcje zależały od Exchange?
0:22 zależą od niej. Oto przydatne rozróżnienie ze strony statusu Microsoftu. Połączenia Teams i czaty grupowe w większości działały. Funkcje kalendarza i żądania danych skrzynki pocztowej mogły zakończyć się niepowodzeniem. Sprawdź zależność, której faktycznie używa Twoja aplikacja. Oznacza to, że spotkanie może się odbyć, nawet jeśli kalendarz odmawia współpracy. Bezpośredni dostęp do plików w SharePoint również pozostał funkcjonalny, podczas gdy niektóre funkcje udostępniania zostały naruszone.
0:42 Logo na oknie niewiele mówi o tym, jakiego backendu potrzebuje Twój następny klik. Zakłócenie rozpoczęło się w czwartek, a Microsoft początkowo badał dostęp do skrzynek pocztowych w obu Amerykach. Następnie potwierdził, że użytkownicy w dowolnym regionie mogą być dotknięci problemem. CNN informowało o problemach w bankach, rządach i sądach. Brakujący e-mail jest niewygodny, dopóki czyjaś prawdziwa praca nie zależy od jego nadesłania. Wczesne wyjaśnienie Microsoftu dotyczyło utraty dostępnych serwerów.
Jak brak pojemności przeciąża usługę?
1:06 Praca, którą te maszyny powinny były wykonać, obciążała pozostałą infrastrukturę. Możesz przeciążyć usługę zwykłym zapotrzebowaniem, gdy jej pojemność zniknie. Kolejka staje się dłuższa, nawet jeśli nikt nagle nie odkrył pasji do wysyłania e-maili. Firma następnie zbadała zautomatyzowane kontrole stanu. Te kontrole pomagają zdecydować, czy serwer może przyjmować pracę. Microsoft powiedział, że komponent przetwarzający stan serwera może być zaangażowany. To jest hipoteza z wciąż trwającego śledztwa.
1:29 Nie mamy ostatecznego raportu z incydentu wyjaśniającego dokładnie, dlaczego te serwery najpierw stały się niedostępne. Aktualizacje wyglądają, jakby dyżur coraz mniej
Co Microsoft wypróbował jako pierwsze?
1:37 interesował się śniadaniem. Wstrzymaj wdrożenia. Przenieś ruch. Uruchom ponownie serwery. Microsoft zatwierdził alternatywną kontrolę stanu, która przywróciła podzbiór, i przygotował zautomatyzowane systemy do wykrywania i ponownego uruchamiania nieodpowiadających maszyn. Każda aktualizacja opisywała próbę odzyskania pojemności. Potem pojawiła się linia, która wyjaśnia pętlę odzyskiwania. Microsoft powiedział, że serwery przywrócone do działania mogą ponownie stać się niedostępne po otrzymaniu ruchu.
1:59 Maszyna mogła wrócić, otrzymać prawdziwą pracę i przestać odpowiadać. Ta obserwacja jest silniejszym dowodem niż jakakolwiek pewna teoria w odpowiedziach. Wyobraź sobie ten sam serwer przechodzący przez te stany. Niedostępny. Przywrócony do działania. Przyjmujący ruch. Ponownie niedostępny. To ilustruje relację Microsoftu. Co wyzwala to ostatnie przejście, pozostaje bez odpowiedzi. Restart może spowodować tymczasową
2:18 poprawę, podczas gdy warunek, który powoduje awarię serwera, pozostaje nierozwiązany. Porada, aby wyłączyć i włączyć ponownie, zaczyna naliczać nadgodziny. Inżynierowie muszą sprawdzić, co dzieje się po powrocie pracy. Klienci potrzebują, aby usługa działała przy następnym żądaniu, i kolejnym. Microsoft ograniczył pewien ruch docierający do dotkniętej infrastruktury w niektórych lokalizacjach. Przebudował również podzbiór serwerów, używając poprzedniej konfiguracji, aby
2:39 sprawdzić, czy pozostaną responsywne. Były to zgłoszone eksperymenty łagodzące. Wstrzymanie wdrożeń podczas odzyskiwania nie daje nam dowodów, że piątkowe wdrożenie spowodowało pierwotną awarię.
Co było wiadomo w momencie odcięcia raportowania?
2:48 Według piątkowej aktualizacji Microsoftu o jedenastej czwartej UTC, działania naprawcze zakończyły się w częściach regionu Azji i Pacyfiku. Ruch stopniowo powracał, z poprawą dostępu do skrzynek pocztowych i przetwarzania opóźnionej poczty e-mail. Niektórzy użytkownicy nadal mogli doświadczać sporadycznych problemów, a odzyskiwanie w innych miejscach trwało. To jest nasz punkt odcięcia raportowania. Microsoft oświadczył, że nie ma dowodów na złośliwe działanie, i obiecał pełny raport z incydentu po złagodzeniu problemu.
3:10 Poczekałbym na ten raport, zanim przypisałbym winowajcę. Detektywistyczna praca w Internecie może wskazać winnego, zanim jeszcze skończysz odświeżanie strony. Dla deweloperów Microsoft Graph sprawia, że zależność jest szczególnie łatwa do przeoczenia.
Dlaczego jedno żądanie Graph mogło się nie powieść?
3:20 Jego żądania poczty, kalendarza i kontaktów Exchange mogły przekroczyć limit czasu. Twoja aplikacja może pomyślnie wywołać Graph dla jednej operacji i zakończyć się niepowodzeniem w przypadku innej. Pomyślne, niezwiązane z tym żądanie niewiele mówi o tym, czy operacja skrzynki pocztowej, której potrzebuje użytkownik, zostanie ukończona. Strona statusu potrzebowała nawet własnej drogi ucieczki. Microsoft publicznie opublikował informacje o incydencie, ponieważ administratorzy mogli nie być w stanie załadować centrum administracyjnego, aby odczytać stan usługi. Gdy panel do dowiadywania się, co jest zepsute, zależy od tego, co jest zepsute,
3:46 panel dołączył do incydentu. Zachowaj dostępny link do statusu poza pasmem. W przypadku zwykłego ograniczania przepustowości Graph, wytyczne Microsoftu mówią, aby przestrzegać opóźnienia ponownej próby, gdy żądanie otrzyma odpowiedź "za dużo żądań", i użyć wykładniczego wycofywania, gdy ten nagłówek jest nieobecny. Te wytyczne zarządzają ograniczaniem przepustowości. Nie diagnozują one tej awarii ani nie obiecują, że ponowne próby przywrócą usługę. Teraz czterdzieści osiem godzin.
Co daje 48-godzinne okno pocztowe?
4:05 Rozszerzona strona statusu Microsoftu mówi, że priorytetowo traktowano przetwarzanie kolejek i zaległości oraz wydłużono okno limitu czasu poczty e-mail w celu zachowania opóźnionych wiadomości. To daje opóźnionej poczcie więcej czasu podczas odzyskiwania. Ustawia okno limitu czasu poczty. Microsoft nie wyznaczył czterdziestoośmiogodzinnego terminu na naprawę usługi, ani nie zagwarantował, że każda wiadomość dotrze. Więc zachowaj uczciwość w kwestii dostarczenia. Opóźnione powiadomienie niekoniecznie zniknęło,
4:28 a wiadomość w kolejce niekoniecznie dotarła do odbiorcy. W przypadku prac wrażliwych na czas, zweryfikuj wynik za pośrednictwem zatwierdzonego niezależnego kanału. Okno klienta to optymistyczne potwierdzenie dostarczenia, gdy backend nadal się odzyskuje. Co pozostawia dużo do przeczytania w ostatecznym raporcie z incydentu. Jeśli wolisz to przeczytać, niż usłyszeć, jak to mówię, "diff" ląduje w Twojej skrzynce odbiorczej każdego ranka, za darmo na daily diff dot dev, link poniżej. Więc dzisiejszy werdykt, WYMAGA PRZEGLĄDU.
Co trzeba by udowodnić, aby odzyskiwanie było trwałe?
4:49 Zachowałbym odzyskiwanie do przeglądu, ponieważ własne aktualizacje Microsoftu pokazały, że przywrócone serwery ulegają awarii pod wpływem ruchu. Użytecznym testem jest trwałe działanie z faktycznie napływającą pracą. Do czasu ostatecznego raportu, początkowa przyczyna pozostaje otwarta. I to jest "diff" na dziś. Jestem Niko z Axrisi. Łącz odpowiedzialnie.
Źródła
- ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
- Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
- Health-processing component investigation hypothesisMicrosoft 365 Status
- Alternative health check returned a subset of serversMicrosoft 365 Status
- Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
- Unavailable servers strain remaining infrastructureMicrosoft 365 Status
- Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
- Users in any region may be affectedMicrosoft 365 Status
- Email timeout extended to preserve delayed messagesMicrosoft 365 Status
- Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
- Independent live reporting on the Microsoft email disruptionCNN
- Microsoft Graph throttling guidanceMicrosoft Learn
- Exchange Online service descriptionMicrosoft Learn
- 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
- Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
- 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
- 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



