Kial banko bezonas AIOps kaj tegmentan monitoradon, aŭ sur kio baziĝas klientrilatoj?

En publikaĵoj pri Habré, mi jam skribis pri mia sperto konstrui partnerecojn kun mia teamo (tie parolas pri kiel ellabori partneran interkonsenton kiam oni komencas novan komercon, por ke la komerco ne disfalu). Kaj nun mi ŝatus paroli pri kiel konstrui partnerecojn kun klientoj, ĉar sen ili nenio disfalos. Mi esperas, ke ĉi tiu artikolo estos utila al noventreprenoj, kiuj komencas vendi sian produkton al grandaj entreprenoj.

Nuntempe mi gvidas noventreprenon nomatan MONQ Cifereca laboratorio, kie mia teamo kaj mi disvolvas produkton por aŭtomatigi la procezojn por subteni kaj funkcii kompanian IT. Eniri la merkaton ne estas facila tasko kaj ni komencis per iom hejmtasko, ekzamenis merkatfakulojn, niajn partnerojn kaj efektivigis merkatsegmentadon. La ĉefa demando estis kompreni "kies doloroj ni povas plej bone resanigi?"

Bankoj transformis ĝin en la TOP 3-segmentojn. Kaj kompreneble, la unuaj en la listo estis Tinkoff kaj Sberbank. Kiam ni vizitis spertulojn pri banka merkato, ili diris: enkonduku vian produkton tie, kaj la vojo al la banka merkato estos malfermita. Ni provis eniri kaj tie kaj tie, sed malsukceso atendis nin ĉe Sberbank, kaj la uloj de Tinkoff montriĝis multe pli malfermaj al produktiva komunikado kun rusaj noventreprenoj (eble pro la fakto, ke Sber en tiu tempo) aĉetis preskaŭ miliardo da niaj okcidentaj konkurantoj). Ene de unu monato ni komencis pilotprojekton. Kiel ĝi okazis, legu plu.

Ni traktas problemojn pri funkciado kaj monitorado dum multaj jaroj, nun ni efektivigas nian produkton en la publika sektoro, en asekuro, en bankoj, en telekomunikaj kompanioj, unu efektivigo estis kun flugkompanio (antaŭ la projekto, ni eĉ ne faris pensu, ke aviado estis tia IT-dependa industrio, kaj Nun ni vere esperas, malgraŭ COVID, ke la kompanio aperos kaj ekflugos).

La produkto, kiun ni faras, apartenas al entreprena programaro, la segmento AIOps (Artificial Intelligence for IT Operations, aŭ ITOps). La ĉefaj celoj de efektivigado de tiaj sistemoj kiel la nivelo de proceza matureco en la kompanio pliiĝas:

1. Estingu fajrojn: identigu fiaskojn, purigu la fluon de atentigoj el derompaĵoj, asignu taskojn kaj okazaĵojn al la respondecaj;
2. Pliigi la efikecon de la IT-servo: redukti la tempon por solvi incidentojn, indiki la kaŭzojn de misfunkciadoj, pliigi la travideblecon de la IT-statuso;
3. Pliigu komercan efikecon: reduktu la kvanton de mana laboro, reduktu riskojn, pliigu klientan lojalecon.

Laŭ nia sperto, bankoj havas la jenajn "dolorojn" kun monitorado komuna kun ĉiuj grandaj IT-infrastrukturoj:

• “kiu scias kio”: ekzistas multaj teknikaj fakoj, preskaŭ ĉiuj havas almenaŭ unu monitorsistemon, kaj la plimulto havas pli ol unu;
• "svarmo de moskitoj" de atentigoj: ĉiu sistemo generas centojn kaj bombardas ĉiujn respondecajn per ili (foje ankaŭ inter fakoj). Estas malfacile konstante konservi la fokuson de kontrolo sur ĉiu sciigo; ilia urĝeco kaj graveco estas ebenigitaj pro la granda nombro;
• grandaj bankoj - sektoraj gvidantoj volas ne nur kontinue kontroli siajn sistemojn, scii kie estas misfunkciadoj, sed ankaŭ la reala magio de AI - por igi la sistemojn mem-monitora, mem-antaŭdi kaj mem-korekta.

Kiam ni venis al la unua renkontiĝo ĉe Tinkoff, oni tuj diris al ni, ke ili ne havas problemojn pri monitorado kaj nenio vundas ilin, kaj la ĉefa demando estis: "Kion ni povas proponi por tiuj, kiuj jam fartas bone?"

La konversacio estis longa, ni diskutis kiel iliaj mikroservoj estas konstruitaj, kiel fakoj funkcias, kiuj infrastrukturaj problemoj estas pli sentemaj, kiuj estas malpli sentemaj por uzantoj, kie estas la "blindaj punktoj", kaj kiuj estas iliaj celoj kaj SLA-oj.

