> ## Content Index > Fetch the complete content index at: https://blog.lange-it.com/llms.txt > Use this file to discover other available public pages before exploring further. # Verfügbarkeit ist mehr als ein grüner Status - URL: https://blog.lange-it.com/verfuegbarkeit-mehr-als-ein-gruener-status/ - Published: 2026-10-05T17:34:23.000Z - Updated: 2026-10-05T17:34:23.000Z - Description: Verfügbarkeit entsteht nicht durch einen einzelnen Check. Monitoring, Security, Recovery, Kapazität, Lifecycle, Automatisierung, Dokumentation und Prozesse müssen zusammenspielen. - Author: Peter Lange - Tags: Monitoring, Security, Backup, Recovery, Checkmk, Graylog, Wazuh ## Verfügbarkeit beginnt dort, wo „es läuft“ nicht mehr reicht Ein System aufzubauen ist nur der Anfang. Sobald es produktiv genutzt wird, verschiebt sich die Perspektive. Mich interessiert dann nicht mehr nur, ob ein Dienst gestartet ist. Ich möchte wissen, ob er seine Aufgabe erfüllt, ob sich Probleme frühzeitig ankündigen, ob Veränderungen nachvollziehbar sind und ob ich im Fehlerfall kontrolliert reagieren kann. Genau deshalb ist Verfügbarkeit für mich kein einzelner Messwert. Sie entsteht aus vielen Disziplinen, die gemeinsam funktionieren müssen: Monitoring, Security, Recovery, Kapazitätsplanung, Lifecycle, Redundanz, Automatisierung, Dokumentation und klare Prozesse. Ein grüner Status kann dabei wichtig sein. Er ist aber immer nur eine Aussage über eine konkrete Prüfung zu einem konkreten Zeitpunkt. ![Verfügbarkeit als Zusammenspiel von Monitoring, Security, Recovery, Kapazität, Lifecycle, Redundanz, Automatisierung, Dokumentation und Prozessen](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-verfuegbarkeit-betriebsmodell-flow.png) ## Was bedeutet eigentlich „verfügbar“? Die einfachste Prüfung lautet häufig: Ist der Host erreichbar? Das ist sinnvoll, beantwortet aber nur eine sehr kleine Frage. Ein Server kann auf ICMP reagieren, während der Webserver ausgefallen ist. Der Webserver kann antworten, obwohl die Anwendung keine Verbindung mehr zur Datenbank bekommt. Die Anwendung kann technisch funktionieren, während DNS von außen falsch aufgelöst wird. Und selbst eine HTTP-Antwort mit Status 200 beweist noch nicht, dass Anmeldung, Suche, Bestellung oder Mailzustellung tatsächlich funktionieren. Für mich besteht eine sinnvolle Verfügbarkeitsbetrachtung deshalb aus mehreren Perspektiven. Ich prüfe die technische Grundlage, den eigentlichen Dienst, die Anwendung, eine relevante Benutzerfunktion und – wo es sinnvoll ist – die externe Erreichbarkeit. Das ist auch der Grund, warum internes Monitoring allein nicht genügt. Checkmk beschreibt bei seinen Active Checks genau diesen Unterschied: Agentenbasierte Überwachung zeigt den Zustand aus Sicht des Hosts, während aktive Prüfungen einen Netzwerkdienst von außen ansprechen und damit beispielsweise Erreichbarkeit und Antwortzeit aus einer anderen Perspektive bewerten können. Die entscheidende Frage lautet also nicht: „Ist alles grün?“ Sondern: **Was wurde geprüft, von wo wurde geprüft und welche Aussage kann ich daraus tatsächlich ableiten?** ## Monitoring soll Probleme sichtbar machen, nicht nur Ausfälle melden Gutes Monitoring beginnt für mich lange vor dem Totalausfall. Ein voller Datenträger ist ein Problem. Ein Datenträger, dessen Belegung seit Wochen kontinuierlich steigt und in drei Tagen voraussichtlich voll sein wird, ist aber die wesentlich interessantere Information. Das Gleiche gilt für Arbeitsspeicher, CPU, Datenbankgröße, Warteschlangen, Zertifikatslaufzeiten, Backupdauer, Antwortzeiten oder die Zahl fehlgeschlagener Jobs. Viele Störungen kündigen sich an. Voraussetzung ist, dass nicht nur Grenzwerte betrachtet werden, sondern auch Entwicklungen. Dabei versuche ich, zwischen Symptomen und Ursachen zu unterscheiden. Eine hohe Antwortzeit kann von der Anwendung kommen, von einer Datenbank, einem Storage-System, DNS, einem externen Dienst oder schlicht von erschöpften Ressourcen. Ein einzelner Alarm sollte deshalb möglichst nicht isoliert betrachtet werden. Checkmk ist ein Beispiel für ein Werkzeug, das Host- und Servicezustände, aktive Checks und historische Verfügbarkeiten zusammenführen kann. Interessant ist dabei auch die rückblickende Betrachtung: Verfügbarkeit lässt sich nur sinnvoll bewerten, wenn klar ist, welcher Zeitraum betrachtet wird und wie Wartungsfenster, nicht überwachte Zeiten oder kurze Unterbrechungen behandelt werden. Eine Zahl wie 99,9 Prozent klingt zunächst präzise. Ohne Messpunkt, Zeitraum und Definition sagt sie jedoch deutlich weniger aus, als man vermuten könnte. ## Logs erklären, was zwischen zwei Statuswerten passiert ist Monitoring ist stark darin, Zustände und Abweichungen sichtbar zu machen. Für die Ursachenanalyse reicht das oft nicht aus. Wenn ein Dienst um 10:14 Uhr ausfällt, möchte ich wissen, was kurz davor passiert ist. Wurde eine Konfiguration geändert? Ist eine Datenbankverbindung abgebrochen? Gab es einen Neustart? Ist ein Zertifikat erneuert worden? Sind ungewöhnlich viele Anmeldefehler aufgetreten? Hat ein Prozess begonnen, große Datenmengen zu schreiben? Genau hier werden zentrale Logs wertvoll. Statt mich nach einem Vorfall auf mehreren Systemen durch lokale Dateien zu arbeiten, kann ich Ereignisse zeitlich zusammenführen und durchsuchen. Graylog ist dafür ein mögliches Beispiel. Eingehende Nachrichten lassen sich verarbeiten und strukturieren; definierte Ereignisse können wiederum Benachrichtigungen auslösen. Wichtig ist mir dabei die Trennung der Aufgaben: Ein Logsystem ersetzt kein Zustandsmonitoring, und Monitoring ersetzt keine Loganalyse. Beide liefern unterschiedliche Teile derselben Geschichte. Das gilt auch für die Datenqualität. Wenn ein System plötzlich keine Logs mehr liefert, ist das nicht automatisch ein Zeichen dafür, dass nichts passiert. Es kann ebenso bedeuten, dass Logshipping, Netzwerk, Agent oder Zielsystem ausgefallen sind. Deshalb gehört auch der Datenfluss der Beobachtung selbst unter Überwachung. ## Security ist keine zusätzliche Betriebsdisziplin Sicherheit steht für mich nicht neben der Verfügbarkeit. Sie begrenzt, welche Maßnahmen im Betrieb überhaupt vertretbar sind. Das wird besonders deutlich, wenn ein Dienst unerwartet ausfällt. Der reflexartige Neustart kann richtig sein – muss es aber nicht. Wenn unmittelbar vorher ungewöhnliche Authentifizierungsereignisse, Änderungen an sicherheitsrelevanten Dateien oder andere verdächtige Aktivitäten aufgetreten sind, verändert sich die Lage. Ein Werkzeug wie Wazuh kann an dieser Stelle eine weitere Perspektive liefern. Dazu gehören unter anderem Logdatenanalyse, File Integrity Monitoring, Security Configuration Assessment, Systeminventarisierung und Vulnerability Detection. File Integrity Monitoring kann beispielsweise Änderungen an überwachten Dateien erkennen; Security Configuration Assessment prüft definierte Konfigurationsregeln und Hardening-Vorgaben. Das bedeutet nicht, dass jeder Ausfall ein Security Incident ist. Es bedeutet aber, dass ich vor einer schnellen Reparatur verstehen möchte, ob Hinweise auf einen Sicherheitsvorfall vorliegen. Bei einem begründeten Verdacht kann Isolation wichtiger sein als sofortige Wiederverfügbarkeit. Ein kompromittiertes System schnellstmöglich wieder online zu bringen, wäre kein erfolgreicher Betrieb. In diesem Fall muss zunächst geklärt werden, welchem Zustand ich noch vertrauen kann. ## Ein Beispiel: Die Anwendung ist plötzlich nicht erreichbar Angenommen, das Monitoring meldet, dass eine Webanwendung nicht mehr erreichbar ist. Der Host selbst ist online, CPU und Arbeitsspeicher sehen unauffällig aus. Eine reine Verfügbarkeitsreaktion wäre, den Dienst neu zu starten. Vielleicht funktioniert die Anwendung danach sogar wieder. Die eigentliche Ursache wäre damit trotzdem unbekannt. Ich würde stattdessen den Kontext zusammensetzen. Zeigt das Monitoring einen vorausgehenden Anstieg der Antwortzeiten? Gibt es im zentralen Logging einen Datenbankfehler oder eine Konfigurationsänderung? Meldet die Security-Telemetrie eine unerwartete Dateiänderung oder auffällige Anmeldung? Ist Speicherplatz knapp geworden? Gab es ein Deployment? Funktionieren DNS, Zertifikat und Reverse Proxy? Ist nur die interne Prüfung erfolgreich oder auch die externe Benutzerperspektive? Erst aus diesen Informationen entsteht ein belastbares Bild. Und erst dann lässt sich entscheiden, ob ein Neustart genügt, eine Änderung zurückgenommen werden muss, eine Abhängigkeit ausgefallen ist oder ein System zunächst isoliert und untersucht werden sollte. Das ist für mich einer der wichtigsten Unterschiede zwischen Fehlerbehebung und Betrieb: **Nicht nur den grünen Zustand wiederherstellen, sondern verstehen, warum er verloren gegangen ist.** ## Backup ist noch keine Recovery Backups sind unverzichtbar, aber sie sind zunächst nur gespeicherte Daten und Zustände. Für Verfügbarkeit wird daraus erst dann etwas Wertvolles, wenn eine Wiederherstellung tatsächlich möglich und planbar ist. Dazu gehören für mich mehrere Fragen: Welche Daten werden gesichert? Welche Konfigurationen gehören dazu? Wie weit darf ich im Fehlerfall zeitlich zurückfallen? Wie lange darf die Wiederherstellung dauern? Welche Abhängigkeiten müssen vorher verfügbar sein? Und wurde der Restore jemals praktisch getestet? RPO und RTO helfen, diese Anforderungen greifbar zu machen. Das Recovery Point Objective beschreibt vereinfacht, welchen maximalen Datenverlust in Zeit ich akzeptieren kann. Das Recovery Time Objective beschreibt, innerhalb welcher Zielzeit ein Dienst nach einer Störung wiederhergestellt werden soll. Beide Werte sind keine Eigenschaften einer Backupsoftware, sondern Anforderungen an den Betrieb und an die Architektur dahinter. Ein tägliches Backup kann für einen wenig veränderten Dienst völlig ausreichend sein. Für ein System mit vielen geschäftskritischen Änderungen pro Stunde kann dasselbe Konzept unbrauchbar sein. Noch wichtiger ist der Restore-Test. Ein Backup, dessen Wiederherstellung nie geprüft wurde, enthält eine Annahme. Ein getesteter Wiederherstellungsweg liefert dagegen Evidenz. ## Redundanz hilft nur gegen die richtigen Fehler Redundanz klingt zunächst nach der direkten Antwort auf Verfügbarkeit: Wenn ein System ausfällt, übernimmt ein zweites. In der Praxis muss ich genauer hinsehen. Zwei Anwendungsinstanzen helfen nicht gegen eine gemeinsam genutzte, ausgefallene Datenbank. Zwei Server helfen nicht gegen einen gemeinsamen Storage-Fehler. Mehrere Dienste hinter demselben fehlerhaften DNS-Eintrag bleiben gemeinsam nicht erreichbar. Und identische Systeme können denselben Software- oder Konfigurationsfehler gleichzeitig besitzen. Redundanz reduziert deshalb nur die Risiken, gegen die sie tatsächlich entworfen wurde. Gleichzeitig erhöht sie die Zahl der Komponenten, Abhängigkeiten und möglichen Fehlerzustände. Ich halte es deshalb für sinnvoller, zuerst Fehlerdomänen und Abhängigkeiten zu verstehen und anschließend gezielt zu entscheiden, wo Redundanz den zusätzlichen Aufwand rechtfertigt. Auch ein Failover muss getestet werden. Eine Architektur, die theoretisch automatisch übernehmen kann, deren Umschaltung aber nie geprüft wurde, bleibt im Ernstfall eine Wette. ## Kapazität ist ein Verfügbarkeitsthema Viele Ausfälle sind keine spektakulären Defekte. Ein Dateisystem läuft voll. Eine Datenbank wächst über Jahre. Logs belegen immer mehr Speicher. Ein Backupfenster wird länger, bis es mit dem nächsten Lauf kollidiert. Eine Queue wächst schneller, als sie abgearbeitet werden kann. Kapazitätsplanung bedeutet für mich deshalb nicht, überall möglichst große Reserven vorzuhalten. Es geht darum, Wachstum zu beobachten, Grenzwerte zu kennen und rechtzeitig handeln zu können. Dabei ist auch die Dynamik wichtig. 80 Prozent Speichernutzung können über Jahre stabil sein oder innerhalb weniger Stunden entstanden sein. Der aktuelle Wert ist derselbe, das Risiko nicht. Trends und Prognosen machen Monitoring damit zu einem Werkzeug für Planung – und nicht nur für Alarmierung. ## Lifecycle und Patchbarkeit werden in der Architektur entschieden Ein System kann heute stabil laufen und trotzdem bereits ein zukünftiges Betriebsproblem enthalten. Nicht mehr unterstützte Betriebssysteme, festgefahrene Bibliotheken, ungepflegte Container-Images oder Abhängigkeiten, die nur mit großen Versionssprüngen aktualisiert werden können, erhöhen mit der Zeit das Risiko. Gleichzeitig dürfen Updates nicht blind installiert werden, nur weil sie verfügbar sind. Ich möchte deshalb schon beim Aufbau eines Systems wissen, wie es später aktualisiert, getestet und bei Bedarf zurückgerollt werden kann. Patchbarkeit ist für mich eine Architektureigenschaft. Security macht diesen Punkt besonders wichtig. Bekannte Schwachstellen lassen sich nicht dauerhaft mit dem Argument akzeptieren, ein Update könne die Verfügbarkeit gefährden. Umgekehrt ist ein ungeprüftes Update auf einem kritischen System ebenfalls kein gutes Sicherheitsmodell. Ein guter Lifecycle schafft einen kontrollierten Weg zwischen beiden Risiken: Änderungen kennen, Auswirkungen bewerten, testen, geplant ausrollen, beobachten und einen Rückweg vorsehen. ## Automatisierung muss beobachtbar bleiben Automatisierung kann Betrieb enorm stabilisieren. Wiederkehrende Aufgaben werden reproduzierbar, manuelle Fehler nehmen ab und Prüfungen können regelmäßig stattfinden. Das gilt beispielsweise für Backups, Updates, Deployments, Konfigurationsprüfungen, Zertifikatserneuerungen oder wiederkehrende Funktionstests. Automatisierung erzeugt aber auch eine neue Abhängigkeit. Wenn ein automatischer Job nicht mehr läuft und niemand das bemerkt, wurde die manuelle Arbeit lediglich durch einen unsichtbaren Fehler ersetzt. Deshalb sollte eine Automatisierung nicht nur einen Erfolgsfall ausführen, sondern ihren eigenen Zustand sichtbar machen. Wann lief der Job zuletzt? War er erfolgreich? Wie lange dauerte er? Wurde das erwartete Ergebnis erzeugt? Ist die erzeugte Sicherung auch lesbar? Ein „automatisch“ vor einer Aufgabe sagt noch nichts darüber aus, ob sie zuverlässig betrieben wird. ## Dokumentation ist Teil der technischen Verfügbarkeit Technik allein löst keinen Vorfall. Irgendwann muss ein Mensch entscheiden, was zu tun ist. Wenn relevantes Wissen nur im Kopf einer einzelnen Person existiert, entsteht eine Abhängigkeit, die sich mit keinem Cluster lösen lässt. Deshalb gehören für mich Dokumentation und Runbooks genauso zum Betrieb wie Monitoring und Backup. Ich möchte bei einem kritischen Dienst zumindest nachvollziehen können, wofür er zuständig ist, welche Abhängigkeiten bestehen, wo sein Sollzustand beschrieben ist, wie er geprüft wird und welche Wiederherstellungswege existieren. Besonders wertvoll ist ein bekannter funktionierender Referenzzustand. Wenn ein System gestern nachweislich funktioniert hat und heute nicht mehr, kann ich gezielt untersuchen, was sich verändert hat. Das ist wesentlich belastbarer, als während einer Störung gleichzeitig Architektur und Fehlerbild neu verstehen zu müssen. Dokumentation ist dabei kein Selbstzweck. Sie soll im Fehlerfall Zeit sparen und Fehlentscheidungen verhindern. ## Prozesse entscheiden, ob aus einem Alarm eine gute Reaktion wird Ein Monitoringalarm ist noch keine Problemlösung. Es muss klar sein, wer reagieren soll, wie kritisch ein Zustand ist und wann eskaliert wird. Nicht jede Warnung braucht einen nächtlichen Anruf. Umgekehrt darf ein kritischer Sicherheitsalarm nicht bis zum nächsten Arbeitstag in einem Dashboard liegen bleiben. Deshalb gehören Prioritäten, Wartungsfenster, Eskalationswege und Verantwortlichkeiten zum Verfügbarkeitskonzept. Dasselbe gilt für Changes. Wenn Änderungen nachvollziehbar dokumentiert werden, lässt sich bei einer späteren Störung schneller erkennen, ob ein Zusammenhang besteht. Nach größeren Vorfällen lohnt sich außerdem die Nachbereitung. Nicht um Schuldige zu suchen, sondern um die Umgebung zu verbessern: Hätte das Problem früher erkannt werden können? Fehlte ein Check? War die Dokumentation unvollständig? War der Alarm zu unspezifisch? Hat der Recovery-Weg funktioniert? Welche Maßnahme verhindert eine Wiederholung? So wird aus einer Störung neues Betriebswissen. ## Auch die Beobachtung braucht Überwachung Es gibt einen Zustand, den ich besonders gefährlich finde: Alles sieht ruhig aus, weil die Systeme, die Probleme melden sollen, selbst nicht mehr funktionieren. Ein Monitoringserver kann ausfallen. Ein Agent kann keine Daten mehr senden. Logshipping kann stehen. Ein Security-Sensor kann offline sein. Ein Backupjob kann gar nicht mehr starten. Eine Benachrichtigung kann am Mailgateway hängen bleiben. Deshalb versuche ich, zwischen „kein Problem erkannt“ und „Beobachtung funktioniert nachweislich“ zu unterscheiden. Das kann externe Prüfungen, Heartbeats, Dead-Man-Switches, Testalarme oder gegenseitige Kontrollen bedeuten. Welche Methode sinnvoll ist, hängt vom System ab. Das Prinzip bleibt gleich: Ein fehlendes Signal ist nicht automatisch ein positives Signal. ## Verfügbarkeit ist eine Eigenschaft des gesamten Betriebs Je länger ich Systeme betreibe, desto weniger überzeugt mich die Vorstellung, Verfügbarkeit ließe sich nachträglich durch ein Monitoringtool oder ein zweites System hinzufügen. Sie entsteht bereits bei Architekturentscheidungen. Kann ich Komponenten aktualisieren? Sind Abhängigkeiten bekannt? Gibt es sinnvolle Fehlergrenzen? Kann ich Daten wiederherstellen? Sind kritische Funktionen messbar? Sind Security-Ereignisse sichtbar? Kann ich Änderungen nachvollziehen? Weiß im Fehlerfall jemand, was zu tun ist? Monitoring liefert Signale. Logs liefern Kontext. Security hilft bei der Bewertung von Risiken und Vertrauenswürdigkeit. Backups und Recovery schaffen einen Rückweg. Redundanz kann ausgewählte Fehler abfangen. Kapazitätsplanung schafft Vorlauf. Lifecycle hält Systeme wartbar. Automatisierung macht Abläufe reproduzierbar. Dokumentation und Prozesse sorgen dafür, dass aus Informationen kontrolliertes Handeln wird. Für mich ist das die eigentliche Bedeutung von professionellem Betrieb: Ein System nicht nur zum Laufen zu bringen, sondern es **sicher, nachvollziehbar, wartbar und wiederherstellbar** zu halten. Ein grüner Status ist dann weiterhin willkommen. Ich weiß aber auch, was er bedeutet – und was nicht. ## Quellen und weiterführende Dokumentation Für die technischen Beispiele und Begriffe habe ich unter anderem die aktuelle Primärdokumentation von Checkmk, Graylog und Wazuh sowie die NIST-Dokumentation zur Contingency-Planung herangezogen: - Checkmk: Active Checks und Availability - Graylog: Event Definitions, Alerts und Pipelines - Wazuh: File Integrity Monitoring, Security Configuration Assessment und Vulnerability Detection - NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems