Stets alarmbereit

von Hedayat Paktyan

Selbst kleinste IT-Vorfälle können heute großen Schaden anrichten. Der 24/7-Betrieb ist deshalb zu einem ungeschriebenen Gesetz geworden. Doch die bewährten Konstrukte zur Hochverfügbarkeit sind nur die eine Seite der Medaille. Wie der Artikel zeigt, müssen IT-Profis bei der Hochverfügbarkeit auch ein proaktives Monitoring, eine optimierte Alarmkette sowie eine automatisierte Fehlerbehebung umsetzen – im Idealfall so, dass der Anwender davon nichts merkt.

Hochverfügbarkeit (HA) ist keine Erfindung des Cloudzeitalters. Viele der grundlegenden Konzepte sind heute immer noch anwendbar – wenn auch in angepasster Version. Neue Technologien und Ansätze haben die Möglichkeiten für HA erweitert. Ein äußerst wichtiger Grundsatz ist die Wahl der richtigen Perspektive: Auf welcher Ebene ist Hochverfügbarkeit tatsächlich nötig?

Grob lässt sich der Technologie-Stack in Software, Plattform und Infrastruktur unterteilen. Der überwiegende Teil der Online-Angebote und -Dienstleistungen ist in der Software- beziehungsweise der Anwendungsebene angesiedelt und genau hier ist die Hochverfügbarkeit gefordert. Die Schichten Plattform und Infrastruktur spielen zwar auch eine Rolle, agieren aber hinter den Kulissen. Hier haben sich viele der Vorgänge im Hintergrund nicht geändert: Immer noch bilden redundante Hardware, gespiegelte Daten und multiple Instanzen wie Farm oder Cluster das HA-Rückgrat. Mit Caches und Sitzungsverwaltung auf Client- und/oder Serverseite sind sogar Umschaltungen im großen Maßstab möglich.

Ein kleiner Paradigmenwechsel ist dennoch beachtenswert: Die Verschiebung von monolithischen Anwendungen hin zu Microservices. Eigentlich handelt es sich nur um eine Unterteilung der Software-Ebenen in verschiedene und fast unabhängige Komponenten. So lassen sich singuläre Funktionen verändern, ohne die gesamte Anwendung auszutauschen. Hinzu kommt, dass die Problemanalyse inklusive Fehlerbehebung einfacher sein kann. Beides kann sich im Idealfall komplett auf diesen einen Microservice fokussieren, der nicht so funktioniert, wie er soll.

Eines aber hat sich nicht verändert: Wer Hochverfügbarkeit erzielen will, muss trotz neuer Technologien den entsprechenden Dienst mit seinen Komponenten, die Abhängigkeiten und den jeweils zugehörigen Technologie-Stack genau kennen und überwachen.

Hochverfügbarkeit bedarf Überwachung

Angenommen, eine bestimmte Anwendung ist in höchstem Maße mit Hochverfügbarkeit ausgestattet. Damit wäre jede Komponente mindestens zweifach abgesichert, sodass sogar ein Doppel- oder Tripel-Fehler keine Auswirkungen hat. Doch reicht das aus? Im ersten Ansatz könnte man meinen: ja. Dies ist jedoch sogar aus zwei Gründen falsch. Hochverfügbarkeit bedeutet zunächst nur, dass Fehlfunktionen oder der Ausfall einzelner Komponenten keine Auswirkung auf den Dienst an sich beziehungsweise seine Aufgabe haben. Dennoch sind bestimmte Folgeaktionen nötig, denn der Ausfall oder das Fehlverhalten korrigiert sich in den wenigsten Fällen selbst. Es gilt, defekte Hardware zu ersetzen, einen toten Prozess neu zu starten oder das Fehlverhalten an sich zu untersuchen. Voraussetzung dafür ist, dass die IT-Teams davon auch Kenntnis haben. Und hier kommen Monitoring und Alerting ins Spiel.

Denn ohne Monitoring und Alarmierung ist die erforderliche Hochverfügbarkeit der Systeme nicht zu leisten. Effektives Monitoring hat das Ziel, die Dauer und die Auswirkungen von IT-Incidents zu verringern. Monitoring hilft sicherzustellen, dass Systeme und Dienste wie vorgesehen laufen. Es unterstützt Teams dabei, die Leistung und Verfügbarkeit jeder internen oder externen Anwendung, jedes Systems oder Dienstes im Auge zu behalten. Alerting ist der nachfolgende Prozess der Benachrichtigung der richtigen Ansprechpartner über verschiedene Kommunikationstools.

Monitoring sorgt für Netz und doppelten Boden

Demnach muss es ein System geben, dass die zuvor genannten Komponenten der Anwendung und ihren Technologiestapel regelmäßig überprüft. Prinzipiell gibt es hier zwei Vorgehensweisen. Die erste Alternative: Das Überwachungssystem fragt regelmäßig von außen den Zustand der Anwendung ab. Typischerweise kommen hier recht funktionale Tests zum Einsatz. Ein Ping überprüft die Erreichbarkeit eines Servers im Netzwerk. Netcat oder Telnet stellen fest, ob ein bestimmter Port erreichbar und offen ist. Ein einfacher SQL-Befehl prüft auf simple Weise den Zugriff auf eine relationale Datenbank. Diese Liste lässt sich beliebig fortsetzen. Außerdem gibt es seit vielen Jahren kommerzielle und freie Implementationen, die eine Fülle dieser Tests mitbringen.

Neben dieser Überprüfung von außen gibt es noch eine zweite Variante: Die Komponente meldet von selbst, dass etwas nicht stimmt. Das klingt vielleicht einfach, ist aber in der Realisierung etwas komplexer. Bei einfachen Fehlfunktionen kann die Komponente durchaus noch in der Lage sein, dies zu protokollieren und zu melden. Das könnte sogar ein sauberes Herunterfahren beinhalten. So bleibt das Gesamtsystem in einem geordneten Zustand.

Vorbeugen ist besser als Heilen

Größere Funktionsstörungen oder gar ein Ausfall lassen kaum eine automatische Fehleranzeige zu. Hier ist eine regelmäßige Überprüfung der Protokolldateien unerlässlich. Beim Auftreten bestimmter Muster erfolgt die Alarmierung. Es ist nicht untypisch, dass eine Kombination der Verfahren von außen und von innen zum Einsatz kommt. Grundsätzlich basiert dieses Denkmuster bei Hochverfügbarkeit auf dem Prinzip "Netz und doppelter Boden", und das in vielen Schichten.

Alerting und Monitoring führt als proaktive Methode seit einigen Jahren immer mehr zum Erfolg. Es geht dann nicht mehr allein darum, ein vorhandenes Fehlverhalten festzustellen und dann erst zu reagieren. Vielmehr liegt der Fokus darauf, Fehlverhalten zu antizipieren, also bereits im Vorfeld bestimmte Muster zu erkennen, die schon in der Vergangenheit zu Fehlern geführt haben, um so kostspielige Ausfälle proaktiv oder gar präventiv zu vermeiden. Denn rund 80 Prozent der IT-Incidents sind wiederkehrende Vorfälle. Ausgangspunkt ist erneut eine genaue Kenntnis des Gesamtsystems, und zwar inklusive der Parameter und Kennwerte im Normalbetrieb:

- Wie viele SQL-Anfragen sind am Dienstagvormittag typisch?

- Was ist eine normale Varianz dieses Werts?

- Wächst der Füllstand des Datenspeichers weiterhin linear?

- Gibt es signifikante Abweichungen nach oben oder unten?

- Wann erreicht der Füllstand einen bedenklichen Wert?

- Wie lange dauert die Bestellung, Lieferung, der Einbau und die Inbetriebnahme zusätzlicher Ressourcen?

Letzteres bringt einen weiteren Aspekt ins Spiel: Eine Änderung in der IT ohne Betriebsausfall, der kritische Situationen verursacht. Eine proaktive Anpassung ist demnach eine Investition in die Zukunft. Die Dringlichkeit dafür ist allerdings deutlich schwieriger zu vermitteln als beispielsweise der Austausch einer defekten Komponente. Bewährt hat sich deshalb eine Was-wäre-wenn-Strategie: Es geht darum aufzuzeigen, was ohne die proaktive Anpassung passiert wäre. Die dafür benötigten Daten sind dieselben wie jene für die Überwachung.

Iterativer Ansatz zeigt Verlauf

