Statusseiten für IT-Infrastruktur mit cState generieren

Kunden der Deutschen Bahn fühlen sich oft gleich doppeltem Ärger ausgesetzt: Erst kommt der Zug nicht oder zu spät, und dann sprechen automatische Lautsprecherdurchsagen und Apps schlicht von „Verzögerungen im Betriebsablauf“. So sieht eine professionelle Reaktion auf Störungen nicht aus. Kunden und Nutzer von Diensten erwarten heute – zu Recht – eine Erklärung des Problems, und viel Frust am Bahnsteig wäre vermieden, wenn zum Beispiel eine menschliche Stimme per Lautsprecher vermelden würde, dass Kriminelle soeben die Oberleitung gestohlen haben.

Aber nicht nur Bahnunternehmen, auch Betreiber von Websites und anderen IT-Dienstleistungen tun gut daran, ihren Nutzern eine Anlaufstelle bereitzustellen, bei der sie sich über Störungen informieren können. Einige der Großen machen vor, wie das aussehen kann. „Incident Management“ heißt diese Disziplin und informative Statusseiten sind ein Baustein. Über Probleme der IT-Infrastruktur offen zu sprechen ist heute keine Schande mehr – sie totzuschweigen schon eher. Unter der Adresse cloudflarestatus.com stellt zum Beispiel der DNS- und DDoS-Abwehr-Anbieter Cloudflare eine solche Übersicht über den Zustand seiner Systeme bereit. Für vernetzte Microsoft-Produkte wie Outlook.com, OneDrive und Skype gibt es admin.microsoft.com/servicestatus. Der Paketdienstleister DHL betreibt für Nutzer seiner APIs die Seite status.api.dhl.com, GitHub hat githubstatus.com.

Kein Wunder, könnte man einwenden, dass solche Großunternehmen sich das leisten können, schließlich haben die auch eigene Teams mit Mitarbeitern, die sich ausschließlich um Ausfälle und Probleme kümmern. Doch auch in kleinen Umgebungen können sich solche Statusseiten lohnen. Wenn Sie etwa die Infrastruktur für ein Unternehmen betreuen, den Mitarbeitern Mail-Postfächer, VPN und weitere Dienste bereitstellen und sie dazu erzogen haben, bei vermeintlichen Ausfällen zunächst die Statusseite zu prüfen, sparen Sie sich eine Menge Mails im Support-Postfach mit redundanten Hinweisen auf den Ausfall.

Die gesparte Zeit können Sie im Störungsfall für die Problembehebung aufwenden. Die einmalige Einrichtungsarbeit der Statusseite sollten Sie in ruhigeren Zeiten erledigen. Auf eine solche Seite gehören aber nicht nur unvorhergesehene Störungen, sondern auch Ankündigungen von geplanten Wartungsmaßnahmen. Je genauer Sie den Nutzern erklären, was hinter den Kulissen vorgeht, desto zufriedener sind diese mit Ihrer Arbeit.

Die Voraussetzungen

Damit eine Statusseite ihren Zweck erfüllen kann, muss sie so unabhängig wie möglich von der restlichen Infrastruktur sein, über deren Status sie berichten soll. Wenn Sie Ihre Server im eigenen Rechenzentrum betreiben, sollten Sie für die Statusseite ein kleines Hosting-Paket bei einem Web­hoster anmieten. Wenn Sie irgendwelche Dienste betreiben, die bei einem der großen Cloud-Provider wie AWS, Google oder Azure liegen (direkt oder indirekt über Produkte, die Sie bei Drittanbietern mieten), sollte die Statusseite definitiv woanders laufen – zum Beispiel bei einem kleineren Webhoster, der ein eigenes Rechenzentrum betreibt, gern auch außerhalb der Internetmetropole Frankfurt. So reduzieren Sie die Wahrscheinlichkeit, dass Sie sich einen „Single Point of Failure“ in Ihre Kommunikationsstrategie eingebaut haben.

Cloudflare geht sogar soweit, eine eigene Domain nur für seine Statusseite zu betreiben und vertraut diese nicht seinen eigenen DNS-Servern an, obwohl DNS das Kerngeschäft des Unternehmens ist. Die Domain cloudflarestatus.com wird von einem DNS-Server bei Google verwaltet. Ganz so weit müssen Sie nicht gehen. Viele Statusseiten liegen unter der Subdomain „status“, also etwa status.example.org. Solange Sie nicht selbst im DNS-Geschäft tätig sind und diese Aufgabe anderen überlassen, ist das ausreichend unabhängig. Versuchen Sie nicht, den Ausfall zu 100 Prozent auszuschließen, sondern vielmehr, offensichtlich verhängnisvolle Verkettungen zu verhindern.

