Eine Plattform für Alarmierung, Rufbereitschaften und Status­seiten.

In den letzten 12 Monaten hat sich unser Team darauf konzentriert, die Produktfunktionen durch die Integration von generativer AI zu verbessern. Durch das nahtlose Einweben der AI in das Gefüge unseres Dienstes haben wir die Effizienz und Reaktionsfähigkeit der Incident-Management-Prozesse gesteigert und einen neuen Ansatz zur Krisenbewältigung eingeführt. Ein leistungsstarkes Set neuer Funktionen wurde entwickelt, um die Vorbereitungsphase des Incident Managements zu vereinfachen, den Antwortprozess zu beschleunigen und die manuelle Arbeit der Bereitschaftsteams in der Nach-Incident-Phase zu reduzieren.

‍

In diesem Blogbeitrag haben wir alle AI-unterstützten Funktionen zusammengestellt, um Ihnen zu helfen, deren Potenzial für Ihren Incident-Management-Prozess zu verstehen. Wenn Sie mehr erfahren möchten oder Fragen zum AI-Potenzial von ilert haben, freuen wir uns, Sie bei unserem Webinar „AI und Incident Management“ zu sehen, das am 30. April stattfinden wird und von ilert-Gründer und CEO Birol Yildiz geleitet wird. Reservieren Sie Ihren Platz.

‍

Zusätzlich haben wir einen kostenlosen Leitfaden veröffentlicht, wie Sie GenAI & LLMs im Incident-Management-Prozess nutzen können.

Vorbereiten: Nutzen Sie AI für die Einsatzplanung

Wir bei ilert glauben, dass Vorfälle unvermeidlich sind. Schnelllebige und ambitionierte Teams müssen ständig Veränderungen an ihrem Service vornehmen, was ein fruchtbarer Boden für Pannen und Fehler ist. Daher lautet die beste Strategie hier „Vorwarnung ist Vorbereitung“.

‍

Die Einsatzplanung ist eine kritische Komponente des effektiven Incident Managements, da sie sicherstellt, dass immer ein bestimmter Ansprechpartner verfügbar ist, um Probleme jederzeit, Tag und Nacht, anzugehen und zu mildern. Ein robuster Einsatzplan bietet eine strukturierte, zuverlässige Methode, um das richtige Personal mit der notwendigen Expertise schnell für die Bewältigung neu auftretender Probleme zu mobilisieren.

‍

Die Einrichtung eines effektiven Einsatzplans bringt mehrere Schwierigkeiten mit sich, vor allem aufgrund der Herausforderungen, organisatorische Bedürfnisse mit dem Wohlbefinden der Mitarbeiter in Einklang zu bringen. Eines der größten Hindernisse ist die Koordination der unterschiedlichen Verfügbarkeiten der Teammitglieder, während sichergestellt wird, dass alle kritischen Fähigkeiten und Rollen rund um die Uhr abgedeckt sind. Es gibt auch technische Komplexitäten, wie die sorgfältige Orchestrierung von Schichtplänen, in denen verschiedene Teams beteiligt sein können, Schichtwechsel und ordnungsgemäße Übergaben sowie administrative Belastungen im Zusammenhang mit der Einführung neuer Teammitglieder oder dem Ausscheiden bestehender.

‍

Unter Berücksichtigung all dieser Komplikationen haben wir einen neuen Ansatz zur Einsatzplanung eingeführt. Alle manuellen Anpassungen, die manuell vorgenommen werden müssen, können jetzt automatisch mit Hilfe einer einfachen Chat-Schnittstelle eingerichtet werden. Geben Sie alle notwendigen Informationen für einen neuen Einsatzplan auf natürliche Weise beschreibend ein, und lassen Sie ilert AI den Rest übernehmen.

Reagieren: Lassen Sie AI Incident-Details kommunizieren

