Jak analizować monitorowanie e-maili i sygnały Postmaster

Pierwsze 15 minut

1. Potwierdź, że oczekiwany ruch trafia na prywatne konta gmail.com lub googlemail.com, a nie tylko do odbiorców w Google Workspace.
2. Sprawdź, czy w Postmaster Tools jest domena używana przez SPF, DKIM lub oba; subdomeny dodaj osobno, gdy potrzebujesz niezależnych widoków.
3. Potwierdź weryfikację DNS i odczekaj do 10 minut na aktualizację jej statusu.

Teraz

• Dodaj do Postmaster Tools aktywną domenę uwierzytelniania SPF lub DKIM.

Najbliższe 24 godziny

• Zakończ weryfikację DNS i odczekaj do 10 minut na aktualizację statusu weryfikacji.

Najbliższe 7 dni

• Utrzymuj telemetrię SMTP i ESP w czasie rzeczywistym obok Postmaster Tools, ponieważ dane na dashboardzie zwykle aktualizują się w ciągu 24 godzin, a czasem trwa to dłużej.

Kontrole techniczne

Kryteria weryfikacji

• Skonfigurowana domena uwierzytelniania pokazuje status zweryfikowanej po odczekaniu do 10 minut.
• Dane na dashboardzie pojawiają się po zwykłym czasie aktualizacji. Jeżeli nadal ich nie ma, ten utrzymujący się brak jest zgodny z udokumentowanym pomijaniem danych przy niskim wolumenie ze względu na prywatność i nie traktujesz go jako udowodnionej awarii.

Kryteria eskalacji

• Eskaluj sprawę konfiguracji dopiero po zweryfikowaniu poprawnej domeny uwierzytelniania i odczekaniu normalnego opóźnienia aktualizacji, dokumentując, że dane zazwyczaj pojawiają się w ciągu 24 godzin, ale może to potrwać dłużej.

Zapobieganie

• Udokumentuj zakres prywatnych kont Gmail oraz dokładne domeny SPF lub DKIM, które trzeba dodać i zweryfikować, i nigdy nie traktuj samego pustego dashboardu jako dowodu awarii.

Wpływ na biznes

• Pusty dashboard odbiera użyteczny sygnał diagnostyczny, ale bez niezależnych dowodów z SMTP, z odbić lub od odbiorców nie dowodzi awarii dostarczania.

Uwagi dostawcy

• Google może pominąć dane w Postmaster Tools w dni o niskim wolumenie ze względów prywatności i nie publikuje uniwersalnego progu widoczności.

Otwarte pytania

• Skonfigurowana domena Postmaster, status weryfikacji, aktywne domeny SPF i DKIM, dzienny wolumen na prywatnych kontach Gmail oraz czas od konfiguracji nie są podane.
• Google nie publikuje uniwersalnego progu dziennego wolumenu, który gwarantowałby widoczność danych na dashboardzie.

Pierwsze 15 minut

1. Pogrupuj wiersze raportu według źródłowego adresu IP i domeny RFC5322.From, zachowując liczbę wiadomości, dyspozycję oraz wyniki zgodności domen dla DKIM i SPF.
2. Zestaw te grupy ze spisem zatwierdzonych nadawców.
3. W pierwszej kolejności zajmij się nieoczekiwanymi źródłami o wysokim wolumenie, powtarzającymi się błędami zgodności domen i nieoczekiwanymi dyspozycjami w ramach polityki.

Teraz

• Pogrupuj wiersze zbiorcze według źródłowego adresu IP i domeny header-from, po czym porównaj je ze spisem zatwierdzonej wysyłki.

Najbliższe 24 godziny

• Zbadaj — w kolejności priorytetów — nieoczekiwane źródła o wysokim wolumenie, powtarzające się błędy zgodności domen i nieoczekiwane dyspozycje w ramach polityki.

Najbliższe 7 dni

• Utrzymuj wiarygodny spis nadawców, aby kolejne okresy zbiorcze dało się spójnie zestawiać.

Kontrole techniczne

Kryteria weryfikacji