Eine ganz simple Statusseite können Sie mit etwas HTML- und CSS-Erfahrungen selbst zusammenbauen. Es gibt aber auch Software, die noch schneller ansehnliche Statusseiten generiert und in ein Format bringt, das Nutzer von anderen Statusseiten gewohnt sind. Für solche Anwendungen kann man durchaus Geld ausgeben: Einige Unternehmen setzen auf das kommerzielle Produkt „Statuspage“ von Atlassian (in Aktion zu sehen bei redditstatus.com) und der Markt hat noch weitere kostenpflichtige Alternativen zum Selbsthosten oder als angemietete Lösung zu bieten.

Doch es gibt auch Open-Source-Alternativen: Lange war das Projekt Cachet populär (zu finden unter cachethq.io), das jedoch seit 2019 eingeschlafen zu sein scheint – obwohl auch große Unternehmen wie DHL noch darauf setzen (status.api.dhl.com). Im Hintergrund arbeitet eine Art Content Management System nur für Störungen und Probleme, zum Betrieb ist eine Datenbank wie MySQL oder PostgreSQL nötig.

Wesentlich schlanker und aktiv entwickelt ist „cState“. Im realen Einsatz sehen Sie cState etwa beim deutschen IT-Dienstleister Proventa (status.proventa.io). Die Entwickler von cState haben das Projekt nicht bei Null begonnen, sondern den Static-Site-Generator Hugo als Basis eingesetzt: Hugo rendert aus Markdown-Dateien HTML-Seiten, die fertig sind zum Ausliefern durch einen Webserver. Die Bedingungen, um cState zu betreiben, sind entsprechend leicht zu erfüllen: Das günstigste Paket bei einem Webhoster Ihres Vertrauens reicht aus – der Server muss keine Datenbank bereitstellen und keine Skript­sprachen wie PHP oder Perl ausführen, sondern nur HTML ausliefern.

Einzige Herausforderung: Um eine Störung einzutragen, muss man das Kommandozeilenwerkzeug hugo ausführen und die gerenderten Dateien auf den Server kopieren. Je nach Umgebung kann man diese Aufgabe aber auch einer Automation anvertrauen.

cState ausprobieren

Wenn Sie cState ausprobieren wollen, brauchen Sie zunächst den Static-Site-Generator Hugo. Falls Sie den nicht installieren wollen und Docker benutzen, finden Sie später im Artikel Hinweise, wie Hugo im Container seine Arbeit verrichtet.

Eine vollständige Installationsanleitung für Windows haben wir über ct.de/ycu6 verlinkt. Unter macOS kommen Sie am schnellsten mit dem Paketmanager Homebrew zum Ziel:

brew install hugo 

Linux-Anwender finden ein Paket namens hugo in ihren Paketquellen. Unter Ubuntu und Debian installieren Sie es mit

sudo apt install hugo

Fedora-Nutzer installieren Hugo mit

sudo dnf install hugo

Sobald hugo version bei Ihnen eine Versionsnummer und keinen Fehler anzeigt, können Sie loslegen. Jetzt brauchen Sie einen Ordner, in dem Sie Ihre Statusseite ablegen und verwalten. Hier liegen die Konfiguration, Grafiken wie Ihr Logo und alle Störungsmeldungen als Markdown-Dateien. Sehr empfehlenswert ist es, diesen Ordner von Anfang an in einer Versionsverwaltung wie Git zu verwahren und bestenfalls über einen Git-­Hoster wie GitLab oder GitHub mit Kollegen zu teilen.

Damit Sie nicht mit einem leeren Ordner beginnen müssen, haben wir ein Beispielprojekt vorbereitet. Es orientiert sich am offiziellen Beispielprojekt von cState, die Konfiguration ist aber schon auf die Bedürfnisse und Gewohnheiten von Mitteleuropäern angepasst und um Docker-­Rezepte erweitert. Laden Sie unser Beispiel bei GitHub herunter:

git clone https://github.com/jamct/cstate-example

Bewegen Sie sich in das Verzeichnis mit cd cstate-example. Hier müssen Sie zunächst das aktuelle cState nachladen, das als sogenanntes Git-Submodul hinterlegt ist:

git submodule update --init --recursive

Bevor Sie die fertige Seite rendern, sollten Sie mit Hugo einen lokalen Entwicklungsserver starten und Ihre Statusseite lokal anpassen:

hugo serve

Unter http://localhost:1313 finden Sie jetzt die Beispielseite, die aussieht wie das Beispiel oben. Haben Sie Hugo nicht installiert und wollen die Docker-Variante nutzen, führen Sie im Verzeichnis einfach folgenden Docker-Compose-Befehl aus:

docker-compose -f dc-dev.yml up

Nötige Anpassungen

Läuft die Seite, können Sie cState an Ihre Bedürfnisse anpassen. Los geht die Arbeit in der Datei config.yml. Am Anfang ändern Sie den Seitennamen, dann folgt der große Abschnitt params, in dem cState personalisiert wird. Zunächst legen Sie categories für Ihre Infrastruktur an. Das sind Gruppen, in denen Sie mehrere Dienste zusammenfassen und oben auf der Statusseite gebündelt darstellen. Große Unternehmen brauchen vielleicht die Kategorien „Europa“ und „Asien“, andere vielleicht „Online-Dienste“ und „Lokale Infrastruktur“. Dann folgen in systems Ihre Systeme. Ein paar Beispiele haben wir schon angelegt, typische Einträge sind etwa „Website“, „Mail“ oder „VPN“. Störungen werden später diesen Systemen zugewiesen – cState zeigt dann oben direkt in Ampelfarben an, ob Störungen für ein System offen sind.

Alle weiteren Optionen in der Datei config.yml sind gut mit Kommentaren dokumentiert. Es lohnt sich, hier einmal bis zum Ende zu scrollen, die Kommentare zu lesen und die Werte an eigene Wünsche anzupassen. Anschließend sollten Sie die Datei static/logo.png durch Ihr eigenes Logo ersetzen und die Datei layouts/partials/custom/below-­footer.html durch eine eigene Fußzeile austauschen.

Dann ist es an der Zeit, das erste Problem zu melden. Alle Störungen landen als eigene Dateien im Ordner content/issues. Zwei Beispiele haben wir bereits vorbereitet. Im Kopfbereich der Datei, eingerahmt von ---, tragen Sie Metadaten der Störung im YAML-Format ein. Behalten Sie dabei das vorgegebene Datumsformat bei, cState rechnet es um und stellt es im europäischen Format dar. Außerdem rechnet es automatisch aus, wie lange ein Ereignis schon zurückliegt, wie lange die Beseitigung gedauert hat und sortiert das Ereignis in der Darstellung im richtigen Monat ein.

Ist ein Problem behoben, setzen Sie resolved: true und ein Datum für resolved­When. Sobald das eingetragen ist, springt die Ampel oben auf der Seite wieder auf Grün.

Im Bereich unter den --- können Sie sich in der Auszeichnungssprache Markdown austoben und den Nutzern Status-­Updates geben, während Sie am Problem arbeiten.

HTML, bitte

Der Hugo-Server ist nicht dafür gedacht, die Seite an die Kunden auszuliefern. Nutzen Sie stattdessen hugo --minify, um statisches HTML mit komprimiertem CSS und JavaScript zu erzeugen. Die fertige Seite landet im Ordner public. Docker-­Nutzer bekommen mit unserer Docker-­Compose-Datei ihre gerenderten Dateien:

docker-compose -f dc-build.yml

Wie Sie die fertigen Dateien am bequemsten auf den Webserver bekommen, hängt etwas von Ihren Vorlieben und Ihrer Umgebung ab. Wenn Sie es gewohnt sind, Daten per FTPS oder SFTP auf den Server Ihres Webhosters zu kopieren, schreiben Sie sich zum Beispiel ein kleines Skript, das den Bauprozess startet und den Upload mit scp auslöst. Wenn Sie Erfahrung mit CI/CD-Lösungen wie GitHub Actions [1] haben, können Sie das Rendern auch dorthin auslagern – unser Beispiel-Repository enthält eine Workflow-Datei für GitHub Actions. Bei jedem Push ins Repository wird automatisch mit Hugo gebaut. So kann man die Seite bequem und sogar kostenlos mit GitHub Pages oder dem Serverless-Dienst „Zeit Now“ ausliefern lassen [2, 3].

Besser integriert

Weil alle Störungen als Textdateien in einem maschinenschreibbaren Format im Ordner content/issues liegen, sind nützliche Automationen denkbar – mit etwas Skript-Erfahrungen können Sie zum Beispiel Ihr Monitoring-Werkzeug dazu bringen, bei größeren Problemen schon mal eine mögliche Störung einzutragen. Sobald sich ein Mensch des Problems angenommen hat, ergänzt er einen Kommentar und beruhigt so die nervösen Nutzer. Zur Einführung einer solchen Statusseite gehört daher nicht nur die technische Komponente – damit das Projekt erfolgreich wird, gilt es auch, Nutzer und Admin-Kollegen von den Vorteilen zu überzeugen und daran zu gewöhnen. (jam@ct.de)

cState und Beispielprojekt: ct.de/ycu6