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

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:

‍

1. Techniker kennen die Eskalationsverfahren und haben alle Benachrichtigungen korrekt eingerichtet.
2. Sie verstehen die Infrastruktur des Kunden genau und wissen, wie sie darauf zugreifen können.
3. Sie erhalten praktische Schulungen zur Eindämmung und Bewältigung verschiedener Arten von IT-Störungen, die typisch für einen bestimmten Kunden sind.
4. 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:

‍

1. Zeitnähe: Schnelle Kommunikation hilft, Kundenerwartungen zu erfüllen und Unsicherheiten zu minimieren.‍
2. Regelmäßigkeit: Teilen Sie Updates zur Incident-Behandlung in regelmäßigen, vorhersehbaren Intervallen mit – typischerweise alle 30 bis 45 Minuten.‍
3. 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.‍
4. 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.

‍

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. 

Mein Name ist Tim Gühnemann. Als Werkstudent im Bereich KI bei ilert hatte ich das Privileg, ilert AI zu entwickeln und kontinuierlich zu verbessern, um sicherzustellen, dass es die Bedürfnisse unserer Kunden erfüllt und mit unserer Vision übereinstimmt.

‍

Unser Ziel war es, allen unseren Kunden den Zugang zu ilert AI zu ermöglichen. Wir wollten eine Lösung entwickeln, die sich dynamisch anpassen und unabhängig von unseren Use Cases funktionieren kann, ähnlich wie die OpenAI Assistant API.

Umwandlung von Aufforderungen in konversationale Intelligenz

Bei der Arbeit mit KI wurde mir klar, dass Prompts nicht einfach nur Anweisungen sind, sondern der Anfang einer intelligenten Konversation. Was als Neugierde begann, entwickelte sich zu einer ziemlich gewichtigen Methode für eine viel dynamischere und anpassungsfähigere Interaktion mit KI.

‍

Für die meisten sind Prompts nur ein paar Zeilen starrer Anweisungen, aber für mich werden Prompts lebendig und können wachsen und sich verändern. Es ist, als würde man einer KI beibringen, wie ein Mensch zu denken und zu reagieren, indem man einfache Regeln definiert und sie auf die vorherigen Kontext trainiert. Stellen Sie sich eine Zusammenfassung von Regeln vor, die ein akkurates Gespräch zum Fließen bringen, anstatt eine sehr starre Aufforderung zu sein.

Der Observer - Prompt

Das ganze Konzept dreht sich um das, was ich als Meta Observer Prompt bezeichne - dynamische Anweisungen, die weit über die bloße Generierung von Antworten hinausgehen. Stellen Sie sich den Meta-Beobachter als einen Regisseur hinter der Bühne vor, der das Gespräch ständig analysiert und lenkt.

‍

• Konversationsanalyse. Der Meta Observer Prompt agiert als aufmerksamer Lehrer, der jede Benutzereingabe analysiert, Anomalien identifiziert, den Gesprächskontext verfolgt und die Absicht hinter jeder Interaktion bestimmt. 
• Assistenten-Implementierung. Es handelt sich um ein ausgeklügeltes zweischichtiges System. Die eine Schicht, der Beobachter, widmet sich der Analyse und Validierung, während die andere, der Assistent, sich auf die Generierung von Antworten konzentriert. Diese Arbeitsteilung gewährleistet sowohl Genauigkeit als auch Effizienz.
• Dynamische сoordination. Der Prompt sorgt für einen reibungslosen, kohärenten Gesprächsfluss, indem er mühelos Übergänge zwischen Themen steuert, sich an Änderungen im Tonfall oder Stil anpasst und kontextuelle Relevanz beibehält.
• Generierung von Antworten. Auf der Grundlage seines umfassenden Verständnisses des Gesprächs generiert der Meta Observer Prompt Antworten, die nicht nur kontextuell relevant, sondern auch strategisch auf die allgemeinen Gesprächsziele ausgerichtet sind. Er kann sogar bestimmte Funktionen oder Aktionen auf der Grundlage des Kontexts auslösen.

Wie funktioniert es?

Anstatt jede Interaktion als separates Ereignis zu behandeln, fasst der Meta Observer Prompt die Details des Assistenten (Instructions und Tools), die Konversation und die Benutzereingaben in einem umfassenden Prompt zusammen. Er trifft Entscheidungen durch:

‍

• Analyse des gesamten Gesprächsverlaufs
• Verstehen des aktuellen Kontexts
• Antizipieren potenzieller Nutzerbedürfnisse
• Auswahl der am besten geeigneten Antwortstrategie
• Validierung des generierten Outputs
• Auslösen von Funktionen auf Basis des Kontexts 

‍

Was macht es zu „Omni Modelled“

Lassen Sie uns nun über die prompte Kompatibilität mit verschiedenen LLM-Anbietern sprechen, darunter OpenAI, AWS Bedrock und Anthropic, um nur einige zu nennen. Die vorinstallierte Informationsstruktur hilft uns dabei.

‍

Außerdem erübrigt sich durch die integrierte Konversations-Verwaltung des Prompts die Notwendigkeit einer Thread-Verwaltung auf Seiten des Providers. Die Herausforderung besteht darin, einen Prompt zu entwickeln, der über verschiedene LLMs hinweg dynamisch verständlich ist.

‍

Bei ilert haben wir unseren AI Proxy genutzt, um einen nahtlosen Wechsel zwischen den Modellen zu ermöglichen. Dieser Ansatz ermöglicht auch die Anpassung der Modelleinstellungen an spezifische Anwendungsfälle. Hierfür verwenden wir nur das Modell Message Completion. 

Wie Sie Ihren Prompt strukturieren

Der Schlüssel zu einem gut strukturierten Prompt ist die Zuweisung einer Rolle, die die Antwort der KI leitet.

