Twój system się uruchamia. Baza danych działa prawidłowo. Klient klika przycisk, który powinien pozwolić mu kontynuować, i czeka na wiadomość, która nie przychodzi.

Według monitoringu produkt jest dostępny. Z perspektywy klienta nie da się z niego korzystać. Awaria Microsoft 365 z 12–13 listopada 2026 roku ujawniła lukę w planach ciągłości działania poczty: **twój system może działać, choć kolejny krok zależy od tego, czy odbiorca ma dostęp do swojej skrzynki**.

Aktualny stan usług Outlook i Microsoft 365 sprawdzisz na [stronie stanu usług Microsoft](https://status.cloud.microsoft/m365).

Warto więc prześledzić zadanie aż do końca. Niezależność od dostawcy zależy od tego, czy ludzie mogą odebrać wiadomość, wejść do systemu, podjąć decyzję i skontaktować się z tobą, gdy coś zawiedzie. Kontrola nad serwerem rozwiązuje tylko część problemu.

## Awaria Outlooka może zablokować przyjmowanie próśb o pomoc

W piątek rano [CloudTree poinformowało klientów, że nie otrzymuje maili ze zgłoszeniami do pomocy technicznej](https://status.cloud-tree.co.uk/). W sprawach niezwiązanych z awarią klienci mieli dzwonić, aby agent telefoniczny mógł utworzyć zgłoszenie. O 14:03 firma podała, że jej konta Microsoft znów się połączyły. Spodziewała się przywrócenia przyjmowania zgłoszeń pocztą i zapowiedziała dalszą obserwację sytuacji.

Awaria odebrała klientom sposób zgłoszenia dostawcy innej awarii. Ktoś mógł mieć osobny problem z hostingiem, ale nie mógł skorzystać ze zwykłej drogi kontaktu. Ten szczegół odsłania szerszy problem.

Spójrz na własną firmę. Działająca kolejka pomocy technicznej przydaje się dopiero wtedy, gdy trafi do niej zgłoszenie. Formularz, który przesyła wiadomości do tej samej niedostępnej skrzynki, może wyglądać jak drugi kanał kontaktu, choć kończy się w tym samym zablokowanym miejscu.

Droga awaryjna musi doprowadzić sprawę do zespołu. Ktoś odbiera telefon, zapisuje problem tam, gdzie współpracownicy mają dostęp, i mówi klientowi, jak może sprawdzić postępy. Samo opublikowanie numeru to początek. Trzeba jeszcze ustalić, kto może z niego korzystać i co dzieje się później.

Dlatego komunikat o awarii powinien wskazywać, jaka czynność jest niedostępna. „Nasze serwery działają” każe klientowi zgadywać, czy ma czekać, spróbować ponownie, czy szukać kontaktu. „Poczta pomocy technicznej dociera z opóźnieniem; w pilnych sprawach skorzystaj z tej drogi” pozwala podjąć decyzję.

## Drugi dostawca poczty nie otworzy skrzynki odbiorcy

Możesz przenieść własną pocztę i nadal potrzebować kontaktu z klientem, który korzysta z Microsoft 365. Infrastruktura odbiorcy pozostaje częścią tej wymiany.

[Komunikat Bright Software Group](https://status.brightsg.com/incident/1124108) pokazał tę granicę: narzędzia firmy i osobna usługa wysyłki poczty działały, ale występowały problemy z dostarczaniem wiadomości do odbiorców korzystających z usług Microsoft. Sprawność własnych systemów nie usuwała zależności po stronie odbiorcy.

W startupie ta różnica zmienia znaczenie wskaźników dotyczących poczty. Zakończenie zadania w twoim systemie dowodzi, że kod dotarł do danego etapu. Przyjęcie wiadomości przez usługę wysyłkową potwierdza kolejny etap. Żadna z tych informacji nie mówi, czy odbiorca może otworzyć skrzynkę i zareagować.

Wyobraź sobie taki przebieg rekrutacji: przygotowujesz zaproszenie na rozmowę, dostawca wysyłki je przyjmuje, ale skrzynka kandydata jest niedostępna. Zaproszenie nadal wymaga odpowiedzi. Zmiana dostawcy wysyłki nie przywróci kandydatowi dostępu do poczty.

Nie masz kontroli nad infrastrukturą każdego odbiorcy. Możesz za to zdecydować, co twój produkt zakłada po wysłaniu wiadomości. Czy na ekranie pojawia się informacja, że odbiorca został powiadomiony? Czy od razu zaczyna biec termin? Czy zaproszenie można znaleźć po zalogowaniu na konto, czy mail zawiera jedyną dostępną drogę?

To decyzje dotyczące produktu. Zasługują na tyle samo uwagi co ponawianie wysyłki i konfiguracja serwera pocztowego. Od nich zależy, czy opóźniona wiadomość skończy się niedotrzymanym zobowiązaniem.

## Logowanie, kalendarz i pomoc techniczna mają więcej wspólnego niż logo

[Komunikaty Uniwersytetu w Bath](https://status.bath.ac.uk/index.json) ujawniły inny rodzaj zależności. Według wstępnych ustaleń podstawowe funkcje Teams wydawały się działać, a uwierzytelnianie wyglądało na niezakłócone. Pracownicy nie mieli jednak dostępu do Outlooka. Uczelnia wskazała też problemy z TOPdesk i systemem CRM do obsługi kandydatów, ponieważ korzystały z Outlooka do poczty. Ostrzegła, że planowanie spotkań, zaproszenia i czynności w kalendarzu mogą nie działać.

Awaria dotknęła poszczególne funkcje w różnym stopniu. Niektóre pozostały dostępne, choć związane z nimi zadania były zablokowane. Ogólne hasło „Teams nie działa” albo „Microsoft działa” ukryłoby różnicę potrzebną do zaplanowania dnia.

Tak samo sprawdzaj własne zależności: nie zatrzymuj się na nazwie dostawcy. Korzystanie z otwartej sesji, nowe logowanie, reset hasła i przyjęcie zaproszenia do konta to odrębne sytuacje. Jedna może działać, podczas gdy druga wymaga oczekiwania na maila.

Drugie narzędzie do współpracy może być dostępne dla już zalogowanych pracowników, ale wymagać kodu z maila od osoby, która otwiera je na nowym urządzeniu. Strona z informacjami o stanie usług może być publiczna, choć opublikowanie aktualizacji wymaga logowania przez usługę tożsamości objętą awarią.

Kanał awaryjny, z którego można skorzystać tylko za pośrednictwem niedziałającego kanału, daje mniej możliwości, niż sugeruje jego nazwa. Sprawdź te drogi z ludźmi, którzy rzeczywiście mieliby z nich korzystać. Otwarta sesja założyciela nie dowodzi, że nowy klient lub upoważniony współpracownik z pomocy technicznej zdoła wejść do systemu. Zapisz konkretną czynność, która zawodzi, zamiast uznawać całe narzędzie za dostępne albo niedostępne.

## Oprzyj plan ciągłości działania poczty na zadaniach

Plan ciągłości działania poczty zaczyna się od zadań, które nie mogą czekać: dzisiejszej rozmowy rekrutacyjnej, pilnej prośby o pomoc lub zatwierdzenia z nieprzekraczalnym terminem. Drugie narzędzie do każdej funkcji oznacza dla małego zespołu więcej systemów do utrzymania. Pomaga tylko wtedy, gdy ludzie mogą wykonać te zadania.

Dla każdego z nich krótko opisz, jak doprowadzić zadanie do końca. Uwzględnij odbiorcę wiadomości i dostęp, którego potrzebuje. Poniższe przykłady służą do planowania; nie opisują zaobserwowanych skutków tej awarii:

| Zobowiązanie | Ukryta zależność od poczty | Droga awaryjna do sprawdzenia |
|---|---|---|
| Klient wchodzi na konto | Wiadomość do logowania lub odzyskania dostępu | Wcześniej ustalony i zatwierdzony sposób uwierzytelniania |
| Kandydat uczestniczy w rozmowie | Zaproszenie i aktualizacja kalendarza | Uzgodnione dane kontaktowe oraz dostępny zapis terminu spotkania |
| Klient zgłasza pilny problem | Mail tworzy zgłoszenie do pomocy technicznej | Opublikowana droga, która niezależnie dociera do obsługiwanej kolejki |
| Zespół informuje o incydencie | Mail kieruje do strony ze stanem usług | Znany publiczny adres, który można otworzyć bezpośrednio |

Microsoft w swoich [zaleceniach dotyczących ograniczania skutków incydentów](https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-365-mitigations) zaleca równoległy kontakt pocztą, telefonem i SMS-em, gdy reagowanie na incydent zależy od Exchange. Tak samo sprawdź procesy obsługi klientów: czy droga awaryjna pozwala dotrzeć do właściwej osoby bez korzystania z niedostępnej skrzynki?

Świadome wstrzymanie procesu też może być rozwiązaniem awaryjnym. Jeśli bez skrzynki nie da się bezpiecznie uwierzytelnić danej osoby, wyjaśnij opóźnienie i zachowaj jej miejsce w procesie. Awaria nie uzasadnia improwizowanej weryfikacji tożsamości ani udzielania dostępu na podstawie niesprawdzonej wiadomości.

Nasz [test ciągłości działania pod nieobecność założyciela](/blog/founder-unavailable-continuity-rehearsal) sprawdza, czy upoważniony współpracownik może pracować bez niego. Tu pytanie jest inne: czy zdoła wykonać zadanie, gdy zabraknie potrzebnego kanału komunikacji? Potrzebne są zarówno uprawnienia, jak i dostęp do infrastruktury.

## Przywrócenie usług to dopiero część nadrabiania zaległości

W oświadczeniu przytoczonym przez [BBC 13 listopada o 16:51 GMT](https://www.bbc.com/news/live/cq5y10ge3dp3t) Microsoft powiązał incydent z problemem powstałym podczas wcześniejszej rozbudowy przepustowości sieci, który ujawnił się po niedawnej zmianie w sieci. Firma podała, że nie miał on związku z cyberatakami ani AI czy agentami, że usunęła podstawowy problem i nadal przywracała usługi. Pełny raport z incydentu nie był jeszcze dostępny.

Wyjaśniając przyczynę, trzeba pozostać w granicach tego opisu. Zespół ma jednak osobne pytanie dotyczące powrotu do pracy: co stało się z zadaniami, które czekały na te wiadomości?

Gdy dostęp wróci, sprawdź zaległe zobowiązania, zanim uznasz, że wszystko nadrobiono. W swoich procesach poszukaj próśb bez odpowiedzi, wygasłych linków i spotkań zmienionych inną drogą. Uzgodnij tymczasowe zapisy z danymi w zwykłym systemie, żeby współpracownicy nie działali na podstawie sprzecznych wersji.

Następnie zmień jedno konkretne założenie, które okazało się błędne. Udostępnij zaproszenie także poza mailem. Zadbaj o niezależną drogę przyjmowania pilnych spraw przez pomoc techniczną. Poinformuj, że wiadomość czeka na dostarczenie, zamiast sugerować, że odbiorca już zareagował.

Monitoring powie ci, kiedy twój system działa prawidłowo. Żeby sprawdzić, czy działa firma, prześledź dalsze działania klienta po kliknięciu przycisku wysyłania.