Nachweise und Aufbewahrung

Die Grenzen sind gemessen, nicht gesetzt

Das SLA-Fenster eines Incidents läuft von der Bestätigung durch das Quorum bis zur bestätigten Wiederherstellung. Das sind dieselben beiden Zeitpunkte, zu denen Sie alarmiert wurden. Wird ein Fehlalarm verworfen, rechnet Perstat das Ausschlussfenster für jede betroffene Region einzeln aus: vom letzten erfolgreichen Check vor dem Incident bis zum ersten erfolgreichen Check danach. Keine Minute wird zurechtgebogen, damit die Zahl freundlicher aussieht.

Was der Report zählt

Ein Incident fließt in den Report ein, wenn er den Berichtszeitraum überlappt. Zwei Klassen bleiben draußen:

• Ausgeschlossene Incidents: Ausfallzeit, die Sie als Fehlalarm verworfen haben. Der Ausschluss ist Ihre aufgezeichnete Entscheidung, und sie zusätzlich in den Zahlen zu zählen, würde sie doppelt anwenden.
• Gelöschte Incidents.

Angekündigte Wartungsfenster, die den Monitor betreffen, stehen im Report als eigene Klasse. So ist genau zu sehen, was geplant war und was nicht.

Reports tragen die Ereignisse, die Sie freigeben

Die Zeitleiste eines Incidents im SLA-Report enthält die Ereignisse, die ausdrücklich als öffentlich markiert sind. Ereignisse sind standardmäßig internal, ein Ereignis gelangt also nach außen, sobald jemand es freigibt.

Der Filter sitzt in der Abfrage, die den Report erzeugt, und wirkt damit auf jedem Weg, den ein Report nimmt. Ein Report ist dazu da, das Haus zu verlassen: Er geht an Kunden und Prüfer. Der Filter in der Abfrage stellt sicher, dass er nie mehr trägt, als nach außen darf.

Soll eine interne Notiz in einem Nachweis für Kunden erscheinen, markieren Sie sie als öffentlich. Alles andere bleibt standardmäßig intern.

Die Rechnung

Die Verfügbarkeit wird abgerundet, nie aufgerundet. Eine SLA-Zahl soll eine untere Schranke sein, die Sie verteidigen können. Der Beispiel-SLA-Report zeigt den vollständigen Aufbau mit Zahlen, die aufgehen. Geben Sie ihn jemandem, der nachrechnet.

Was welches Historienfenster steuert

Die Tarif-Fenster betragen 7 Tage (Free), 30 Tage (Pulse), 90 Tage (Sentinel), 365 Tage (Command) und 730 Tage (Enterprise). Perstat wendet sie je Datenart an, jede mit ihrem eigenen Horizont:

Daten oder Ansicht	Technisch durchgesetzter Horizont
Öffentliche Historie geschlossener Monitor-Incidents	Leselimit am Tarif-Fenster. Der Incident wird nicht automatisch gelöscht.
Rohe externe Probe-Checks	Die physische Bereinigung nutzt das Tarif-Fenster plus 2 Tage technischen Puffer.
Rohkurven der Host-Agent-Messwerte	Bis zu 90 Tage, in jedem Tarif.
Uptime-Verlauf einer Statusseite	Bis zu 365 Tage, in jedem Tarif.
Tagesaggregate, Incident- und Post-mortem-Versionen, Aktivität und weitere Datensätze	Objektbezogener Lebenszyklus, unabhängig vom Tarif-Fenster. Ein Teil davon läuft derzeit nicht automatisch ab.

Die AGB nennen daneben 13 Monate als Standard für Mess- und Ereignisdaten. Diese Seite beschreibt das Produktverhalten je Datenart und ersetzt keine verbindlichen Vertragsbedingungen. Bestätigen Sie die geltenden Aufbewahrungsbedingungen vor Beschaffung oder Einsatz über die Sicherheitsprüfung.

Export

Perstat stellt einen Organisations-Export als CSV mit Manifest auf Anfrage bereit, und ein Self-Service-Export ist geplant. Mit einem API-Schlüssel liest die REST-API Monitore, Checks, Zeitreihen und Incidents jederzeit. Für eine Ausstiegsanfrage und den Löschprozess nutzen Sie den Weg auf der Sicherheitsseite.

Wo Perstat in der Prüfungsarbeit steht

Perstat liefert Systemzeitstempel, Messungen, Wartung und sichtbare Kuration für die größere Arbeit, aus der ein Prüfbericht oder eine DORA-Meldung entsteht. Bericht, Meldung und Compliance-Entscheidung bleiben bei Ihren Prüfern und Ihrem Compliance-Team. Die Nachweisseite für die Geschäftsführung beschreibt diese Rollenteilung genau.

Nächste Schritte

• Wartung und Kuratierung: geplante Arbeit und Fehlalarme sichtbar aus den Zahlen halten.
• Tarife und Limits: das Historienfenster jedes Tarifs.