Waarom heeft een bank AIOps en overkoepelende monitoring nodig, of waar zijn klantrelaties op gebaseerd?

In publicaties over Habré schreef ik al over mijn ervaring met het opbouwen van partnerschappen met mijn team (hier vertelt hoe je een samenwerkingsovereenkomst opstelt bij het starten van een nieuw bedrijf, zodat het bedrijf niet uit elkaar valt). En nu zou ik het willen hebben over het opbouwen van partnerschappen met klanten, want zonder hen zal er niets uit elkaar vallen. Ik hoop dat dit artikel nuttig zal zijn voor startups die hun product aan grote bedrijven beginnen te verkopen.

Momenteel geef ik leiding aan een startup genaamd MONQ Digital lab, waar mijn team en ik een product ontwikkelen voor het automatiseren van de processen voor het ondersteunen en exploiteren van bedrijfs-IT. Het betreden van de markt is geen gemakkelijke taak en we zijn begonnen met wat huiswerk, hebben marktexperts en onze partners doorgenomen en marktsegmentatie uitgevoerd. De belangrijkste vraag was om te begrijpen “wiens pijnen kunnen we het beste genezen?”

Banken bereikten de TOP 3-segmenten. En natuurlijk waren de eersten op de lijst Tinkoff en Sberbank. Toen we deskundigen op de bancaire markt bezochten, zeiden ze: introduceer je product daar, en de weg naar de bancaire markt ligt open. We probeerden zowel daar als daar binnen te komen, maar bij Sberbank wachtte ons een mislukking, en de jongens van Tinkoff bleken veel opener te staan ​​voor productieve communicatie met Russische startups (misschien vanwege het feit dat Sber op dat moment gekocht bijna een miljard van onze westerse concurrenten). Binnen een maand zijn we gestart met een pilotproject. Hoe het gebeurde, lees verder.

We hebben ons al vele jaren beziggehouden met kwesties op het gebied van de exploitatie en monitoring, nu implementeren we ons product in de publieke sector, bij verzekeringen, bij banken, bij telecombedrijven. Eén implementatie vond plaats bij een luchtvaartmaatschappij (vóór het project hadden we dat niet eens gedaan). denken dat de luchtvaart zo’n IT-afhankelijke industrie was, en nu hopen we echt, ondanks COVID, dat het bedrijf zal opkomen en van de grond zal komen).

Het product dat wij maken behoort tot bedrijfssoftware, het AIOps-segment (Artificial Intelligence for IT Operations, oftewel ITOps). De belangrijkste doelstellingen van het implementeren van dergelijke systemen naarmate het niveau van procesvolwassenheid in het bedrijf toeneemt:

1. Branden blussen: storingen identificeren, de stroom waarschuwingen opruimen van puin, taken en incidenten toewijzen aan de verantwoordelijken;
2. Vergroot de efficiëntie van de IT-dienstverlening: verkort de tijd om incidenten op te lossen, geef de oorzaken van storingen aan, vergroot de transparantie van de IT-status;
3. Verhoog de bedrijfsefficiëntie: verminder de hoeveelheid handarbeid, verminder risico's, verhoog de klantenloyaliteit.

Onze ervaring is dat banken bij alle grote IT-infrastructuren de volgende ‘problemen’ hebben met monitoring:

• “wie weet wat”: er zijn veel technische afdelingen, bijna iedereen heeft minstens één monitoringsysteem, en de meeste hebben er meer dan één;
• “muggenzwerm” van waarschuwingen: elk systeem genereert honderden en bestookt daarmee alle verantwoordelijken (soms ook tussen afdelingen). Het is moeilijk om voortdurend de focus van de controle op elke melding te behouden; de urgentie en het belang ervan worden gelijkgesteld vanwege het grote aantal;
• grote banken – sectorleiders willen niet alleen hun systemen voortdurend monitoren, om te weten waar er fouten zijn, maar ook de echte magie van AI – om ervoor te zorgen dat de systemen zichzelf monitoren, zichzelf voorspellen en zichzelf corrigeren.

Toen we bij de eerste bijeenkomst bij Tinkoff kwamen, kregen we meteen te horen dat ze geen problemen hadden met de monitoring en dat niets hen pijn deed, en de belangrijkste vraag was: “Wat kunnen we bieden voor degenen die het al goed doen?”

Het gesprek duurde lang, we bespraken hoe hun microservices zijn gebouwd, hoe afdelingen werken, welke infrastructuurproblemen gevoeliger zijn, welke minder gevoelig voor gebruikers, waar zitten de ‘blinde vlekken’, en wat zijn hun doelen en SLA’s.

