Monitorowanie i sygnały Postmaster

Pierwsze 15 minut

1. Potwierdź, że oczekiwany ruch jest adresowany do osobistych odbiorców gmail.com lub googlemail.com, a nie tylko do odbiorców Google Workspace.
2. Sprawdź, czy Postmaster Tools zawiera domenę używaną przez SPF, DKIM lub oba; dodaj subdomeny oddzielnie, gdy wymagane są niezależne widoki.
3. Potwierdź weryfikację DNS i odczekaj do 10 minut na aktualizację jej statusu.

Teraz

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

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Obsługuj telemetrię SMTP i ESP w czasie rzeczywistym obok Postmaster Tools, ponieważ dane na dashboardzie zazwyczaj aktualizują się w ciągu 24 godzin i może to potrwać dłużej.

Kontrole techniczne

Kryteria weryfikacji

• Skonfigurowana domena uwierzytelniania ma status zweryfikowanej po odczekaniu do 10 minut.
• Dane na dashboardzie pojawiają się po zwykłym interwale aktualizacji lub ich dalszy brak jest zgodny z udokumentowanym pominięciem z powodu niskiego wolumenu i prywatności, i nie jest traktowany jako udowodniona awaria.

Kryteria eskalacji

• Eskaluj konfigurację 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 osobistych kont Gmail oraz dokładne domeny SPF lub DKIM, które muszą zostać dodane i zweryfikowane, i nigdy nie używaj pustego dashboardu jako jedynego dowodu awarii.

Wpływ na biznes

• Pusty dashboard pozbawia użytecznego sygnału diagnostycznego, ale bez niezależnych dowodów z SMTP, odrzuceń lub od odbiorców, nie stanowi dowodu na awarię dostarczania.

Uwagi dostawcy

• Google może pominąć dane 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 dla osobistych kont Gmail oraz czas od konfiguracji nie są podane.
• Google nie publikuje uniwersalnego progu dziennego wolumenu, który gwarantuje widoczność na dashboardzie.

Pierwsze 15 minut

1. Pogrupuj wiersze raportu, łącząc źródłowy adres IP i domenę RFC5322.From, zachowując liczbę wiadomości, dyspozycję oraz wyniki zgodności DKIM i SPF.
2. Uzgodnij te grupy z zatwierdzonym inwentarzem nadawców.
3. Priorytetyzuj nieoczekiwane źródła o wysokim wolumenie, powtarzające się błędy zgodności i nieoczekiwane dyspozycje w ramach polityki.

Teraz

• Pogrupuj wiersze zbiorcze według źródłowego adresu IP i domeny header-from, a następnie porównaj je z zatwierdzonym inwentarzem wysyłkowym.

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Utrzymuj autorytatywny inwentarz nadawców, aby późniejsze okresy zbiorcze mogły być konsekwentnie uzgadniane.

Kontrole techniczne

Kryteria weryfikacji

• W późniejszych okresach zbiorczych potwierdź, że oczekiwane legalne źródła wykazują zgodność, a podejrzane źródło znika lub otrzymuje zamierzoną dyspozycję.
• Potwierdź trend zbiorczy za pomocą logów bezpieczeństwa, pamiętając, że odbiorcy mogą pomijać raporty i są jedynie zachęcani do raportowania co najmniej raz na 24 godziny.

Kryteria eskalacji

• Eskaluj do działu bezpieczeństwa, gdy źródło pozostaje niewyjaśnione po uzgodnieniu z inwentarzem; nie traktuj brakujących raportów od odbiorców ani samego błędu zgodności jako dowodu na kompromitację.

Zapobieganie

• Opublikuj prawidłowy rekord DMARC z zamierzonym miejscem docelowym raportowania rua.
• Utrzymuj aktualny inwentarz legalnych nadawców i z czasem uzgadniaj go z raportami zbiorczymi.

Wpływ na biznes

• Nieuzgodnione źródła mogą maskować możliwe nieautoryzowane użycie domeny, podczas gdy fałszywa etykieta złośliwego działania może zakłócić pracę legalnych nadawców.

Otwarte pytania

• Zaobserwowane źródłowe adresy IP, liczby, wyniki zgodności, inwentarz zatwierdzonych nadawców i potwierdzające logi bezpieczeństwa nie są podane, więc na podstawie samej tej paczki żadne źródło nie może zostać oznaczone jako złośliwe.
• Zasięg i czas raportowania przez odbiorców są różne, a niektórzy odbiorcy nie wysyłają raportów zbiorczych z powodów polityki, zasobów lub prywatności.

Pierwsze 15 minut

