Varför behöver en bank AIOs och paraplyövervakning, eller vad bygger kundrelationer på?

I publikationer om Habré har jag redan skrivit om min erfarenhet av att bygga partnerskap med mitt team (här talar om hur man upprättar ett samarbetsavtal när man startar en ny verksamhet så att verksamheten inte går sönder). Och nu skulle jag vilja prata om hur man bygger partnerskap med kunder, eftersom utan dem kommer det inte att finnas något att falla isär. Jag hoppas att den här artikeln kommer att vara användbar för startups som börjar sälja sin produkt till stora företag.

Jag leder för närvarande en startup som heter MONQ Digital lab, där mitt team och jag utvecklar en produkt för att automatisera processerna för att stödja och driva företagens IT. Att komma in på marknaden är ingen lätt uppgift och vi började med lite läxor, gick igenom marknadsexperter, våra partners och genomförde marknadssegmentering. Huvudfrågan var att förstå "vems smärtor kan vi läka bäst?"

Bankerna tog sig in i TOP 3-segmenten. Och naturligtvis var de första på listan Tinkoff och Sberbank. När vi besökte bankmarknadsexperter sa de: introducera din produkt där, så kommer vägen till bankmarknaden att vara öppen. Vi försökte komma in både där och där, men misslyckanden väntade oss på Sberbank, och killarna från Tinkoff visade sig vara mycket mer öppna för produktiv kommunikation med ryska startups (kanske på grund av det faktum att Sber vid den tiden köpt nästan en miljard av våra västerländska konkurrenter). Inom en månad startade vi ett pilotprojekt. Hur det gick till, läs vidare.

Vi har sysslat med frågor om drift och övervakning i många år, nu implementerar vi vår produkt i den offentliga sektorn, inom försäkringar, i banker, i telekombolag, en implementering var med ett flygbolag (före projektet gjorde vi inte ens tror att flyget var en så IT-beroende bransch, och nu hoppas vi verkligen, trots covid, att företaget kommer att växa fram och ta fart).

Produkten vi tillverkar tillhör företagsprogramvaran, AIOps-segmentet (Artificial Intelligence for IT Operations, eller ITOps). Huvudmålen med att implementera sådana system som nivån på processmognad i företaget ökar:

1. Släck bränder: identifiera fel, rensa strömmen av varningar från skräp, tilldela uppgifter och incidenter till de ansvariga;
2. Öka effektiviteten hos IT-tjänsten: minska tiden för att lösa incidenter, ange orsakerna till fel, öka insynen i IT-statusen;
3. Öka verksamhetens effektivitet: minska mängden manuellt arbete, minska riskerna, öka kundlojaliteten.

Enligt vår erfarenhet har banker följande "besvär" med övervakning gemensamt med alla stora IT-infrastrukturer:

• "vem vet vad": det finns många tekniska avdelningar, nästan alla har minst ett övervakningssystem och de flesta har mer än ett;
• "myggsvärm" av varningar: varje system genererar hundratals och bombarderar alla ansvariga med dem (ibland även mellan avdelningar). Det är svårt att ständigt behålla fokus på kontrollen på varje anmälan, deras brådska och betydelse jämnas ut på grund av det stora antalet;
• stora banker - sektorledare vill inte bara kontinuerligt övervaka sina system, veta var det finns fel, utan också den verkliga magin med AI - för att göra systemen självövervakande, självförutsägande och självkorrekta.

När vi kom till det första mötet på Tinkoff fick vi omedelbart veta att de inte hade några problem med övervakningen och ingenting skadade dem, och huvudfrågan var: "Vad kan vi erbjuda för dem som redan har det bra?"

Samtalet var långt, vi diskuterade hur deras mikrotjänster är uppbyggda, hur avdelningar fungerar, vilka infrastrukturproblem som är känsligare, vilka som är mindre känsliga för användarna, var finns de "blinda fläckarna" och vilka är deras mål och SLA.

