Hvorfor har en bank brug for AIOps og paraplyovervågning, eller hvad er kundeforhold baseret på?

I publikationer om Habré skrev jeg allerede om min erfaring med at bygge partnerskaber med mit team (her fortæller om, hvordan man udarbejder en partnerskabsaftale, når man starter en ny virksomhed, så virksomheden ikke falder fra hinanden). Og nu vil jeg gerne tale om, hvordan man opbygger partnerskaber med kunder, da uden dem vil der ikke være noget, der falder fra hinanden. Jeg håber, at denne artikel vil være nyttig for startups, der begynder at sælge deres produkt til store virksomheder.

Jeg står i øjeblikket i spidsen for en startup kaldet MONQ Digital lab, hvor mit team og jeg udvikler et produkt til automatisering af processerne med at understøtte og drive virksomheds-IT. At komme ind på markedet er ikke en let opgave, og vi startede med lidt hjemmearbejde, gennemgik markedseksperter, vores partnere og gennemførte markedssegmentering. Hovedspørgsmålet var at forstå "hvis smerter kan vi bedst helbrede?"

Banker kom ind i TOP 3-segmenterne. Og selvfølgelig var de første på listen Tinkoff og Sberbank. Da vi besøgte bankmarkedseksperter, sagde de: introducer dit produkt der, og vejen til bankmarkedet vil være åben. Vi forsøgte at komme ind både der og der, men fiasko ventede os i Sberbank, og fyrene fra Tinkoff viste sig at være meget mere åbne over for produktiv kommunikation med russiske startups (måske på grund af det faktum, at Sber på det tidspunkt købt næsten en milliard af vores vestlige konkurrenter). Inden for en måned startede vi et pilotprojekt. Hvordan det skete, læs videre.

Vi har beskæftiget os med spørgsmål om drift og overvågning i mange år, nu implementerer vi vores produkt i den offentlige sektor, i forsikringer, i banker, i teleselskaber, en implementering var med et flyselskab (før projektet gjorde vi ikke engang tror, ​​at luftfart var sådan en it-afhængig industri, og nu håber vi virkelig, på trods af COVID, at virksomheden vil dukke op og tage fart).

Det produkt, vi laver, tilhører virksomhedssoftware, AIOps-segmentet (Artificial Intelligence for IT Operations eller ITOps). Hovedmålene med at implementere sådanne systemer som niveauet af procesmodenhed i virksomheden øges:

1. Sluk brande: Identificer fejl, fjern strømmen af ​​advarsler fra affald, tildel opgaver og hændelser til de ansvarlige;
2. Øg effektiviteten af ​​IT-tjenesten: Reducer tiden til at løse hændelser, angiv årsagerne til fejl, øg gennemsigtigheden af ​​IT-status;
3. Øg virksomhedens effektivitet: reducer mængden af ​​manuelt arbejde, reducer risici, øge kundeloyaliteten.

Det er vores erfaring, at banker har følgende "problemer" med overvågning til fælles med alle store it-infrastrukturer:

• "hvem ved hvad": der er mange tekniske afdelinger, næsten alle har mindst ét ​​overvågningssystem, og de fleste har mere end ét;
• "myggesværm" af alarmer: hvert system genererer hundredvis og bombarderer alle ansvarlige med dem (nogle gange også mellem afdelinger). Det er vanskeligt konstant at fastholde fokus på kontrollen på hver enkelt anmeldelse, deres hastende karakter og betydning er udjævnet på grund af det store antal;
• store banker - sektorledere ønsker ikke kun løbende at overvåge deres systemer, at vide, hvor der er fejl, men også den virkelige magi ved AI - at gøre systemerne selvovervågende, selvforudsigelige og selvkorrekte.

Da vi kom til det første møde hos Tinkoff, fik vi straks at vide, at de ikke havde nogen problemer med at overvåge, og intet gjorde dem ondt, og hovedspørgsmålet var: "Hvad kan vi tilbyde dem, der allerede har det godt?"

Samtalen var lang, vi diskuterede, hvordan deres mikrotjenester er bygget op, hvordan afdelinger fungerer, hvilke infrastrukturproblemer der er mere følsomme, hvilke er mindre følsomme for brugerne, hvor er de "blinde vinkler", og hvad er deres mål og SLA'er.