• W kolejnych okresach zbiorczych potwierdź, że oczekiwane, legalne źródła osiągają zgodność domen, a podejrzane źródło znika lub otrzymuje zamierzoną dyspozycję.
• Potwierdź trend zbiorczy logami bezpieczeństwa i pamiętaj, że odbiorcy mogą pomijać raporty, a do raportowania co najmniej raz na 24 godziny są tylko zachęcani.

Kryteria eskalacji

• Eskaluj sprawę do działu bezpieczeństwa, gdy źródło pozostaje niewyjaśnione po zestawieniu ze spisem nadawców. Nie traktuj przy tym brakujących raportów od odbiorców ani samego błędu zgodności domen jako dowodu na przejęcie konta.

Zapobieganie

• Opublikuj prawidłowy rekord DMARC z zamierzonym adresem docelowym raportów w tagu rua.
• Utrzymuj aktualny spis legalnych nadawców i z czasem zestawiaj go z raportami zbiorczymi.

Wpływ na biznes

• Nieuzgodnione źródła mogą przesłaniać ewentualne nieautoryzowane użycie domeny, a błędne uznanie źródła za złośliwe potrafi zakłócić pracę legalnych nadawców.

Otwarte pytania

• Nie podano zaobserwowanych źródłowych adresów IP, liczb, wyników zgodności domen, spisu zatwierdzonych nadawców ani potwierdzających logów bezpieczeństwa, więc na podstawie samej tej paczki żadnego źródła nie da się uznać za złośliwe.
• Zasięg i moment raportowania po stronie odbiorców bywają różne, a część odbiorców nie wysyła raportów zbiorczych z powodów związanych z polityką, zasobami lub prywatnością.

Pierwsze 15 minut

1. Ustal, które miejsca docelowe zdarzeń (event destinations) i strumienie wysyłkowe skonfigurowano i wybrano dla wysyłek objętych incydentem.
2. Oddziel sukces żądania u dostawcy od dostarczenia do serwera odbiorcy oraz od trafienia do skrzynki odbiorczej.
3. Odtwórz bezpieczną dla prywatności oś czasu z zachowanych znaczników czasu, identyfikatorów wiadomości, odpowiedzi SMTP lub DSN, webhooków oraz kontrolowanych nagłówków z próbek.

Teraz

• Odtwórz przebieg incydentu z zachowanych znaczników czasu — zakolejkowania i tych od dostawcy — identyfikatorów wiadomości, odpowiedzi SMTP lub DSN, webhooków oraz kontrolowanych nagłówków.

Najbliższe 24 godziny

• Włącz lub napraw publikację zdarzeń dla każdego strumienia wysyłkowego objętego incydentem oraz każdego skonfigurowanego miejsca docelowego.

Najbliższe 7 dni

• Ustaw alerty na luki między przesłanymi wiadomościami a wynikami końcowymi — po wcześniejszym zweryfikowaniu publikacji zdarzeń kontrolowaną wysyłką.

Kontrole techniczne

Kryteria weryfikacji

• Zweryfikuj, czy kontrolowana wysyłka generuje oczekiwane zdarzenia przesłania i wyniku końcowego w skonfigurowanym miejscu docelowym.
• Potwierdź, że monitoring ostrzega o lukach między przesłanymi wiadomościami a wynikami końcowymi — i pamiętaj, że taki test nie dowodzi trafienia do skrzynki odbiorczej u wszystkich dostawców.

Kryteria eskalacji

• Eskaluj sprawę do inżynierii i ESP, gdy publikacja zdarzeń nadal jest niesprawna, gdy nie da się odtworzyć wymaganych identyfikatorów lub wyników albo gdy ładunki DeliveryDelay pokazują nierozwiązane, tymczasowe błędy serwera odbiorcy.

Zapobieganie

• Skonfiguruj publikację zdarzeń dla każdego strumienia wysyłkowego. Przy każdej wysyłce wybieraj właściwe miejsce docelowe zdarzeń.
• Nieprzerwanie testuj kontrolowany przepływ zdarzeń i alertuj o brakujących wynikach końcowych.

Wpływ na biznes