1. Zidentyfikuj, które miejsca docelowe zdarzeń i strumienie wysyłkowe zostały skonfigurowane i wybrane dla danych wysyłek.
2. Oddziel sukces żądania u dostawcy od dostarczenia do serwera odbiorcy i od trafienia do skrzynki odbiorczej.
3. Zrekonstruuj bezpieczną dla prywatności oś czasu na podstawie zachowanych znaczników czasu, identyfikatorów wiadomości, odpowiedzi SMTP lub DSN, webhooków i kontrolowanych nagłówków próbek.

Teraz

• Zrekonstruuj incydent na podstawie zachowanych znaczników czasu zakolejkowania i dostawcy, identyfikatorów wiadomości, odpowiedzi SMTP lub DSN, webhooków i kontrolowanych nagłówków.

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Ustaw alerty na luki między przesłanymi wiadomościami a wynikami końcowymi po zweryfikowaniu publikacji zdarzeń za pomocą kontrolowanej wysyłki.

Kontrole techniczne

Kryteria weryfikacji

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

Kryteria eskalacji

• Eskaluj do inżynierii i ESP, gdy publikacja zdarzeń pozostaje zepsuta, nie można zrekonstruować wymaganych identyfikatorów lub wyników, lub ładunki DeliveryDelay pokazują nierozwiązane tymczasowe błędy serwera odbiorcy.

Zapobieganie

• Skonfiguruj publikację zdarzeń dla każdego strumienia wysyłkowego i wybierz zamierzone miejsce docelowe zdarzeń dla każdej wysyłki.
• Stale 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, podczas gdy pozorny sukces u dostawcy może nadal pozostawiać trafienie do skrzynki odbiorczej i odbiór przez użytkownika nieznanymi.

Uwagi dostawcy

• W Amazon SES, Wysłanie (Send) oznacza, że żądanie się powiodło i SES spróbuje dostarczyć, podczas gdy Dostarczenie (Delivery) oznacza, że serwer pocztowy odbiorcy je zaakceptował; żadne z nich nie dowodzi trafienia do skrzynki odbiorczej.
• Gmail Postmaster Tools jest ograniczony do dostawcy, nie działa w czasie rzeczywistym i może pomijać dane o niskim wolumenie ze względów prywatności.

Otwarte pytania

• Dostawca, zachowane identyfikatory wiadomości, odpowiedzi SMTP, DSN, stan miejsca docelowego zdarzeń, strumień, domeny odbiorców i okno czasowe incydentu są niedostępne; w związku z tym rzeczywisty wynik dostarczenia nie jest możliwy do poznania na podstawie promptu.
• Nazwy zdarzeń, retencja, próbkowanie na dashboardzie i widoczność przy niskim wolumenie różnią się w zależności od ESP i dostawcy skrzynek pocztowych; zachowań SES i Gmaila nie można uogólniać.

Pierwsze 15 minut

1. Potwierdź zakres dat na dashboardzie i weź pod uwagę zwykłe 24-godzinne opóźnienie aktualizacji, dłuższe opóźnienia i pominięcia z powodu prywatności przy niskim wolumenie.
2. Interpretuj Wskaźnik Spamu, biorąc pod uwagę jego mianownik (uwierzytelnione przez DKIM wiadomości dostarczone do skrzynki odbiorczej) i sprawdź efekty automatycznego umieszczania w spamie.
3. Porównaj zgłoszony wskaźnik spamu z wytycznymi Gmaila, aby utrzymać go poniżej 0,10% i unikać 0,30% lub więcej.

Teraz

• Zmniejsz dany strumień kierowany do Gmaila, gdy spam w Postmaster osiągnie 0,30% lub więcej.

Najbliższe 24 godziny

• Ponownie sprawdź Status zgodności, biorąc pod uwagę jego kroczące, wielodniowe zachowanie, zamiast oczekiwać natychmiastowej zmiany statusu po wdrożeniu poprawki.

Najbliższe 7 dni

• Kontynuuj sprawdzanie kroczącego Statusu zgodności, ponieważ poprawka może wymagać czasu, aby pojawić się w jego wielodniowych średnich.

Kontrole techniczne

Kryteria weryfikacji

• Dane z Postmaster dla odpowiedniej daty zostały zaktualizowane, a wszelkie brakujące dni o niskim wolumenie są wyraźnie traktowane jako odfiltrowane ze względów prywatności, a nie jako zero skarg.
• Kroczący Status zgodności odzwierciedla poprawkę, a uwierzytelnione Błędy dostarczenia spadają dla tego samego zakresu ruchu.

Kryteria eskalacji