Förresten, bankens SLA är verkligen imponerande. Till exempel kan en incident med prioritet XNUMX nätverkstillgänglighet bara ta några minuter att lösa. Kostnaden för fel och stillestånd här är förstås imponerande.

Som ett resultat identifierade vi flera samarbetsområden:

1. det första steget är paraplyövervakning för att öka hastigheten på incidentlösningen
2. det andra steget är processautomation för att minska risker och minska kostnaderna för att skala IT-avdelningen.

Flera "vita fläckar" kunde målas i ljusa färger av varningar endast genom att bearbeta information från flera övervakningssystem, eftersom det var omöjligt att direkt ta mätvärden; det var också nödvändigt att centralisera data från olika övervakningssystem till "en skärm" för att att förstå den övergripande bilden av vad som hände. "Paraplyer" är lämpliga för denna uppgift och vi uppfyllde dessa krav då.

En mycket viktig sak, enligt vår mening, i relationer med kunder är ärlighet. Efter det första samtalet och beräkningen av kostnaden för licensen sa man att eftersom kostnaden är så låg kan det vara värt att köpa en licens direkt (jämfört med Dynatrace Klyuch-Astrom från artikeln ovan om den gröna banken, vår licens kostar inte en tredjedel av en miljard, utan 12 tusen rubel per månad för 1 gigabyte, för Sber skulle det kosta flera gånger billigare). Men vi berättade omedelbart för dem vad vi har och vad vi inte har. Kanske kunde en säljare från en stor integratör säga "ja, vi kan göra allt, naturligtvis köpa vår licens", men vi bestämde oss för att lägga alla kort på bordet. Vid tidpunkten för lanseringen hade vår box inte integration med Prometheus, och en ny version med ett automationsundersystem var på väg att släppas, men vi har inte skickat den till kunderna än.

Pilotprojektet började, dess gränser bestämdes och vi fick 2 månader. Huvuduppgifterna var:

• förbereda en ny version av plattformen och distribuera den i bankens infrastruktur
• ansluta 2 övervakningssystem (Zabbix och Prometheus);
• skicka aviseringar till ansvariga i Slack och via SMS;
• kör autoläkningsskript.

Den första månaden av pilotprojektet ägnades åt att förbereda en ny version av plattformen i supersnabbt läge för pilotprojektets behov. Den nya versionen inkluderar omedelbart integration med Prometheus och auto-healing. Tack vare vårt utvecklingsteam sov de inte på flera nätter, utan släppte vad de lovade utan att missa deadlines för andra tidigare gjorda åtaganden.

Medan vi satte upp piloten stötte vi på ett nytt problem som kunde avsluta projektet i förväg: för att skicka varningar till snabbmeddelanden och via SMS behövde vi inkommande och utgående anslutningar till Microsoft Azure-servrar (vid den tiden använde vi den här plattformen för att skicka varningar till Slack) och en extern sändningstjänst SMS. Men i det här projektet var säkerheten ett särskilt fokus. I enlighet med bankens policy kunde sådana "hål" inte under några omständigheter öppnas. Allt måste fungera från en sluten slinga. Vi erbjöds att använda API:et för våra egna interna tjänster som skickar varningar till Slack och via SMS, men vi hade inte möjlighet att koppla upp sådana tjänster direkt.

En kväll av debatt med utvecklingsteamet avslutades med ett framgångsrikt sökande efter en lösning. Efter att ha rotat igenom eftersläpningen hittade vi en uppgift som vi aldrig hade tillräckligt med tid och prioritet för - att skapa ett plug-in-system så att implementeringsteamen eller klienten kunde skriva tillägg själva, vilket utökade plattformens möjligheter.

Men vi hade exakt en månad kvar, under vilken vi var tvungna att installera allt, konfigurera och distribuera automatisering.

Enligt Sergei, vår chefsarkitekt, tar det minst en månad att implementera plug-in-systemet.

Vi hade inte tid...

Det fanns bara en lösning - gå till klienten och berätta allt som det är. Diskutera deadline shift tillsammans. Och det fungerade. Vi fick 2 veckor extra. De hade även egna deadlines och interna skyldigheter att visa resultat, men de hade 2 reservveckor. Till slut satte vi allt på spel. Det var omöjligt att strula. Ärlighet och en partnerskapsstrategi gav återigen resultat.

