Pse një bankë ka nevojë për AIO dhe monitorim ombrellë, apo mbi çfarë bazohen marrëdhëniet me klientët?

Në botimet në Habré, kam shkruar tashmë për përvojën time të ndërtimit të partneriteteve me ekipin tim (këtu flet se si të hartoni një marrëveshje partneriteti kur filloni një biznes të ri në mënyrë që biznesi të mos shpërbëhet). Dhe tani do të doja të flisja se si të ndërtojmë partneritete me klientët, pasi pa to nuk do të ketë asgjë për t'u shkatërruar. Shpresoj se ky artikull do të jetë i dobishëm për startup-et që kanë filluar t'u shesin produktin e tyre bizneseve të mëdha.

Aktualisht jam duke drejtuar një startup të quajtur MONQ Digital lab, ku ekipi im dhe unë po zhvillojmë një produkt për automatizimin e proceseve të mbështetjes dhe funksionimit të IT të korporatave. Hyrja në treg nuk është një detyrë e lehtë dhe ne filluam me pak detyra shtëpie, kaluam përmes ekspertëve të tregut, partnerëve tanë dhe bëmë segmentimin e tregut. Pyetja kryesore ishte të kuptonim se "dhimbjet e kujt mund t'i shërojmë më mirë?"

Bankat hynë në 3 segmentet TOP. Dhe sigurisht, të parët në listë ishin Tinkoff dhe Sberbank. Kur vizituam ekspertët e tregut bankar, ata thanë: prezantoni produktin tuaj atje dhe rruga për në tregun bankar do të jetë e hapur. Ne u përpoqëm të hynim si atje ashtu edhe atje, por dështimi na priste në Sberbank, dhe djemtë nga Tinkoff doli të ishin shumë më të hapur për komunikim produktiv me startup-et ruse (ndoshta për shkak të faktit se Sber në atë kohë blerë pothuajse një miliard nga konkurrentët tanë perëndimorë). Brenda një muaji filluam një projekt pilot. Si ndodhi, lexoni më tej.

Ne kemi shumë vite që merremi me çështje të operimit dhe monitorimit, tani po zbatojmë produktin tonë në sektorin publik, në sigurime, në banka, në kompanitë e telekomit, një zbatim ka qenë me një linjë ajrore (para projektit as mendoni se aviacioni ishte një industri kaq e varur nga IT, dhe tani ne me të vërtetë shpresojmë, pavarësisht COVID, që kompania të shfaqet dhe të ngrihet).

Produkti që ne bëjmë i përket softuerit të ndërmarrjes, segmentit AIOps (Inteligjencë Artificiale për Operacionet e IT, ose ITOps). Qëllimet kryesore të zbatimit të sistemeve të tilla si rritja e nivelit të pjekurisë së procesit në kompani:

1. Fikni zjarret: identifikoni dështimet, pastroni rrymën e alarmeve nga mbeturinat, caktoni detyra dhe incidente personave përgjegjës;
2. Rritja e efikasitetit të shërbimit të IT: zvogëloni kohën për zgjidhjen e incidenteve, tregoni shkaqet e dështimeve, rrisni transparencën e statusit të TI-së;
3. Rritja e efikasitetit të biznesit: zvogëloni sasinë e punës manuale, zvogëloni rreziqet, rrisni besnikërinë e klientit.

Në përvojën tonë, bankat kanë këto “dhimbje” me monitorimin të përbashkët me të gjitha infrastrukturat e mëdha të IT-së:

• “kush e di çfarë”: ka shumë departamente teknike, pothuajse të gjithë kanë të paktën një sistem monitorimi dhe shumica kanë më shumë se një;
• "Grumbull mushkonjash" alarmesh: çdo sistem gjeneron qindra dhe bombardon me to të gjithë ata që janë përgjegjës (nganjëherë edhe ndërmjet departamenteve). Është e vështirë të ruhet vazhdimisht fokusi i kontrollit në çdo njoftim, urgjenca dhe rëndësia e tyre është e niveluar për shkak të numrit të madh;
• bankat e mëdha - drejtues të sektorëve duan jo vetëm të monitorojnë vazhdimisht sistemet e tyre, të dinë se ku ka dështime, por edhe magjinë e vërtetë të AI - t'i bëjnë sistemet të vetë-monitorohen, të parashikojnë dhe të korrigjohen vetë.

Kur erdhëm në takimin e parë në Tinkoff, na thanë menjëherë se nuk kishin probleme me monitorimin dhe asgjë nuk i lëndonte, dhe pyetja kryesore ishte: "Çfarë mund të ofrojmë për ata që tashmë po bëjnë mirë?"

Biseda ishte e gjatë, diskutuam se si ndërtohen mikroshërbimet e tyre, si funksionojnë departamentet, cilat probleme infrastrukturore janë më të ndjeshme, cilat janë më pak të ndjeshme për përdoruesit, ku janë "pikat e verbër" dhe cilat janë qëllimet dhe SLA-të e tyre.

Nga rruga, SLA-të e bankës janë vërtet mbresëlënëse. Për shembull, një incident i disponueshmërisë së rrjetit me prioritet 1 mund të marrë vetëm disa minuta për t'u zgjidhur. Kostoja e gabimit dhe joproduktive këtu, natyrisht, është mbresëlënëse.

Si rezultat, ne identifikuam disa fusha bashkëpunimi:

1. Faza e parë është monitorimi me ombrellë për të rritur shpejtësinë e zgjidhjes së incidentit
2. Faza e dytë është automatizimi i procesit për të reduktuar rreziqet dhe për të zvogëluar kostot për shkallëzimin e departamentit të IT.

Disa "njolla të bardha" mund të pikturoheshin me ngjyrat e ndezura të sinjalizimeve vetëm duke përpunuar informacionin nga disa sisteme monitorimi, pasi ishte e pamundur të merreshin drejtpërdrejt metrikat; ishte gjithashtu e nevojshme të centralizoheshin të dhënat nga sisteme të ndryshme monitorimi në "një ekran" në mënyrë që për të kuptuar pamjen e përgjithshme të asaj që po ndodhte. “Cadra” janë të përshtatshme për këtë detyrë dhe ne i plotësuam këto kërkesa atëherë.

Një gjë shumë e rëndësishme, për mendimin tonë, në marrëdhëniet me klientët është ndershmëria. Pas bisedës së parë dhe llogaritjes së kostos së licencës, u tha se meqenëse kostoja është kaq e ulët, mund të ia vlente të blini një licencë menjëherë (krahasuar me Dynatrace Klyuch-Astrom nga artikulli i mësipërm për bankën e gjelbër, tonë licenca kushton jo një të tretën e një miliardi, por 12 mijë rubla në muaj për 1 gigabajt, për Sber do të kushtonte disa herë më lirë). Por ne menjëherë u thamë atyre se çfarë kemi dhe çfarë nuk kemi. Ndoshta një përfaqësues i shitjeve nga një integrues i madh mund të thotë "po, ne mund të bëjmë gjithçka, natyrisht të blejmë licencën tonë", por ne vendosëm t'i hedhim të gjitha kartat tona në tryezë. Në momentin e lansimit, kutia jonë nuk kishte integrim me Prometheus dhe një version i ri me një nënsistem automatizimi ishte gati të dilte, por ne nuk e kemi dërguar ende te klientët.

Filloi projekti pilot, u përcaktuan kufijtë dhe na dhanë 2 muaj. Detyrat kryesore ishin:

• përgatitni një version të ri të platformës dhe vendoseni atë në infrastrukturën e bankës
• lidhë 2 sisteme monitorimi (Zabbix dhe Prometheus);
• dërgoni njoftime për përgjegjësit në Slack dhe me SMS;
• ekzekutoni skriptet e shërimit automatik.

Muaji i parë i projektit pilot kaloi duke përgatitur një version të ri të platformës në modalitetin super të shpejtë për nevojat e projektit pilot. Versioni i ri përfshin menjëherë integrimin me Prometheus dhe auto-shërimin. Falë ekipit tonë të zhvillimit, ata nuk fjetën për disa netë, por lëshuan atë që premtuan pa humbur afatet për angazhimet e tjera të bëra më parë.

Ndërkohë që po vendosnim pilotin, hasëm një problem të ri që mund ta mbyllte projektin përpara afatit: për të dërguar sinjalizime te mesazherët e çastit dhe përmes SMS, na duheshin lidhje hyrëse dhe dalëse me serverët Microsoft Azure (në atë kohë ne përdornim këtë platformë për të dërguar sinjalizime te Slack) dhe një shërbim të jashtëm dërgimi SMS. Por në këtë projekt, siguria ishte një fokus i veçantë. Në përputhje me politikën e bankës, "vrima" të tilla nuk mund të hapeshin në asnjë rrethanë. Gjithçka duhej të funksiononte nga një lak i mbyllur. Na u ofrua të përdornim API-në e shërbimeve tona të brendshme që dërgojnë sinjalizime në Slack dhe përmes SMS, por ne nuk patëm mundësinë të lidhnim shërbime të tilla jashtë kutisë.

Një mbrëmje debati me ekipin e zhvillimit përfundoi me një kërkim të suksesshëm për një zgjidhje. Pasi hulumtuam në grumbullimin e mbetur, gjetëm një detyrë për të cilën nuk kishim kurrë kohë dhe prioritet të mjaftueshëm - të krijonim një sistem plug-in në mënyrë që ekipet e zbatimit ose klienti të mund të shkruanin vetë shtesa, duke zgjeruar aftësitë e platformës.

Por na kishte mbetur saktësisht një muaj, gjatë të cilit duhej të instalonim gjithçka, të konfiguronim dhe të vendosnim automatizimin.

Sipas Sergeit, arkitektit tonë kryesor, duhet të paktën një muaj për të zbatuar sistemin plug-in.

Nuk kishim kohë...

Kishte vetëm një zgjidhje - shkoni te klienti dhe tregoni gjithçka ashtu siç është. Diskutoni së bashku ndryshimin e afatit. Dhe funksionoi. Na dhanë 2 javë shtesë. Ata kishin edhe afatet dhe detyrimet e tyre të brendshme për të treguar rezultate, por kishin 2 javë rezervë. Në fund, ne vendosëm gjithçka në linjë. Ishte e pamundur të ngatërrohesh. Ndershmëria dhe qasja e partneritetit u shpaguan përsëri.

Si rezultat i pilotimit, u morën disa rezultate dhe përfundime të rëndësishme teknike:

Ne testuam funksionalitetin e ri për përpunimin e sinjalizimeve

Sistemi i vendosur filloi të marrë saktë sinjalizimet nga Prometheus dhe t'i grupojë ato. Alarmet për problemin nga klienti Prometheus fluturonin çdo 30 sekonda (grupimi sipas kohës nuk është i aktivizuar) dhe ne po pyesnim nëse do të ishte e mundur t'i gruponim në vetë "ombrellën". Doli se është e mundur - vendosja e përpunimit të sinjalizimeve në platformë zbatohet nga një skenar. Kjo bën të mundur zbatimin e pothuajse çdo logjike për përpunimin e tyre. Ne kemi zbatuar tashmë logjikën standarde në platformë në formën e shablloneve - nëse nuk doni të dilni me diçka tuajën, mund të përdorni një të gatshme.

Ndërfaqja "Shkasë sintetike". Vendosja e përpunimit të sinjalizimeve nga sistemet e lidhura të monitorimit

Ndërtoi gjendjen e "shëndetit" të sistemit