Das Reduzieren manueller Arbeit während IT-Vorfällen ist entscheidend, um sicherzustellen, dass Ingenieure ihre Bemühungen dort konzentrieren können, wo sie am meisten benötigt werden: bei der Untersuchung und Behebung des Problems. In einer Hochdrucksituation zählt jede Sekunde, und die kognitive Belastung der Ingenieure wird erheblich erhöht. Sie müssen schnell Informationen aufnehmen, ihre Expertise anwenden, um das Problem zu diagnostizieren, und eine Lösung implementieren. Das gleichzeitige Management von Kommunikationen – wie Updates für Stakeholder, Koordinationsnachrichten unter Teammitgliedern oder Anweisungen für Workarounds – kann ihre Hauptaufgabe erheblich beeinträchtigen. Die Suche nach den richtigen Worten oder das Verfassen von Updates erfordert geistige Bandbreite, die sonst dem Problemlösen gewidmet sein könnte.

‍

Deshalb haben wir ilert AI auch für die Incident-Kommunikation eingeführt. ilerts AI-gestützte Hilfe erstellt schnell präzise incident-bezogene Nachrichten. Bei einem Vorfall geben Sie einfach eine kurze technische Zusammenfassung in die dafür vorgesehenen Felder ein, und ilerts AI übernimmt von dort. Es wird eine prägnante Zusammenfassung des Vorfalls generieren und eine Nachricht für die Statusseite erstellen, die angibt, welche Dienste basierend auf den bereitgestellten Informationen betroffen sind.

‍

Darüber hinaus kann ilerts AI auch während des Vorfalls Updates liefern. Detaillierte Statusbeschreibungen sind nicht mehr notwendig; Ihr Team kann sich ausschließlich auf die Behebung des Problems konzentrieren, sicher in dem Wissen, dass klare, benutzerfreundliche Kommunikationen an die Nutzer gesendet werden.

Lernen: Erstellen Sie automatisch Nachbesprechungen

Die Widmung von Zeit zum Lernen nach IT-Vorfällen ist von größter Bedeutung für das Wachstum und die Widerstandsfähigkeit einer Organisation. Diese Zeit ermöglicht die Durchführung gründlicher Nachbesprechungen, ein kritischer Prozess, bei dem Teams analysieren, was passiert ist, die Hauptursachen des Vorfalls identifizieren und die Wirksamkeit der Reaktion verstehen. Die primäre Bedeutung von Nachbesprechungen liegt in ihrer Fähigkeit, Vorfälle in Lernmöglichkeiten umzuwandeln. Indem jedes Ereignis sorgfältig analysiert wird, können Teams Schwächen in ihren Systemen und Prozessen aufdecken und umsetzbare Erkenntnisse entwickeln, um ähnliche Vorfälle in Zukunft zu verhindern. Darüber hinaus tragen Nachbesprechungen zum Aufbau einer Kultur der Transparenz und kontinuierlichen Verbesserung bei, in der Fehler offen geteilt und als Sprungbretter für Verbesserungen genutzt werden, anstatt stigmatisiert zu werden. Diese gewidmete Zeit für Reflexion und Lernen dient nicht nur dazu, das zu beheben, was schiefgelaufen ist, sondern auch dazu, die Widerstandsfähigkeit einer Organisation zu stärken und den Weg für robustere und zuverlässigere IT-Betriebe in der Zukunft zu ebnen.

‍

Um diese letzte Phase des Incident-Managements abzudecken, haben wir AI-Unterstützung bei der Erstellung von Nachbesprechungen eingeführt. Sammeln Sie Zeitdaten und Kommunikationen aus Chat-Tools wie Slack und Microsoft Teams zusammen mit Kommentaren, die in ilert gemacht wurden, überprüfen Sie alle zugehörigen Alerts und deren Details und exportieren Sie eine Datei für mögliche zukünftige Verbesserungen – das ist unser Nachbesprechungsfeature in a nutshell.

‍

Was als nächstes kommt

In den kommenden Monaten werden noch weitere großartige AI-Neuigkeiten kommen. Da die meisten AI-Funktionen sich in der öffentlichen Betaphase befinden, schätzen wir Ihr Feedback und Ihre Ideen zur Verbesserung. Teilen Sie Ihre Gedanken im Roadmap oder schreiben Sie uns per E-Mail an support@ilert.com. Denken Sie auch daran, unserem Webinar beizuwohnen, in dem wir tief in das Thema AI im Incident-Management-Bereich eintauchen werden.

