Af hverju þarf banki AIOps og regnhlífareftirlit, eða á hverju byggjast viðskiptatengsl?

Í ritum um Habré skrifaði ég þegar um reynslu mína af því að byggja upp samstarf við teymið mitt (hér fjallar um hvernig eigi að semja samstarfssamning við stofnun nýs fyrirtækis svo reksturinn falli ekki í sundur). Og nú langar mig að tala um hvernig á að byggja upp samstarf við viðskiptavini, þar sem án þeirra verður ekkert að falla í sundur. Ég vona að þessi grein muni nýtast sprotafyrirtækjum sem eru að byrja að selja vöru sína til stórra fyrirtækja.

Ég er núna að stýra sprotafyrirtæki sem heitir MONQ Digital Lab, þar sem ég og teymið mitt erum að þróa vöru til að gera sjálfvirkan ferla til að styðja og reka upplýsingatækni fyrirtækja. Að komast inn á markaðinn er ekki auðvelt verkefni og við byrjuðum á smá heimavinnu, fórum í gegnum markaðssérfræðinga, samstarfsaðila okkar og gerðum markaðsskiptingu. Aðalspurningin var að skilja "hvers sársauka getum við best læknað?"

Bankar komust í TOP 3 hlutina. Og auðvitað voru fyrstir á listanum Tinkoff og Sberbank. Þegar við heimsóttum sérfræðinga á bankamarkaði sögðu þeir: kynntu vöruna þína þar og leiðin inn á bankamarkaðinn verður opin. Við reyndum að komast inn bæði þar og þar, en bilun beið okkar í Sberbank og strákarnir frá Tinkoff reyndust vera mun opnari fyrir afkastamiklum samskiptum við rússnesk sprotafyrirtæki (kannski vegna þess að Sber á þeim tíma keypti næstum milljarður af vestrænum keppinautum okkar). Innan mánaðar hófum við tilraunaverkefni. Hvernig það gerðist, lestu áfram.

Við höfum verið að fást við rekstrar- og eftirlitsmál í mörg ár, nú erum við að innleiða vöruna okkar hjá hinu opinbera, í tryggingum, í bönkum, í fjarskiptafyrirtækjum, ein framkvæmd var hjá flugfélagi (fyrir verkefnið gerðum við ekki einu sinni held að flugið hafi verið svo upplýsingatækniháð iðnaður og nú vonum við svo sannarlega, þrátt fyrir COVID, að fyrirtækið muni koma fram og taka við).

Varan sem við framleiðum tilheyrir fyrirtækjahugbúnaði, AIOps (gervigreind fyrir upplýsingatæknirekstur, eða ITOps) hlutanum. Meginmarkmiðin með innleiðingu slíkra kerfa þar sem ferlaþroski eykst í fyrirtækinu:

1. Slökkva elda: greina bilanir, hreinsa straum viðvarana frá rusli, úthluta verkefnum og atvikum til þeirra sem bera ábyrgð;
2. Auka skilvirkni upplýsingatækniþjónustunnar: draga úr tíma til að leysa atvik, benda á orsakir bilana, auka gagnsæi upplýsingatæknistöðunnar;
3. Auka skilvirkni fyrirtækja: draga úr magni handavinnu, draga úr áhættu, auka tryggð viðskiptavina.

Reynsla okkar er að bankar hafa eftirfarandi „sársauka“ við eftirlit sameiginlegt með öllum stórum upplýsingatækniinnviðum:

• „hver veit hvað“: það eru margar tæknideildir, næstum allir eru með að minnsta kosti eitt eftirlitskerfi og flestar hafa fleiri en eitt;
• „moskítósveimur“ af viðvörunum: hvert kerfi býr til hundruð og sprengir alla þá sem bera ábyrgð á þeim (stundum líka á milli deilda). Erfitt er að halda stöðugt áherslu eftirlitsins á hverri tilkynningu, brýnt og mikilvægi þeirra er jafnt vegna fjöldans;
• stórir bankar - leiðtogar geirans vilja ekki aðeins fylgjast stöðugt með kerfum sínum, vita hvar það eru bilanir, heldur einnig raunverulega töfra gervigreindar - til að láta kerfin fylgjast með sjálfum sér, spá fyrir um sjálf og leiðrétta þau.

Þegar við komum á fyrsta fundinn hjá Tinkoff var okkur strax sagt að þeir ættu ekki í neinum vandræðum með að fylgjast með og ekkert skaðaði þá og aðalspurningin var: „Hvað getum við boðið þeim sem nú þegar hafa það gott?

Samtalið var langt, við ræddum hvernig örþjónustur þeirra eru byggðar upp, hvernig deildir virka, hvaða innviðavandamál eru viðkvæmari, hver eru minna viðkvæm fyrir notendur, hvar eru „blindu blettirnir“ og hver eru markmið þeirra og SLA.

