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: Die Kasse schlägt nach Büroschluss fehl
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 Online-Shop hat vier Ingenieure. Um 22:40 Uhr erkennt die Überwachung fehlgeschlagene Zahlungsanfragen, während Kunden noch zur Kasse gehen. Eine Nachricht im allgemeinen Chat sagt dem Support nicht, wer das Problem bearbeitet. Unvollendete Einkäufe und eine wachsende Support-Warteschlange stellen das Geschäftsrisiko dar; Die Warnung selbst ist nur das Signal.
Workflow mit IR. Senden Sie die Abrechnungsbenachrichtigung an den aktuellen Haupthelfer. Wenn niemand dies bestätigt, wird die Richtlinie auf das benannte Backup verschoben. Der zugewiesene Ingenieur nimmt die Gruppe zur Kenntnis und untersucht; Der Support kann den vereinbarten Vorfallprozess verwenden, um diesen Eigentümer zu finden und ein Update zu erhalten. Testen Sie diese Kette mit dem folgenden Fehler- und Wiederherstellungspaar.
Zu validierender betrieblicher Nutzen. Ersetzen Sie die manuelle Suche nach einem verfügbaren Techniker durch eine vordefinierte Eigentümerkette. Halten Sie die Verantwortung durch die Übergabe sichtbar, anstatt davon auszugehen, dass eine zugestellte Chat-Nachricht bedeutet, dass jemand daran arbeitet.
Was zu messen ist. Erfassen Sie die Zeit von der ersten umsetzbaren Warnung bis ACK, den innerhalb Ihres internen Ziels bestätigten Anteil und die Anzahl der manuellen Neuzuweisungen. Verfolgen Sie im E-Commerce-Monitoring fehlgeschlagene Checkouts und die Zeit bis zur Wiederaufnahme erfolgreicher Zahlungen separat.
Grenze. IR repariert weder die Kasse noch einen Zahlungsanbieter. Ein ACK beweist nicht, dass Kunden erneut zahlen können, und eine Eskalationsrichtlinie kann nicht helfen, wenn keiner der Techniker erreichbar ist. Behalten Sie den Fallback-Kontaktpfad und eine echte Überprüfung der Zahlungsrückerstattung bei.
Vier Ingenieure, ein Abrechnungsdienst, eine Eigentümerkette
Angenommen, vier Ingenieure teilen sich die Unterstützung für eine Abrechnung API. Beginnen Sie mit einem Team und einer wöchentlichen Primärrotation. Weisen Sie der Route einen Standarddienst und einen getesteten Lieferkanal zu. Fügen Sie explizit eine Ersatzperson hinzu. Ein gemeinsamer Chatroom ist keine Eskalationsrichtlinie.
| Objekt | Beispieleinstellung in der Benutzeroberfläche |
|---|---|
| Eigentum | Team payments; Dienst billing-api; Rotation payments-primary mit vier aktiven Mitgliedern und 24/7 Abdeckung. |
| Aufnahme | Quelle webhook, Standarddienst billing-api, Richtlinieneskalationsmodus und angehängte Benachrichtigungskanäle. |
| Eskalation | Regel 1: Primärrotation, Verzögerung 300 Sekunden. Regel 2: ein benannter Backup-Benutzer, Verzögerung 600 Sekunden. Legen Sie repeat_count=0 für dieses Pilotprojekt fest. |
Konfigurieren Sie Kanäle und Responder-Kontakte, bevor Sie eine Warnung senden. Öffnen Sie die vollständige Bereitstellungs-Gesundheitsdiagnose: Die Zusammenfassung in der grünen Tabelle allein scannt nicht die zukünftige Abdeckung oder beweist nicht, dass eine Nachricht ein Telefon erreicht.
Senden Sie einen Fehler und dann die Wiederherstellung
Senden Sie diese JSON-Körper separat mit Content-Type: application/json und Authorization: Bearer ROUTE_TOKEN an POST /api/integrations/webhook. Ersetzen Sie den Platzhalter durch das Testrouten-Token aus der Benutzeroberfläche. Halten Sie es von der Quellcodeverwaltung und freigegebenen Protokollen fern. Dies ist das generische Webhook-Format, kein normalisiertes Simulator-Ereignis.
{
"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"
}
}Behalten Sie zur Wiederherstellung die gleichen Routen-, Fingerabdruck- und Gruppierungsbezeichnungen bei. Der Fingerabdruck identifiziert den Kinderalarm; Wenn Sie ihn bei jeder Anfrage auf einen neuen Zufallswert ändern, wird die Deduplizierung zunichte gemacht. Bei einer verwaisten Wiederherstellung wird keine neue Gruppe erstellt.
Prüfen Sie die Kette vor einer echten Nachtschicht
- Schicken Sie den Zündkörper zweimal. Erwarten Sie eine untergeordnete Benachrichtigung, den vorgesehenen Dienst und den aktuellen primären Beauftragten; Bestätigen Sie die tatsächliche Lieferung, nicht nur einen HTTP-Erfolg.
- Lassen Sie eine separate Testwarnung unbestätigt. Überprüfen Sie, ob die Sicherung nach der ersten Richtlinienverzögerung zum Ziel wird. Die Taktfrequenz des Planers, die Warteschlangen und die Zustellung durch den Anbieter bedeuten, dass es sich hierbei nicht um eine genaue Liefer-SLA von fünf Minuten handelt.
- Bestätigen Sie eine andere Testgruppe und stellen Sie sicher, dass ausstehende Nur-Auslösungs-Benachrichtigungen gestoppt werden. Senden Sie die Wiederherstellung und bestätigen Sie, dass die Gruppe aufgelöst wird, wenn keine feuernden Kinder mehr vorhanden sind.
- Erstellen Sie eine temporäre Rotationsüberschreibung und wiederholen Sie den Test. Bestätigen Sie, dass es sich bei der Außerkraftsetzung um den effektiven Beauftragten handelt, und entfernen Sie dann die Testkonfiguration.
Wissen Sie, wann die Kette stoppt
Im Richtlinienmodus wird die auf Teamerinnerungen basierende Eskalation ignoriert. Nachdem alle Regeln und zulässigen Wiederholungen ausgeschöpft sind, werden die Richtlinienerinnerungen beendet. Der Alarm kann weiterhin ausgelöst werden. Eine Ersatzperson ohne funktionierende Kontaktdaten ist nur ein Name in einer Datenbank.
Bei ACK handelt es sich um das Eigentum, nicht um die Wiederherstellung des Abrechnungsdienstes. IR kann die Anwendung nicht reparieren oder einen fehlenden Techniker bereitstellen. Behalten Sie einen externen Weg bei, um das Team zu erreichen, wenn IR oder sein Benachrichtigungsanbieter nicht verfügbar sind, und vereinbaren Sie diesen Fallback während des Onboardings.