For øvrigt er bankens SLA'er virkelig imponerende. For eksempel kan en hændelse med prioritet XNUMX netværkstilgængelighed kun tage et par minutter at løse. Omkostningerne ved fejl og nedetid her er selvfølgelig imponerende.

Som et resultat har vi identificeret flere samarbejdsområder:

1. den første fase er paraplyovervågning for at øge hastigheden af ​​hændelsesløsningen
2. anden fase er procesautomatisering for at reducere risici og reducere omkostningerne til at skalere IT-afdelingen.

Adskillige "hvide pletter" kunne kun males i de klare farver af alarmer ved at behandle information fra flere overvågningssystemer, da det var umuligt at tage målinger direkte; det var også nødvendigt at centralisere data fra forskellige overvågningssystemer til "én skærm" for at at forstå det overordnede billede af, hvad der skete. "Paraplyer" er velegnede til denne opgave, og vi opfyldte disse krav dengang.

En meget vigtig ting, efter vores mening, i relationer med kunder er ærlighed. Efter den første samtale og beregning af omkostningerne ved licensen blev det sagt, at da omkostningerne er så lave, kunne det være værd at købe en licens med det samme (sammenlignet med Dynatrace Klyuch-Astrom fra artiklen ovenfor om den grønne bank, vores licens koster ikke en tredjedel af en milliard, men 12 tusind rubler om måneden for 1 gigabyte, for Sber ville det koste flere gange billigere). Men vi fortalte dem straks, hvad vi har, og hvad vi ikke har. Måske kunne en salgsrepræsentant fra en stor integrator sige "ja, vi kan alt, selvfølgelig købe vores licens", men vi besluttede at lægge alle vores kort på bordet. På lanceringstidspunktet havde vores boks ikke integration med Prometheus, og en ny version med et automatiseringsundersystem var ved at blive frigivet, men vi har ikke sendt den til kunderne endnu.

Pilotprojektet begyndte, dets grænser blev fastlagt, og vi fik 2 måneder. Hovedopgaverne var:

• udarbejde en ny version af platformen og implementere den i bankens infrastruktur
• forbinde 2 overvågningssystemer (Zabbix og Prometheus);
• sende notifikationer til de ansvarlige i Slack og via SMS;
• køre autohealing scripts.

Den første måned af pilotprojektet gik med at forberede en ny version af platformen i superhurtig tilstand til pilotprojektets behov. Den nye version inkluderer straks integration med Prometheus og auto-healing. Takket være vores udviklingsteam sov de ikke i flere nætter, men frigav, hvad de lovede uden at gå glip af deadlines for andre tidligere afgivne forpligtelser.

Mens vi satte pilotprojektet op, stødte vi på et nyt problem, der kunne lukke projektet før tidsplanen: for at sende advarsler til instant messengers og via SMS havde vi brug for indgående og udgående forbindelser til Microsoft Azure-servere (på det tidspunkt brugte vi denne platform for at sende alarmer til Slack) og en ekstern sendetjeneste SMS. Men i dette projekt var sikkerhed et særligt fokus. I overensstemmelse med bankens politik kunne sådanne "huller" under ingen omstændigheder åbnes. Alt skulle fungere fra et lukket kredsløb. Vi blev tilbudt at bruge API'et til vores egne interne tjenester, der sender alarmer til Slack og via SMS, men vi havde ikke mulighed for at forbinde sådanne tjenester ud af boksen.

En aften med debat med udviklingsteamet endte med en vellykket søgen efter en løsning. Efter at have rodet gennem efterslæbet fandt vi én opgave, som vi aldrig havde tid og prioritet nok til - at skabe et plug-in-system, så implementeringsteamene eller klienten selv kunne skrive tilføjelser, hvilket udvidede platformens muligheder.

Men vi havde præcis en måned tilbage, hvor vi skulle installere alt, konfigurere og implementere automatisering.

Ifølge Sergei, vores chefarkitekt, tager det mindst en måned at implementere plug-in-systemet.

Vi havde ikke tid...

Der var kun én løsning - gå til klienten og fortæl alt, som det er. Diskuter tidsfristskiftet sammen. Og det virkede. Vi fik 2 uger ekstra. De havde også deres egne deadlines og interne forpligtelser til at vise resultater, men de havde 2 reserveuger. Til sidst sætter vi alt på spil. Det var umuligt at rode. Ærlighed og en partnerskabstilgang gav igen pote.