• Wiadomości mogą pozostawać tymczasowo nieprzyjęte przez serwery odbiorców, a pozorny sukces u dostawcy nadal może pozostawiać nieznanym to, czy trafiły do skrzynki odbiorczej i czy odebrał je użytkownik.

Uwagi dostawcy

• W Amazon SES zdarzenie Send oznacza, że żądanie się powiodło i SES podejmie próbę dostarczenia, natomiast zdarzenie Delivery oznacza, że serwer pocztowy odbiorcy przyjął wiadomość; żadne z nich nie dowodzi trafienia do skrzynki odbiorczej.
• Gmail Postmaster Tools obejmuje tylko jednego dostawcę, nie działa w czasie rzeczywistym i ze względów prywatności może pomijać dane o niskim wolumenie.

Otwarte pytania

• Dostawca, zachowane identyfikatory wiadomości, odpowiedzi SMTP, DSN, stan miejsca docelowego zdarzeń, strumień, domeny odbiorców oraz okno czasowe incydentu są niedostępne; dlatego rzeczywistego wyniku dostarczenia nie da się ustalić na podstawie samego pytania.
• Nazwy zdarzeń, retencja, próbkowanie na dashboardzie oraz widoczność przy niskim wolumenie różnią się w zależności od ESP i operatora pocztowego; zachowań SES i Gmaila nie da się uogólniać.

Pierwsze 15 minut

1. Sprawdź zakres dat w panelu i uwzględnij zwykłe 24-godzinne opóźnienie aktualizacji, jeszcze dłuższe opóźnienia oraz pominięcia danych przy niskim wolumenie ze względu na prywatność.
2. Interpretuj Spam Rate przez pryzmat jego mianownika — uwierzytelnionych przez DKIM wiadomości trafiających do skrzynki odbiorczej aktywnych odbiorców — i sprawdź, jak wpływa na niego automatyczne umieszczanie w spamie.
3. Porównaj raportowany wskaźnik spamu z wytycznymi Gmaila, które każą utrzymywać go poniżej 0,10% i unikać wartości 0,30% lub wyższych.

Teraz

• Ogranicz strumień wysyłający do Gmaila, którego dotyczy problem, gdy spam w Postmaster sięgnie 0,30% lub więcej.

Najbliższe 24 godziny

• Ponownie sprawdź status Compliance i pamiętaj, że działa on w kroczącym, wielodniowym oknie — nie oczekuj natychmiastowej zmiany zaraz po wdrożeniu poprawki.

Najbliższe 7 dni

• Dalej sprawdzaj kroczący status Compliance, bo poprawka może pojawić się w jego wielodniowych średnich dopiero po pewnym czasie.

Kontrole techniczne

Kryteria weryfikacji

• Dane z Postmaster dla właściwej daty zostały zaktualizowane, a brakujące dni o niskim wolumenie traktujesz wprost jako odfiltrowane ze względu na prywatność, a nie jako zero zgłoszeń spamu.
• Kroczący status Compliance odzwierciedla poprawkę, a Delivery Errors dla uwierzytelnionego ruchu spadają w tym samym zakresie wysyłki.

Kryteria eskalacji

• Eskaluj sprawę do specjalisty ds. dostarczalności, jeśli po ograniczeniu strumienia, którego dotyczy problem, spam nadal wynosi 0,30% lub więcej albo Delivery Errors dla uwierzytelnionego ruchu wciąż nie spadają.

Zapobieganie

• Monitoruj spam w Gmail Postmaster względem zalecanego progu poniżej 0,10% i granicy 0,30%, której należy unikać, a obok tego śledź kroczące dane o zgodności.

Wpływ na biznes

• Rosnący wskaźnik spamu w Gmailu oznacza, że aktywni odbiorcy korzystający ze skrzynki odbiorczej ręcznie oznaczają wiadomości jako spam, a automatyczne umieszczanie w spamie może ukrywać dodatkowy wpływ, którego nie widać w wyświetlanym procencie.

Uwagi dostawcy

• Starsze panele Domain Reputation i IP Reputation mają zostać wycofane, a nie przeniesione w niezmienionej formie do Postmaster Tools v2, ale Google nie podaje ostatecznej daty ich wyłączenia.

Otwarte pytania

• Nie podano eksportu z panelu, wolumenu wysyłki, zakresu dat, zestawu domen ani przykładowego błędu SMTP po stronie dostawcy, więc na podstawie samego pytania nie da się określić aktualnej wagi incydentu.
• Google nie podaje ostatecznej daty wyłączenia starszych paneli reputacji i informuje, że wycofanie zostało przełożone.
• Brakujące lub wyjątkowo niskie dane o wskaźniku spamu mogą wynikać z progów prywatności, pokrycia obejmującego tylko DKIM albo automatycznego umieszczania w spamie; to nie to samo co zero zgłoszeń spamu.

Pierwsze 15 minut

1. Potwierdź konto AWS i Region. Następnie zanotuj, czy SES pokazuje «Under review», «Pending sending pause» czy «Sending paused».
2. Otwórz zgłoszenie w AWS Support i — zanim odpowiesz — ustal przyczynę oraz działanie naprawcze, którego oczekuje AWS.
3. Skoreluj metrykę skarg SES z powiadomieniami o zdarzeniach, danymi od operatorów pocztowych, kampaniami i źródłami list, bo jej pokrycie informacją zwrotną nie jest pełne.

Teraz

• Jeśli konto jest w przeglądzie i sytuacja na to pozwala, wstrzymaj pocztę i usuń przyczynę wskazaną w zgłoszeniu AWS.

Najbliższe 24 godziny

• Skoreluj zgłoszenia spamu ze zdarzeniami, dostawcami, kampaniami i źródłami list, a następnie odpisz AWS, opisując wdrożone już zmiany naprawcze i zapobiegawcze.

Najbliższe 7 dni

• Przejrzyj, na ile pełne jest pokrycie informacją zwrotną o skargach, i zachowaj dowody z kohort odbiorców, które posłużyły do wyjaśnienia naprawionej przyczyny.

Kontrole techniczne

Kryteria weryfikacji

• Metryki reputacji SES dla odbić i skarg są poniżej progów alarmowych incydentu i nadal są monitorowane na poziomie konta.
• Konto i Region objęte incydentem nie pokazują już na stronie Reputation stanu «Under review», «Pending sending pause» ani «Sending paused».

Kryteria eskalacji

• Przy stanach «Under review», «Pending sending pause» lub «Sending paused» eskaluj sprawę natychmiast przez zgłoszenie w AWS Support i opisz zakończone zmiany naprawcze oraz zapobiegawcze.

Zapobieganie

• Utrzymuj alarmy CloudWatch na udokumentowanych progach dla konta SES: 5% dla odbić i 0,1% dla skarg. Tam, gdzie potrzebujesz wcześniejszego wykrycia, ustaw niższe progi ostrzegawcze na potrzeby wewnętrzne.
• Alerty o wskaźniku skarg SES koreluj z powiadomieniami o zdarzeniach, dostawcami, kampaniami i źródłami list, zamiast uznawać tę metrykę za pełne pokrycie zgłoszeń spamu.

Wpływ na biznes

• Jeśli SES wejdzie w stan «Sending paused», konto i Region objęte incydentem nie mogą wysyłać przez SES, co przerywa każdy zależny od nich strumień e-mail.

Uwagi dostawcy

• Wskaźnik skarg SES obejmuje zgłoszenia spamu z domen, które przekazują SES informacje zwrotne, i opiera się na reprezentatywnym wolumenie, a nie na stałym oknie czasowym.

Otwarte pytania

• Nie podano konta AWS, Regionu, aktualnego statusu konta SES, stanu alarmu ani zmierzonych wskaźników odbić i skarg.
• Strumienie wysyłkowe objęte incydentem oraz przyczyna ewentualnego zdarzenia reputacyjnego pozostają nierozstrzygnięte, dopóki nie przejrzysz metryk SES, powiadomień i kohort odbiorców.
• Nie znamy krytyczności kampanii, pochodzenia list, pokrycia informacją zwrotną o skargach ani wpływu na biznes.