Við the vegur, SLAs bankans eru virkilega áhrifamikill. Til dæmis gæti forgang XNUMX netatvik aðeins tekið nokkrar mínútur að leysa. Kostnaður við villur og niður í miðbæ hér er auðvitað áhrifamikill.

Í kjölfarið bentum við á nokkur samstarfssvið:

1. Fyrsta stigið er regnhlífaeftirlit til að auka hraða við úrlausn atvika
2. Annað stig er sjálfvirkni ferla til að draga úr áhættu og draga úr kostnaði við að stækka upplýsingatæknideildina.

Aðeins var hægt að mála nokkra „hvíta bletti“ í skærum litum viðvarana með því að vinna úr upplýsingum frá nokkrum vöktunarkerfum, þar sem ómögulegt var að taka mælikvarða beint; það var líka nauðsynlegt að miðstýra gögnum frá mismunandi vöktunarkerfum á „einn skjá“ til þess að skilja heildarmyndina af því sem var að gerast. „Regnhlífar“ henta þessu verkefni og við uppfylltum þessar kröfur þá.

Mjög mikilvægur hlutur, að okkar mati, í samskiptum við viðskiptavini er heiðarleiki. Eftir fyrsta samtalið og útreikninga á kostnaði við leyfið var sagt að þar sem kostnaðurinn er svo lítill gæti verið þess virði að kaupa leyfi strax (samanborið við Dynatrace Klyuch-Astrom úr greininni hér að ofan um græna bankann, okkar leyfi kostar ekki þriðjung úr milljarði, heldur 12 þúsund rúblur á mánuði fyrir 1 gígabæt, fyrir Sber myndi það kosta nokkrum sinnum ódýrara). En við sögðum þeim strax hvað við eigum og hvað ekki. Kannski gæti sölufulltrúi frá stórum samþættingaraðila sagt „já, við getum allt, auðvitað keypt leyfið okkar,“ en við ákváðum að leggja öll spilin á borðið. Þegar kassi okkar var settur á markað var ekki samþætting við Prometheus og ný útgáfa með sjálfvirkni undirkerfi var að fara að koma út, en við höfum ekki sent það til viðskiptavina ennþá.

Tilraunaverkefnið hófst, mörk þess voru ákveðin og við fengum 2 mánuði. Helstu verkefnin voru:

• undirbúa nýja útgáfu af pallinum og setja hana í innviði bankans
• tengja 2 eftirlitskerfi (Zabbix og Prometheus);
• senda tilkynningar til ábyrgðarmanna í Slack og með SMS;
• keyra sjálfvirka heilunarforskriftir.

Fyrsti mánuður tilraunaverkefnisins fór í að undirbúa nýja útgáfu af pallinum í ofurhraða ham fyrir þarfir tilraunaverkefnisins. Nýja útgáfan inniheldur strax samþættingu við Prometheus og sjálfvirka heilun. Þökk sé þróunarteymi okkar, sváfu þeir ekki í nokkrar nætur, en slepptu því sem þeir lofuðu án þess að missa af fresti fyrir aðrar áður gerðar skuldbindingar.

Á meðan við vorum að setja upp tilraunaverkefnið lentum við í nýju vandamáli sem gæti lokað verkefninu á undan áætlun: til að senda tilkynningar til spjalls og með SMS þurftum við inn- og úttengingar við Microsoft Azure netþjóna (á þeim tíma notuðum við þennan vettvang til að senda tilkynningar til Slack) og utanaðkomandi sendiþjónustu SMS. En í þessu verkefni var öryggi sérstaklega í brennidepli. Í samræmi við stefnu bankans var ekki hægt að opna slík „göt“ undir neinum kringumstæðum. Allt varð að vinna úr lokaðri lykkju. Okkur bauðst að nota API eigin innri þjónustu sem sendir tilkynningar til Slack og með SMS, en við höfðum ekki möguleika á að tengja slíka þjónustu upp úr kassanum.

Umræðukvöldi með þróunarteymi lauk með farsælli leit að lausn. Eftir að hafa grúfað í gegnum eftirstöðvarnar fundum við eitt verkefni sem við höfðum aldrei nægan tíma og forgang til - að búa til viðbætur kerfi þannig að innleiðingarteymi eða viðskiptavinur gæti skrifað viðbætur sjálfir, aukið möguleika vettvangsins.

En við áttum nákvæmlega mánuð eftir, þar sem við þurftum að setja allt upp, stilla og beita sjálfvirkni.

Að sögn Sergei, yfirarkitekts okkar, tekur það að minnsta kosti mánuð að innleiða viðbótakerfið.

Við höfðum ekki tíma...

Það var aðeins ein lausn - farðu til viðskiptavinarins og segðu allt eins og það er. Ræddu saman frestvaktina. Og það tókst. Við fengum 2 vikur í viðbót. Þeir höfðu líka sína eigin fresti og innri skyldur til að sýna niðurstöður, en þeir höfðu 2 varavikur. Á endanum settum við allt á blað. Það var ómögulegt að klúðra. Heiðarleiki og samstarfsnálgun skilaði sér aftur.

