Funktionierte Beispiele für IncidentRelay v2.3.1, überprüft am . Die folgenden Namen, Kennungen und Zeitangaben dienen der Veranschaulichung. Validieren Sie sie in einer Testbereitstellung, bevor Sie Produktionsanmeldeinformationen verwenden.
Geschäftsbeispiel · Einrichtung · Arbeitsbeispiel · Abnahmeprüfungen · Grenzwerte und Fehlermodi
Geschäftsbeispiel: SaaS-Kunden arbeiten über Zeitzonen hinweg
Anschauliches Szenario, keine Kundenfallstudie. Bei den folgenden Kennzahlen handelt es sich um Vorschläge für Ihr Pilotprojekt, nicht um gemessene Einsparungen oder um die Behauptung, dass IR jedes Berichts-Dashboard umfasst.
Situation und Risiko. Ein B2B-SaaS-Team betreut Kunden in Europa und Nordamerika. Der Arbeitsnachmittag eines Kunden überschneidet sich mit dem Abend eines anderen Ingenieurs, und der übliche Helfer ist im Urlaub. Ohne einen vereinbarten Zeitplan verlässt sich das Team darauf, wer den Chat zuerst bemerkt. Das Risiko besteht in einem unbeabsichtigten Ausfall und wiederholten Unterbrechungen für dienstfreies Personal.
Workflow mit IR. Vereinbaren Sie eine personelle Abdeckung und stellen Sie diese dann mit einer Basisrotation und einer Arbeitstagsebene dar. Erfassen Sie Feiertagsvertretungen als Außerkraftsetzungen und konfigurieren Sie ein separates Backup-Eskalationsziel. Überprüfen Sie Übergaben und zukünftige Lücken. Verwenden Sie für eine geplante Abrechnungsbereitstellung ein dienstbezogenes Wartungsfenster, während unabhängige Dienste weiterhin Benachrichtigungen senden.
Zu validierender betrieblicher Nutzen. Machen Sie die Verantwortung für Support und Technik, einschließlich Urlaub und Übergaben, vorhersehbar. Geplante Arbeiten sollten nicht die Stummschaltung des gesamten Alarmstroms des Unternehmens erfordern.
Was zu messen ist. Überprüfen Sie die nicht abgedeckten Minuten in einem definierten zukünftigen Zeitraum, z. B. die nächsten 14 Tage, manuelle Übergaben in letzter Minute und Bestätigungen innerhalb des Reaktionsziels des Teams. Vergleichen Sie die nächtlichen Benachrichtigungen pro Ingenieur mit dem tatsächlichen Personalplan. Ein ausgeglichener Kalender allein zeigt die Arbeitsbelastung nicht an.
Grenze. Ein gefüllter Kalender schafft kein zusätzliches Personal und beweist nicht, dass jemand antworten kann. IR garantiert keine vertragliche Reaktionszeit und berechnet die Kundenverfügbarkeit nicht anhand von ACK s. Behalten Sie Personalentscheidungen, SLO-Überwachung und Kundenkommunikation im breiteren Betriebsprozess bei.
Decken Sie die Nacht ab, bevor Sie den Arbeitstag optimieren
Angenommen, ein SRE-Team verfügt über die Abrechnungszuverlässigkeit über eine Arbeitstagsschicht und einen Nachtschichtplan. Erstellen Sie in einer Rotation eine Basisebene mit der Priorität 10 und einer uneingeschränkten 24/7-Abdeckung. Fügen Sie eine Ebene mit der Priorität 20 hinzu, beschränkt auf Montag–Freitag, 09:00–18:00 Uhr in Europe/Berlin. Verwenden Sie echte aktive Mitglieder und überprüfen Sie den generierten Kalender.
Die aktive Schicht mit der höchsten Priorität versorgt den Beauftragten; Eine Überschreibung hat Vorrang vor Ebenen. Dabei handelt es sich nicht um zwei gleichzeitige Antwortende. Konfigurieren Sie ein separates Eskalationsziel oder eine separate Rotation für die Backup-Abdeckung. Wenn keine Ebene aktiv ist und keine Überschreibung gilt, gibt es keinen Beauftragten. Siehe Rotations- und Ebenenregeln.
Unterbrechen Sie Abrechnungsbenachrichtigungen während einer geplanten Bereitstellung
Erstellen Sie über die Schnittstelle ein dienstbezogenes Fenster oder übermitteln Sie diese Konfiguration mithilfe einer authentifizierten Verwaltungssitzung API mit der Berechtigung zum Ändern des Bereichs an POST /api/maintenance-windows. Ein Einlassrouten-Token ist kein Management-Berechtigungsnachweis. Ersetzen Sie 42 durch Ihre tatsächliche Abrechnungsdienst-ID und wählen Sie ein zukünftiges Testfenster.
{
"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
}
]
}Bei diesen Zeitstempeln handelt es sich um Uhrzeiten in der ausgewählten Zeitzone, nicht um UTC-Werte ohne Z. Während dieses Zeitfensters bleiben eingehende Abrechnungswarnungen sichtbar, Benachrichtigungen, Erinnerungen und Eskalationen werden jedoch angehalten. Andere Dienste sollen davon unberührt bleiben. Dieses Verhalten ist nicht suppress_incident, wodurch neue AlertGroups verhindert werden, oder pause_escalation_only, wodurch Benachrichtigungen aktiviert bleiben.
Testen Sie die Grenzen, nicht nur mitten in einer Schicht
- Überprüfen Sie den Auftrag kurz vor und nach 09:00 und 18:00 Uhr, an einem Wochenende und einer Sommerzeitumstellung. Fügen Sie eine temporäre Überschreibung hinzu, bestätigen Sie, dass sie erfolgreich ist, und entfernen Sie sie dann.
- Öffnen Sie die vollständige Gesundheitsprüfung auf Abruf. Überprüfen Sie das überprüfte zukünftige Fenster, Lücken, inaktive Mitglieder und verwendbare Zustellungsmethoden. Eine grüne Zusammenfassung ist kein Beweis für die dauerhafte Abdeckung oder die Zustellung an ein Telefon.
- Senden Sie während der Wartung Abrechnungs- und unabhängige Service-Testereignisse. Bestätigen Sie, dass die Abrechnung sichtbar, aber leise ist und der unabhängige Dienst weiterhin benachrichtigt. Um bereits ungelöste Warnungen einzubeziehen, aktivieren Sie explizit die Option, das Fenster auf vorhandene Warnungen anzuwenden. es ist standardmäßig deaktiviert.
- Lassen Sie die Abrechnung los, wenn das Fenster endet. Wenn die Reaktivierung aktiviert ist, können Sie überprüfen, ob die normale Benachrichtigung fortgesetzt wird, ohne jede verpasste Erinnerung erneut abzuspielen. Bestätigen Sie, dass der eigentliche Antwortende die Nachricht erhält und bestätigen kann.
Ein stiller Dienst ist kein wiederhergestellter Dienst
Die Wartung repariert den Dienst nicht, zieht zugestellte Nachrichten nicht zurück und impliziert keine Lösung. Die Reaktivierung am Ende ist standardmäßig aktiviert; Durch die Deaktivierung bleibt der Wartungseffekt nach Ende des Fensters erhalten. Überlappende Fenster können einen Alarm stillhalten, bis der letzte anwendbare aktive oder beibehaltene Effekt freigegeben wird. Sehen Sie sich diese Steuerelemente im Wartungshandbuch an.
Behalten Sie SLO-Berechnungen und Burn-Rate-Erkennung in Ihrem Überwachungsstapel. IR leitet und koordiniert die resultierenden Signale. Eine AlertGroup ist für die technische Bestätigung, Lösung, Benachrichtigung und Eskalation zuständig. Ein Vorfall ist ein separater betrieblicher Arbeitsablauf. Durch die Verknüpfung mehrerer AlertGroups mit einem Vorfall werden deren technische Historien nicht zusammengeführt. In Version 2.3.1 gehören Responder und Stakeholder weiterhin zu AlertGroups. Testen Sie beide Lebenszyklen, anstatt eine Änderung des Vorfallstatus als AlertGroup ACK zu behandeln.