Overigens zijn de SLA’s van de bank echt indrukwekkend. Het kan bijvoorbeeld maar een paar minuten duren voordat een netwerkbeschikbaarheidsincident met prioriteit XNUMX is opgelost. De kosten van fouten en downtime zijn hier uiteraard indrukwekkend.

Als gevolg hiervan hebben we verschillende samenwerkingsgebieden geïdentificeerd:

1. de eerste fase is overkoepelende monitoring om de snelheid waarmee incidenten worden opgelost te verhogen
2. de tweede fase is procesautomatisering om de risico's te verminderen en de kosten voor het opschalen van de IT-afdeling te verlagen.

Verschillende “witte vlekken” konden alleen in de felle kleuren van waarschuwingen worden geschilderd door informatie van verschillende monitoringsystemen te verwerken, omdat het onmogelijk was om rechtstreeks meetgegevens te verzamelen; het was ook nodig om gegevens van verschillende monitoringsystemen op “één scherm” te centraliseren om de om het algemene beeld te begrijpen van wat er gebeurde. “Paraplu’s” zijn geschikt voor deze taak en wij voldeden toen aan deze eisen.

Naar onze mening is eerlijkheid een heel belangrijk aspect in de relatie met klanten. Na het eerste gesprek en de berekening van de kosten van de licentie werd gezegd dat, aangezien de kosten zo laag zijn, het misschien de moeite waard zou zijn om meteen een licentie te kopen (vergeleken met Dynatrace Klyuch-Astrom uit het artikel hierboven over de groene bank, onze licentie kost geen derde miljard, maar 12 duizend roebel per maand voor 1 gigabyte, voor Sber zou het meerdere malen goedkoper zijn). Maar we vertelden ze meteen wat we hebben en wat we niet hebben. Misschien zou een vertegenwoordiger van een grote integrator kunnen zeggen “ja, we kunnen alles doen, natuurlijk onze licentie kopen”, maar we besloten alle kaarten op tafel te leggen. Op het moment van lancering had onze box geen integratie met Prometheus en stond er een nieuwe versie met een automatiseringssubsysteem op het punt uit te komen, maar we hebben deze nog niet naar klanten verzonden.

Het proefproject begon, de grenzen werden bepaald en we kregen 2 maanden. De belangrijkste taken waren:

• een nieuwe versie van het platform voorbereiden en implementeren in de infrastructuur van de bank
• koppel 2 monitoringsystemen (Zabbix en Prometheus);
• notificaties versturen naar de verantwoordelijken in Slack en via SMS;
• voer autohealing-scripts uit.

De eerste maand van het proefproject werd besteed aan het voorbereiden van een nieuwe versie van het platform in supersnelle modus voor de behoeften van het proefproject. De nieuwe versie omvat onmiddellijk integratie met Prometheus en auto-healing. Dankzij ons ontwikkelingsteam hebben ze een aantal nachten niet geslapen, maar hebben ze hun beloftes waargemaakt zonder de deadlines voor andere eerder gemaakte toezeggingen te missen.

Terwijl we de pilot aan het opzetten waren, kwamen we een nieuw probleem tegen waardoor het project eerder dan gepland kon worden afgerond: om waarschuwingen naar instant messengers en via sms te sturen, hadden we inkomende en uitgaande verbindingen nodig met Microsoft Azure-servers (destijds gebruikten we dit platform om waarschuwingen naar Slack te sturen) en een externe sms-service. Maar bij dit project stond vooral veiligheid centraal. Conform het beleid van de bank mochten dergelijke “gaten” onder geen enkele omstandigheid worden gedicht. Alles moest vanuit een gesloten lus werken. Ons werd aangeboden om de API van onze eigen interne diensten te gebruiken die waarschuwingen naar Slack en via sms sturen, maar we hadden niet de mogelijkheid om dergelijke diensten kant-en-klaar aan te sluiten.

Een debatavond met het ontwikkelteam eindigde met een succesvolle zoektocht naar een oplossing. Nadat we de achterstand hadden doorzocht, vonden we één taak waarvoor we nooit genoeg tijd en prioriteit hadden: het creëren van een plug-insysteem zodat de implementatieteams of de klant zelf add-ons konden schrijven, waardoor de mogelijkheden van het platform werden uitgebreid.

Maar we hadden nog precies een maand waarin we alles moesten installeren, configureren en automatiseren.

Volgens Sergei, onze hoofdarchitect, duurt het minstens een maand om een ​​plug-in systeem te implementeren.

Wij hadden geen tijd...

Er was maar één oplossing: naar de klant gaan en alles vertellen zoals het is. Bespreek samen de deadlineverschuiving. En het werkte. We kregen nog 2 weken extra. Ze hadden ook hun eigen deadlines en interne verplichtingen om resultaten te tonen, maar ze hadden 2 reserveweken. Uiteindelijk hebben we alles op het spel gezet. Het was onmogelijk om het te verpesten. Eerlijkheid en partnerschapsaanpak hebben opnieuw hun vruchten afgeworpen.