• Eskaluj do specjalisty ds. dostarczalności, gdy spam utrzymuje się na poziomie 0,30% lub wyższym, lub gdy uwierzytelnione Błędy dostarczenia utrzymują się po zmniejszeniu danego strumienia.

Zapobieganie

• Monitoruj spam w Gmail Postmaster w odniesieniu do zalecenia poniżej 0,10% i granicy 0,30%, której należy unikać, wraz z kroczącymi danymi o zgodności.

Wpływ na biznes

• Rosnący sygnał wskaźnika spamu w Gmailu wskazuje, że zaangażowani odbiorcy ręcznie odrzucają pocztę, podczas gdy automatyczne umieszczanie w spamie może ukrywać dodatkowy wpływ przed wyświetlanym procentem.

Uwagi dostawcy

• Starsze dashboardy Reputacji Domeny i IP mają zostać wycofane, a nie przeniesione w niezmienionej formie do Postmaster Tools v2, ale Google nie publikuje ostatecznej daty wycofania.

Otwarte pytania

• Nie podano eksportu z dashboardu, wolumenu wysyłki, zakresu dat, zestawu domen ani próbki błędu SMTP po stronie dostawcy, więc aktualna waga nie może zostać sklasyfikowana na podstawie samego pytania.
• Google nie publikuje ostatecznej daty wycofania starszych dashboardów reputacji i twierdzi, że wycofanie zostało przełożone.
• Brakujące lub niezwykle niskie dane o wskaźniku spamu mogą odzwierciedlać progi prywatności, pokrycie tylko dla DKIM lub automatyczne umieszczanie w spamie; nie jest to równoznaczne z zerową liczbą skarg.

Pierwsze 15 minut

1. Potwierdź konto AWS i Region, a następnie zapisz, czy SES pokazuje W trakcie przeglądu, Oczekujące wstrzymanie wysyłki czy Wysyłka wstrzymana.
2. Otwórz sprawę w AWS Support i zidentyfikuj przyczynę oraz działania naprawcze, jakich oczekuje AWS przed odpowiedzią.
3. Skoreluj metrykę skarg SES z powiadomieniami o zdarzeniach, danymi od dostawców skrzynek pocztowych, kampaniami i źródłami list, ponieważ jej pokrycie w zakresie informacji zwrotnych nie jest uniwersalne.

Teraz

• Jeśli konto jest w trakcie przeglądu i sytuacja na to pozwala, wstrzymaj pocztę i napraw przyczynę zidentyfikowaną w sprawie AWS.

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Przejrzyj pokrycie informacji zwrotnych o skargach i zachowaj dowody dotyczące kohorty, użyte do wyjaśnienia naprawionej przyczyny.

Kontrole techniczne

Kryteria weryfikacji

• Metryki reputacji SES dotyczące odrzuceń i skarg są poniżej warunków alarmowych incydentu i nadal są obserwowane na poziomie konta.
• Dotknięte konto i Region nie pokazują już W trakcie przeglądu, Oczekujące wstrzymanie wysyłki ani Wysyłka wstrzymana na stronie Reputacji.

Kryteria eskalacji

• Eskaluj natychmiast poprzez sprawę w AWS Support w przypadku stanów W trakcie przeglądu, Oczekujące wstrzymanie wysyłki lub Wysyłka wstrzymana, i opisz zakończone działania naprawcze i zapobiegawcze.

Zapobieganie

• Utrzymuj alarmy CloudWatch na udokumentowanych warunkach poziomu konta SES: 5% dla odrzuceń i 0,1% dla skarg, z niższymi wewnętrznymi ostrzeżeniami tam, gdzie potrzebne jest wcześniejsze wykrycie.
• Koreluj alerty o wskaźniku skarg SES z powiadomieniami o zdarzeniach, dostawcami, kampaniami i źródłami list, zamiast traktować tę metrykę jako pełne pokrycie skarg.

Wpływ na biznes

• Jeśli SES osiągnie stan Wysyłka wstrzymana, dotknięte konto i Region nie mogą wysyłać przez SES, co przerywa każdy zależny tam strumień e-mail.

Uwagi dostawcy

• Wskaźnik skarg SES obejmuje skargi z domen, które dostarczają informacje zwrotne do SES i wykorzystuje reprezentatywny wolumen zamiast stałego okna czasowego.

Otwarte pytania

• Konto AWS, Region, aktualny status konta SES, stan alarmu oraz zmierzone wskaźniki odrzuceń i skarg nie zostały podane.
• Dotknięte strumienie wysyłkowe i przyczyna jakiegokolwiek zdarzenia reputacyjnego pozostają nierozwiązane do czasu przejrzenia metryk SES, powiadomień i kohort odbiorców.
• Krytyczność kampanii, pochodzenie list, pokrycie informacji zwrotnych o skargach i wpływ na biznes nie są dostępne.

