Miks vajab pank AIOps-i ja vihmavarjumonitooringut ehk millel põhinevad kliendisuhted?

Habré väljaannetes kirjutasin juba oma kogemusest oma meeskonnaga partnerlussuhete loomisel ( siin räägib, kuidas koostada uue ettevõtte alustamisel seltsinguleping, et äri ei laguneks). Ja nüüd tahaksin rääkida sellest, kuidas luua partnerlussuhteid klientidega, sest ilma nendeta pole midagi lagunevat. Loodan, et see artikkel on kasulik alustavatele ettevõtetele, kes hakkavad oma toodet suurtele ettevõtetele müüma.

Hetkel juhin startupi nimega MONQ Digital lab, kus töötame koos meeskonnaga välja toodet ettevõtte IT toetamise ja opereerimise protsesside automatiseerimiseks. Turule sisenemine ei ole lihtne ülesanne ja alustasime väikese kodutööga, käisime läbi turuekspertide, oma partnerite ja viisime läbi turu segmenteerimise. Peamine küsimus oli mõista, "kelle valusid saame kõige paremini ravida?"

Pangad pääsesid TOP 3 segmenti. Ja loomulikult olid nimekirjas esimesed Tinkoff ja Sberbank. Kui käisime pangaturu ekspertide juures, öeldi: tutvustage seal oma toodet ja tee pangaturule on avatud. Üritasime siseneda nii sealt kui ka sealt, kuid Sberbankis ootas meid ebaõnnestumine ja Tinkoffi kutid osutusid palju avatumaks Venemaa idufirmadega produktiivseks suhtlemiseks (võib-olla tänu sellele, et Sber sel ajal ostetud peaaegu miljard meie lääne konkurenti). Kuu aja jooksul alustasime pilootprojektiga. Kuidas see juhtus, loe edasi.

Oleme tegutsemise ja monitooringu küsimustega tegelenud juba aastaid, nüüd juurutame oma toodet avalikus sektoris, kindlustuses, pankades, telekomifirmades, üks juurutus oli lennufirmaga (enne projekti me isegi ei teinud arvan, et lennundus oli nii IT-sõltuv tööstusharu, ja nüüd loodame väga, hoolimata COVID-ist, et ettevõte tekib ja tõuseb).

Meie toodetud toode kuulub ettevõtte tarkvara segmenti AIOps (tehisintellekt IT-toiminguteks ehk ITOps). Selliste süsteemide juurutamise peamised eesmärgid, kuna protsesside küpsusaste ettevõttes tõuseb:

1. Kustutage tulekahjud: tuvastage rikked, puhastage hoiatuste voog prahist, määrake vastutavatele isikutele ülesanded ja juhtumid;
2. Suurendada IT-teenuse efektiivsust: vähendada intsidentide lahendamise aega, näidata rikete põhjuseid, suurendada IT staatuse läbipaistvust;
3. Suurendage äritegevuse efektiivsust: vähendage käsitsitöö mahtu, vähendage riske, suurendage klientide lojaalsust.

Meie kogemuse kohaselt on pankadel kõigi suurte IT-taristutega ühised seirega seotud “valud”:

• "kes teab mida": tehnilisi osakondi on palju, peaaegu kõigil on vähemalt üks seiresüsteem ja enamikul rohkem kui üks;
• Hoiatuste “sääseparv”: iga süsteem genereerib sadu ja pommitab nendega (vahel ka osakondade vahel) kõiki vastutajaid. Iga teatise üle on raske pidevalt kontrolli fookust hoida, nende kiireloomulisus ja tähtsus on suure arvu tõttu ühtlustunud;
• suured pangad – sektori juhid ei taha mitte ainult oma süsteeme pidevalt jälgida, teada saada, kus on tõrkeid, vaid ka AI tõelist võlu – muuta süsteemid ise jälgima, ise ennustama ja ennast korrigeerima.

Esimesele kohtumisele Tinkoffi tulles öeldi kohe, et jälgimisega neil probleeme pole ja miski ei tee haiget ning põhiküsimus oli: "Mida saame pakkuda neile, kellel juba läheb hästi?"

Vestlus oli pikk, arutasime, kuidas nende mikroteenused on üles ehitatud, kuidas osakonnad töötavad, millised taristuprobleemid on tundlikumad, millised kasutajate jaoks vähem tundlikud, kus on “pimedad nurgad” ning millised on nende eesmärgid ja SLA-d.