Doch zunächst einen Schritt zurück. IT-Verantwortliche müssen sich überlegen, wie sie mit dieser proaktiven Überwachung inklusive Alarmierung beginnen. Die ersten Aufgaben sind identisch zum oben beschriebenen reaktiven Ansatz. Wie ist mein Dienst aufgebaut? Was sind typische Ausfälle oder Fehlfunktionen der einzelnen Komponenten? Wo kann ich durch zusätzliche Mechanismen die Gesamtverfügbarkeit erhöhen? Wann ist eine Alarmierung sinnvoll, um ausreichend Zeit zur Korrektur zu haben? Kurzum: Was messe ich und wie messe ich?

Oft ist hier von Metriken die Rede. Bei der reaktiven Überwachung finden die Messungen punktuell statt. Wie hoch ist der Speicherverbrauch dieser Anwendung in genau diesem Moment? Der proaktive Ansatz merkt sich die Daten der einzelnen Messpunkte, was wiederum eine Trendanalyse erlaubt. Und wie hat sich der Speicherhunger dieser Anwendung in den letzten 24 Stunden oder sieben Tagen entwickelt? Gibt es Abweichungen, die eine genauere Analyse erfordern?

Die schwierige Aufgabe besteht in der Definition, ab wann eine Variation der Messdaten zu stark vom Normalwert abweicht. Hier hilft eine Kombination aus Erfahrung, Statistik und die Unterstützung moderner Datenanalyse-Methoden. Zudem hat sich ein iterativer Ansatz bewährt: Messen, Auswerten, Anpassen und Optimieren.

Klar ist, dass das proaktive Monitoring und Alerting deutlich mehr Anfangsaufwand erfordert als der reaktive Ansatz. Dafür lassen sich aber auch wesentlich mehr Fehlerbilder abdecken. Außerdem sind drohende Gefahren frühzeitig erkennbar. Das ermöglicht die rechtzeitige Einleitung von Gegenmaßnahmen, bevor tatsächlich ein Schaden entsteht, und das ohne die Hektik im Umfeld eines Betriebsausfalls.

Automatisierung bedeutet Sichtbarkeit

Hochverfügbarkeit ist oft genug ein Wettlauf mit der Zeit. Eine fehlerhafte Komponente muss sich schnell austauschen lassen. Ein System muss im Notfall auch ohne Sicherheitsnetz laufen. Die Problemanalyse und die Lösungsfindung müssen schnell erfolgen. Dieser Wettlauf ist manuell nicht mehr zu gewinnen.

Die Antwort lautet Automatisierung. Gründe dafür gibt es mehrere. Zum einen erlaubt die Automatisierung das Formalisieren von Abläufen und Prozessen, was wiederum eine Beschleunigung ermöglicht. Wissen und Erfahrung lassen sich so in Skripte und Code gießen. Das erleichtert das Anlernen von neuen Mitarbeitern und die Anbindung an andere Werkzeuge. Zum anderen lässt sich durch automatisierte Prozesse die Schnelligkeit von Computern besser nutzen. Selbst mit klassischen Methoden sind Reaktion und Gegenmaßnahmen auf Vorfälle in Echtzeit möglich. Letzteres ist quasi der Baustein zur bereits genannten Selbstheilung des Systems.

Fehlererkennung und Erstanalyse sind da nur der Anfang – sozusagen die Spitze des Eisbergs. Automatisierung erlaubt zudem einen Brückenschlag zwischen der IT und den Fachabteilungen. Kryptische Fehlermeldungen lassen sich in Nachrichten übersetzen, die jeder Nutzer im Unternehmen versteht. Statt "Die Tabelle 15 in Datenbank X ist korrupt" kann da nun stehen: "Die Funktion Newsletter ist ausgefallen".

DevOps überwindet klassische Gräben

Neue Technologien und Ansätze bringen neue Chancen und Optionen, so auch die oben genannten Microservices. Diese erlauben aber nicht nur eine gezieltere Fehleranalyse als in der monolithischen Welt. Die Behebung des Fehlers – sei es Software oder Hardware – ist ebenfalls einfacher. Anstelle des Gesamtkonstrukts reicht im Idealfall der Austausch einer einzelnen Komponente. Auch in Sachen Hochverfügbarkeit ergeben sich deshalb für Teams neue Möglichkeiten.

