Warum braucht eine Bank AIOps und Umbrella-Monitoring bzw. worauf basieren Kundenbeziehungen?

In Veröffentlichungen auf Habré habe ich bereits über meine Erfahrungen beim Aufbau von Partnerschaften mit meinem Team geschrieben (hier spricht darüber, wie man bei der Gründung eines neuen Unternehmens einen Partnerschaftsvertrag erstellt, damit das Unternehmen nicht auseinanderfällt. Und jetzt möchte ich darüber sprechen, wie man Partnerschaften mit Kunden aufbaut, denn ohne sie wird nichts scheitern. Ich hoffe, dass dieser Artikel für Startups nützlich sein wird, die beginnen, ihre Produkte an große Unternehmen zu verkaufen.

Derzeit leite ich ein Startup namens MONQ Digital lab, wo ich mit meinem Team ein Produkt zur Automatisierung der Prozesse zur Unterstützung und zum Betrieb der Unternehmens-IT entwickle. Der Markteintritt ist keine leichte Aufgabe und wir begannen mit ein paar Hausaufgaben, gingen Marktexperten und unsere Partner durch und führten eine Marktsegmentierung durch. Die Hauptfrage bestand darin, zu verstehen: „Wessen Schmerzen können wir am besten heilen?“

Banken haben es in die TOP-3-Segmente geschafft. Und natürlich waren Tinkoff und Sberbank die ersten auf der Liste. Als wir Bankenmarktexperten besuchten, sagten sie: Stellen Sie Ihr Produkt dort vor, und der Weg in den Bankenmarkt ist frei. Wir haben versucht, dort und dort einzusteigen, aber bei der Sberbank erwartete uns ein Misserfolg, und die Jungs von Tinkoff erwiesen sich als viel offener für eine produktive Kommunikation mit russischen Startups (vielleicht aufgrund der Tatsache, dass Sber zu dieser Zeit gekauft fast eine Milliarde unserer westlichen Konkurrenten). Innerhalb eines Monats starteten wir ein Pilotprojekt. Wie es dazu kam, lesen Sie weiter.

Wir beschäftigen uns seit vielen Jahren mit Fragen der Bedienung und Überwachung, jetzt implementieren wir unser Produkt im öffentlichen Sektor, bei Versicherungen, in Banken, in Telekommunikationsunternehmen, eine Implementierung erfolgte bei einer Fluggesellschaft (vor dem Projekt hatten wir das noch nicht einmal). Ich denke, dass die Luftfahrt eine so IT-abhängige Branche war, und jetzt hoffen wir wirklich, dass das Unternehmen trotz COVID entstehen und durchstarten wird.

Das von uns hergestellte Produkt gehört zur Unternehmenssoftware, dem AIOps-Segment (Artificial Intelligence for IT Operations, kurz ITOps). Die Hauptziele der Implementierung solcher Systeme sind, da der Reifegrad der Prozesse im Unternehmen steigt:

1. Brände löschen: Störungen identifizieren, den Alarmstrom von Trümmern befreien, Aufgaben und Vorfälle den Verantwortlichen zuweisen;
2. Erhöhen Sie die Effizienz des IT-Services: Verkürzen Sie die Zeit zur Behebung von Vorfällen, zeigen Sie Fehlerursachen an und erhöhen Sie die Transparenz des IT-Status.
3. Steigern Sie die Geschäftseffizienz: Reduzieren Sie den manuellen Arbeitsaufwand, reduzieren Sie Risiken und erhöhen Sie die Kundenbindung.

Unserer Erfahrung nach haben Banken mit allen großen IT-Infrastrukturen folgende „Schwierigkeiten“ bei der Überwachung gemeinsam:

• „wer weiß was“: Es gibt viele technische Abteilungen, fast jede hat mindestens ein Überwachungssystem und die meisten haben mehr als eines;
• „Mückenschwarm“ an Alarmen: Jedes System generiert Hunderte und bombardiert damit alle Verantwortlichen (manchmal auch abteilungsübergreifend). Es ist schwierig, den Fokus der Kontrolle auf jede Meldung ständig aufrechtzuerhalten; ihre Dringlichkeit und Wichtigkeit wird aufgrund der großen Anzahl eingeebnet;
• Große Banken – Branchenführer wollen nicht nur ihre Systeme kontinuierlich überwachen, um zu wissen, wo Fehler auftreten, sondern auch die wahre Magie der KI – die Systeme selbst überwachen, selbst vorhersagen und selbst korrigieren.

Als wir zum ersten Treffen bei Tinkoff kamen, wurde uns sofort gesagt, dass sie keine Probleme mit der Überwachung hätten und dass ihnen nichts schaden würde, und die Hauptfrage war: „Was können wir denen anbieten, denen es bereits gut geht?“

Das Gespräch war lang, wir besprachen, wie ihre Microservices aufgebaut sind, wie Abteilungen arbeiten, welche Infrastrukturprobleme sensibler und welche weniger sensibel für Benutzer sind, wo die „blinden Flecken“ sind und was ihre Ziele und SLAs sind.

Die SLAs der Bank sind übrigens wirklich beeindruckend. Beispielsweise kann die Lösung eines Netzwerkverfügbarkeitsvorfalls der Priorität XNUMX nur wenige Minuten dauern. Die Kosten für Fehler und Ausfallzeiten sind hier natürlich beeindruckend.

Als Ergebnis haben wir mehrere Bereiche der Zusammenarbeit identifiziert:

1. Die erste Stufe ist die umfassende Überwachung, um die Geschwindigkeit der Vorfalllösung zu erhöhen
2. Die zweite Stufe ist die Prozessautomatisierung, um Risiken zu reduzieren und die Kosten für die Skalierung der IT-Abteilung zu senken.

Mehrere „weiße Flecken“ konnten nur durch die Verarbeitung von Informationen aus mehreren Überwachungssystemen in den leuchtenden Farben von Warnungen gemalt werden, da es unmöglich war, Metriken direkt zu erfassen; es war außerdem notwendig, Daten aus verschiedenen Überwachungssystemen auf „einem Bildschirm“ zu zentralisieren um das Gesamtbild des Geschehens zu verstehen. „Regenschirme“ eignen sich für diese Aufgabe und diese Anforderungen haben wir damals erfüllt.

Unserer Meinung nach ist Ehrlichkeit im Umgang mit Kunden sehr wichtig. Nach dem ersten Gespräch und der Berechnung der Kosten für die Lizenz hieß es, dass es sich aufgrund der geringen Kosten lohnen könnte, gleich eine Lizenz zu kaufen (im Vergleich zu Dynatrace Klyuch-Astrom aus dem obigen Artikel über die grüne Bank, unsere Die Lizenz kostet nicht eine Drittelmilliarde, sondern 12 Rubel pro Monat für 1 Gigabyte, für Sber wäre sie um ein Vielfaches günstiger. Aber wir haben ihnen sofort gesagt, was wir haben und was nicht. Vielleicht könnte ein Vertriebsmitarbeiter eines großen Integrators sagen: „Ja, wir können alles, natürlich kaufen wir unsere Lizenz“, aber wir beschlossen, alle unsere Karten auf den Tisch zu legen. Zum Zeitpunkt der Markteinführung verfügte unsere Box über keine Integration mit Prometheus und eine neue Version mit einem Automatisierungssubsystem stand kurz vor der Veröffentlichung, wir haben sie jedoch noch nicht an Kunden ausgeliefert.

Das Pilotprojekt begann, seine Grenzen wurden festgelegt und wir bekamen 2 Monate Zeit. Die Hauptaufgaben waren:

• Bereiten Sie eine neue Version der Plattform vor und stellen Sie sie in der Infrastruktur der Bank bereit
• 2 Überwachungssysteme anschließen (Zabbix und Prometheus);
• Benachrichtigungen an die Verantwortlichen in Slack und per SMS senden;
• Führen Sie Autohealing-Skripte aus.

Der erste Monat des Pilotprojekts wurde damit verbracht, eine neue Version der Plattform im Superschnellmodus für die Anforderungen des Pilotprojekts vorzubereiten. Die neue Version beinhaltet ab sofort die Integration mit Prometheus und die automatische Heilung. Dank unseres Entwicklungsteams haben sie mehrere Nächte lang nicht geschlafen, sondern veröffentlicht, was sie versprochen hatten, ohne die Fristen für andere zuvor eingegangene Verpflichtungen zu verpassen.

Während wir das Pilotprojekt einrichteten, stießen wir auf ein neues Problem, das das Projekt vorzeitig abschließen konnte: Um Benachrichtigungen an Instant Messenger und per SMS zu senden, benötigten wir ein- und ausgehende Verbindungen zu Microsoft Azure-Servern (damals nutzten wir diese Plattform). um Benachrichtigungen an Slack zu senden) und einen externen SMS-Versanddienst. Doch bei diesem Projekt stand die Sicherheit im Vordergrund. Entsprechend der Politik der Bank durften solche „Löcher“ unter keinen Umständen geöffnet werden. Alles musste in einem geschlossenen Kreislauf funktionieren. Uns wurde angeboten, die API unserer eigenen internen Dienste zu verwenden, die Benachrichtigungen an Slack und per SMS senden, wir hatten jedoch nicht die Möglichkeit, solche Dienste sofort anzubinden.

Ein Diskussionsabend mit dem Entwicklungsteam endete mit einer erfolgreichen Lösungssuche. Beim Durchsuchen des Rückstands fanden wir eine Aufgabe, für die wir nie genug Zeit und Priorität hatten – die Erstellung eines Plug-in-Systems, damit die Implementierungsteams oder der Kunde selbst Add-ons schreiben und so die Möglichkeiten der Plattform erweitern konnten.

Aber wir hatten noch genau einen Monat Zeit, in dem wir alles installieren, konfigurieren und die Automatisierung bereitstellen mussten.

Laut Sergei, unserem Chefarchitekten, dauert die Implementierung des Plug-in-Systems mindestens einen Monat.

Wir hatten keine Zeit...

Es gab nur eine Lösung: zum Kunden gehen und alles so erzählen, wie es ist. Besprechen Sie gemeinsam die Terminverschiebung. Und es hat funktioniert. Uns wurden zwei zusätzliche Wochen gegeben. Sie hatten auch ihre eigenen Fristen und internen Verpflichtungen, Ergebnisse vorzulegen, hatten aber zwei Reservewochen. Am Ende haben wir alles aufs Spiel gesetzt. Es war unmöglich, etwas zu vermasseln. Ehrlichkeit und ein partnerschaftlicher Ansatz haben sich erneut ausgezahlt.

Als Ergebnis des Pilotprojekts wurden mehrere wichtige technische Ergebnisse und Schlussfolgerungen gewonnen:

Wir haben die neue Funktionalität zur Verarbeitung von Alarmen getestet

Das bereitgestellte System begann, Warnungen von Prometheus korrekt zu empfangen und zu gruppieren. Alle 30 Sekunden wurden Warnungen zu dem Problem vom Prometheus-Client verschickt (die Gruppierung nach Zeit ist nicht aktiviert), und wir fragten uns, ob es möglich wäre, sie im „Umbrella“ selbst zu gruppieren. Es stellte sich heraus, dass dies möglich ist – die Einrichtung der Verarbeitung von Warnungen auf der Plattform wird durch ein Skript implementiert. Dadurch ist es möglich, nahezu jede Logik zu deren Verarbeitung zu implementieren. Wir haben die Standardlogik bereits in Form von Vorlagen in die Plattform implementiert. Wenn Sie sich nicht etwas Eigenes ausdenken möchten, können Sie auf eine vorgefertigte Logik zurückgreifen.

Schnittstelle „Synthetischer Trigger“. Einrichten der Verarbeitung von Warnungen von angeschlossenen Überwachungssystemen

Konstruiert den „Gesundheitszustand“ des Systems

Basierend auf Warnungen wurden Überwachungsereignisse erstellt, die sich auf den Zustand von Konfigurationseinheiten (CUs) auswirkten. Wir implementieren ein Resource-Service-Modell (RSM), das entweder eine interne CMDB nutzen oder eine externe anbinden kann – während des Pilotprojekts hat der Kunde keine eigene CMDB angebunden.

Schnittstelle zum Arbeiten mit dem Ressourcen-Service-Modell. Pilot-RSM.

Nun, tatsächlich verfügt der Client endlich über einen einzigen Überwachungsbildschirm, auf dem Ereignisse aus verschiedenen Systemen sichtbar sind. Derzeit sind zwei Systeme mit dem „Umbrella“ verbunden – Zabbix und Prometheus – sowie ein internes Überwachungssystem der Plattform selbst.

Analytics-Schnittstelle. Einzelner Überwachungsbildschirm.

Prozessautomatisierung gestartet

Überwachungsereignisse lösten den Start vorkonfigurierter Aktionen aus – Senden von Warnungen, Ausführen von Skripts, Registrieren/Anreichern von Vorfällen – Letzteres wurde mit diesem bestimmten Client nicht versucht, weil Im Pilotprojekt gab es keine Integration mit dem Service Desk.

Benutzeroberfläche für Aktionseinstellungen. Senden Sie Benachrichtigungen an Slack und starten Sie den Server neu.

Erweiterte Produktfunktionalität

Bei der Diskussion über Automatisierungsskripte fragte der Kunde nach Bash-Unterstützung und einer Schnittstelle, in der diese Skripte bequem konfiguriert werden könnten. Die neue Version hat etwas mehr getan (die Möglichkeit, vollwertige logische Konstrukte in Lua mit Unterstützung für cURL, SSH und SNMP zu schreiben) und Funktionen implementiert, die es Ihnen ermöglichen, den Lebenszyklus eines Skripts zu verwalten (Erstellen, Bearbeiten, Versionskontrolle). , löschen und archivieren).