Pierwsze 15 minut

1. Gdy objawem jest odrzucenie lub odroczenie, przechwyć bieżące odpowiedzi SMTP i otwórz sekcję Delivery Errors dla właściwej uwierzytelnionej domeny i okna czasowego.
2. Gdy mogło się zmienić DNS lub uwierzytelnianie wiadomości, otwórz sekcję Authentication dla konkretnej tożsamości, której dotyczy problem.

Teraz

• Skieruj analizę do sekcji Delivery Errors, Spam Rate, Reputation lub Authentication — zależnie od zaobserwowanego objawu i tożsamości, której dotyczy problem.

Najbliższe 24 godziny

• Usuń konkretną przyczynę z sekcji Delivery Errors lub błąd uwierzytelniania, a po zmianie porównaj tę samą uwierzytelnioną kohortę.

Najbliższe 7 dni

• Prowadź runbook, który przypisuje objawy do dashboardów i obejmuje błędy dostarczenia, zgłoszenia spamu, reputację oraz uwierzytelnianie, zamiast polegać na jednym wykresie.

Kontrole techniczne

Kryteria weryfikacji

• Bieżące logi nadawcy i zaktualizowany widok Delivery Errors pokazują, że przyczyna odrzuceń lub odroczeń z incydentu słabnie dla objętej nim uwierzytelnionej kohorty.
• Sekcja Authentication pokazuje oczekiwany odsetek wyników pass dla wybranej tożsamości, a odebrana wiadomość potwierdza ten wynik na poziomie pojedynczej wiadomości.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub specjalisty ds. dostarczalności, gdy bieżące błędy w Gmailu utrzymują się, a Postmaster jest pusty z powodu limitów wolumenu, albo gdy nie potrafisz samodzielnie odizolować reputacji współdzielonego IP lub domeny.

Zapobieganie

• Trzymaj bieżącą telemetrię SMTP obok monitoringu w Postmaster, dobieraj dashboardy według objawu i tożsamości oraz dokumentuj opóźnienia w raportowaniu i ograniczenia pokrycia przy niskim wolumenie.

Wpływ na biznes

• Odrzucenia i tymczasowe błędy zmniejszają lub opóźniają zasięg w Gmailu. Sygnały o reputacji i zgłoszeniach spamu mogą z kolei wskazywać na szersze ryzyko, że wiadomości trafią do spamu zamiast do skrzynki odbiorczej.

Uwagi dostawcy

• Postmaster Tools zwykle aktualizuje się w ciągu 24 godzin, ale bywa, że dłużej, więc nie jest źródłem danych o incydentach w czasie rzeczywistym.
• Postmaster pokrywa ruch do prywatnych kont Gmail, a Google ze względów prywatności może pominąć dane o niskim wolumenie.

Otwarte pytania

• Nie podano bieżącego objawu, wybranej domeny w Postmaster, wolumenu nadawcy, okna czasowego incydentu ani populacji odbiorców w Gmailu objętej incydentem.
• Nie da się wskazać właściwego pierwszego dashboardu, dopóki objaw nie zostanie sklasyfikowany jako tymczasowe odroczenie, trwałe odrzucenie, trafienie do spamu, reputacja lub uwierzytelnianie.
• Bieżące dane z Postmaster Tools nie są dostępne w tym środowisku badawczym, a luki wynikające z niskiego wolumenu lub opóźnień w raportowaniu mogą ograniczać diagnozę.

Pierwsze 15 minut

1. Zapisz dokładny panel Postmaster, zweryfikowaną domenę, zakres dat i widoczne ostrzeżenie.
2. Powtórz pojedynczy test z tą samą domeną widoczną w From oraz z domenami koperty i DKIM, których używa ścieżka produkcyjna.
3. Uzgodnij wybraną domenę Postmaster i widok produkcyjny z domenami From, DKIM i SPF użytymi w pojedynczym teście.

Teraz

• Wykorzystaj razem pojedynczy test i produkcyjne dane zbiorcze Postmaster, aby wyodrębnić ścieżkę, której dotyczy problem.

