Zuverlässigkeit

Servicelevel, Monitoring, Rufbereitschaft: was „zuverlässig“ wirklich bedeutet

Uptime, RTO, RPO, Servicelevel von 99,9 %, Monitoring, getestete Backups, Notfall-Wiederherstellungsplan, garantierte Reaktions- und Wiederherstellungszeiten: was „zuverlässig“ konkret bedeutet, in Zahlen und schriftlichen Zusagen.

Durchgehende Verfügbarkeitslinie mit einem einzigen Einbruch, aus dem eine läutende Alarmglocke aufsteigt, über drei gestapelten Backup-Festplatten, Illustration dessen, was Servicelevel, Überwachung und Rufbereitschaft abdecken
Inhalt (7 Abschnitte)
  1. Zuverlässigkeit definieren: Uptime, RTO, RPO
  2. Was ein Servicelevel von 99,9 % konkret bedeutet
  3. Monitoring und Alarmierung: erkennen, bevor es Folgen hat
  4. Backups und Notfall-Wiederherstellungsplan
  5. Rufbereitschaft, garantierte Reaktions- und Wiederherstellungszeit
  6. Unsere Checkliste für Zuverlässigkeit
  7. Zusammengefasst

„Wir wollen etwas Zuverlässiges.“ Das ist ein berechtigter Wunsch, aber das Wort „zuverlässig“ bedeutet nichts, solange man es nicht in Zahlen und Zusagen übersetzt. Eine zuverlässige Anwendung ist keine Anwendung, die nie ausfällt, so etwas gibt es nicht. Es ist eine Anwendung, deren erwartetes Verhalten bekannt ist, deren Abweichungen gemessen werden und deren Dienst innerhalb garantierter Fristen wieder anläuft. So schlüsseln wir das bei Sanfytech auf.

Zuverlässigkeit definieren: Uptime, RTO, RPO #

Drei Kennzahlen genügen, um ein ernsthaftes Gespräch über Zuverlässigkeit abzustecken.

Die Uptime (oder Verfügbarkeit) misst den Prozentsatz der Zeit, in der der Dienst betriebsbereit ist. Der RTO (Recovery Time Objective) ist die maximal akzeptable Frist, um den Dienst nach einem Vorfall wieder in Gang zu bringen. Der RPO (Recovery Point Objective) ist die maximale Datenmenge, deren Verlust man akzeptiert, ausgedrückt in Zeit: Ein RPO von einer Stunde bedeutet, dass Sie im schlimmsten Fall eine Stunde an Daten verlieren.

Solange diese drei Zeilen nicht mit Zahlen gefüllt sind, bleibt „zuverlässig“ ein frommer Wunsch.

Was ein Servicelevel von 99,9 % konkret bedeutet #

Eine Servicelevel-Vereinbarung (Service Level Agreement) mit 99,9 % Uptime bedeutet rund 8 Stunden 45 Minuten tolerierte Nichtverfügbarkeit pro Jahr, also etwa 43 Minuten pro Monat. Bei 99,99 % liegt man unter einer Stunde pro Jahr. Der Unterschied zwischen diesen beiden Zahlen ist nicht kosmetisch: Er schlägt sich in redundanter Architektur, Kosten und Komplexität nieder.

Die klassische Falle besteht darin, 99,99 % zu versprechen, ohne den technischen Preis dafür zu zahlen. Unser Ansatz: das Servicelevel vorschlagen, das wirklich zu Ihrer Nutzung passt (ein internes Werkzeug und eine Plattform für den Onlinehandel haben nicht dieselben Anforderungen), und es schwarz auf weiß festhalten, samt dem, was passiert, wenn wir es nicht einhalten.

Ein Servicelevel ist kein Versprechen, nie auszufallen. Es ist eine schriftliche Zusage darüber, wie schnell wir wieder aufstehen, und darüber, was für Sie gilt, wenn wir sie nicht einhalten.

Monitoring und Alarmierung: erkennen, bevor es Folgen hat #

Zuverlässigkeit beginnt mit Sichtbarkeit. Wir überwachen laufend die Verfügbarkeit, die Antwortzeiten, die Auslastung von CPU, Arbeitsspeicher und Festplatte sowie die Anwendungsfehler. Ziel ist nicht, Diagramme anzuhäufen, sondern im richtigen Moment einen Alarm auszulösen, idealerweise bevor der Nutzer irgendetwas bemerkt.

Eine gute Alarmregel erkennt die Verschlechterung (die steigende Latenz, die sich füllende Festplatte) und nicht nur den Totalausfall. Das ist der Unterschied zwischen einem Eingriff um 3 Uhr morgens bei einem beherrschten Vorfall und der Entdeckung des Problems um 9 Uhr, wenn die Kunden online sind.