Schnittstelle zum Arbeiten mit Autohealing-Skripten. Server-Neustart-Skript über SSH.

Die wichtigsten Ergebnisse

Während des Pilotprojekts wurden auch User Stories erstellt, die die aktuelle Funktionalität verbessern und den Wert für den Kunden steigern. Hier einige davon:

• Implementieren Sie die Möglichkeit, Variablen direkt von der Warnung an das Autohealing-Skript weiterzuleiten.
• Fügen Sie der Plattform über Active Directory eine Autorisierung hinzu.

Und wir erhielten weitere globale Herausforderungen – das Produkt mit anderen Fähigkeiten „aufzubauen“:

• Automatischer Aufbau eines Ressourcen-Service-Modells basierend auf ML anstelle von Regeln und Agenten (derzeit wahrscheinlich die größte Herausforderung);
• Unterstützung für zusätzliche Skript- und Logiksprachen (und dies wird JavaScript sein).

Meiner Meinung nach, das WichtigsteWas dieser Pilot zeigt, sind zwei Dinge:

1. Partnerschaften mit dem Kunden sind der Schlüssel zur Effektivität, wenn effektive Kommunikation auf der Grundlage von Ehrlichkeit und Offenheit aufgebaut wird und der Kunde Teil eines Teams wird, das in kurzer Zeit bedeutende Ergebnisse erzielt.
2. Auf keinen Fall ist es nötig, „Krücken nach Maß“ zu bauen, sondern nur Systemlösungen. Es ist besser, etwas mehr Zeit zu investieren, aber eine Systemlösung zu entwickeln, die von anderen Kunden genutzt wird. Das ist übrigens passiert, das Plugin-System und die Beseitigung der Abhängigkeit von Azure haben anderen Kunden einen Mehrwert geboten (Hallo, Bundesgesetz 152).

Source: habr.com