Wie wir die besten Statusseiten für das Incident-Management jeder Größe entwickelten

In diesem Blogbeitrag erklären wir, wie die Statusseiten in ilert funktionieren, auf welche Herausforderungen wir bei der Entwicklung dieses Features gestoßen sind und mit welchen Ansätzen wir die Probleme angegangen sind.

Rückblick: Deshalb haben wir Statusseiten eingeführt

ilert ist seit langem eine zuverlässige Plattform für kritische Benachrichtigungs-, Alarmierungs- und Eskalationsprozesse. Anfang 2021 erkannten wir die Notwendigkeit, den Umfang unseres Angebots zu erweitern, um die Bedürfnisse unserer Kunden besser erfüllen zu können. Dies führte zu einer wesentlichen Verfeinerung unseres Ansatzes: die Trennung von Benachrichtigungen in Alarmierungen und Störungen.

‍

Alarmierungen sind kritische Meldungen, die sich in erster Linie an Entwicklungs- und Support-Teams richten. Sie beziehen sich auf Probleme wie Serveranomalien, die sich direkt oder indirekt auf die Gesamtleistung der Kundensysteme auswirken können. Auf der anderen Seite bezeichnen Störungen schwerwiegende Probleme, die sich auf die Systeme des Kunden auswirken und oft so eskalieren, dass die Endnutzer betroffen sind. In diesem Artikel beschreiben wir im Detail, wie wir zu dieser Entscheidung gekommen sind.

‍

Durch die Kategorisierung von Problemen als Alarmierung oder Störung waren wir in der Lage, unsere Reaktionsstrategien effizient zu gestalten. Darüber hinaus führte diese Unterscheidung logischerweise zur Einführung von Statusseiten als neues zentrales Kommunikationsinstrument bei Incidents, um Transparenz und die Weitergabe aktueller Informationen an alle beteiligten Stakeholder zu gewährleisten.

‍

Mitte 2021 begannen wir mit der Planung unserer zukünftigen Statusseiten. Die Leitprinzipien für die Entwicklung dieser Statusseiten waren zweierlei: einwandfreie technische Ausführung und nahtlose native Integration mit unserer bestehenden Plattform. Der letzte Punkt war dabei die größte Herausforderung. Damals (und auch heute noch) gab es in der Branche keine Erfahrung mit der Kombination einer Incident-Management-Plattform und Statusseiten als nativ integrierte Lösung. Wenn man sich die bekanntesten Lösungen auf dem Markt anschaut, wie zum Beispiel Atlassian Status Pages und OpsGenie, dann sind das jeweils separate Produkte. Unser Ziel war es, zwei Lösungen so zu kombinieren, als ob sie eine einzige wären. Und natürlich wollten wir die Statusseiten zu einer transparenten, leicht verständlichen Funktion machen, die die Benutzerfreundlichkeit unserer Plattform sowohl für unsere direkten Nutzer als auch für Drittanbieter verbessert.

Entwicklung

Unser Bestreben war es, eine superschnelle Performance sowohl für unsere Seiten als auch für unsere APIs zu gewährleisten. Ursprünglich dachten wir an CDN-basierte Statusseiten, um den Rendering-Prozess zu optimieren. Im Laufe der Entwicklung sahen wir uns jedoch mit verschiedenen Herausforderungen konfrontiert, darunter die dynamische Generierung von Zertifikaten für benutzerdefinierte Domains, die schnelle Aktualisierung von Statusseiten, die gegenseitige Authentifizierung für private Seiten und die dynamische Anpassung von Inhalten auf der Grundlage von Benutzereingaben, um nur einige zu nennen.

‍

Diese Herausforderungen veranlassten uns, einen Server-Side-Rendering (SSR)-Ansatz mit einer mehrschichtigen Caching-Strategie zu verfolgen. Wir prüften verschiedene Standardlösungen, fanden sie aber für unsere Bedürfnisse ungeeignet. Also entwickelten wir eine auf unsere Anforderungen zugeschnittene SSR-Lösung, die uns die ultimative Kontrolle von der ersten Benutzeranforderung bis zur endgültigen Pixelauslieferung ermöglicht. Das Ergebnis ist eine ideale Performance sowohl auf dem Desktop als auch auf mobilen Geräten.

‍

Eine der größten Schwierigkeiten war die Aufbereitung der Daten vor dem Rendering der Seite. Wir mussten die für die Microservices der Statusseite benötigten Daten vollständig von den zugrunde liegenden Daten trennen, zum Beispiel von den Daten, die der Nutzer in der Verwaltungsoberfläche ändert.

‍