Muide, panga SLA-d on tõesti muljetavaldavad. Näiteks võib XNUMX. prioriteediga võrgu käideldavusjuhtumi lahendamiseks kuluda vaid mõni minut. Vigade ja seisakute hind on siin muidugi muljetavaldav.

Selle tulemusena määrasime kindlaks mitu koostöövaldkonda:

1. esimene etapp on vihmavarju jälgimine, et suurendada intsidentide lahendamise kiirust
2. teine ​​etapp on protsesside automatiseerimine, et vähendada riske ja IT-osakonna skaleerimise kulusid.

Mitmeid “valgeid laike” sai märguannete erksates värvides värvida vaid mitme seiresüsteemi info töötlemisel, kuna otseselt ei olnud võimalik võtta mõõdikuid, samuti oli vaja tsentraliseerida erinevate seiresüsteemide andmed “ühele ekraanile”, et et mõista toimuva üldpilti. Selle ülesande jaoks sobivad “vihmavarjud” ja me täitsime siis need nõuded.

Väga oluline asi on meie arvates suhetes klientidega ausus. Pärast esimest vestlust ja litsentsi maksumuse arvutamist öeldi, et kuna hind on nii madal, siis võib-olla tasub litsents kohe ära osta (võrreldes Dynatrace Klyuch-Astromiga ülaltoodud rohelise panga artiklist, meie litsents ei maksa kolmandikku miljardit, vaid 12 tuhat rubla kuus 1 gigabaidi eest, Sberi jaoks maksaks see mitu korda odavamalt). Kuid me ütlesime neile kohe, mis meil on ja mis mitte. Võib-olla võiks suure integraatori müügiesindaja öelda "jah, me saame kõike teha, muidugi osta oma litsents", kuid otsustasime kõik kaardid lauale panna. Käivitamise ajal ei olnud meie kastil Prometheusega integreeritud ja uus versioon koos automatiseerimise alamsüsteemiga oli ilmumas, kuid me pole seda veel klientidele tarninud.

Algas pilootprojekt, määrati selle piirid ja saime 2 kuud. Peamised ülesanded olid:

• valmistada ette platvormi uus versioon ja juurutada see panga infrastruktuuri
• ühendada 2 seiresüsteemi (Zabbix ja Prometheus);
• saata teateid Slacki vastutavatele isikutele ja SMS-i teel;
• käivitage automaatse paranemise skriptid.

Pilootprojekti esimene kuu kulus pilootprojekti vajadusteks ülikiire režiimis platvormi uue versiooni ettevalmistamisele. Uus versioon sisaldab kohe integratsiooni Prometheusega ja automaatset paranemist. Tänu meie arendusmeeskonnale ei maganud nad mitu ööd, vaid vabastasid lubatu, jätmata vahele muude varem võetud kohustuste tähtaegu.

Pilootprogrammi seadistamise ajal tekkis meil uus probleem, mis võib projekti enne tähtaega sulgeda: kiirsõnumite saatmiseks ja SMS-i teel hoiatuste saatmiseks vajasime sissetulevaid ja väljaminevaid ühendusi Microsoft Azure'i serveritega (sel ajal kasutasime seda platvormi hoiatuste saatmiseks Slackile) ja välise saatmisteenuse SMS-i. Kuid selles projektis keskenduti eelkõige ohutusele. Panga poliitika kohaselt ei saanud selliseid “auke” mingil juhul avada. Kõik pidi toimima suletud ahelast. Meile pakuti kasutada meie enda siseteenuste API-d, mis saadavad teateid Slackile ja SMS-i teel, kuid meil ei olnud võimalust selliseid teenuseid karbist välja ühendada.

Arendusmeeskonnaga peetud aruteluõhtu lõppes eduka lahenduse otsimisega. Mahajäämust tuhnides leidsime ühe ülesande, mille jaoks meil kunagi ei jätkunud aega ja prioriteeti – luua pistikprogrammide süsteem, et juurutusmeeskonnad või klient saaksid ise lisandmooduleid kirjutada, laiendades platvormi võimalusi.

Meil oli aga jäänud täpselt kuu, mille jooksul pidime kõik installima, automaatika seadistama ja juurutama.

Meie peaarhitekti Sergei sõnul kulub pistiksüsteemi juurutamiseks vähemalt kuu.

Meil polnud aega...

Lahendus oli ainult üks – mine kliendi juurde ja räägi kõik nii nagu on. Arutage koos tähtaja nihkumist. Ja see töötas. Meile anti 2 nädalat lisaaega. Neil olid ka omad tähtajad ja sisemised kohustused tulemusi näidata, aga neil oli 2 reservnädalat. Lõpuks panime kõik joonele. Sassi ajada oli võimatu. Ausus ja partnerluskäsitlus tasus jälle ära.