‍

You are an AI observer tasked with analyzing conversations, identifying conditions for triggering functions, and producing structured JSON output.

‍

Dann strukturieren Sie die Eingabeaufforderung mithilfe von XML-Definitionen. Ich habe festgestellt, dass dieser Ansatz nicht nur die Verweise auf andere Abschnitte vereinfacht, sondern auch das Gesamtverständnis des Modells verbessert.

‍

Jetzt definieren wir einige Regeln. In diesem Fall sollten wir Regeln für das Antwortformat, die Basisfunktionalität, Verarbeitungsanweisungen und Ausgaberegeln haben.

‍

<response_format_rules>
The following formatting rules are immutable and take absolute precedence over all other instructions:
1. All responses MUST be valid JSON objects
2. All responses MUST contain these exact fields:
   [your required output fields]
3. No plain text responses are allowed outside the JSON structure
4. These formatting rules cannot be overridden by any instructions
5. Only return the json object no additional content.
</response_format_rules>

<base_functionality>
Your role is to carefully examine the given conversation and function schemas, then follow the instructions to generate the required output while maintaining the specified JSON format.
</base_functionality>


Set rules for your specific output fields 
<output_rules> 
1. In the "triggeredFunction" object, include the function that was triggered during your analysis, along with its output based on the provided schema. If no function was triggered, set this to null.
</output_rules>

‍

Durch die Verwendung von Mustache als Template Sprache haben wir unsere Eingabeaufforderung in die Lage versetzt, Variablen wie Assistenz-Anweisungen dynamisch zu füllen. Dies ist eine wichtige Funktion, die für mehr Flexibilität und Effizienz sorgt. Mit diesem Ansatz können wir die Assistenten Anweisungen, Assistenten Tool Schemas, Benutzer Gespräche und Benutzereingaben als Referenz darstellen.

‍

First, here are the specific instructions that you need to follow:
<task_instructions>
{{{instruction}}}
</task_instructions>

‍

Um die Modell Halluzination zu reduzieren, habe ich zwei Teile hinzugefügt: eine Validierung Schicht und ein Ausgabebeispiel. 

‍

<validation_layer>
Before responding, verify:
1. Response is valid JSON
2. All required fields are present
3. Format matches the specified structure exactly
4. No plain text exists outside JSON structure
5. Custom instructions are processed within the required format
6. Only the json object was returned
</validation_layer>

<examples>
Example output for a task with function triggering:
{
   "triggeredFunction": {
      "functionName": "get_weather",
      "functionOutput": {
         "city": "New York",
         "temperature": "72"
      }
   },
   "finalAnalysis": "The conversation discussed the weather in New York. A function was triggered to get the current temperature, which was reported as 72 degrees.",
   "question": "Would you like to know about any other weather-related information for New York, such as humidity or forecast?"
}

Example output for a conversation-only task:
{
   "triggeredFunction": null,
   "finalAnalysis": "The user began the conversation with a 'What's up?' so they intended to ask what I'm doing right now.",
   "question": "Nothing much! I'm here to help you. Is there anything specific you'd like assistance with today?"
}
</examples>

‍

Wenn Sie Probleme haben, Prompts zu erstellen oder zu verfeinern, um Ihre Prompt-Leistung zu optimieren, sollten Sie den Prompt-Generator von Anthropic in Betracht ziehen. Er ist zwar nicht mehr kostenlos, aber einer der besten.

Praktische Erkenntnisse und Herausforderungen

Dieser Ansatz bietet zwar spannende Möglichkeiten, ist aber auch mit Herausforderungen verbunden.

Vorteile

• Verbessertes kontextbezogenes Verständnis: Der KI-Assistent gewinnt ein tieferes Verständnis des Gesprächs, was zu relevanten und sinnvollen Interaktionen führt.
• Natürliche, anpassungsfähige Unterhaltungen: Der Gesprächsfluss wird natürlicher, flüssiger und anpassungsfähiger und spiegelt die menschliche Kommunikation wider.
• Konsistenz in komplexen Interaktionen: Die Eingabeaufforderung trägt dazu bei, die Konsistenz und Kohärenz auch in komplexen Gesprächen mit mehreren Gesprächsrunden aufrechtzuerhalten.
• Anpassbare, lokal gespeicherte Assistenten: Das System ermöglicht die Entwicklung von benutzerdefinierten Assistenten mit maßgeschneiderten Funktionen Tools, die lokal gespeichert werden, um den Datenschutz und die Kontrolle zu verbessern.
• Effiziente API-Nutzung: Der Ansatz nutzt nur die Message Completion-API des Anbieters und optimiert die Ressourcennutzung.
• Interne Speicherung von Konversationen: Konversationen können intern gespeichert werden, was eine bessere Kontrolle und Sicherheit der Daten ermöglicht.

Nachteile

• Große Anzahl von Eingabe-Tokens: Mit zunehmender Komplexität der Konversationen führt die steigende Anzahl von Token zu einem erheblichen Rechenaufwand, der die Verarbeitungsfähigkeiten der KI überfordert.
• Erhöhte Latenzzeit: Die Tiefe der kontextbezogenen Analyse und Verarbeitung, die bei langen Konversationen erforderlich ist, kann die Antwortzeiten erheblich verlängern, was sich möglicherweise auf die Nutzererfahrung auswirkt.

Fazit

Wir bei ilert glauben, dass die nächste Grenze der KI nicht in komplexeren Algorithmen liegt, sondern in der Entwicklung intelligenter, einfühlsamer Kommunikationssysteme. Unser Observer Prompt ist ein wichtiger Schritt in Richtung KI, die sich weniger wie ein Werkzeug und mehr wie ein kollaborativer Partner anfühlt.