Um dies zu erreichen, wird ein spezieller Microservice eingesetzt, der die Aufgabe hat, alle mit der Statusseite verbundenen Änderungen zu überwachen, einschließlich den Aktualisierungen von Properties, Incidents, Wartungsfenstern und Diensten. Dieser Microservice erhält die erforderlichen Daten über Events aus der ilert-Plattform. Anschließend werden diese Daten in ein sogenanntes „Invalidierungsevent“ umgewandelt und an eine spezielle Messaging-Queue für die Bearbeitung von Aktualisierungen der Statusseite weitergeleitet.

‍

Ein weiterer Microservice, der für die Verarbeitung dieser Aktualisierungen zuständig ist, nimmt die Nachrichten aus der Warteschlange entgegen. Er übernimmt die Speicherung der Daten in einer Long Term-Datenbank und aktualisiert den Cache-Speicher entsprechend. Der verarbeitende Microservice arbeitet kontinuierlich und zieht neue Invalidierungsevents aus der Event-Queue, sobald sie eintreffen, um sicherzustellen, dass die Informationen aktuell und korrekt bleiben. Dank dieser Struktur von Invalidierungsevents kann unser System schnell und mit minimaler Latenz aktuelle Statusseiten-Informationen darstellen und anzeigen.

‍

Dieser Ansatz ermöglicht auch die physische Trennung der logischen Komponenten der Plattform auf der Datenspeicherebene, sodass die Statusseiten-Microservices ohne Verzögerung oder Unterbrechung arbeiten können, selbst wenn die Hauptdatenbank aus irgendeinem Grund Performance-Probleme hat.

‍

Mobile Leistung

Desktop-Leistung

Microservices von Statusseiten

Um die Komplexität der Funktion zu strukturieren, haben wir die Statusseiten in Microservices unterteilt: Gateway, Content Renderer, Content Updater, Certificate Updater und Background Cache Runner.

‍

Gateway: Dieser Microservice initiiert den Prozess bei jeder Anfrage, indem er die Statusseite über die im Browser des Nutzers eingegebene Domain ausfindig macht. Er bewertet den Seitentyp und die Rechte des Nutzers auf der Grundlage der vorkonfigurierten Einstellungen in der ilert-Oberfläche.

‍

Content Renderer: Er wird aktiv, sobald das Gateway den Zugriff autorisiert. Er prüft zunächst, ob eine vorgerenderte Seite im Cache verfügbar ist. Öffentliche Seiten oder private Seiten ohne spezifische Konfigurationen werden unter ihrer Domain gecached. Zielgruppenspezifische Seiten hingegen werden individuell zwischengespeichert, um den Zugriffsbeschränkungen einzelner Nutzer gerecht zu werden. Wenn eine Seite im Cache verfügbar ist, wird sie sofort ausgeliefert. Ist dies nicht der Fall, versucht der Renderer, die Seite schnell zu generieren und im Cache zu speichern. Sollte dieser Prozess die Zeitgrenzen überschreiten, wird ein grundlegendes, vorgerendertes Seitenlayout an den Browser des Benutzers gesendet, der das Rendering lokal abschließt und kurz einen Skeleton Loader anzeigt, während sich die Seite aufbaut; dies ist besonders hilfreich für unsere größeren Unternehmenskunden, die manchmal Unterstützung bei der Erstellung großer Mengen von Beziehungen in ihren Ressourcen benötigen.

‍

Content Updater: Der Microservice verarbeitet Content Updates, indem er zunächst Anfragen vom Gateway erhält. Anschließend arbeitet er mit dem Content Renderer zusammen, um Daten in eine HTML-Seite umzuwandeln, die er zur Anzeige durch den Nutzer an das Gateway zurücksendet. Außerdem wird die HTML-Seite im Cache gespeichert, um künftige Anfragen zu beschleunigen und den Nutzern einen schnellen und responsive Zugriff auf aktualisierte Inhalte zu ermöglichen.

‍

Background Cache-Runner: Er signalisiert fehlende Caches, um die Seite im Hintergrund zu generieren, unabhängig von der Generierungszeit, und stellt so sicher, dass sie innerhalb von Millisekunden für zukünftige Anfragen bereit ist. Außerdem werden die Seiten als Reaktion auf Änderungen in der Verwaltungsoberfläche oder in verwandten Komponenten wie Diensten, Störungen oder Wartungsfenstern aktualisiert, sodass die Statusseiten immer auf dem neuesten Stand sind.

‍

Certificate Updater: Dieser Microservice verwaltet dynamisch die Sicherheit der benutzerdefinierten Domain-Statusseiten, indem er Events vom Certificate Manager abruft. Beim Empfang dieser Events werden die Informationen zu SSL-Zertifikaten automatisch aktualisiert, um sicherzustellen, dass die Statusseiten immer mit optimaler Sicherheit und Konformität funktionieren.

Infrastruktur