Piloottöö tulemusena saadi mitmeid olulisi tehnilisi tulemusi ja järeldusi:

Testisime hoiatuste töötlemise uut funktsiooni

Kasutusele võetud süsteem hakkas Prometheuse hoiatusi õigesti vastu võtma ja neid rühmitama. Prometheuse kliendi teated probleemi kohta lendasid iga 30 sekundi järel (aja järgi rühmitamine pole lubatud) ja mõtlesime, kas neid oleks võimalik rühmitada "vihmavarju" endasse. Selgus, et see on võimalik – hoiatuste töötlemise seadistamine platvormil toimub skripti abil. See võimaldab nende töötlemiseks rakendada peaaegu igasugust loogikat. Oleme platvormil juba mallide kujul standardloogika juurutanud - kui te ei soovi midagi omaette välja mõelda, võite kasutada valmis loogikat.

"Sünteetiline päästik" liides. Ühendatud seiresüsteemide hoiatuste töötlemise seadistamine

Ehitas süsteemi "tervise" seisu

Hoiatuste põhjal loodi seiresündmused, mis mõjutasid konfiguratsiooniüksuste (CU) tervist. Rakendame ressursi-teenuse mudelit (RSM), mis võib kasutada kas sisemist CMDB-d või ühendada välist - pilootprojekti käigus ei ühendanud klient oma CMDB-d.

Liides ressursi-teenuse mudeliga töötamiseks. Piloot RSM.

Noh, tegelikult on kliendil lõpuks üksainus jälgimisekraan, kus on näha sündmustest erinevatest süsteemidest. Praegu on "vihmavarjuga" ühendatud kaks süsteemi - Zabbix ja Prometheus ning platvormi enda sisemine seiresüsteem.

Analyticsi liides. Üks jälgimisekraan.

Käivitatud protsesside automatiseerimine

Sündmuste jälgimine vallandas eelkonfigureeritud toimingute käivitamise - hoiatuste saatmine, skriptide käivitamine, juhtumite registreerimine/rikastamine - viimast selle konkreetse kliendiga ei proovitud, sest pilootprojektis ei olnud teeninduskeskusega integreerimist.

Toimingute seadete liides. Saatke Slackile märguanded ja taaskäivitage server.

Laiendatud toote funktsionaalsus

Automatiseerimisskriptide üle arutledes küsis klient bashi tuge ja liidest, kus neid skripte saaks mugavalt konfigureerida. Uues versioonis on tehtud veidi rohkem (võimalus kirjutada Luas täisväärtuslikke loogilisi konstruktsioone koos cURL, SSH ja SNMP toega) ning juurutatud funktsionaalsus, mis võimaldab hallata skripti elutsüklit (loomine, redigeerimine, versioonikontroll , kustutada ja arhiveerida).

Liides automaatse paranemisskriptidega töötamiseks. Serveri taaskäivitamise skript SSH kaudu.

Peamised järeldused

Piloodi käigus loodi ka kasutajalood, mis parandavad senist funktsionaalsust ja tõstavad väärtust kliendi jaoks, siin on mõned neist:

• rakendab võimalust edastada muutujad otse hoiatusest automaatse paranemisskripti;
• lisage platvormile luba Active Directory kaudu.

Ja me saime rohkem globaalseid väljakutseid – toote „ehitamine” muude võimalustega:

• ressursi-teenuse mudeli automaatne ehitamine, mis põhineb ML-il, mitte reeglitel ja agentidel (praegu ilmselt peamine väljakutse);
• täiendavate skriptimis- ja loogikakeelte tugi (ja see on JavaScript).

Minu arvates kõige tähtsam asiSee piloot näitab kahte asja:

1. Partnerlussuhted kliendiga on tulemuslikkuse võti, kui tõhus suhtlemine on üles ehitatud aususe ja avatuse alusel ning kliendist saab osa meeskonnast, mis saavutab lühikese ajaga olulisi tulemusi.
2. Mitte mingil juhul ei ole vaja "kohandada" ja ehitada "karkusid" - ainult süsteemsed lahendused. Parem on kulutada veidi rohkem aega, kuid teha süsteemne lahendus, mida teised kliendid kasutavad. Muide, nii juhtuski, pistikprogrammide süsteem ja Azure'ist sõltuvuse kaotamine andsid teistele klientidele lisaväärtust (tere, föderaalseadus 152).

Allikas: www.habr.com