ilert ist die Incident-Management-Lösung, die von Grund auf als Single-Application konzipiert wurde und den gesamten Lebenszyklus der Reaktion auf Vorfälle abdeckt.
Die Funktionen, die Sie für den Betrieb von Always-On-Services benötigen
Jede Funktion in ilert wurde entwickelt, um Ihnen zu helfen, schneller auf Vorfälle zu reagieren und die Verfügbarkeit zu erhöhen.
Nutzen Sie das Potenzial generativer AI
Verbessern Sie die Kommunikation bei Vorfällen und optimieren Sie die Erstellung von Post Mortems mit ilert AI. ilert AI unterstützt Ihr Unternehmen dabei, schneller auf Vorfälle zu reagieren.
ilert stellt mithilfe unserer vorgefertigten Integrationen oder per E-Mail eine nahtlose Verbindung zu Ihren Tools her. Ilert lässt sich in Überwachungs-, Ticketing-, Chat- und Kollaborationstools integrieren.
Wir haben unseren Incident-Management-Prozess mit ilert transformiert. Unsere Plattform ist intuitiv, zuverlässig und hat die Reaktionszeit unseres Teams erheblich verbessert.
Das Jahr 2025 startet mit jeder Menge praktischer ilert-Updates!
Deployment- events
Mit der Funktion “Deployment-Events” können Sie Ihre CI/CD-Pipelines in ilert integrieren. Alert-Kontexte werden erweitert und die Ursachenanalyse von Downtimes erleichtert. Deployment-Pipeline-Integrationen senden automatisch erfolgreiche Deployment-Events an ilert und bieten Ihnen eine komplette Übersicht über Ihren Entwicklungsprozess. Im Falle eines Incidents haben Programmierer schnellen Zugriff auf die letzten Codeänderungen und können im Handumdrehen feststellen, ob diese Änderungen eine Störung verursacht haben könnten. Sie finden diese neue Funktion unter dem Tab “Alert Sources” in Ihrem ilert-Konto. Sie können eine der vorinstallierten Integrationen – wie zum Beispiel GitHub oder GitLab verwenden – oder eine generische API-Deployment-Pipeline. Weitere Integrationen beliebter CI/CD-Tools sind geplant! Teilen Sie uns gerne mit, welche Anwendung Sie nutzen und in ilert unbedingt sehen möchten: support@ilert.com.
Übrigens: ilert Deployment Events sind auch schon im Terraform Provider verfügbar. Schauen Sie sich dazu gerne die Dokumentation an.
Alert-Reports 2.0
Wir haben die Berichtsfunktion in ilert komplett überarbeitet. Der Bereich hat jetzt ein modernes Design und bietet schnellen Zugriff auf die wichtigsten Kennzahlen: Anzahl der Alarmierungen, MTTA und MTTR. Außerdem gibt es mehr Filteroptionen für einen präziseren Überblick über die Performance Ihres Teams und Ihres Unternehmens.
Noch besseres Call Routing
Im Jahr 2024 hatten wir ja einen tollen, intuitiven Call Routing-Builder eingeführt – und jetzt können Sie noch mehr Funktionen einer der fortschrittlichsten Hotline-Anwendungen ausprobieren!
KI Voice Agent (geschlossene Beta-Version)
Es gibt jetzt einen neuen Node im Call Flow Builder: den KI Voice Agenten, einen menschenähnlichen Agenten für natürliche Unterhaltungen und intelligentes Routing. Der Agent übernimmt die erste Kommunikation mit dem Anrufer, verarbeitet die erfragten Informationen und erstellt je nach Eingabe einen Incident oder ruft einen dienstbereiten Techniker an. Diese neue Funktion zielt darauf ab, die erste Interaktion über das Anruf-Routing noch individueller und umfassender zu gestalten und den Technikern in Bereitschaft einen informativen Kontext zu liefern, bevor sie Maßnahmen ergreifen können.
Der erste Schritt bei der Einrichtung des neuen Nodes besteht darin, eine Absicht (“Intent”) festzulegen – der Grund, warum der Anrufer Sie über die Hotline kontaktiert hat. Sie können zwischen verschiedenen Anliegen wählen: Meldung einer kritischen Störung, eines Systemausfalls oder einer Sicherheitsverletzung, Anforderung von technischem Support oder eine allgemeinen Anfrage. Sie können einen Intent auch selbst konfigurieren, indem Sie ihm bestimmte Wörter und Wortkombinationen zuweisen. Im nächsten Schritt können Sie angeben, welche Informationen Sie vom Anrufer erfragen möchten. Sie können zum Beispiel nach einem Namen, einer Kontaktnummer oder den betroffenen Services fragen. Sobald der Zweck des Anrufs für den KI-Voice-Agenten klar ist, erstellt er einen neuen Node in dem Flow und eine Benachrichtigung mit allen erfassten Daten für die dienstbereiten Techniker.
Wenn Sie als einer der Ersten diese Funktion testen möchten, wenden Sie sich bitte an unser Support-Team. Bitte beachten Sie, dass nur Nutzer des Call-Routing Add-ons diese Funktion testen können.
Templates
Sie müssen einen neuen Call-Flow nicht mehr von Grund auf neu erstellen. Wir haben Vorlagen für drei der gängigsten Anruf-Routing-Szenarien erstellt, die Sie als Ausgangspunkt für Ihren eigenen Flow verwenden können. Gehen Sie in ilert einfach auf den Tab „Call Routing“ im oberen Menü. Dort können Sie mit der Erstellung eines neuen Flows beginnen und neue, sofort nutzbare Vorlagen entdecken.
Nummern blockieren
Ein neuer Node ermöglicht es ilert-Nutzern, Blacklists zu erstellen und Anrufe von bestimmten Nummern abzulehnen. Sie finden ihn unter dem “Plus”-Symbol.
Wiederholte Anrufsversuche
Wir haben die Erstellung der Flows für wiederholte Anrufe – für den Fall, dass der Anruf beim ersten Versuch nicht beantwortet wurde – vereinfacht. Sie können jetzt die Anzahl der Versuche festlegen und müssen die sich wiederholenden Flows nicht mehr neu erstellen. Sie finden diese Einstellung im Node “Route Call”.
Anruf-Timeout
Mit dem aktuellen Update können Sie auch die maximale Klingelzeit in Sekunden angeben, bevor der Anruf als unbeantwortet markiert und an den nächsten Nutzer eskaliert wird.
ITL – ilert Template-Sprache
Mit der ITL können Sie Alerts individualisieren und auf Ihre spezifischen Anwendungsfälle anpassen. Sie bietet nicht nur eine hohe Flexibilität bei der Formatierung und Strukturierung von Alerts, sondern auch eine Vielzahl von eingebauten Funktionen, die die Lesbarkeit der Alarmierungen verbessern. ITL enthält auch Funktionen wie String Manipulation, Formatierung von Datum und Uhrzeit und das Verketten ("joinen") von Arrays. Diese Flexibilität ermöglicht die einfache Textformatierung, Datenextraktion und Transformationen – innerhalb desselben Templates. Weitere Informationen über die Syntax finden Sie in der Dokumentation.
Audit-Logs
Eine neue Funktion für Enterprise-Kunden: Audit- Logs sind detaillierte Aufzeichnungen von Systemaktivitäten, die eine chronologische Abfolge von Ereignissen, Änderungen und Aktionen innerhalb der ilert-Plattform festhalten. Audit-Logs sind unerlässlich, um die Systemnutzung zu verfolgen, die Nachvollziehbarkeit zu gewährleisten und um Compliance-Anforderungen zu erfüllen.
Mobile App
Anfrage für die Übernahme von Bereitschaftsdiensten
Sie können jetzt einen Kollegen bitten, Ihren Dienst ganz oder teilweise zu übernehmen – direkt über die App. Gehen Sie zum Menü in der ilert-App und suchen Sie im Bereich „Bereitschaftsdienst“ unter Ihrem Avatar die Schaltfläche „Request Coverage“ (Dienst-Übernahme). Alternativ können Sie im Kalender auf „Meine Bereitschaften“ gehen und auf das Symbol mit den drei Punkten tippen. Wenn Sie eine Anfrage von einem Kollegen erhalten, bekommen Sie eine Push-Nachricht. Der Dienst wird nur überschrieben, wenn ein Empfänger die Anfrage annimmt.
Einige der benutzerdefinierten Töne in der ilert-App sind jetzt länger, um sicherzustellen, dass Sie im Falle einer Downtime die Benachrichtigung nicht verpassen.
Die Farbe der Kopfzeile wurde für bessere Lesbarkeit dezenter gestaltet.
Wenn Sie die ilert-App noch nicht kennen, empfehlen wir Ihnen, sie auszuprobieren! ilert-Nutzer, die die App regelmäßig nutzen, verzeichnen eine deutliche Reduzierung der MTTA. Hier geht es zum Download für Android und iOS.
Kleine, aber nützliche Verbesserungen
Verwenden Sie eine “Re-Route Alert”-Aktion, um Alarmierungen, die bis zum Ende eskaliert wurden oder in einem bestimmten Zeitraum nicht gelöst wurden, automatisch an eine andere Eskalationsstufe weiterzuleiten.
Für diejenigen, die nicht alle Empfänger in den Benachrichtigungen der ilert Email Outbound Integration anzeigen möchten, haben wir ein BCC-Feld hinzugefügt.
Das Erstellen einer Alarmierung aus einer Call-Flow-Source ist jetzt noch intuitiver.
Mehrfach-Lösung von Alarmierungen mit der globalen Suche von ilert. Hier finden Sie eine Anleitung dazu.
Integrationen
Noch mehr sofort einsatzfähige Optionen für Alarmierungsquellen:
Honeybadger.io — ein Monitoring-Tool, das Fehler, Betriebszeit und Performance in Webanwendungen verfolgt.
ServerGuard24 — ein Monitoring-Dienst, der die Serverleistung überwacht und Alarmierungen für IT-Systeme liefert..
Healthchecks.io — ein Monitoring-Tool, das geplante Aufgaben überwacht und Sie benachrichtigt, wenn sie nicht ausgeführt werden.
Amazon DevOps Guru — ein auf maschinellem Lernen basierender Service, der betriebliche Probleme in Anwendungen identifiziert und behebt.
AWS CloudTrail — eine Anwendung, die Aktivitäten in Ihrem AWS-Konto protokolliert und überwacht, um Sicherheit und Compliance zu gewährleisten..
AWS Security Hub — ein zentraler Dienst, der Sicherheitsinformationen und Compliance-Prüfungen in Ihrer gesamten AWS-Umgebung bereitstellt..
ThousandEyes — eine Network Intelligence-Lösung, die die Anwendungs- und Netzwerkleistung im Internet und in der Cloud überwacht..
Gerne können Sie über unseren Support weitere Integrationen anfordern, die für Ihr Unternehmen relevant sind.
Dieser Artikel wurde ursprünglich im Blog von N-able veröffentlicht. N-able, ein Partner von ilert, bietet IT-Management- und Monitoring-Lösungen speziell für Managed Service Provider (MSPs) und IT-Experten. Die Produktpalette von N-able umfasst Tools für Fernüberwachung, Backup, Schutz von Endgeräten und Netzwerkverwaltung. Diese Lösungen helfen MSPs dabei, ihren IT-Betrieb zu optimieren, die Sicherheit zu erhöhen und zuverlässige Services bereitzustellen. Erfahren Sie mehr über die ilert-Integration für N-able N-central.
Incident-Response-Management bezeichnet einen strukturierten Ansatz zur schnellen Identifizierung, Analyse und Lösung von IT-Störungen. Der Begriff Incidents beschreibt in diesem Kontext Abweichungen vom Normalzustand eines IT-Netzwerks, die den Betrieb, die Kundenerfahrung und letztendlich das gesamte Geschäft beeinträchtigen können. Diese Definition dient dazu, Incidents von technischen Warnmeldungen abzugrenzen, die zwar auf Probleme in der Netzwerk-Infrastruktur hinweisen können, jedoch noch keine Auswirkungen auf den Kunden haben.
Die schnelle und effektive Behebung von Incidents ist entscheidend, damit MSPs (Managed Service Provider) eine positive Kundenerfahrung aufrechterhalten können. Dennoch ist effektives Incident-Management oft ein komplexer Prozess. Während größere MSPs häufig vollständigen Zugriff auf die Infrastruktur ihrer Kunden haben und in kritischen Situationen schnell und eigenständig agieren können, haben kleinere Unternehmen meist nur Zugriff auf einen Teil der Services und des Technologie-Stacks. Dies erschwert eine effektive Reaktion auf Störungen erheblich.
Zusätzlich stehen MSPs regelmäßig vor weiteren Herausforderungen bei der Gewährleistung operativer Exzellenz, darunter:
Vielfältige Kundenumgebungen: MSPs betreuen unterschiedliche Kunden mit individuellen SLAs (Service-Level-Agreements), die spezifische Reaktions- und Lösungszeiten vorschreiben.
Remote-Management: Die Diagnose und Lösung von Problemen aus der Ferne erhöht die Komplexität.
Heterogene Umgebungen: Jeder Kunde verwendet möglicherweise unterschiedliche Software, Hardware und Konfigurationen.
Eine effektive Incident-Response-Strategie ist für MSPs unerlässlich, um die Systeme ihrer Kunden zu schützen, Vertrauen aufzubauen und ihren eigenen Ruf zu wahren. Eine schlecht gehandhabte Störung kann zu einer Vielzahl von Problemen führen, wie zum Beispiel Betriebsunterbrechungen, finanziellen Verlusten, Kundenabwanderung, Reputationsschäden sowie rechtliche und regulatorische Strafen.
Auf der anderen Seite bietet effektives Incident-Response-Management einen echten geschäftlichen Mehrwert für MSPs, indem es Folgendes ermöglicht: Minimierung von Downtimes (Erfüllung von SLAs und Vermeidung von Strafzahlungen), Aufbau von Kundenvertrauen, Einhaltung von Compliance- und Regulierungsanforderungen (speziell für ihre Branche oder für Cyber-Versicherungen), Reputationsschutz, Kostenreduzierung (zum Beispiel Wiederherstellungskosten).
Da sich Cyber-Bedrohungen kontinuierlich weiterentwickeln, ist der Bedarf an schnellen, effizienten und gut koordinierten Reaktionen auf Störungen größer denn je. Doch wie lässt sich ein effektiver Incident-Response-Prozess aufbauen?
ilert ist Mitglied im “N-able Technology Alliance Program" und bietet eine fortschrittliche Plattform für Incident-Management, die sich nahtlos in N-able N-central integrieren lässt. Ich habe mit Daria Yankevich, Partner Marketing Manager bei ilert, darüber gesprochen, welche Erfahrungen das Unternehmen bei der Zusammenarbeit mit MSPs gemacht hat und welche Best Practices für das Incident-Management von MSPs am wichtigsten sind.
Die vier Phasen des Incident-Response-Managements
„Der Incident-Lebenszyklus umfasst vier Phasen“, erklärt Daria: „Vorbereitung, Reaktion, Kommunikation und Lernen. Die Unterteilung der wichtigsten Empfehlungen für das Incident- Management in diese vier Bereiche vereinfacht die Arbeit für Teams und hilft ihnen, ihre Position in kritischen Situationen klar zu verstehen.“
Phase 1: Vorbereitung auf einen Incident
Automatisierung von Incident-Erkennung und Reaktion
„Automatisierung ist eng mit Tools verbunden“, sagt Daria. „Wir sehen vier Schlüsselbereiche, auf die erfahrene MSPs ihren Fokus legen, um Systemprobleme so schnell wie möglich zu erkennen und darauf zu reagieren.“
1. Monitoring und Observability
Tools, die die Systemleistung überwachen, Daten aufzeichnen und das Verhalten von Anwendungen analysieren, bieten einen Überblick in Echtzeit über Ihre IT-Systeme. Dadurch können potenzielle Störungen schnell erkannt werden. Lösungen wie N-able N-central helfen dabei, Multi-Tenant-Umgebungen zu überwachen.
2. Bereitschaftsmanagement
In einer Multi-Client-Umgebung ist es eine Herausforderung, Bereitschaftsdienste über Kalender oder Tabellen zu organisieren. Stellen Sie sicher, dass die Rufbereitschaften ordnungsgemäß zwischen Kunden und dedizierten Teams verteilt sind, die Rotation automatisch erfolgt und Techniker immer wissen, wann ihre Schichten beginnen. Eine bewährte Methode ist der mobile Zugriff auf das On-Call-Managementsystem, um Zeitpläne bei Bedarf auch unterwegs anpassen zu können.
3. Alarmierung
Sobald ein Incident erkannt wird, ist eine schnelle und kanalübergreifende Benachrichtigung der Techniker entscheidend. Alarmierungstools sorgen dafür, dass die richtigen Informationen zur richtigen Zeit bei den richtigen Personen ankommen. Alarmierungsplattformen für MSPs können Alerts aus verschiedenen Mandantenumgebungen anzeigen und klar trennen sowie Eskalationsrichtlinien erstellen, die den SLA-Anforderungen unterschiedlicher Kunden entsprechen. Ihre Alarmierungssysteme sollten so fortschrittlich sein, dass sie Alerts aus verschiedenen Quellen verarbeiten und in Telefonanrufe, SMS, Push-Benachrichtigungen und andere Benachrichtigungstypen umwandeln können. Obwohl maschinell erkannte Alarmierungen für MSPs typisch sind, melden Kunden in vielen Fällen Störungen direkt über Tickets oder Telefonanrufe. Für diese beiden Arten benötigen MSPs zusätzliche Tools.
4. Manuelle Meldung von Störungen
Die Kunden von MSPs benötigen eine schnelle, benutzerfreundliche und vertraute Möglichkeit, Anomalien zu melden. Eine Option ist Call Routing – eine Hotline, über die Kunden eine dedizierte Telefonnummer anrufen können, wodurch direkt eine Alarmierung erstellt wird. Eine weitere Lösung ist ein Ticketing-System. Abhängig von den SLA-Anforderungen können Sie zwischen diesen Optionen wählen oder beide für unterschiedliche Szenarien nutzen.
Einführung eines strukturierten Incident-Response-Plans
„Ein gut durchdachter Reaktionsplan stellt sicher, dass Störungen mit System bearbeitet werden“, ergänzt Daria. „Der beste Weg, dies zu erreichen, besteht nicht nur darin, Anweisungen auf Papier festzuhalten, sondern auch durch tatsächliche Trainingssessions, in denen ein Incident simuliert wird.
Das Training muss die folgenden vier Ziele verfolgen:
Techniker kennen die Eskalationsverfahren und haben alle Benachrichtigungen korrekt eingerichtet.
Sie verstehen die Infrastruktur des Kunden genau und wissen, wie sie darauf zugreifen können.
Sie erhalten praktische Schulungen zur Eindämmung und Bewältigung verschiedener Arten von IT-Störungen, die typisch für einen bestimmten Kunden sind.
Techniker von MSPs werden mit realistischen, anspruchsvollen Szenarien konfrontiert, in denen sie Aufgaben priorisieren und Ressourcen effektiv zuweisen müssen, um das Treffen von Entscheidungen zu trainieren."
Phase 2: Reaktion
Daria erklärt weiter: „In der Reaktionsphase des Incident-Managements bestimmen zwei entscheidende Faktoren den Erfolg eines MSP-Ansatzes: die Geschwindigkeit, mit der der MSP die Störung bestätigt, und die effiziente Festlegung von Prioritäten, wenn mehrere Incidents bei verschiedenen Kunden gleichzeitig auftreten.
„Eine schnelle Rückmeldung ist von entscheidender Bedeutung, da eine schnelle Reaktion den Kunden versichert, dass das Problem angegangen wird und mögliche Ausfallzeiten reduziert werden. Gleichzeitig ist die Priorisierung unerlässlich, wenn mehrere Vorfälle auftreten.
MSPs sollten ihre Priorisierungen auf SLA-Verpflichtungen und den Auswirkungen der einzelnen Störungen auf die Betriebsabläufe der Kunden basieren. Ein kritischer Serverausfall, der das gesamte Geschäft eines Kunden betrifft, sollte beispielsweise Vorrang vor einem geringfügigen Anwendungsproblem bei einem anderen Kunden haben.“
Phase 3: Kommunikation
Wie bei jeder Kundeninteraktion ist auch hier eine effektive Kommunikation entscheidend. „Es gibt mehrere Möglichkeiten, Kunden auf dem Laufenden zu halten“, sagt Daria. „Eine davon ist die manuelle Übermittlung von Updates per Telefonanruf oder Nachrichten durch einen MSP-Account-Manager. Dieser Ansatz ist jedoch nicht skalierbar und kann zu Kommunikationsfehlern und Missverständnissen führen. Wir empfehlen, eine Statusseite einzurichten, die Kunden abonnieren können.“
Daria empfiehlt, dass MSPs separate Statusseiten für jeden Kunden einrichten sollten, was sich in der Regel gut für kleinere Unternehmen eignet. Dieser Ansatz wird jedoch teurer, je mehr Kunden hinzukommen. Für größere Anbieter wird dringend empfohlen, zielgruppenspezifische Seiten zu verwenden, die nur relevante Daten basierend auf Nutzerparametern anzeigen. Dies reduziert nicht nur die Kosten, sondern minimiert auch die Anzahl der zu wartenden Seiten.
Daria hebt vier wichtige Punkte hervor, die berücksichtigt werden sollten:
Zeitnähe: Schnelle Kommunikation hilft, Kundenerwartungen zu erfüllen und Unsicherheiten zu minimieren.
Regelmäßigkeit: Teilen Sie Updates zur Incident-Behandlung in regelmäßigen, vorhersehbaren Intervallen mit – typischerweise alle 30 bis 45 Minuten.
Realistische Erwartungen: Bieten Sie realistische Zeitpläne für die Lösung und informieren Sie Kunden über mögliche temporäre Workarounds. Falls sich die Situation ändert, passen Sie die Erwartungen an und kommunizieren Sie diese umgehend.
Klarheit: Vermeiden Sie es, Kunden mit technischem Fachjargon zu überfordern. Geben Sie klare, einfache Erklärungen, um Frustrationen zu minimieren.
Phase 4: Aus Erfahrungen lernen
Abschließend verweist Daria auf zwei wichtige Metriken – MTTA (Mean Time to Acknowledgment) und MTTR (Mean Time to Resolution) – die entscheidend sind, um die Effektivität der Incident Response zu messen.
Diese Metriken können manuell mit den folgenden Formeln berechnet werden oder automatisch von Ihrer Incident-Management-Plattform erfasst werden:
MTTA = (Gesamtzeit zwischen Alarmierung und Bestätigung) / Anzahl der Incidents für einen bestimmten Kunden
MTTR = (Gesamtzeit zwischen Alarmierung und Behebung) / Anzahl der Incidents für einen bestimmten Kunden
„Denken Sie unbedingt daran, die bearbeiteten Störungen zu dokumentieren und die Erkenntnisse in Post-Mortem-Dokumenten zusammenzufassen“, schließt Daria. „Dies wird Ihnen helfen, Ihre MTTR und MTTA zu reduzieren und die Einarbeitung neuer Techniker und Account-Manager erleichtern.“
ilert und N‑central: Optimiertes Incident-Management durch RMM-Integration
Laut Daria sind Remote-Monitoring-and-Management-Lösungen (RMM) wie N‑central ein entscheidender Bestandteil eines effektiven Incident-Response-Plans für MSPs. Sie ermöglichen es MSPs, die Systeme ihrer Kunden in Echtzeit zu überwachen und potenzielle Probleme wie Systemausfälle, Netzwerk-Schwachstellen oder ungewöhnliche Aktivitäten, die auf einen Cyberangriff hindeuten könnten, frühzeitig zu erkennen. Eine frühzeitige Erkennung ist entscheidend, um Incidents einzudämmen, bevor sie eskalieren, Downtimes zu minimieren und die Auswirkungen auf die Kunden zu reduzieren.
Durch die Integration von ilert in ihre N‑central-Plattform können MSPs ihre Effektivität in mehreren Bereichen deutlich steigern und ihre Incident-Response wesentlich verbessern:
Multi-Channel-Benachrichtigungen: Sobald N‑central ein Problem erkennt, kann ilert sofort Benachrichtigungen per SMS, E-Mail, Telefon oder Mobile-App auslösen. So werden die richtigen Teammitglieder schnell informiert, und die Reaktionszeit wird verkürzt. Dieser Multi-Channel-Ansatz stellt sicher, dass kein kritischer Alarm übersehen wird – auch nicht außerhalb der regulären Arbeitszeiten.
Automatische Rotation von Bereitschaftsdiensten: Die automatische Rotation von Dienstbereitschaften durch ilert gewährleistet, dass immer jemand verfügbar ist, um zu reagieren, ohne dass manuelle Eingriffe erforderlich sind. Dieser optimierte Prozess verhindert, dass Störungen aufgrund von Verzögerungen eskalieren.
Zielgruppenspezifische Statusseiten: Mit den Statusseiten in ilert können MSPs Kunden in Echtzeit während einer Störung informieren und so Kommunikation und Transparenz verbessern. Durch die Steuerung von Erwartungen und die Bereitstellung von Echtzeit-Updates schaffen MSPs Vertrauen und reduzieren die Frustration der Kunden.
Die Integration von N‑central in ilert ermöglicht es MSPs, schneller zu reagieren, Alarmierung und Bereitschaftsmanagement zu automatisieren sowie die Kommunikation mit den Kunden zu verbessern. Dies führt zu einer effektiveren Incident Resolution und besseren Kundenbeziehungen.
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.
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.
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Cookie-Richtlinie
Wir verwenden Cookies, um Ihre Erfahrung zu verbessern, den Seitenverkehr zu verbessern und für Marketingzwecke. Erfahren Sie mehr in unserem Datenschutzrichtlinie.