‍

Der Integrationskatalog von ilert umfasst jetzt eine neue Ergänzung für InfluxDB – eine Open-Source-Zeitreihendatenbank.

Was ist InfluxDB?

InfluxDB ist eine Open-Source-Zeitreihendatenbank, die für hohe Schreib- und Abfragebelastungen in einer zeiteffizienten Weise konzipiert ist. Sie ist speziell dafür entwickelt, zeitgestempelte Daten wie Metriken und Ereignisse zu speichern und zu analysieren, was sie zu einem kritischen Werkzeug für die Überwachung von Anwendungen, Internet-of-Things-Anwendungen, Echtzeitanalysen und mehr macht. Die Datenbank zeichnet sich durch ihre leistungsfähige Datenspeicherung, einfache Skalierbarkeit und eine unkomplizierte Abfragesprache namens InfluxQL aus, die den Umgang mit Zeitreihendaten vereinfacht. InfluxDB unterstützt eine breite Palette von Datentypen und bietet Funktionen wie Datenhaltungsrichtlinien, kontinuierliche Abfragen und Echtzeitwarnungen, was sie zu einer vielseitigen Wahl für das Management großer Mengen von zeitsensitiven Daten in verschiedenen Branchen macht.

Was können Sie von der ilert-Integration für InfluxDB erwarten?

Diese Integration ermöglicht es Ihnen, Alarme an die ilert-Vorfallmanagementplattform zu senden und Teammitglieder über verschiedene Kanäle zu benachrichtigen, einschließlich Push-Benachrichtigungen, SMS, Sprachanrufen und mehr. Alarme werden eskaliert, bis sie anerkannt werden. Alle Benachrichtigungen sind aktionsfähig, was es Ihnen ermöglicht, den Alarmstatus direkt innerhalb des Kanals zu ändern, in dem Sie ihn erhalten haben.

‍

Die Verknüpfung von InfluxDB mit der ilert-Plattform stattet Ihr Team mit einem umfassenden Werkzeugsatz für das gesamte Vorfalllebenszyklusmanagement aus – von der Anerkennung von Alarmen bis zur Durchführung von Nachvorfallsanalysen mit der Unterstützung von KI-gesteuerten Nachbesprechungen. Zusätzlich haben Sie die Möglichkeit, Bereitschaftsdienste zu organisieren, Ihre Kunden und Stakeholder über kritische Probleme über Statusseiten zu informieren und verschiedene ChatOps-Funktionen für Slack und Microsoft Teams zu nutzen, um Vorfälle zu lösen.

‍

Entdecken Sie eine Schritt-für-Schritt-Anleitung zum Herstellen einer Verbindung zwischen InfluxDB und ilert in unserer Dokumentation.

Das Konzept der Beobachtbarkeit ist zu einem Grundpfeiler für die Sicherstellung der Zuverlässigkeit und Effizienz von Systemen im modernen Software-Engineering und Betrieb geworden. Beobachtbarkeit, über ihren traditionellen Rahmen von Logging, Überwachung und Tracing hinaus, lässt sich durch das Prisma der Effizienz der Incident-Response definieren – insbesondere durch die Untersuchung der Zeit, die Teams benötigen, um den vollständigen Kontext und Hintergrund eines technischen Vorfalls zu verstehen.

Optimierung der Zeit bis zum Verständnis