Unsere Infrastruktur basiert auf der Vielseitigkeit und Zuverlässigkeit von Kubernetes, das das Zusammenspiel unserer zustandslosen und zustandsorientierten Microservices gewährleistet. Ob bei der Skalierung in Spitzenzeiten oder bei der Sicherstellung der Fehlertoleranz, Kubernetes bietet das zuverlässige Gerüst, das für einen kontinuierlichen Service erforderlich ist. Wir verwenden Redis sowohl zum Caching von Statusseiten als auch für die schnelle Kommunikation zwischen den Diensten. Durch die Konfiguration mehrerer Redis-Datenbanken optimieren wir diese Prozesse separat und effizient, um sie an den Bedarf unserer Dienste anzupassen.

‍

Seiten-Caching: Redis speichert die gerenderten Statusseiten im Cache, sodass sie bei nachfolgenden Anfragen schnell und ohne erneutes Rendern abgerufen werden können. 

‍

Service-Kommunikation: Die Microservices unseres Systems, wie zum Beispiel der Content Renderer, der Background Cache Runner und der Certificate Updater, kommunizieren über Events unter Verwendung von Message Queues, was die Fehlertoleranz und Skalierbarkeit verbessert. Auf diese Weise können die Dienste unabhängig voneinander arbeiten, sodass die Systemintegrität und Responsiveness auch dann gewährleistet ist, wenn ein Dienst ausfällt, und eine flexible Skalierung auf der Grundlage des Traffics oder der Datenanforderungen möglich ist. Außerdem wird die Ressourceneffizienz durch Deduplizierung hochfrequenter, redundanter Aktualisierungen der Statusseiten erhöht.

‍

Wir verwenden Redis ausschließlich für Caching-Zwecke auf unserer gesamten Plattform und konfigurieren separate Cache-Datenbanken für fast jeden Microservice wie das Gateway, den Content Renderer und den Background Cache Runner. Diese Aufteilung stellt sicher, dass jeder Microservice unabhängig arbeitet und seinen eigenen Cache unterhält, um einen schnellen und zuverlässigen Datenzugriff ohne Beeinträchtigung durch andere Services zu gewährleisten, während wir die Cloud-Kosten durch Skalierung der Instanzen entsprechend ihrer Arbeitslast reduzieren können. NGINX dient als Reverse Proxy und Load Balancer, leitet Nutzeranfragen effizient an verfügbare Ressourcen weiter und verbessert Sicherheitsprotokolle wie die SSL/TLS-Terminierung für HTTPS-Verbindungen.

‍

Im Hinblick auf die Sicherheit, insbesondere für benutzerdefinierte Domains auf Statusseiten, setzen wir CertManager in unseren Kubernetes-Clustern ein, um die Verwaltung und Ausstellung von TLS-Zertifikaten zu automatisieren und die Sicherheitsabläufe ohne manuelle Eingriffe zu optimieren.

‍

Hier eine grobe Übersicht über das Setup:

‍

Diese Architektur garantiert, dass jede Komponente zustandslos und über mehrere Instanzen oder geografische Standorte hinweg skalierbar ist, wo immer Kubernetes eingesetzt werden kann. Die Agilität, die Kubernetes, Redis und NGINX in unserem Setup bieten, stellt sicher, dass wir die Nutzer effizient bedienen und eine hohe Verfügbarkeit und Zuverlässigkeit über alle Standorte hinweg aufrechterhalten können. 

ilert-Statusseiten heute

Im April 2022 haben wir die Statusseiten für alle ilert-Kunden verfügbar gemacht. Im Zuge unserer kontinuierlichen Innovationen und Verbesserungen sind unsere Kubernetes-Cluster nun in mehreren wichtigen Regionen in Betrieb, und wir planen eine weitere Expansion. Außerdem haben wir eine neue Art von zielgruppenspezifischen Statusseiten und brandneue Authentifizierungsoptionen für unsere privaten Seiten eingeführt.  

‍

Die in die Incident-Management-Plattform integrierten Statusseiten von ilert sind von Natur aus zuverlässiger und robuster als eigenständige Lösungen, da sie sich in bestehende Workflows integrieren und eine Echtzeit-Synchronisation von Incident-Updates gewährleisten. Im Gegensatz zu separaten Tools, die auf externe APIs oder manuelle Prozesse angewiesen sind, spiegelt eine integrierte Statusseite automatisch und ohne Verzögerung den aktuellen Status der Systeme wider und reduziert so das Risiko, dass veraltete oder falsche Informationen angezeigt werden. Darüber hinaus vereinfacht diese enge Integration die Wartung, beseitigt Kompatibilitätsprobleme und erhöht die Datensicherheit, da die gemeinsame Nutzung sensibler Informationen mit Plattformen Dritter vermieden wird.