Bazuar në sinjalizimet, u krijuan ngjarje monitorimi që ndikuan në shëndetin e njësive të konfigurimit (CU). Ne po zbatojmë një model të shërbimit të burimeve (RSM), i cili mund të përdorë ose një CMDB të brendshme ose të lidhë një të jashtme - gjatë projektit pilot klienti nuk e lidhi CMDB-në e tij.

Ndërfaqja për të punuar me modelin burim-shërbim. RSM pilot.

Epo, në fakt, klienti më në fund ka një ekran të vetëm monitorimi, ku ngjarjet nga sisteme të ndryshme janë të dukshme. Aktualisht, dy sisteme janë të lidhura me "ombrellën" - Zabbix dhe Prometheus, dhe një sistem i brendshëm monitorimi i vetë platformës.

Ndërfaqja e analitikës. Ekran i vetëm monitorues.

Filloi automatizimi i procesit

Monitorimi i ngjarjeve shkaktoi nisjen e veprimeve të para-konfiguruara - dërgimi i sinjalizimeve, ekzekutimi i skripteve, regjistrimi/pasurimi i incidenteve - ky i fundit nuk u provua me këtë klient të veçantë, sepse në projektin pilot nuk kishte integrim me tavolinën e shërbimit.

Ndërfaqja e cilësimeve të veprimit. Dërgoni alarme te Slack dhe rindizni serverin.

Funksionaliteti i zgjeruar i produktit

Kur diskutonim skriptet e automatizimit, klienti kërkoi mbështetje bash dhe një ndërfaqe në të cilën këto skripta mund të konfiguroheshin me lehtësi. Versioni i ri ka bërë pak më shumë (aftësia për të shkruar konstruksione logjike të plota në Lua me mbështetje për cURL, SSH dhe SNMP) dhe funksionalitet të implementuar që ju lejon të menaxhoni ciklin jetësor të një skripti (krijoni, modifikoni, kontrolloni versionin , fshini dhe arkivoni).

Ndërfaqe për të punuar me skriptet e shërimit automatik. Skripti i rindezjes së serverit nëpërmjet SSH.

Gjetjet kryesore

Gjatë pilotimit, u krijuan edhe histori të përdoruesve që përmirësojnë funksionalitetin aktual dhe rrisin vlerën për klientin, këtu janë disa prej tyre:

• të zbatojë aftësinë për të përcjellë variablat drejtpërdrejt nga alarmi në skriptin e vetëshërimit;
• shtoni autorizimin në platformë përmes Active Directory.

Dhe ne morëm më shumë sfida globale - për të "ndërtuar" produktin me aftësi të tjera:

• ndërtimi automatik i një modeli shërbimi burimesh bazuar në ML, në vend të rregullave dhe agjentëve (ndoshta sfida kryesore tani);
• mbështetje për gjuhë shtesë skriptimi dhe logjike (dhe kjo do të jetë JavaScript).

Sipas mendimit tim, më e rëndësishmjaAjo që tregon ky pilot është dy gjëra:

1. Partneritetet me klientin janë çelësi i efektivitetit, kur komunikimi efektiv ndërtohet mbi bazën e ndershmërisë dhe çiltërsisë, dhe klienti bëhet pjesë e një ekipi që arrin rezultate të rëndësishme në një kohë të shkurtër.
2. Në asnjë rrethanë nuk është e nevojshme të "përshtatni" dhe të ndërtoni "paterica" ​​- vetëm zgjidhje të sistemit. Është më mirë të shpenzoni pak më shumë kohë, por bëni një zgjidhje sistemi që do të përdoret nga klientët e tjerë. Nga rruga, kjo është ajo që ndodhi, sistemi i shtojcave dhe eliminimi i varësisë nga Azure u dha vlerë shtesë klientëve të tjerë (përshëndetje, Ligji Federal 152).

Burimi: www.habr.com