Diese differenzierte Sichtweise führt die kritische Metrik der Zeit bis zum Verständnis (Time to Understanding, TTU) ein, eine Dimension, die als entscheidendes Glied in der Kette von Incident-Management-Metriken dient, einschließlich der Zeit bis zur Anerkennung (Time to Acknowledge, TTA) und der Zeit bis zur Lösung (Time to Resolve, TTR). TTU etabliert sich als Metrik, indem sie die Dauer von dem Moment, in dem ein Alarm empfangen wird, bis zu dem Punkt, an dem ein Team den Umfang, die Auswirkungen und die zugrundeliegenden Ursachen eines Vorfalls vollständig versteht, quantifiziert. Im komplexen Kontext der Alarmierung überbrückt TTU nicht nur das Intervall zwischen der anfänglichen Alarmierung (TTA) und dem Beginn der Lösungsbemühungen (TTR), sondern spielt auch eine transformative Rolle bei der Verfeinerung von Alarmmanagementstrategien. Durch die Optimierung von TTU können Organisationen ihre operationelle Resilienz signifikant erhöhen, Ausfallzeiten minimieren und ihren Weg zur Incident-Lösung effizienter gestalten. Es ist jedoch wichtig zu verstehen, dass die Optimierung von TTU völlig abhängig von der zugrundeliegenden Infrastruktur und Architektur des gepflegten Softwareprodukts ist.

Die Auswirkungen von Mikroservice-Architekturen auf die Zeit bis zum Verständnis

Softwarebereitstellungen bevorzugen oft monolithische Architekturen aufgrund ihrer Einfachheit, bei denen die Anwendung als eine einzige, einheitliche Einheit gebaut wird. Dieser Ansatz vereinfachte das Verständnis der Funktionsweise des Systems und das Debugging von Problemen, da alle Komponenten innerhalb eines einzigen Codebasis- und Laufzeitumfelds operierten. Wenn jedoch Entwicklungsteams und die Komplexität der Anwendung wachsen, stoßen die Grenzen monolithischer Architekturen, wie Skalierbarkeit und Geschwindigkeit der Bereitstellung, Organisationen zur Umstellung auf Mikroservice-Architekturen. Mikroservices, die die Anwendung in kleinere, unabhängig einsetzbare Dienste aufteilen, bieten größere Flexibilität und Skalierbarkeit. Doch diese Fragmentierung führt zu einem chaotischen Verständnis des Systems, da die Interdependenzen und Interaktionen über zahlreiche Dienste hinweg das Gesamtbild verschleiern können, was es selbst für große Entwicklungsteams herausfordernd—fast unmöglich—macht, das volle Ausmaß des Zusammenspiels zu erfassen.

Wo OpenTelemetry ins Spiel kommt

Mikroservice-Architekturen können die Beobachtbarkeit erheblich behindern und das Management sowie die Fehlersuche bei Diensten zu einer entmutigenden Aufgabe machen. OpenTelemetry tritt als Entwurf auf, um diesen Herausforderungen zu begegnen, indem es einen einheitlichen und standardisierten Rahmen für das Sammeln, Verarbeiten und Versenden von Telemetriedaten (Metriken, Logs und Traces) von jedem Mikroservice bereitstellt. Durch die Implementierung von OpenTelemetry können Organisationen eine umfassende Sicht auf ihre Mikroservice-Landschaft gewinnen, die es ihnen ermöglicht, den Fluss von Anfragen über Dienstgrenzen hinweg zu verfolgen, die Interaktionen und Abhängigkeiten zwischen den verschiedenen Diensten zu verstehen und Leistungsengpässe oder Ausfallpunkte präzise zu identifizieren. Diese verbesserte Ebene der Beobachtbarkeit durchbricht die chaotische Natur von Mikroservice-Architekturen und erleichtert ein tieferes Verständnis der Systemverhaltensweisen und betrieblichen Dynamiken.

Die drei Säulen von OpenTelemetry

Metriken, die erste Säule von OpenTelemetry, stellen eine entscheidende Komponente für das Monitoring und Verständnis der Systemleistung im großen Maßstab dar. Sie sind so konzipiert, dass sie leichtgewichtig und einfach zu speichern sind, auch bei hohem Volumen, was sie ideal macht, um einen Überblick über die Gesundheit und das Verhalten des Systems im Zeitverlauf zu erfassen. Durch die Aggregation numerischer Datenpunkte – wie Anfragenzahlen, Fehlerquoten und Ressourcennutzung – bieten Metriken eine vereinfachte, aber dennoch umfassende Momentaufnahme des betrieblichen Zustands. Der Prozess der Aggregation, obwohl vorteilhaft für Skalierbarkeit und Verwaltbarkeit, kann jedoch detaillierte Informationen über seltene oder außergewöhnliche Ereignisse versehentlich verdecken und potenzielle Probleme im System verbergen.

