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: Ein nächtliches Backup wird nie abgeschlossen
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 Unternehmen sichert seine Auftragsdatenbank vor Arbeitsbeginn auf zwei Servern. Ein Job stoppt lautlos; der andere hat Erfolg. Ein einziges gemeinsames Erfolgssignal würde die Lücke verdecken. Das Geschäftsrisiko besteht darin, einen alten oder fehlenden Wiederherstellungspunkt erst dann zu entdecken, wenn eine Wiederherstellung erforderlich ist.
Workflow mit IR. Definieren Sie einen Abschlusstermin und verfolgen Sie jeden erwarteten Server separat. Ein Host sendet seinen Heartbeat erst, nachdem die Job- und Erfolgsüberprüfungen abgeschlossen sind. Bei fehlender Fertigstellung wird eine Überfälligkeitswarnung mit einem Backup-Eskalationspfad an den Plattform-Responder weitergeleitet. Der Techniker untersucht den Job oder führt ihn erneut aus und zeichnet das Ergebnis auf.
Zu validierender Betriebsvorteil. Verwandeln Sie einen stillen geplanten Jobfehler in eine eigene Aufgabe vor der nächsten Geschäftsschicht. Das gleiche Muster kann einen geplanten Export- oder Batch-Job abdecken, vorausgesetzt, dass das Abschlusssignal tatsächlich einen Erfolg anzeigt.
Was zu messen ist. Verfolgen Sie versäumte Fristen pro Server, die Zeit von der Frist bis zur Bestätigung und das Alter des letzten verifizierten Backups. Bewahren Sie die Ergebnisse der Backup-Überprüfung und der Wiederherstellungsübung im Backup-System oder im Betriebsbericht auf; folgere sie nicht aus einem grünen Herzschlag.
Grenze. Ein Heartbeat beweist, dass ein Signal angekommen ist, nicht, dass die Daten wiederhergestellt werden können. Es wird kein Wiederherstellungspunkt oder eine Wiederherstellungszeit garantiert. Testen Sie Wiederherstellungen unabhängig und überwachen Sie IR selbst von außerhalb derselben Fehlerdomäne.
Behandeln Sie das Paging-System als einen Dienst, den Sie betreiben
Stellen Sie sich ein Plattformteam vor, das über einen Produktionscluster und nächtliche Datenbanksicherungen verfügt. Es möchte IR in der Nähe seines Überwachungsstapels haben, aber das macht das Team auch für das System verantwortlich, das es aufweckt. Benennen Sie einen Eigentümer für den Webdienst, den Scheduler, die Datenbank, die Geheimnisse und das Wiederherstellungsverfahren.
Das Release-Docker-Setup führt Web- und Planerdienste getrennt aus. Nachdem Sie diese Bereitstellungsanleitung in einer Testumgebung befolgt haben, überprüfen Sie sie beim Release-Checkout:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerDer Webprozess akzeptiert eingehende Warnungen; Der Scheduler kümmert sich um Erinnerungen, Eskalationen und periodische Aufgaben. Starten Sie nicht in jedem Web-Worker einen Scheduler. Eine funktionierende Anmeldeseite ist kein Beweis dafür, dass eine zeitgesteuerte Eskalation ausgeführt wird.
Erkennen Sie ein fehlendes Backup auf einem Host
Erstellen Sie einen geplanten Abschluss-Heartbeat, der täglich um 03:00 UTC fällig ist und an eine Route angehängt ist, deren Quelle heartbeat ist. Instanzverfolgung aktivieren; Verwenden Sie für eine feste Flotte statische erwartete Instanzen wie db-1 und db-2. Hängen Sie die Plattformrotation oder Richtlinien- und Testkanäle an.
Nachdem die Sicherung eines Hosts und seine Erfolgsprüfungen abgeschlossen sind, senden Sie diesen Text mit dem Inhaltstyp JSON an POST /api/heartbeats/ping/HEARTBEAT_TOKEN. Verwenden Sie die geheime URL dieses Heartbeats, kein Routen-Token oder ein administratives API-Token.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Senden Sie von jedem Host einen eindeutigen Instanzwert. Ohne Instanzverfolgung kann ein erfolgreicher Ping von einem Server das fehlende Backup eines anderen Servers verbergen. Senden Sie nach einem fehlgeschlagenen Job nicht bedingungslos einen Erfolgs-Ping von einem Shell-Cleanup-Handler. Schwärzen Sie geheime Ping-URLs aus Proxy- und Jobprotokollen.
Testfehler, nicht nur Start
- Pingen Sie beide erwarteten Instanzen und lassen Sie dann in einem kurzen Testplan bewusst eine aus. Erwarten Sie für diese Instanz eine Überfälligkeitswarnung, während die fehlerfreie Instanz in Ordnung bleibt.
- Setzen Sie die fehlende Instanz fort. Wenn die automatische Auflösung aktiviert ist, stellen Sie sicher, dass die Überfälligkeitswarnung behoben wird, ohne den Fehler einer anderen Instanz zu beheben.
- Stoppen Sie den Scheduler nur in der Testbereitstellung. Beobachten Sie die Auswirkung auf die zeitgesteuerte Arbeit und beweisen Sie, dass ein unabhängiger Überwacher sie bemerkt. Stellen Sie es dann wieder her und überprüfen Sie die Verarbeitung.
- Stellen Sie die Datenbank, die Konfiguration und die erforderlichen Geheimnisse in einer isolierten Umgebung wieder her, wobei ausgehende Benachrichtigungen blockiert werden. Überprüfen Sie alte Auslösegruppen, bevor Sie die Zustellung zulassen, damit eine Wiederherstellungsübung keine Produktionshelfer ausrufen kann.
Ein erfolgreicher Ping ist kein Wiederherstellungstest
Heartbeats erkennen fehlende Signale; Es handelt sich nicht um aktive HTTP/TCP-Prüfungen und sie können nicht nachweisen, dass ein Backup verwendbar ist. IR kann Sie auch nicht zuverlässig über den eigenen Totalausfall informieren. Behalten Sie eine externe Verfügbarkeitsprüfung und einen separaten Kontaktpfad außerhalb derselben Fehlerdomäne bei.
Durch das Selbsthosting werden Chat-, E-Mail-, Sprach- oder Netzwerkabhängigkeiten nicht beseitigt. Entscheiden Sie, welche Datenbank und welches Bereitstellungsmodell zur Arbeitslast passen, heften Sie die getestete Version fest und üben Sie Upgrades und Rollbacks. Diese Beispiele begründen weder eine hohe Verfügbarkeit noch eine Durchsatzgarantie.
Legen Sie die Aufbewahrung bewusst fest: Der Verlauf gelöster Warnungen wird standardmäßig auf unbestimmte Zeit aufbewahrt. Durch die Bereinigung können auch verknüpfte Kommentare und Zustellungsdatensätze entfernt werden, die Datenbankdatei wird jedoch nicht zwangsläufig verkleinert. Die Aufbewahrung ist kein Ersatz für Backups.