Í kjölfar tilraunarinnar fengust nokkrar mikilvægar tæknilegar niðurstöður og niðurstöður:

Við prófuðum nýja virkni til að vinna úr viðvörunum

Kerfið sem notað var byrjaði að taka á móti tilkynningum frá Prometheus og flokka þær. Viðvaranir um vandamálið frá Prometheus viðskiptavininum voru að fljúga á 30 sekúndna fresti (flokkun eftir tíma er ekki virkjuð) og við vorum að velta fyrir okkur hvort það væri hægt að flokka þær í „regnhlífina“ sjálfa. Það kom í ljós að það er mögulegt - uppsetning á vinnslu áminninga á pallinum er útfærð með handriti. Þetta gerir það mögulegt að innleiða nánast hvaða rökfræði sem er til að vinna úr þeim. Við höfum þegar innleitt staðlaða rökfræði á pallinum í formi sniðmáta - ef þú vilt ekki koma með eitthvað þitt eigið geturðu notað tilbúið.

„Tilbúið kveikja“ viðmót. Uppsetning á viðvörunum frá tengdum vöktunarkerfum

Byggði upp ástand „heilsu“ kerfisins

Byggt á viðvörunum voru vöktunarviðburðir búnir til sem höfðu áhrif á heilsu stillingareininga (CUs). Við erum að innleiða auðlindaþjónustulíkan (RSM), sem getur notað annað hvort innri CMDB eða tengt ytri - meðan á tilraunaverkefninu stóð tengdi viðskiptavinurinn ekki eigin CMDB.

Viðmót til að vinna með auðlindaþjónustulíkanið. Flugmaður RSM.

Jæja, í raun hefur viðskiptavinurinn loksins einn vöktunarskjá, þar sem atburðir frá mismunandi kerfum eru sýnilegir. Sem stendur eru tvö kerfi tengd „regnhlífinni“ - Zabbix og Prometheus, og innra eftirlitskerfi pallsins sjálfs.

Greiningarviðmót. Einn eftirlitsskjár.

Hleypt af stokkunum sjálfvirkni ferla

Eftirlitsatburðir komu af stað forstilltum aðgerðum - sendingu áminninga, keyrslu forskrifta, skráningu/auðgun atvika - hið síðarnefnda var ekki reynt með þessum tiltekna viðskiptavini, vegna þess að í tilraunaverkefninu var engin samþætting við þjónustuborðið.

Aðgerðarstillingarviðmót. Sendu tilkynningar til Slack og endurræstu netþjóninn.

Aukin virkni vörunnar

Þegar rætt var um sjálfvirkni forskriftir bað viðskiptavinurinn um bash stuðning og viðmót þar sem hægt væri að stilla þessar forskriftir á þægilegan hátt. Nýja útgáfan hefur gert aðeins meira (getan til að skrifa fullgildar rökfræðilegar byggingar í Lua með stuðningi fyrir cURL, SSH og SNMP) og innleitt virkni sem gerir þér kleift að stjórna lífsferli handrits (búa til, breyta, útgáfustýringu , eyða og setja í geymslu).

Viðmót til að vinna með sjálfvirka forskriftir. Endurræstu forskrift miðlara í gegnum SSH.

Lykilatriði

Í tilraunaverkefninu voru einnig búnar til notendasögur sem bæta núverandi virkni og auka virði fyrir viðskiptavininn, hér eru nokkrar þeirra:

• innleiða getu til að senda breytur beint frá viðvöruninni yfir í sjálfvirka heilunarforritið;
• bæta við heimild til pallsins í gegnum Active Directory.

Og við fengum fleiri alþjóðlegar áskoranir - að „byggja upp“ vöruna með öðrum getu:

• sjálfvirk smíði auðlindaþjónustulíkans sem byggir á ML, frekar en reglum og umboðsmönnum (líklega helsta áskorunin núna);
• stuðningur við viðbótar forskriftar- og rökfræðimál (og þetta verður JavaScript).

Að mínu mati, mikilvægasti hluturinnÞað sem þessi flugmaður sýnir er tvennt:

1. Samstarf við viðskiptavininn er lykillinn að skilvirkni þegar skilvirk samskipti eru byggð á grundvelli heiðarleika og hreinskilni og viðskiptavinurinn verður hluti af teymi sem nær umtalsverðum árangri á stuttum tíma.
2. Undir engum kringumstæðum er nauðsynlegt að „sérsníða“ og byggja „hækjur“ - aðeins kerfislausnir. Það er betra að eyða aðeins meiri tíma, en búa til kerfislausn sem verður notuð af öðrum viðskiptavinum. Við the vegur, þetta er það sem gerðist, viðbótakerfið og afnám ósjálfstæðis á Azure veitti öðrum viðskiptavinum aukið gildi (halló, alríkislög 152).

Heimild: www.habr.com