Pierwsze 15 minut

1. Przechwyć odpowiedzi SMTP na żywo i otwórz Błędy dostarczenia dla pasującej uwierzytelnionej domeny i okna czasowego, gdy objawem jest odrzucenie lub odroczenie.
2. Otwórz Uwierzytelnianie dla dokładnej dotkniętej tożsamości, gdy DNS lub uwierzytelnianie wiadomości mogło ulec zmianie.

Teraz

• Skieruj badanie do Błędów dostarczenia, Wskaźnika spamu, Reputacji lub Uwierzytelniania zgodnie z zaobserwowanym objawem i dotkniętą tożsamością.

Najbliższe 24 godziny

• Napraw dokładną przyczynę Błędów dostarczenia lub błąd uwierzytelniania i porównaj tę samą uwierzytelnioną kohortę po zmianie.

Najbliższe 7 dni

• Utrzymuj runbook przypisujący objawy do dashboardów, obejmujący błędy dostarczenia, skargi, reputację i uwierzytelnianie, zamiast polegać na jednym wykresie.

Kontrole techniczne

Kryteria weryfikacji

• Logi nadawcy na żywo i zaktualizowany widok Błędów dostarczenia pokazują spadek przyczyny odrzucenia lub odroczenia w incydencie dla dotkniętej uwierzytelnionej kohorty.
• Uwierzytelnianie zgłasza oczekiwane procenty pomyślnych wyników dla wybranej tożsamości, a otrzymana wiadomość potwierdza jej wynik na poziomie wiadomości.

Kryteria eskalacji

• Eskaluj do ESP lub specjalisty ds. dostarczalności, gdy błędy Gmaila na żywo utrzymują się, ale Postmaster jest pusty z powodu limitów wolumenu, lub gdy reputacja współdzielonego IP lub domeny nie może zostać wyizolowana wewnętrznie.

Zapobieganie

• Utrzymuj telemetrię SMTP na żywo obok monitorowania Postmaster, wybieraj dashboardy według objawu i tożsamości oraz dokumentuj opóźnienia w raportowaniu i ograniczenia zasięgu przy niskim wolumenie.

Wpływ na biznes

• Odrzucenia i tymczasowe błędy zmniejszają lub opóźniają zasięg w Gmailu, podczas gdy sygnały o reputacji i skargach mogą wskazywać na szersze ryzyko trafiania do spamu zamiast do skrzynki odbiorczej.

Uwagi dostawcy

• Postmaster Tools jest zazwyczaj aktualizowany w ciągu 24 godzin, ale może to potrwać dłużej, więc nie jest to źródło informacji o incydentach w czasie rzeczywistym.
• Zasięg Postmaster obejmuje ruch do osobistych kont Gmail, a Google może pominąć dane o niskim wolumenie ze względów prywatności.

Otwarte pytania

• Obecny objaw, wybrana domena Postmaster, wolumen nadawcy, okno czasowe incydentu i dotknięta populacja odbiorców Gmaila nie zostały podane.
• Prawidłowy pierwszy dashboard pozostaje nierozwiązany, dopóki objaw nie zostanie sklasyfikowany jako tymczasowe odroczenie, trwałe odrzucenie, umieszczenie w spamie, reputacja lub uwierzytelnianie.
• Dane Postmaster Tools na żywo 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 dashboard Postmaster, zweryfikowaną domenę, zakres dat i widoczne ostrzeżenie.
2. Powtórz pojedynczy test z tymi samymi domenami widocznymi w From, kopercie i DKIM, których używa ścieżka produkcyjna.
3. Dopasuj wybraną domenę Postmaster i widok produkcyjny do domen From, DKIM i SPF użytych w pojedynczym teście.

Teraz

• Użyj pojedynczego testu i agregatów produkcyjnych Postmaster razem, aby wyizolować dotkniętą ścieżkę.

Najbliższe 24 godziny

• Oddziel widoki domeny From, domeny DKIM i domeny SPF i zbadaj ruch z przekierowań lub list mailingowych, który zmienia agregat.

Najbliższe 7 dni

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

Kontrole techniczne

Kryteria weryfikacji