Som ett resultat av pilotprojektet erhölls flera viktiga tekniska resultat och slutsatser:

Vi testade den nya funktionen för att bearbeta varningar

Det utplacerade systemet började korrekt ta emot varningar från Prometheus och gruppera dem. Varningar om problemet från Prometheus-klienten flög var 30:e sekund (gruppering efter tid är inte aktiverat), och vi undrade om det skulle vara möjligt att gruppera dem i själva "paraplyet". Det visade sig att det är möjligt - att ställa in behandlingen av varningar i plattformen implementeras av ett skript. Detta gör det möjligt att implementera nästan vilken logik som helst för att bearbeta dem. Vi har redan implementerat standardlogik i plattformen i form av mallar - om du inte vill komma på något eget kan du använda en färdig.

"Syntetisk trigger"-gränssnitt. Ställa in bearbetning av larm från anslutna övervakningssystem

Konstruerade systemets "hälsotillstånd".

Baserat på varningar skapades övervakningshändelser som påverkade tillståndet för konfigurationsenheter (CU). Vi implementerar en resursservicemodell (RSM), som kan använda antingen en intern CMDB eller ansluta en extern - under pilotprojektet kopplade inte klienten upp sin egen CMDB.

Gränssnitt för att arbeta med resursservicemodellen. Pilot RSM.

Jo, faktiskt, klienten har äntligen en enda övervakningsskärm, där händelser från olika system är synliga. För närvarande är två system anslutna till "paraplyet" - Zabbix och Prometheus, och ett internt övervakningssystem för själva plattformen.

Analytics gränssnitt. Enkel övervakningsskärm.

Lanserade processautomation

Övervakningshändelser utlöste lanseringen av förkonfigurerade åtgärder - skicka varningar, köra skript, registrera/berika incidenter - det senare testades inte med just den här klienten, eftersom i pilotprojektet fanns ingen integration med servicedesk.

Gränssnitt för åtgärdsinställningar. Skicka varningar till Slack och starta om servern.

Utökad produktfunktionalitet

När man diskuterade automatiseringsskript bad klienten om bash-stöd och ett gränssnitt där dessa skript bekvämt kunde konfigureras. Den nya versionen har gjort lite mer (möjligheten att skriva fullfjädrade logiska konstruktioner i Lua med stöd för cURL, SSH och SNMP) och implementerat funktionalitet som låter dig hantera livscykeln för ett skript (skapa, redigera, versionskontroll , radera och arkivera).

Gränssnitt för att arbeta med autohealing-skript. Serverns omstartsskript via SSH.

Huvudresultat

Under pilotprojektet skapades även användarberättelser som förbättrar nuvarande funktionalitet och ökar värdet för kunden, här är några av dem:

• implementera förmågan att vidarebefordra variabler direkt från varningen till autohealing-skriptet;
• lägga till auktorisering till plattformen via Active Directory.

Och vi fick fler globala utmaningar - att "bygga upp" produkten med andra funktioner:

• automatisk konstruktion av en resursservicemodell baserad på ML, snarare än regler och agenter (förmodligen den största utmaningen nu);
• stöd för ytterligare skript- och logikspråk (och detta kommer att vara JavaScript).

Enligt min mening, det viktigasteVad den här piloten visar är två saker:

1. Partnerskap med kunden är nyckeln till effektivitet, när effektiv kommunikation byggs på ärlighet och öppenhet, och kunden blir en del av ett team som når betydande resultat på kort tid.
2. Under inga omständigheter är det nödvändigt att "anpassa" och bygga "kryckor" - bara systemlösningar. Det är bättre att spendera lite mer tid, men gör en systemlösning som kommer att användas av andra kunder. Förresten, detta är vad som hände, pluginsystemet och elimineringen av beroendet av Azure gav ytterligare värde till andra klienter (hej, federal lag 152).

Källa: will.com