Backups und Notfall-Wiederherstellungsplan #

Ein Backup, das nie wiederhergestellt wurde, ist kein Backup, sondern eine Hoffnung. Wir sichern täglich und verschlüsselt, und wir testen die Wiederherstellungen regelmäßig. Der Notfall-Wiederherstellungsplan (auf Französisch PRA, Plan de Reprise d'Activité) dokumentiert genau, was in welcher Reihenfolge und in welcher Zeit wiederhergestellt wird, damit an dem Tag, an dem es wirklich darauf ankommt, nicht improvisiert werden muss.

Rufbereitschaft, garantierte Reaktions- und Wiederherstellungszeit #

Tritt ein kritischer Vorfall außerhalb der Geschäftszeiten auf, übernimmt die Rufbereitschaft. Zwei Zusagen geben ihr den Rahmen: die GTI (Garantie de Temps d'Intervention, garantierte Reaktionszeit), die Frist, innerhalb derer sich jemand des Vorfalls annimmt, und die GTR (Garantie de Temps de Rétablissement, garantierte Wiederherstellungszeit), die Frist, innerhalb derer der Dienst wiederhergestellt ist. Beide Zahlen sind vertraglich: Sie machen aus „wir kümmern uns darum“ eine messbare Zusage.

Unsere Checkliste für Zuverlässigkeit #

  • Ziele für Uptime, RTO und RPO festlegen, bevor über Technik gesprochen wird.
  • Das Servicelevel schriftlich festhalten, und ebenso, was passiert, wenn es nicht eingehalten wird.
  • Bei Verschlechterung alarmieren, nicht nur bei Ausfall.
  • Die Wiederherstellung der Backups testen, nicht nur ihr Vorhandensein.
  • Den Notfall-Wiederherstellungsplan dokumentieren und regelmäßig durchspielen.
  • Garantierte Reaktions- und Wiederherstellungszeit schriftlich festlegen, mit einer echten Rufbereitschaft dahinter.

Zusammengefasst #

„Zuverlässig“ wird nützlich, wenn man es in messbare Kennzahlen und schriftliche Zusagen übersetzt: eine Ziel-Uptime, ein bewusst festgelegtes RTO und RPO, ein Monitoring, das früh alarmiert, getestete Backups, ein dokumentierter Notfall-Wiederherstellungsplan und eine Rufbereitschaft mit garantierten Reaktions- und Wiederherstellungszeiten. Genau das decken unsere Managed Services ab: ein einziger Verantwortlicher, kein Hin- und Herschieben der Verantwortung.

Wenn Sie Ihre Anwendung überwachen lassen und sich auf klare Zusagen stützen möchten, lernen Sie unsere Managed Services, Tag und Nacht kennen oder kontaktieren Sie uns: Erstgespräch kostenlos, Antwort binnen 24 Stunden an Werktagen.

Über uns
01/Als Nächstes lesenDrei Artikel

Verwandte Artikel

Entwicklung

Zwei Jahre Commits in Docker nachspielen: die Zeitmaschine eines Repositorys

Einen Commit von 2024 heute nachbauen, starten und fotografieren: Das ist keine Nostalgie, sondern Dokumentation, die nicht lügt. Die sechsstufige Pipeline, die wir für BuyStep geschrieben haben, die Fallstricke, die zu lösen waren, und warum das Zählen Aufgabe von Git bleibt.

dockergit
Methode

93 % des Codes wurden nie geprüft. Wir haben die Tür geschlossen.

In neunzig Tagen kamen 855 Commits ohne Merge Request auf den Hauptzweig, gegenüber 63 mit Merge Request. Und dieser Zweig löst die Produktivsetzung aus. Messung, Entscheidung und die vier Fallstricke, auf die wir beim Schließen der Tür gestoßen sind.

continuous integrationcode review
Sicherheit

Eine veraltete Lock-Datei ist ein Scan, der lügt

Lock-Dateien für Abhängigkeiten sind die maßgebliche Quelle für Sicherheitsanalysen. Wenn eine CI-Pipeline sie stillschweigend umschreibt, statt zu scheitern, liest die Analyse falsche Versionen und liefert ein beruhigendes Urteil. Wie wir das entdeckt haben und was wir geändert haben.

abhängigkeitensoftware-lieferkette

Und jetzt

Eine .NET-Anwendung, die modernisiert werden soll?

Migration, Relaunch oder neue Anwendung: Wir sehen uns Ihren Code gemeinsam an, unverbindlich.

Ihr Projekt besprechen

Antwort binnen 24 Stunden an Werktagen, von einem der beiden Gründer. Oder telefonisch: +33 7 59 96 14 99.