• Pojedynczy test i porównanie produkcyjne używają tej samej ścieżki domen widocznych w From, kopercie, DKIM i SPF.
• Pojedynczy test i dowody produkcyjne z Postmaster są używane razem do zidentyfikowania i rozwiązania problemu z wysyłką w danym zakresie.
• Wybrany dashboard produkcyjny pokazuje zrozumiały lub poprawiony sygnał uwierzytelniania, reputacji, spamu, szyfrowania lub błędu dostarczenia dla zweryfikowanej domeny.

Kryteria eskalacji

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

Zapobieganie

• Monitoruj produkcyjne agregaty Gmaila wraz z pojedynczymi testami uwierzytelniania, aby żadne nie było traktowane jako substytut 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 udanym teście może pozostawić niezbadaną kohortę dotyczącą uwierzytelniania, reputacji, spamu, szyfrowania lub błędów dostarczenia w Gmailu.

Uwagi dostawcy

• Postmaster obejmuje zagregowaną pocztę produkcyjną do osobistych kont Gmail i jest opóźniony oraz filtrowany pod kątem prywatności; LearnDMARC obserwuje jedną wiadomość na własnym serwerze odbiorczym.

Otwarte pytania

• Dokładne ostrzeżenie Postmaster, wybrana domena i zakres dat, widok dashboardu, wiadomość testowa LearnDMARC i próbki uwierzytelniania wiadomości produkcyjnych nie są podane, więc dotknięta kohorta produkcyjna pozostaje nieznana.
• Tester jednej wiadomości i opóźnione, filtrowane agregaty produkcyjne Gmaila mają różne zakresy, dane wejściowe i widoczność; jeden udany test nie unieważnia ostrzeżenia Postmaster.

Pierwsze 15 minut

1. Zweryfikuj próbkę przychodzącego XML i poddaj kwarantannie zniekształcone raporty, zamiast mieszać je z zaufanymi agregatami.
2. Zmierz zaległości w surowych raportach i zidentyfikuj, które zaakceptowane dane nie są jeszcze zindeksowane dla dashboardów lub monitorowania.

Teraz

• Odłóż na bok zniekształcony XML i traktuj wszelkie odzyskane dane jako wyraźnie niezaufane, dopóki nie zostaną zweryfikowane.

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Udostępnij zindeksowane dane poprzez raportowanie, dashboardy i monitorowanie odpowiednie do wolumenu raportów.

Kontrole techniczne

Kryteria weryfikacji

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

Kryteria eskalacji

• Skontaktuj się z generatorem raportów, gdy powtarzające się wady formatu uniemożliwiają weryfikację jego raportów.
• Eskaluj do właściciela monitorowania, gdy decyzje zakładają codzienne pełne pokrycie, ponieważ odbiorcy mogą zrezygnować z raportowania pomimo zalecenia raportowania co 24 godziny.

Zapobieganie

• Utrzymuj zaakceptowane dane z raportów zindeksowane dla dashboardów i monitorowania zamiast polegać na ręcznym przeglądzie surowego XML.
• Zaprojektuj wskaźniki pokrycia tak, aby tolerowały odbiorców, którzy nie generują raportów, ponieważ raportowanie jest zalecane, a nie gwarantowane.

Wpływ na biznes

• Nieprzetworzone raporty ukrywają sygnały dotyczące wysyłającego IP, wolumenu, polityki, dyspozycji, uwierzytelniania, zgodności i domen, które są potrzebne do oddzielenia legalnej poczty od nierozpoznanej.

Otwarte pytania

• Pokrycie raportami zbiorczymi DMARC jest niepełne i zmienne w zależności od dostawcy, ponieważ odbiorcy mogą zdecydować o niegenerowaniu raportów.

Pierwsze 15 minut

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

Teraz

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

Najbliższe 24 godziny

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

Najbliższe 7 dni

• Przetestuj zarówno e-mailowe, jak i skonfigurowane ścieżki powiadomień SMS dla krytycznych alertów Service Monitor.

Kontrole techniczne

Kryteria weryfikacji

• Kolejne 15-minutowe migawki usługi nie pokazują już dotkniętego warunku, a powtarzające się powiadomienia ustają.
• Skonfigurowane e-mailowe i niezależne ścieżki powiadomień SMS są z powodzeniem testowane dla krytycznych alertów.

Kryteria eskalacji

• Jeśli domyślny poziom eskalacji pozostaje na wartości pięć, a warunek się utrzymuje, sprawdź, czy subskrybenci eskalacji otrzymują szóste i kolejne powiadomienia w udokumentowanym punkcie 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.
• Używaj i testuj niezależny kanał powiadomień, 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órej monitorowanej usługi dotyczy.

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 najemcy, krytyczne usługi i mapowanie wagi incydentów są nieznane i muszą zostać dostarczone przez lokalną politykę operacyjną.