Sprawdzone przykłady dla IncidentRelay v2.3.1, sprawdzone . Poniższe nazwy, identyfikatory i czasy mają charakter ilustracyjny; Sprawdź je we wdrożeniu testowym przed użyciem poświadczeń produkcyjnych.
Przykład biznesowy · Konfiguracja · Przykład praktyczny · Kontrola akceptacji · Ograniczenia i tryby awarii
Przykład biznesowy: realizacja transakcji kończy się niepowodzeniem po zamknięciu biura
Przykładowy scenariusz, a nie studium przypadku klienta. Poniższe dane to sugestie dotyczące pilotażu, a nie zmierzone oszczędności lub stwierdzenie, że IR obejmuje każdy panel raportowania.
Sytuacja i ryzyko. W sklepie internetowym pracuje czterech inżynierów. O godzinie 22:40 jego monitorowanie wykrywa nieudane żądania płatności, gdy klienci są jeszcze w trakcie realizacji transakcji. Wiadomość na czacie ogólnym nie informuje pomocy technicznej, kto zajmuje się problemem. Niedokończone zakupy i rosnąca kolejka do wsparcia to ryzyko biznesowe; samo ostrzeżenie jest jedynie sygnałem.
Przebieg pracy z wykorzystaniem podczerwieni. Wyślij alert dotyczący płatności do bieżącego głównego osoby reagującej. Jeśli nikt tego nie potwierdzi, polityka zostanie przeniesiona do nazwanej kopii zapasowej. Wyznaczony inżynier potwierdza grupę i bada; dział pomocy technicznej może skorzystać z uzgodnionego procesu incydentu, aby znaleźć tego właściciela i uzyskać aktualizację. Przetestuj ten łańcuch za pomocą poniższej pary awarii i odzyskiwania.
Korzyść operacyjna do sprawdzenia. Zastąp ręczne wyszukiwanie dostępnego inżyniera wstępnie zdefiniowanym łańcuchem własności. Staraj się, aby odpowiedzialność była widoczna podczas przekazania, zamiast zakładać, że dostarczona wiadomość na czacie oznacza, że ktoś nad nią pracuje.
Co mierzyć. Zapisz czas od pierwszego alertu, który można podjąć, do ACK, udział potwierdzony w ramach celu wewnętrznego oraz liczbę ręcznych ponownych przypisań. Oddzielnie śledź nieudane transakcje i czas do wznowienia pomyślnych płatności w monitorowaniu handlu.
Granica. Podczerwień nie naprawia kasy ani dostawcy płatności. ACK nie stanowi dowodu, że klienci mogą zapłacić ponownie, a zasady eskalacji nie mogą pomóc, jeśli żaden z inżynierów nie jest osiągalny. Zachowaj rezerwową ścieżkę kontaktu i rzeczywistą kontrolę odzyskania płatności.
Czterech inżynierów, jedna usługa rozliczeniowa, jeden łańcuch własności
Załóżmy, że czterech inżynierów wspólnie pomaga w rozliczeniu API. Zacznij od jednego zespołu i jednej cotygodniowej rotacji podstawowej. Nadaj trasie domyślną usługę i jeden przetestowany kanał dostawy. Dodaj osobę zastępczą bezpośrednio; wspólny pokój rozmów nie jest polityką eskalacji.
| Obiekt | Przykładowe ustawienie w interfejsie użytkownika |
|---|---|
| Własność | Zespół payments; usługa billing-api; rotacja payments-primary z czterema aktywnymi członkami i zasięgiem 24/7. |
| Wlot | Źródło webhook, usługa domyślna billing-api, tryb eskalacji zasad i dołączone kanały powiadomień. |
| Eskalacja | Zasada 1: rotacja podstawowa, opóźnienie 300 sekund. Zasada 2: nazwany użytkownik zapasowy, opóźnij 600 sekund. Ustaw repeat_count=0 dla tego pilota. |
Przed wysłaniem alertu skonfiguruj kanały i kontakty osób odpowiadających. Otwórz pełną Diagnostykę stanu na wezwanie: samo podsumowanie zielonej tabeli nie pozwala na sprawdzenie przyszłego zasięgu ani na potwierdzenie, że wiadomość dotrze na telefon.
Wyślij jedną awarię, a następnie jej odzyskanie
Wyślij te JSON ciała oddzielnie do POST /api/integrations/webhook za pomocą Content-Type: application/json i Authorization: Bearer ROUTE_TOKEN. Zastąp symbol zastępczy tokenem trasy testowej z interfejsu użytkownika; trzymaj go poza kontrolą źródła i udostępnionymi dziennikami. To jest ogólny format webhooka, a nie znormalizowane zdarzenie symulatora.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}Zachowaj tę samą trasę, odcisk palca i etykiety grupujące na potrzeby odzyskiwania. Odcisk palca identyfikuje alert podrzędny; zmiana jej na nową losową wartość przy każdym żądaniu eliminuje deduplikację. Powrót do zdrowia sieroty nie powoduje utworzenia nowej grupy.
Sprawdź łańcuch przed prawdziwą nocną zmianą
- Wyślij korpus egzekucyjny dwa razy. Spodziewaj się jednego alertu podrzędnego, zamierzonej usługi i bieżącego głównego cesjonariusza; potwierdź rzeczywistą dostawę, a nie tylko sukces w wysokości HTTP.
- Pozostaw osobny alert testowy bez potwierdzenia. Sprawdź, czy kopia zapasowa stanie się celem po pierwszym opóźnieniu wynikającym z zasad. Taktowanie harmonogramu, kolejkowanie i dostawa przez dostawcę oznaczają, że nie jest to dokładnie pięciominutowa umowa SLA na dostawę.
- Potwierdź inną grupę testową i sprawdź, czy powiadomienia oczekujące na uruchomienie zostały zatrzymane. Wyślij odzyskiwanie i potwierdź, że grupa zostanie rozpatrzona, gdy nie pozostaną żadne zwalniające dzieci.
- Utwórz tymczasowe zastąpienie rotacji i powtórz test. Potwierdź, że zastąpienie jest efektywną osobą przypisaną, a następnie usuń konfigurację testową.
Wiedz, kiedy łańcuch się zatrzyma
W trybie zasad eskalacja oparta na przypomnieniach zespołu jest ignorowana. Po wyczerpaniu wszystkich zasad i dozwolonych powtórzeń przypomnienia o zasadach przestają działać; alert może nadal być uruchamiany. Osoba zastępcza bez roboczych danych kontaktowych to tylko nazwisko w bazie danych.
ACK oznacza własność, a nie odzyskanie usługi rozliczeniowej. IR nie może naprawić aplikacji ani dostarczyć brakującego inżyniera. Zachowaj zewnętrzny sposób kontaktu z zespołem, jeśli IR lub jego dostawca powiadomień jest niedostępny, i uzgodnij tę opcję zastępczą podczas wdrażania.