Als resultaat van de pilot zijn verschillende belangrijke technische resultaten en conclusies verkregen:

We hebben de nieuwe functionaliteit voor het verwerken van waarschuwingen getest

Het ingezette systeem begon waarschuwingen van Prometheus correct te ontvangen en te groeperen. Waarschuwingen over het probleem van de Prometheus-client vlogen elke 30 seconden (groeperen op tijd is niet ingeschakeld) en we vroegen ons af of het mogelijk zou zijn om ze in de "paraplu" zelf te groeperen. Het bleek mogelijk: het instellen van de verwerking van waarschuwingen op het platform wordt geïmplementeerd door een script. Dit maakt het mogelijk om vrijwel elke logica voor de verwerking ervan te implementeren. We hebben al standaardlogica in het platform geïmplementeerd in de vorm van sjablonen. Als je niet zelf iets wilt bedenken, kun je een kant-en-klaar exemplaar gebruiken.

“Synthetische trigger”-interface. Instellen van verwerking van waarschuwingen van aangesloten monitoringsystemen

De staat van “gezondheid” van het systeem geconstrueerd

Op basis van waarschuwingen zijn monitoringgebeurtenissen gecreëerd die de status van configuratie-eenheden (CU's) beïnvloedden. We implementeren een resource-service model (RSM), dat een interne CMDB kan gebruiken of een externe CMDB kan verbinden. Tijdens het pilotproject heeft de klant zijn eigen CMDB niet aangesloten.

Interface voor het werken met het resource-servicemodel. Piloot RSM.

In feite beschikt de klant eindelijk over één enkel monitoringscherm, waarop gebeurtenissen uit verschillende systemen zichtbaar zijn. Momenteel zijn twee systemen verbonden met de "paraplu" - Zabbix en Prometheus, en een intern monitoringsysteem van het platform zelf.

Analytics-interface. Eén bewakingsscherm.

Procesautomatisering gelanceerd

Het monitoren van gebeurtenissen veroorzaakte de lancering van vooraf geconfigureerde acties - het verzenden van waarschuwingen, het uitvoeren van scripts, het registreren/verrijken van incidenten - dit laatste is bij deze specifieke client niet geprobeerd, omdat in het pilotproject was er geen integratie met de servicedesk.

Interface voor actie-instellingen. Stuur waarschuwingen naar Slack en start de server opnieuw op.

Uitgebreide productfunctionaliteit

Bij het bespreken van automatiseringsscripts vroeg de klant om bash-ondersteuning en een interface waarin deze scripts gemakkelijk konden worden geconfigureerd. De nieuwe versie heeft iets meer gedaan (de mogelijkheid om volwaardige logische constructies in Lua te schrijven met ondersteuning voor cURL, SSH en SNMP) en functionaliteit geïmplementeerd waarmee je de levenscyclus van een script kunt beheren (maken, bewerken, versiebeheer , verwijderen en archiveren).

Interface voor het werken met autohealing-scripts. Script voor het opnieuw opstarten van de server via SSH.

Belangrijkste bevindingen

Tijdens de pilot zijn er ook user stories gecreëerd die de huidige functionaliteit verbeteren en de waarde voor de klant verhogen, hier zijn er enkele:

• de mogelijkheid implementeren om variabelen rechtstreeks vanuit de waarschuwing door te sturen naar het autohealing-script;
• voeg autorisatie toe aan het platform via Active Directory.

En we kregen meer mondiale uitdagingen - om het product te 'opbouwen' met andere mogelijkheden:

• automatische constructie van een resource-servicemodel gebaseerd op ML, in plaats van op regels en agenten (waarschijnlijk de grootste uitdaging nu);
• ondersteuning voor extra scripting- en logische talen (en dit zal JavaScript zijn).

Naar mijn mening, het belangrijksteWat deze pilot laat zien zijn twee dingen:

1. Partnerschappen met de klant zijn de sleutel tot effectiviteit, wanneer effectieve communicatie wordt opgebouwd op basis van eerlijkheid en openheid, en de klant onderdeel wordt van een team dat in korte tijd significante resultaten behaalt.
2. Het is in geen geval nodig om “krukken” te “aanpassen” en te bouwen – alleen systeemoplossingen. Het is beter om wat meer tijd te besteden, maar een systeemoplossing te maken die door andere klanten zal worden gebruikt. Dit is trouwens wat er gebeurde: het plug-insysteem en het elimineren van de afhankelijkheid van Azure zorgden voor extra waarde voor andere klanten (hallo, federale wet 152).

Bron: www.habr.com