Warum selbst Gastgeber einer On-Call-Plattform?
Bereitschaftssysteme enthalten sensible Betriebsdaten: Mitarbeiterpläne, Kontaktdaten, Alarmierungsnutzlasten, Dienstnamen, Zeitpläne für Vorfälle und Links zu internen Systemen. Einige Teams ziehen es vor, diese Informationen in ihrem eigenen Netzwerk und ihrer eigenen Datenbank zu speichern.
Self-Hosting gibt Teams auch die Kontrolle über Bereitstellungs-Timing, Integrationen, Aufbewahrung, Backups und Zugriffsgrenzen. Der Kompromiss ist einfach: Sie betreiben die Plattform und besitzen ihre Verfügbarkeit. Es gibt keine magische Wolke, nur einen Computer, der Rechnungen woanders erhält.
Was IncidentRelay beinhaltet
- Bereitschaftspläne, Rotationsebenen und vorübergehende Außerkraftsetzungen.
- Alarm-Routing für Alertmanager, Zabbix, Sentry und generische Webhooks.
- Eskalationsrichtlinien, Erinnerungen und Antwortanfragen.
- Services, Abhängigkeiten, Wartungsfenster und Incident-Prioritäten.
- Mattermost, Telegram, E-Mail, Browser Push, Webhook und Sprachbenachrichtigungen.
- Persönliche API Token und Open API Dokumentation.
Bereitstellungsoptionen
IncidentRelay unterstützt mehrere Bereitstellungsmodelle, so dass Teams vertraute operative Tools verwenden können.
| Methode | Typische Verwendung |
|---|---|
| Docker Compose | Evaluierung, kleinere Umgebungen und unkomplizierte Containerbereitstellungen. |
| RPM packages | Red Hat-ähnliche Linux-Systeme, die über package- und systemd-Workflows verwaltet werden. |
| Manuelles Systemd | Source-basierte Bereitstellungen und benutzerdefinierte Python-Umgebungen. |
| Helm Diagramm | Kubernetes Bereitstellungen mit separatem Web, Scheduler und optionalen Telegram Arbeitern. |
Datenbank- und Skalierungsoptionen
SQLite ist für kleine Installationen mit einzelnen Knoten verfügbar. PostgreSQL ist die praktische Wahl für größere oder länger laufende Umgebungen, ein höheres Alarmvolumen und Bereitstellungen mit mehreren Webworkern. Der Scheduler läuft als separater Prozess, so dass Erinnerungen und Eskalationen nicht über Webworker dupliziert werden.
Integrieren Sie den stack, den Sie bereits ausführen
IncidentRelay fungiert als Routing-Schicht zwischen Monitoring-Systemen, Service Ownership, Zeitplänen und Benachrichtigungszielen. Routen haben ihre eigenen Eingangsmarken und bestimmen, wohin eingehende Warnungen gehen. Kanäle beschreiben, wie der ausgewählte Responder benachrichtigt wird.
Generische Webhooks und Open API Endpunkte ermöglichen es, interne Tools zu verbinden, ohne auf eine herstellerspezifische Integration zu warten. Benutzerdefinierte Sprachanbieter können für Teams installiert werden, die ihren eigenen Telefonie-Workflow betreiben.
Operative Verantwortlichkeiten
Eine selbst gehostete Incident-Plattform sollte wie eine Produktionsinfrastruktur behandelt werden. Planen Sie Datenbank-Backups, überwachen Sie die Web- und Scheduler-Dienste, testen Sie Benachrichtigungskanäle und halten Sie einen Notfallpfad für Vorfälle IncidentRelay selbst.
API s, Konfiguration und Schema können sich zwischen den Releases entwickeln, also überprüfen Sie die Release-Notizen und testen Sie Upgrades vor dem Rollout der Produktion.