Najbliższe 24 godziny

• Rozdziel widoki na domenę From, domenę DKIM i domenę SPF, po czym zbadaj ruch z przekazywania (forwarding) lub z list mailingowych, który zmienia dane zbiorcze.

Najbliższe 7 dni

• Zostaw na operacyjnej liście kontrolnej zarówno pojedyncze testy uwierzytelniania, jak i produkcyjne monitorowanie Postmaster.

Kontrole techniczne

Kryteria weryfikacji

• Pojedynczy test i porównanie produkcyjne korzystają z tej samej ścieżki domen — widocznej w From, koperty, DKIM i SPF.
• Pojedynczy test i dowody produkcyjne z Postmaster posłużyły razem do zidentyfikowania i rozwiązania problemu z wysyłką w ustalonym zakresie.
• Wybrany panel produkcyjny pokazuje dla zweryfikowanej domeny wyjaśniony lub poprawiony sygnał uwierzytelniania, reputacji, spamu, szyfrowania lub błędu dostarczenia.

Kryteria eskalacji

• Skorzystaj ze ścieżki zgłaszania Postmaster dla nierozwiązanego problemu z klasyfikacją, odrzuceniem lub błędem tymczasowym w Gmailu tylko wtedy, gdy próbka spełnia wymagania Google dotyczące SPF, DKIM i zgodnej domeny From.

Zapobieganie

• Monitoruj produkcyjne dane zbiorcze Gmaila razem z pojedynczymi testami uwierzytelniania, tak aby żadne z nich nie zastępowało drugiego.
• Uwzględniaj opóźnione i filtrowane dane produkcyjne Postmaster w każdym rutynowym porównaniu z pojedynczym testem.

Wpływ na biznes

• Odrzucenie zagregowanego sygnału produkcyjnego po jednym czystym teście może pozostawić niezbadaną kohortę Gmaila związaną z uwierzytelnianiem, reputacją, spamem, szyfrowaniem lub błędem dostarczenia.

Uwagi dostawcy

• Postmaster obejmuje zagregowaną pocztę produkcyjną trafiającą na prywatne konta Gmail, jest przy tym opóźniony i filtrowany pod kątem prywatności. LearnDMARC obserwuje jedną wiadomość na swoim serwerze odbiorczym.

Otwarte pytania

• Nie podano dokładnego ostrzeżenia Postmaster, wybranej domeny i zakresu dat, widoku panelu, wiadomości testowej LearnDMARC ani próbek uwierzytelniania wiadomości produkcyjnych, więc kohorta produkcyjna, której dotyczy problem, pozostaje nieznana.
• Narzędzie sprawdzające pojedynczą wiadomość oraz opóźnione, filtrowane dane zbiorcze produkcji z Gmaila mają różny zakres, różne dane wejściowe i różną widoczność. Czysty wynik testu nie unieważnia ostrzeżenia Postmaster.

Pierwsze 15 minut

1. Zweryfikuj próbkę napływającego XML i poddaj kwarantannie wadliwe raporty, zamiast domieszać je do zaufanych agregatów.
2. Zmierz zaległości surowych raportów i ustal, które przyjęte dane nie są jeszcze zindeksowane pod dashboardy i monitoring.

Teraz

• Odłóż na bok wadliwy XML i traktuj wszelkie odzyskane dane jako jawnie niezaufane, dopóki nie przejdą walidacji.

Najbliższe 24 godziny

• Wyodrębnij i zindeksuj przyjęte dane z raportów, aby operatorzy mogli je odpytywać, zamiast ręcznie czytać surowy XML.

Najbliższe 7 dni

• Udostępnij zindeksowane dane przez raporty, dashboardy i monitoring dobrane do wolumenu raportów.

Kontrole techniczne

Kryteria weryfikacji

• Każdy raport dopuszczony do zaufanych agregatów jest zgodny z formatem RFC 9990.
• Znormalizowane wiersze zachowują jedną domenę polityki i konfigurację oraz źródłowy adres IP, liczbę wiadomości, zastosowane działanie, identyfikatory i wyniki uwierzytelniania.

