Status, Service-Ziele und Meldewege.
Diese Seite trennt aktuellen Produktbetrieb, erste Service-Ziele und noch offene Betriebsnachweise. Sie ist für den ersten Release bewusst konservativ gehalten.
Stand: 29. Juni 2026
Datenbasierter Status für den ersten Release
Aktueller Service-Stand
Der Stand ist produktbezogen, nicht marketingbezogen. Wenn ein Nachweis noch fehlt, steht er hier als offen.
| Service | Stand | Nachweis | Nächster Schritt |
|---|---|---|---|
| app.obhut.io Dashboard | In Betrieb | Login, Tenant-Flächen, System-Health und Job-Health sind gebaut. | Dashboard-CSP und externe Erreichbarkeitsprüfung vor Launch anhängen. |
| Access Edge | In Betrieb | Health-, Readiness- und Metrics-Endpunkte existieren; Datenpfad ist DB-frei. | Monitor-Cron live installieren und erste Alert-Evidence anhängen. |
| Audit und SIEM | In Betrieb | Hash-Chain, Evidence-Bundle, Pull-Export und generischer HTTPS-Push mit Auto-Flush sind gebaut. | Durable Worker und Multi-Instance-Ownership später ergänzen. |
| Backup/DR | Skript-Baseline | Postgres- und Maildir-Backups werden verschlüsselt off-box übertragen; Restore-Drill schreibt JSON-Evidence. | Live-Ziel konfigurieren, Cron aktivieren, ersten Restore-Drill dokumentieren. |
Service-Ziele für den ersten Release
Diese Ziele sind die operative Grundlage für Design-Partner. Vertraglich bindende Zusagen werden im jeweiligen Kundenvertrag festgelegt.
| Bereich | Ziel | Aktueller Nachweis |
|---|---|---|
| Reaktionszeit bei kritischen Incidents | Eingang prüfen und erste Rückmeldung am selben Geschäftstag. | Meldeweg und Incident-Runbook sind dokumentiert. |
| Statuskommunikation | Öffentliche Statusseite aktualisieren, sobald ein kundensichtbarer Vorfall bestätigt ist. | Diese Seite rendert den versionierten Incident-Verlauf. |
| Wiederherstellung | RTO/RPO erst nach dem ersten Live-Restore-Drill öffentlich beziffern. | Restore-Drill-Skript schreibt `rtoSeconds` und `rpoSecondsFromBackupMtime`. |
| Wartung | Geplante, kundensichtbare Wartung vorab ankündigen. | Kommunikationsweg und Incident-Verlauf sind vorhanden. |
Incident-Verlauf
Der Verlauf wird aus einer versionierten Status-Datei gerendert. So bleibt der öffentliche Status reproduzierbar und reviewbar.
Keine kundensichtbaren Incidents seit Start des Statusverlaufs.
Der erste Release hat noch keine bestätigten kundensichtbaren Ausfälle im öffentlichen Verlauf. Bestätigte Vorfälle werden hier mit Start, Ende, betroffenen Diensten und Kurzfassung ergänzt.
Verlauf zuletzt abgeglichen:
Meldewege
Betriebsstörungen und Sicherheitsmeldungen laufen bewusst über direkte, erste Partei betriebene Kanäle.
- 1Meldung erfassen: betroffener Dienst, Zeitraum, Auswirkungen, Kontakt.
- 2Einstufen: Betriebsstörung, Sicherheitsvorfall oder Supportfall.
- 3Kommunizieren: Statusseite aktualisieren, wenn ein kundensichtbarer Vorfall bestätigt ist.
- 4Nachbereiten: Ursache, Maßnahmen und Nachweise im Incident-Log festhalten.