Cetere, la SLA de la banko estas vere impresaj. Ekzemple, prioritato XNUMX reta havebleca okazaĵo povas daŭri nur kelkajn minutojn por solvi. La kosto de eraro kaj malfunkcio ĉi tie, kompreneble, estas impona.

Kiel rezulto, ni identigis plurajn areojn de kunlaboro:

1. la unua etapo estas ombrelmonitorado por pliigi la rapidecon de incidenta rezolucio
2. la dua etapo estas proceza aŭtomatigo por redukti riskojn kaj redukti kostojn por grimpi la IT-sekcion.

Pluraj "blankaj punktoj" povus esti pentritaj en la helaj koloroj de atentigoj nur per prilaborado de informoj de pluraj monitoraj sistemoj, ĉar estis maleble rekte preni metrikon; estis ankaŭ necese alcentrigi datumojn de malsamaj monitoraj sistemoj sur "unu ekrano" en ordo. por kompreni la ĝeneralan bildon de kio okazis. "Ombreloj" taŭgas por ĉi tiu tasko kaj ni plenumis ĉi tiujn postulojn tiam.

Tre grava afero, laŭ nia opinio, en rilatoj kun klientoj estas honesteco. Post la unua konversacio kaj kalkulo de la kosto de la permesilo, oni diris, ke ĉar la kosto estas tiel malalta, eble indas aĉeti permesilon tuj (kompare kun Dynatrace Klyuch-Astrom el la supra artikolo pri la verda banko, nia permesilo kostas ne trionon de miliardo, sed 12 mil rublojn monate por 1 gigabajto, por Sber ĝi kostus plurfoje pli malmultekoste). Sed ni tuj diris al ili, kion ni havas kaj kion ni ne havas. Eble venda reprezentanto de granda integristo povus diri "jes, ni povas fari ĉion, kompreneble aĉeti nian permesilon", sed ni decidis meti ĉiujn niajn kartojn sur la tablon. En la momento de la lanĉo, nia skatolo ne havis integriĝon kun Prometheus, kaj nova versio kun aŭtomatiga subsistemo estis liberigota, sed ni ankoraŭ ne sendis ĝin al klientoj.

La pilotprojekto komenciĝis, ĝiaj limoj estis determinitaj kaj ni ricevis 2 monatojn. La ĉefaj taskoj estis:

• preparu novan version de la platformo kaj deploji ĝin en la infrastrukturon de la banko
• konekti 2 monitorajn sistemojn (Zabbix kaj Prometheus);
• sendu sciigojn al respondeculoj en Slack kaj per SMS;
• ruli aŭtomatajn sanigajn skriptojn.

La unua monato de la pilotprojekto estis pasigita preparante novan version de la platformo en superrapida reĝimo por la bezonoj de la pilotprojekto. La nova versio tuj inkluzivas integriĝon kun Prometheus kaj aŭtomatan resanigon. Danke al nia evolua teamo, ili ne dormis dum pluraj noktoj, sed publikigis tion, kion ili promesis, sen maltrafi la limdatojn por aliaj antaŭe faritaj devontigoj.

Dum ni aranĝis la piloton, ni renkontis novan problemon, kiu povus fermi la projekton antaŭ la antaŭplano: por sendi atentigojn al tujmesaĝiloj kaj per SMS, ni bezonis enirajn kaj elirantajn konektojn al Microsoft Azure-serviloj (tiutempe ni uzis ĉi tiun platformon). por sendi atentigojn al Slack) kaj eksteran sendan servon SMS. Sed en ĉi tiu projekto, sekureco estis aparta fokuso. Konforme al la politiko de la banko, tiaj "truoj" ne povus esti malfermitaj en neniu cirkonstanco. Ĉio devis funkcii de fermita buklo. Oni proponis al ni uzi la API de niaj propraj internaj servoj, kiuj sendas atentigojn al Slack kaj per SMS, sed ni ne havis la ŝancon konekti tiajn servojn el la skatolo.

Vespero de debato kun la evolua teamo finiĝis per sukcesa serĉado de solvo. Traserĉinte la restaron, ni trovis unu taskon por kiu ni neniam havis sufiĉe da tempo kaj prioritato - krei kromprogramon por ke la efektivigteamoj aŭ la kliento povu skribi aldonaĵojn mem, vastigante la kapablojn de la platformo.

Sed restis al ni precize monato, dum kiu ni devis instali ĉion, agordi kaj disfaldi aŭtomatigon.

Laŭ Sergej, nia ĉefa arkitekto, necesas almenaŭ unu monato por efektivigi la aldonan sistemon.

Ni ne havis tempon...