Kryteria eskalacji

• Skontaktuj się z podmiotem generującym raporty, gdy powtarzające się wady formatu uniemożliwiają walidację jego raportów.
• Eskaluj sprawę do właściciela monitoringu, gdy decyzje zakładają codzienne pełne pokrycie — odbiorcy mogą bowiem zrezygnować z raportowania mimo zalecenia raportowania co 24 godziny.

Zapobieganie

• Trzymaj przyjęte dane z raportów zindeksowane pod dashboardy i monitoring, zamiast polegać na ręcznym przeglądaniu surowego XML.
• Zaprojektuj wskaźniki pokrycia tak, by tolerowały odbiorców, którzy nie generują raportów — raportowanie jest bowiem zalecane, a nie gwarantowane.

Wpływ na biznes

• Nieprzetworzone raporty ukrywają sygnały — adres IP nadawcy, wolumen, politykę, zastosowane działanie, uwierzytelnianie, zgodność domen i domenę — których potrzebujesz, by oddzielić legalną pocztę od nierozpoznanej.

Otwarte pytania

• Pokrycie raportami zbiorczymi DMARC jest niepełne i różni się między dostawcami, ponieważ odbiorcy mogą nie generować raportów.

Pierwsze 15 minut

1. Ustal, czy alert dotyczy dostarczania wychodzącego, przychodzącego, czy synchronizacji katalogów, i sprawdź najnowszą migawkę Service Monitor.
2. Potwierdź, czy powiadomienia powtarzają się co 15 minut, dopóki warunek pozostaje aktywny.
3. Porównaj skonfigurowany próg z progiem zalecanym dla konta (Recommended Threshold) oraz z lokalną krytycznością biznesową.

Teraz

• Zweryfikuj konfigurację powiadomień i utwórz niezależny kanał alertów dla warunku krytycznego dla biznesu.

Najbliższe 24 godziny

• Dostrój próg kolejki na podstawie zalecanego dla konta punktu wyjścia oraz lokalnych wymagań dotyczących krytyczności biznesowej.

Najbliższe 7 dni

• Przetestuj obie ścieżki powiadomień dla krytycznych alertów Service Monitor — e-mailową oraz skonfigurowaną ścieżkę SMS.

Kontrole techniczne

Kryteria weryfikacji

• Kolejne 15-minutowe migawki usługi nie pokazują już problematycznego warunku, a powtarzające się powiadomienia ustają.
• Zarówno skonfigurowana ścieżka powiadomień e-mail, jak i niezależna ścieżka SMS zostają pomyślnie przetestowane dla krytycznych alertów.

Kryteria eskalacji

• Jeśli domyślny poziom eskalacji nadal wynosi pięć, a warunek się utrzymuje, sprawdź, czy subskrybenci eskalacji otrzymują szóste i kolejne powiadomienia po udokumentowanych 1,5 godziny.

Zapobieganie

• Przeglądaj progi kolejek w odniesieniu do niedawnej historii konta i lokalnej krytyczności, zamiast traktować zalecaną wartość jako uniwersalny próg.
• Korzystaj z niezależnego kanału powiadomień i testuj go, ponieważ alerty e-mailowe Service Monitor mogą czasami nie zostać wysłane.

Wpływ na biznes

• Alert może dotyczyć dostarczania wychodzącego, dostarczania przychodzącego lub synchronizacji katalogów, więc możliwy wpływ zależy od tego, która monitorowana usługa jest objęta problemem.

Uwagi dostawcy

• Service Monitor ostrzega o przekroczeniu skonfigurowanego progu kolejki lub awarii monitorowanej usługi.
• Przy udokumentowanym domyślnym poziomie eskalacji wynoszącym pięć subskrybenci eskalacji otrzymują szóste i kolejne powiadomienia po 1,5 godziny 15-minutowych alertów.

Otwarte pytania

• Skonfigurowane progi kolejek tenanta, krytyczne usługi i mapowanie wagi incydentów są nieznane i muszą zostać określone w lokalnej polityce operacyjnej.