Neben anderen Diensten bietet nine seinen Kunden Managed Services an. Diese Dienste werden auf Servern gehostet, die mindestens eine Festplatte für die Datenspeicherung enthalten. Davon verwalten wir momentan mehr als 4.500. Um zu garantieren, dass unsere Dienste rund um die Uhr zur Verfügung stehen, müssen wir sicherstellen, dass keine dieser Festplatten voll wird. Wird eine Festplatte voll, kann es vorkommen, dass ein Dienst nicht mehr ordnungsgemäß funktioniert, und es wird nicht möglich sein, weiter auf die Festplatte zu schreiben (Logs, Dateien usw.).
Eine der Aufgaben des Entwicklerteams ist es, die bestehenden Prozesse zu optimieren und diese für unsere Kunden so benutzerfreundlich und zeiteffizient wie möglich zu gestalten. Wir haben erkannt, dass der Prozess für Festplattenwarnmeldungen für unser operatives Team ein recht zeitintensiver und (quälend) repetitiver Prozess war. Wir haben daher daran gedacht, diesen zu automatisieren.
Vorheriger Prozess
Bis vor Kurzem haben wir eine „halbautomatische“ Herangehensweise verwendet, die, kurz gesagt, Warnmeldungen aus unserem Überwachungssystem, verschiedene manuelle Überprüfungen des Servers und manuelle Kontaktaufnahme mit dem Kunden beinhaltete.
Unsere Hauptinformationsquelle war unser Überwachungssystem. Dieses hat uns auf dem Laufenden gehalten, sobald eine Festplatte 80 % oder 90 % ihrer Speicherkapazität erreicht hatte.
Mit einem solchen System konnten wir auf Notfälle reagieren. Das ist und bleibt noch immer das Wichtigste. Aber unser Ziel war es, in der Lage zu sein, präventive Maßnahmen treffen zu können, anstatt immer nur im „Notfallmodus“ zu arbeiten.
Wir hatten also zwei manuelle Bestandteile im Prozess, die für unser operatives Team recht anstrengend waren und die wir auf irgendeine Weise verbessern mussten: manuelle Überprüfungen des Servers und manuelle Kontaktaufnahme mit dem Kunden.
Neuer Prozess
Annahmen
- Es gibt andere, ähnliche Prozesse, die eine ähnliche Lösung erfordern. Die Lösung sollte also auf einfache Weise erweiterbar sein.
- Die meisten momentan auftretenden Festplattenprobleme können nicht ohne den Kunden gelöst werden. Die Lösung sollte also auch den Kontakt mit dem Kunden beinhalten.
Bei dieser Lösung haben sich einige Dinge geändert:
- Wir haben jetzt eine klare Trennung zwischen unserem Überwachungssystem und diesem präventiven System.
- Wir haben die manuellen Überprüfungen auf dem Server durch das Disk Alerts Messenger Tool ersetzt.
- Wir haben mit der Einführung des Customer Interactor Programms auch die Notwendigkeit für eine manuelle Kontaktaufnahme mit dem Kunden eliminiert.
Wir verwenden noch immer unser Überwachungssystem, um uns in Notfällen zu alarmieren (Festplattenauslastung 90 % oder höher), und wir verlassen uns auf diese Lösung, wenn die Festplattenauslastung 80 % überschreitet.
In den nächsten Abschnitten werden wir Ihnen unsere beiden neuen Lösungen vorstellen:
Das Disk Alerts Messenger Tool ist dafür verantwortlich, Informationen zur Festplattenverwendung zu ermitteln und zu senden.
Der Customer Interactor ist für die Kontaktaufnahme mit dem Kunden zuständig.
Disk Alerts Messenger
Wir definieren einen Messenger als eine Anwendung, die Nachrichten über AMQP an einen Message Broker sendet.
Der Disk Alerts Messenger ist ein Debian Paket, das auf jedem Node installiert ist (Server, virtuelle Maschinen, Docker Container, AWS EC2 Instanzen, ...), und dessen Aufgabe es ist, die Auslastung aller auf dem Node vorhandenen Festplatten zu melden.
Wenn die Auslastung einer Festplatte den eingestellten Schwellwert überschreitet (standardmäßig 80 %), scannen wir diese Festplatte, um festzustellen, welche der Dateien/Ordner den Platz einnehmen und senden die höchsten N davon (standardmäßig 25) über AMQP (wir verwenden RabbitMQ als Message Broker).
Befindet sich die Festplattenauslastung unter dem konfigurierten Schwellwert, wird eine andere AMQP Meldung gesendet, die darüber informiert, dass die Festplattenauslastung normal/wieder normal ist.
Customer Interactor
Bei einer bestimmten Nachricht von einem Node entscheidet diese Anwendung, wen sie kontaktieren muss und, noch wichtiger, ob wir überhaupt Kontakt aufnehmen müssen. Sie ist außerdem dafür verantwortlich zu entscheiden, ob eine Warnmeldung durch uns gelöst werden kann oder nur über einen Eingriff des Kunden.
Für Disk Alerts Meldungen erstellen wir zunächst ein Ereignis in unserem Ereignis-Verfolgungsprogramm mit allen Informationen, die für eine Diagnose des Problems notwendig sind (Host, größte Dateien/Ordner, ...).
Wenn das Problem nicht direkt durch uns gelöst werden kann, werden wir zusätzlich ein Ticket in unserer Kundendienstsoftware erstellen, um den Kunden über die Festplattenwarnung zu informieren.
Alle Ereignisse in unserem Ereignis-Verfolgungsprogramm werden automatisch gelöst, wenn die letzte aufgetretene Festplattenwarnung älter ist als 48 Stunden.
Vorteile/Nachteile der Lösung
Vorteile
- Automatisierung: der einzige menschliche Eingriff ist, wenn ein Kunde auf das Support-Ticket reagiert
- Kostenlose Verwaltung von Ereignissen: eingebaut in unser Ereignis-Verfolgungsprogramm
- Entkopplung von Herausgeber/Konsument über AMQP
Nachteile
- Disk Alerts Messenger wird auf jedem einzelnen Node installiert: dadurch wird er zu einer wichtigen Software (aber geringe Auswirkung bei einem Crash)
- Ressourcenverbrauch durch das Scannen von Festplatten auf allen Maschinen
- Einige der Festplatten sind zu groß, um vollständig gescannt werden zu können: das erfordert noch immer einen manuellen Eingriff, wenn diese Warnungen auslösen, da wir nicht bestimmen können, durch wen diese gelöst werden sollten (nine oder den Kunden)
Wie geht es jetzt weiter?
Intelligentere AI und Auto-Resolve Modus
Ein weiterer Aspekt wird sein, den Customer Interactor intelligenter zu machen in Bezug auf die Diagnose, was das „Problem“ auf der Festplatte eigentlich ist, und in Bezug auf einen Vorschlag, wie das Problem effektiv gelöst werden kann.
Wir gehen noch einen Schritt weiter: wenn wir das Problem einmal kennen und wissen, wie es gelöst werden kann, könnten wir bei Bedarf auch automatisierte Problemlösungen einsetzen (beispielsweise eine Leerung des /tmp-Ordners).
Data Mining
Mit den im Customer Interactor eingehenden Daten werden wir in der Lage sein, genauere Aussagen über die bisher aufgetretenen „Hauptprobleme“ zu treffen und darüber, wie diese effektiv verhindert werden können. Das ist nur der Anfang!
