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: klienci SaaS pracują w różnych strefach czasowych
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. Zespół B2B SaaS obsługuje klientów w Europie i Ameryce Północnej. Popołudnie pracy klienta pokrywa się z wieczorem innego inżyniera, a osoba udzielająca pomocy jest na wakacjach. Bez ustalonego harmonogramu zespół polega na tym, kto pierwszy zauważy czat. Ryzykiem są niezamierzone przestoje i powtarzające się przerwy w pracy personelu niebędącego na służbie.
Przepływ pracy za pomocą technologii IR. Uzgodnij zakres obsługi personelu, a następnie przedstaw go za pomocą rotacji podstawowej i warstwy dni roboczych. Rejestruj zastępstwa urlopowe jako zastąpienia i konfiguruj oddzielny cel eskalacji kopii zapasowej. Sprawdź przekazania i przyszłe luki. W przypadku planowanego wdrożenia rozliczeń użyj okna konserwacji o zakresie usługi, podczas gdy niepowiązane usługi będą nadal powiadamiać.
Korzyści operacyjne do sprawdzenia. Zapewnij przewidywalność odpowiedzialności za wsparcie i inżynierię, w tym za urlopy i przekazania. Zaplanowane prace nie powinny wymagać wyciszenia strumienia alertów całej firmy.
Co mierzyć. Sprawdź nieobjęte minuty w określonym przyszłym okresie, np. w ciągu najbliższych 14 dni, ręczne przekazania w ostatniej chwili i potwierdzenia w ramach docelowej reakcji zespołu. Porównaj powiadomienia nocne przypadające na inżyniera z rzeczywistym harmonogramem zatrudnienia; sam zrównoważony kalendarz nie pokazuje obciążenia pracą.
Granica. Wypełniony kalendarz nie tworzy dodatkowych pracowników ani nie udowadnia, że ktoś może odpowiedzieć. IR nie gwarantuje umownego czasu reakcji ani nie oblicza dostępności klienta na podstawie potwierdzeń. Zachowaj decyzje kadrowe, monitorowanie SLO i komunikację z klientami w szerszym procesie operacyjnym.
Przykryj noc przed optymalizacją dnia pracy
Załóżmy, że zespół SRE jest niezawodny w zakresie rozliczeń w trybie zmianowym w dni robocze i w systemie nocnym. W jednym obrocie utwórz warstwę bazową z priorytetem 10 i nieograniczonym pokryciem 24/7. Dodaj warstwę o priorytecie 20, ograniczoną od poniedziałku do piątku, 09:00-18:00 w Europe/Berlin. Wykorzystaj naprawdę aktywnych członków i zweryfikuj wygenerowany kalendarz.
Aktywna warstwa o najwyższym priorytecie dostarcza cesjonariuszowi; nadpisanie ma pierwszeństwo przed warstwami. To nie są dwie osoby reagujące jednocześnie. Skonfiguruj oddzielny cel eskalacji lub rotację na potrzeby tworzenia kopii zapasowych. Jeśli żadna warstwa nie jest aktywna i nie ma zastosowania żadne zastąpienie, nie ma przypisanej osoby. Zobacz reguły obrotu i warstw.
Wstrzymaj powiadomienia rozliczeniowe podczas planowanego wdrożenia
Utwórz okno o zakresie usługi za pośrednictwem interfejsu lub prześlij tę konfigurację do POST /api/maintenance-windows przy użyciu uwierzytelnionej sesji zarządzania API z uprawnieniami do modyfikowania zakresu. Token trasy spożycia nie jest poświadczeniem zarządzania. Zastąp 42 rzeczywistym identyfikatorem usługi rozliczeniowej i wybierz przyszłe okno testowe.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}Te znaczniki czasu to czasy zegara ściennego w wybranej strefie czasowej, a nie wartości UTC z pominiętym Z. W tym oknie przychodzące alerty rozliczeniowe pozostają widoczne, ale powiadomienia, przypomnienia i eskalacje są wstrzymane. Pozostałe usługi powinny pozostać niezmienione. To zachowanie nie jest suppress_incident, które zapobiega tworzeniu nowych grup alertów, ani pause_escalation_only, które powoduje włączenie powiadomień.
Testuj granice, a nie tylko środek zmiany
- Sprawdzaj przydział zadań tuż przed i po 09:00 i 18:00, w weekendy i podczas przejścia na czas letni. Dodaj tymczasowe zastąpienie i potwierdź, że wygrywa, a następnie usuń je.
- Otwórz pełną kontrolę stanu na wezwanie. Przejrzyj sprawdzone okno na przyszłość, luki, nieaktywnych członków i użyteczne metody dostawy. Zielone zestawienie nie jest dowodem objęcia ubezpieczeniem na stałe ani dostarczenia go na telefon.
- Wysyłaj zdarzenia testowe związane z rozliczeniami i niepowiązanymi usługami podczas konserwacji. Upewnij się, że rozliczenia są widoczne, ale ciche, a niepowiązana usługa nadal powiadamia. Aby uwzględnić już nierozwiązane alerty, jawnie włącz opcję zastosowania okna do istniejących alertów; jest domyślnie wyłączony.
- Pozostaw rozliczenia uruchomione po zakończeniu okna. Po włączeniu ponownej aktywacji możesz sprawdzić, czy powiadomienia zostaną wznowione bez konieczności odtwarzania każdego pominiętego przypomnienia. Potwierdź, że rzeczywisty respondent otrzymał wiadomość i może ją potwierdzić.
Cicha usługa nie jest usługą odzyskaną
Konserwacja nie naprawia usługi, nie wycofuje dostarczonych wiadomości ani nie sugeruje rozwiązania. Ponowna aktywacja na końcu jest domyślnie włączona; wyłączenie tej opcji powoduje zachowanie efektu konserwacji po zamknięciu okna. Nakładające się okna mogą wyciszyć alert do czasu zwolnienia ostatniego aktywnego lub zachowanego efektu. Przejrzyj te elementy sterujące w przewodniku konserwacji.
Przechowuj obliczenia SLO i wykrywanie szybkości spalania w stosie monitorowania. Podczerwień kieruje i koordynuje powstałe sygnały. Grupa AlertGroup jest właścicielem potwierdzeń technicznych, rozwiązań, powiadomień i eskalacji; Incydent to oddzielny proces operacyjny. Powiązanie kilku AlertGroupów z jednym Incydentem nie powoduje połączenia ich historii technicznej. W wersji 2.3.1 ratownicy i zainteresowane strony nadal należą do AlertGroups. Przetestuj oba cykle życia zamiast traktować zmianę stanu zdarzenia jako grupę alertów ACK.