Som et resultat af piloten blev der opnået flere vigtige tekniske resultater og konklusioner:

Vi testede den nye funktionalitet til behandling af advarsler

Det indsatte system begyndte korrekt at modtage advarsler fra Prometheus og gruppere dem. Advarsler om problemet fra Prometheus-klienten fløj hvert 30. sekund (gruppering efter tid er ikke aktiveret), og vi spekulerede på, om det ville være muligt at gruppere dem i selve "paraplyen". Det viste sig, at det er muligt - opsætning af behandlingen af ​​advarsler i platformen er implementeret af et script. Dette gør det muligt at implementere næsten enhver logik til at behandle dem. Vi har allerede implementeret standardlogik i platformen i form af skabeloner - hvis du ikke vil finde på noget af dit eget, kan du bruge en færdiglavet.

"Syntetisk trigger"-grænseflade. Opsætning af behandling af alarmer fra tilsluttede overvågningssystemer

Konstruerede systemets "sundhedstilstand".

Baseret på advarsler blev der oprettet overvågningshændelser, der påvirkede tilstanden af ​​konfigurationsenheder (CU'er). Vi implementerer en ressource-service model (RSM), som enten kan bruge en intern CMDB eller forbinde en ekstern - under pilotprojektet tilsluttede klienten ikke sin egen CMDB.

Interface til at arbejde med ressource-service modellen. Pilot RSM.

Nå, faktisk har klienten endelig en enkelt overvågningsskærm, hvor hændelser fra forskellige systemer er synlige. I øjeblikket er to systemer forbundet til "paraplyen" - Zabbix og Prometheus, og et internt overvågningssystem af selve platformen.

Analytics-grænseflade. Enkelt overvågningsskærm.

Lanceret procesautomatisering

Overvågningshændelser udløste lanceringen af ​​prækonfigurerede handlinger - afsendelse af advarsler, kørsel af scripts, registrering/berigelse af hændelser - sidstnævnte blev ikke prøvet med denne specifikke klient, fordi i pilotprojektet var der ingen integration med servicedesk.

Handlingsindstillinger grænseflade. Send advarsler til Slack og genstart serveren.

Udvidet produktfunktionalitet

Når vi diskuterede automatiseringsscripts, bad klienten om bash-understøttelse og en grænseflade, hvori disse scripts bekvemt kunne konfigureres. Den nye version har gjort lidt mere (evnen til at skrive fuldgyldige logiske konstruktioner i Lua med understøttelse af cURL, SSH og SNMP) og implementeret funktionalitet, der giver dig mulighed for at administrere et scripts livscyklus (oprette, redigere, versionskontrol , slet og arkiver).

Interface til at arbejde med autohealing scripts. Server genstart script via SSH.

Vigtige fund

Under pilotprojektet blev der også lavet brugerhistorier, der forbedrer den nuværende funktionalitet og øger værdien for klienten, her er nogle af dem:

• implementere evnen til at videresende variabler direkte fra alarmen til autohealing-scriptet;
• tilføje autorisation til platformen via Active Directory.

Og vi fik flere globale udfordringer - at "bygge" produktet op med andre muligheder:

• automatisk konstruktion af en ressourceservicemodel baseret på ML snarere end regler og agenter (sandsynligvis den største udfordring nu);
• understøttelse af yderligere script- og logiksprog (og dette vil være JavaScript).

Efter min mening, den vigtigste tingHvad denne pilot viser er to ting:

1. Partnerskaber med kunden er nøglen til effektivitet, når effektiv kommunikation bygges på baggrund af ærlighed og åbenhed, og kunden bliver en del af et team, der opnår væsentlige resultater på kort tid.
2. Det er under ingen omstændigheder nødvendigt at "tilpasse" og bygge "krykker" - kun systemløsninger. Det er bedre at bruge lidt mere tid, men lav en systemløsning, som vil blive brugt af andre kunder. Det er i øvrigt, hvad der skete, plugin-systemet og elimineringen af ​​afhængighed af Azure gav yderligere værdi til andre klienter (hej, føderal lov 152).

Kilde: www.habr.com