‍

Logs, obwohl sie im OpenTelemetry Protocol (OTLP)-Framework noch als "jung" gelten, spielen eine kritische Rolle bei der Diagnose und dem Verständnis von Problemen innerhalb von Mikroservice-Architekturen. Logs bieten eine sehr detaillierte Erklärung von Problemen, indem sie Ereignisse in einem strukturierten oder unstrukturierten Format erfassen, das Entwickler analysieren können, um die Wurzelursachen von Problemen zu ermitteln. Die Nützlichkeit von Logs bringt jedoch ihre Herausforderungen mit sich; aufgrund des potenziell hohen Volumens an Logs, insbesondere in komplexen und verteilten Systemen, kann deren Speicherung und Verwaltung schwierig werden. Diese Herausforderungen erfordern effiziente Lösungen für die Log-Aggregation und -Verwaltung, um sicherzustellen, dass Logs zugänglich und nützlich für die Fehlersuche bleiben, ohne die Ressourcen des Systems zu überfordern.

‍

Tracing, die dritte Säule von OpenTelemetry, dient als Hybrid zwischen Metriken und Logs und bietet einen einzigartig reichen und detaillierten Einblick in das Verhalten des Systems, indem es sehr dichte Informationen erfasst, noch mehr als traditionelle Logs. Ein Trace umfasst die Reise einer einzelnen Anfrage durch das System, aufgeteilt in mehrere Spans, wobei jeder Span eine distinkte "Arbeitseinheit" oder Operation innerhalb der Servicearchitektur darstellt. Diese Spans bilden gemeinsam eine detaillierte Zeitleiste des Weges der Anfrage, die aufzeigt, wo Zeit verbracht und wo Fehler auftreten können. Trotz der Fülle an Daten, die Traces liefern, ist es bemerkenswert, dass der überwiegende Teil (99,9%) dieser Daten nie aktiv betrachtet wird, was die selektive Natur des Tracing-Datenkonsums unterstreicht.

Das Herzstück von OpenTelemetry: Der Collector

Neben den OpenTelemetry-Instrumenten, wie Bibliotheken und SDKs, die Entwickler dabei unterstützen, OTLP-Daten aus dem Anwendungscode zu veröffentlichen – wie in den drei oben genannten Säulen erwähnt –, markiert der OpenTelemetry Collector (OTelC) das Herzstück des Frameworks.

‍

Der Collector (OTelC) ist nicht nur ein Datenexporteur; er führt fortgeschrittene Fähigkeiten ein, die für die effiziente Verwaltung von Telemetriedaten in verteilten Systemen kritisch sind. Er bewältigt geschickt die Kardinalität, ein wesentliches Merkmal zur Aufrechterhaltung der Datenbenutzbarkeit, während er die Überlastung in Überwachungssystemen durch die Reduzierung der Dimensionalität bei Bedarf verhindert. Diese Flexibilität erlaubt es, OTelC-Instanzen zu verketten und bietet eine skalierbare Lösung für die Vorverarbeitung von Telemetriedaten – durch Filterung, Sampling und Verarbeitung – bevor diese das Backend erreichen. Durch das intelligente Management der zu übertragenden Daten, einschließlich der Entfernung von lärmenden, sensiblen oder sonst unnötigen Informationen, stellt OTelC sicher, dass nur relevante, hochwertige Daten weitergeleitet werden, wodurch Leistung und Compliance optimiert werden.

‍