Dieses Prinzip lässt sich nun auf Komponentenebene umsetzen. So sind sogar Funktionen wie Selbstheilung viel einfacher möglich und realisierbar. Doch Technologie ist nur eine Seite der Medaille. Fast noch wichtiger ist der Faktor Mensch. Die klassische Trennung von Betrieb (Operations) und Entwicklung (Developer) hat ausgedient. Sie ist zu langsam und skaliert nicht wie benötigt.

Einen Softwarefehler im produktiven Betrieb behebt oft genug ein Entwickler am schnellsten. Dabei hilft das Verständnis vom Betrieb an sich im Gesamtbild der Software-Entwicklung. Denn genau genommen verkörpern Denkansätze wie DevOps eigentlich nur eine gesamtheitliche Sicht auf die Anwendung, das Angebot und damit die Dienstleistung. Der Paradigmenwechsel ist also ist eine Chance für Unternehmen, eine neue Kultur des "Full-Service-Ownership" zu etablieren, bei der verantwortliche Teams während eines Projektzyklus die komplette Verantwortung übernehmen.

Trend zum Orchestrierungswerkzeug

Ein wichtiger Aspekt ist weiterhin, wie sich am schnellsten die richtigen Ansprechpartner erreichen lassen, die über die notwendigen Informationen, das erforderliche Know-how und entsprechende Kompetenzen verfügen, ohne dabei selbst in stark verteilten Infrastrukturen den Überblick zu verlieren.

Mit Orchestrierungsplattformen lassen sich Alarme bündeln, gruppieren und in Echtzeit an die richtigen Personen weiterleiten. Diese Plattformen verfügen über Schnittstellen zur Integration verschiedenster Werkzeuge und Prozesse. Diese modernen Lösungen haben einen sehr starken integrativen Charakter: Die vorhandenen Werkzeuge und Prozesse docken sich über (idealerweise native) Schnittstellen an – oder umgekehrt.

Im besten Fall lassen sich nun beispielsweise einfach die Datenbankadministratoren durch eine SMS, der Produktverantwortliche via E-Mail und die Entwickler via Slack über ein Problem informieren – je nach individueller Kommunikationspräferenz. Dazu kommt das Anlegen und Zusammenführen von entsprechenden Einträgen im Ticketsystem. Ein vollautomatisierter Prozess führt zu einer hohen Effizienz und Produktivität. DevOps-Teams können sich ihren eigentlichen Aufgaben zuwenden und müssen nicht unvorhersehbare Arbeitslasten stemmen.

Ohne eine zentrale Instanz – also das erwähnte Orchestrierungswerkzeug – ist dies viel schwieriger. Insbesondere die Korrelation von verschiedenen Fehlerereignissen ist eine Herausforderung. Im Krisenfall, wenn es gleichzeitig zu mehreren großen IT-Vorfällen kommt, erlaubt die Orchestrierung zunächst eine Gruppierung mehrerer Incidents zu einem Alert oder einigen wenigen Alarmen, sodass die Übersichtlichkeit gewahrt bleibt. Zum anderen ermöglicht sie eine eindeutige Priorisierung der definierten Maßnahmen. Wo ist die größte negative Auswirkung für den Kunden? Wo ist der Normalzustand am schnellsten oder einfachsten wiederherzustellen? Dazu kommt noch die Organisation der Notfallteams.

Fazit

Wie gut Monitoring und Alarmierung koordiniert sind, hat entscheidende Auswirkungen auf die Tatsache, wie schnell und effektiv der Administrator einen Vorfall beheben und damit die Hochverfügbarkeit sicherstellen kann. Der zunehmende Druck auf IT-Systeme führt aktuell dazu, dass sich diese Prozesse zunehmend hin zu Automatisierung und Erkennung und Behebung von Vorfällen in Echtzeit bewegen.

Neue Technologien wie die allgegenwärtige Cloud, Microservices und Container rütteln zwar nicht am Grundprinzip der Hochverfügbarkeit, sie verändern aber die Art und Weise, wie Monitoring und Alerting zukünftig zum Einsatz kommen.

Monitoring und Alerting bei Hochverfügbarkeit