Estis nur unu solvo - iru al la kliento kaj rakontu ĉion kiel ĝi estas. Diskutu la limdatan ŝanĝon kune. Kaj ĝi funkciis. Ni ricevis pliajn 2 semajnojn. Ili ankaŭ havis siajn proprajn limdatojn kaj internajn devontigojn montri rezultojn, sed ili havis 2 rezervajn semajnojn. En la fino, ni metis ĉion sur la linio. Estis neeble fuŝi. Honesteco kaj partnereca aliro denove pagis.

Kiel rezulto de la piloto, pluraj gravaj teknikaj rezultoj kaj konkludoj estis akiritaj:

Ni testis la novan funkcion por prilaborado de atentigoj

La deplojita sistemo komencis ĝuste ricevi atentigojn de Prometeo kaj grupigi ilin. Atentigoj pri la problemo de la kliento Prometheus flugis ĉiujn 30 sekundojn (grupiĝo laŭ tempo ne estas ebligita), kaj ni scivolis, ĉu eblus grupigi ilin en la "ombrelo" mem. Evidentiĝis, ke eblas - agordi la prilaboradon de atentigoj en la platformo estas efektivigita per skripto. Ĉi tio ebligas efektivigi preskaŭ ajnan logikon por prilabori ilin. Ni jam efektivigis norman logikon en la platformo en formo de ŝablonoj - se vi ne volas elpensi ion propran, vi povas uzi pretan.

Interfaco "Sinteza ellasilo". Agordi prilaboradon de atentigoj de konektitaj monitoraj sistemoj

Konstruis la staton de "sano" de la sistemo

Surbaze de alarmoj, monitoraj eventoj estis kreitaj, kiuj influis la sanon de agordaj unuoj (CUoj). Ni efektivigas rimedan servomodelon (RSM), kiu povas uzi aŭ internan CMDB aŭ konekti eksteran - dum la pilota projekto la kliento ne konektis sian propran CMDB.

Interfaco por labori kun la rimeda servo-modelo. Piloto RSM.

Nu, fakte, la kliento finfine havas ununuran monitoran ekranon, kie estas videblaj eventoj de malsamaj sistemoj. Nuntempe, du sistemoj estas konektitaj al la "ombrelo" - Zabbix kaj Prometheus, kaj interna monitora sistemo de la platformo mem.

Analiza interfaco. Ununura monitora ekrano.

Lanĉita proceza aŭtomatigo

Monitoraj eventoj ekigis la lanĉon de antaŭkonfiguritaj agoj - sendo de atentigoj, rulado de skriptoj, registrado/riĉigado de okazaĵoj - ĉi-lasta ne estis provita kun ĉi tiu aparta kliento, ĉar en la pilotprojekto ekzistis neniu integriĝo kun la servotablo.

Interfaco de ago-agordoj. Sendu atentigojn al Slack kaj rekomencu la servilon.

Pligrandigita produkta funkcieco

Dum diskutado de aŭtomatigaj skriptoj, la kliento petis bash-subtenon kaj interfacon en kiu ĉi tiuj skriptoj povus esti oportune agorditaj. La nova versio faris iom pli (la kapablo skribi plenrajtajn logikajn konstrukciojn en Lua kun subteno por cURL, SSH kaj SNMP) kaj efektivigis funkciecon, kiu ebligas al vi administri la vivociklon de skripto (krei, redakti, versio-kontrolo). , forigi kaj arkivi).

Interfaco por labori kun aŭtomataj resanigaj skriptoj. Servila rekomenca skripto per SSH.

Ŝlosilaj Trovoj

Dum la piloto, uzantrakontoj ankaŭ estis kreitaj, kiuj plibonigas la nunan funkciecon kaj pliigas valoron por la kliento, jen kelkaj el ili:

• efektivigi la kapablon plusendi variablojn rekte de la atentigo al la aŭtokuraca skripto;
• aldoni rajtigon al la platformo per Active Directory.

Kaj ni ricevis pli tutmondajn defiojn - "konstrui" la produkton kun aliaj kapabloj:

• aŭtomata konstruado de rimed-serva modelo bazita sur ML, prefere ol reguloj kaj agentoj (verŝajne la ĉefa defio nun);
• subteno por pliaj skribaj kaj logiklingvoj (kaj ĉi tio estos JavaScript).

Laŭ mi la plej gravaKion ĉi tiu piloto montras estas du aferoj:

1. Partnerecoj kun la kliento estas la ŝlosilo al efikeco, kiam efika komunikado estas konstruita surbaze de honesteco kaj malfermiteco, kaj la kliento fariĝas parto de teamo kiu atingas signifajn rezultojn en mallonga tempo.
2. Neniam necesas "agordi" kaj konstrui "lambastonojn" - nur sistemaj solvoj. Pli bone estas pasigi iom pli da tempo, sed faru sisteman solvon, kiu estos uzata de aliaj klientoj. Cetere, jen kio okazis, la kromprogramo kaj la forigo de dependeco de Azure provizis plian valoron al aliaj klientoj (saluton, Federacia Leĝo 152).

fonto: www.habr.com