Entscheidend ist, dass mit OTelC in der Nähe der Datenquellen die Menge der Daten, die über das Netzwerk übertragen werden müssen, drastisch reduziert wird, was besonders in Cloud-Umgebungen vorteilhaft ist, wo Datenübertragungskosten anfallen können. Diese Nähe ermöglicht eine effiziente Verkehrsverwaltung und Lastreduktion, um sicherzustellen, dass hochvolumige Telemetriedaten die Netzwerkressourcen nicht sättigen.

‍

Darüber hinaus werden OpenTelemetry-Instrumente (SDKs, Bibliotheken) von der Last der Verkehrs- und Lastüberlegungen befreit, sodass Entwickler sich auf die Instrumentierung konzentrieren können, ohne sich um die Auswirkungen auf das Datentransfervolumen sorgen zu müssen. Mit OTelC wird das Management der OTLP-Kardinalität und die Steigerung der Dateneffizienz nahtlos, wodurch die Notwendigkeit für invasive Änderungen im Anwendungscode selbst entfällt. So wird die Integrität des Codes bewahrt, während eine umfassende Beobachtbarkeit sichergestellt ist.

‍

Letzteres passt auch gut in eine Mikroservice-Umgebung, in der normalerweise die Entwicklerteams selbst für die Bereitstellung und den Betrieb ihrer Dienste verantwortlich sind und ihre eigenen OTel-Collector-Pipelines verwenden können, um ihre OTLP-Datenströme feinabzustimmen, ohne ihre Dienste ändern und neu bereitstellen zu müssen.

Was dem eigenständigen OpenTelemetry fehlt

Während OpenTelemetry im Sammeln und Exportieren von Telemetriedaten in einer verteilten Dienstumgebung hervorragend ist, beinhaltet es keine Funktionalitäten zum Speichern dieser Daten; stattdessen verlässt es sich auf externe Speicherlösungen, um die gesammelten Informationen zu archivieren und zu verwalten.

‍

Zusätzlich bietet OpenTelemetry selbst keine Dashboards, die für die Visualisierung von Datentrends und Einsichten erforderlich sind. Stattdessen benötigt es die Integration mit anderen Tools, um die Daten zu analysieren und anzuzeigen.

‍

Benachrichtigungen, die für die Alarmierung von Teams über Systemprobleme in Echtzeit essenziell sind, gehen ebenfalls über die Fähigkeiten von OpenTelemetry hinaus und erfordern ergänzende Alarmierungsmechanismen.

‍

Schließlich unterstützt OpenTelemetry nicht nativ das proaktive Testen von Anwendungen durch simulierten Verkehr oder Benutzerinteraktionen, einen wichtigen Aspekt zum Verständnis und zur Gewährleistung der Systemleistung und -zuverlässigkeit unter verschiedenen Bedingungen.

‍

Folglich, obwohl OpenTelemetry ein mächtiges Werkzeug für die Beobachtbarkeit ist, muss es mit zusätzlichen Systemen und Strategien ergänzt werden, um diese kritischen Bereiche vollständig abzudecken.

Ein erstklassiger Beobachtbarkeits-Stack mit OpenTelemetry und ilert

Um die Einschränkungen von OpenTelemetry zu adressieren und dadurch einen Spitzen-Beobachtbarkeits-Stack zu schaffen, können seine Fähigkeiten durch die Integration mit spezialisierten Werkzeugen erheblich verbessert werden.

‍

Für die Datenspeicherung und visuell intuitive Dashboards, die eine schnelle Datenanalyse und Einblicke unterstützen, ergänzt Honeycomb.io OpenTelemetry durch das Angebot skalierbarer, leistungsstarker Analysen. Ebenso wird ein Werkzeug wie Checkly integriert, das sich auf proaktives Testen und Validieren von Webdiensten spezialisiert, und schließt damit den Kreis eines umfassenden System-Monitorings. Um die Wirksamkeit von Alarmierungsmechanismen zu verstärken, kann ilert mit Honeycomb und Checkly integriert werden, was sicherstellt, dass Benachrichtigungen zeitnah, handlungsrelevant sind und über die richtigen Kanäle wie Sprachanrufe oder Microsoft Teams-Kanalaktualisierungen eskalieren können.