Zašto banka treba AIOps i krovni nadzor ili na čemu se temelje odnosi s klijentima?

U publikacijama na Habréu već sam pisao o svom iskustvu izgradnje partnerstva sa svojim timom (здесь govori o tome kako sastaviti ortački ugovor pri pokretanju novog posla da se posao ne raspadne). A sada bih želio razgovarati o tome kako izgraditi partnerstvo s klijentima, jer bez njih se ništa neće raspasti. Nadam se da će ovaj članak biti koristan startupima koji počinju prodavati svoje proizvode velikim tvrtkama.

Trenutno sam na čelu startupa pod nazivom MONQ Digital lab, gdje moj tim i ja razvijamo proizvod za automatizaciju procesa podrške i rada korporativnog IT-a. Ulazak na tržište nije lak zadatak i krenuli smo s malom zadaćom, prošli smo tržišne stručnjake, naše partnere i izvršili segmentaciju tržišta. Glavno pitanje bilo je razumjeti "čije boli možemo najbolje izliječiti?"

Banke su ušle u TOP 3 segmenta. I naravno, prvi na listi bili su Tinkoff i Sberbank. Kad smo bili kod stručnjaka za bankarsko tržište, rekli su: uvedite tamo svoj proizvod i put na bankarsko tržište će vam biti otvoren. Pokušali smo ući i tamo i tamo, ali u Sberbanku nas je čekao neuspjeh, a dečki iz Tinkoffa pokazali su se mnogo otvorenijim za produktivnu komunikaciju s ruskim startupima (možda zbog činjenice da je Sber u to vrijeme kupio gotovo milijardu naših zapadnih konkurenata). Unutar mjesec dana započeli smo pilot projekt. Kako se to dogodilo, čitajte dalje.

Problemima rada i nadzora bavimo se dugi niz godina, sada implementiramo naš proizvod u javnom sektoru, u osiguranju, u bankama, u telekom kompanijama, jedna implementacija je bila kod zrakoplovne kompanije (prije projekta nismo ni mislimo da je zrakoplovstvo bilo industrija ovisna o IT-u, a sada se stvarno nadamo, unatoč COVID-u, da će se tvrtka pojaviti i poletjeti).

Proizvod koji izrađujemo pripada poslovnom softveru, segmentu AIOps (Artificial Intelligence for IT Operations, ili ITOps). Glavni ciljevi implementacije takvih sustava kao što je povećanje razine zrelosti procesa u poduzeću:

1. Ugasite požare: identificirajte kvarove, očistite tok upozorenja od krhotina, dodijelite zadatke i incidente odgovornima;
2. Povećati učinkovitost IT usluge: smanjiti vrijeme rješavanja incidenata, ukazati na uzroke kvarova, povećati transparentnost IT statusa;
3. Povećajte učinkovitost poslovanja: smanjite količinu ručnog rada, smanjite rizike, povećajte lojalnost kupaca.

Prema našem iskustvu, banke imaju sljedeće "bolove" s praćenjem zajedničke svim velikim IT infrastrukturama:

• “tko zna što”: postoji mnogo tehničkih odjela, gotovo svi imaju barem jedan sustav nadzora, a većina ih ima više od jednog;
• “roj komaraca” upozorenja: svaki sustav generira stotine i njima bombardira sve odgovorne (ponekad i između odjela). Teško je konstantno održavati fokus kontrole na svakoj obavijesti, njihova hitnost i važnost nivelirana je zbog velikog broja;
• velike banke - lideri sektora žele ne samo kontinuirano nadzirati svoje sustave, znati gdje postoje kvarovi, već i pravu čaroliju umjetne inteligencije - natjerati sustave da se sami nadziru, sami predviđaju i sami ispravljaju.

Kad smo došli na prvi sastanak u Tinkoffu, odmah nam je rečeno da nemaju problema s praćenjem i da ih ništa ne boli, a glavno pitanje je bilo: “Što možemo ponuditi onima kojima je već dobro?”

Razgovor je bio dug, razgovarali smo o tome kako su izgrađeni njihovi mikroservisi, kako funkcioniraju odjeli, koji su infrastrukturni problemi osjetljiviji, koji su manje osjetljivi za korisnike, gdje su “slijepe točke”, te koji su im ciljevi i SLA-ovi.

Usput, ugovori o razini usluge banke stvarno su impresivni. Na primjer, rješavanje incidenta dostupnosti mreže s prioritetom XNUMX može trajati samo nekoliko minuta. Cijena pogreške i zastoja ovdje je, naravno, impresivna.

Kao rezultat toga, identificirali smo nekoliko područja suradnje:

1. prva faza je krovni nadzor kako bi se povećala brzina rješavanja incidenta
2. druga faza je automatizacija procesa kako bi se smanjili rizici i smanjili troškovi za skaliranje IT odjela.

Nekoliko "bijelih mrlja" moglo se obojiti u jarke boje upozorenja samo obradom informacija iz nekoliko sustava za praćenje, budući da je bilo nemoguće izravno uzeti metriku; također je bilo potrebno centralizirati podatke iz različitih sustava za praćenje na "jedan ekran" kako bi kako bi shvatili cjelokupnu sliku onoga što se događalo. “Kišobrani” su prikladni za ovu zadaću i mi smo te zahtjeve tada ispunili.

Vrlo važna stvar, po našem mišljenju, u odnosima s klijentima je iskrenost. Nakon prvog razgovora i izračuna cijene licence, rečeno je da bi se možda isplatilo odmah kupiti licencu, budući da je cijena tako niska (u usporedbi s Dynatrace Klyuch-Astrom iz gornjeg članka o zelenoj banci, naš licenca ne košta trećinu milijarde, već 12 tisuća rubalja mjesečno za 1 gigabajt, za Sber bi koštala nekoliko puta jeftinije). Ali odmah smo im rekli što imamo, a što nemamo. Možda bi prodajni predstavnik velikog integratora mogao reći "da, možemo sve, naravno kupiti našu licencu", ali mi smo odlučili položiti sve karte na stol. U trenutku lansiranja naš box nije imao integraciju s Prometheusom, a nova verzija s podsustavom automatizacije je bila pred izlaskom, ali je još nismo isporučili kupcima.

Počeo je pilot projekt, određene su mu granice i dana su nam 2 mjeseca. Glavni zadaci bili su:

• pripremiti novu verziju platforme i implementirati je u infrastrukturu banke
• spojite 2 nadzorna sustava (Zabbix i Prometheus);
• slati obavijesti odgovornima u Slacku i putem SMS-a;
• pokrenuti skripte za automatsko iscjeljivanje.

Prvi mjesec pilot projekta protekao je u pripremi nove verzije platforme u superbrzom modu za potrebe pilot projekta. Nova verzija odmah uključuje integraciju s Prometheusom i auto-healing. Zahvaljujući našem razvojnom timu, nekoliko noći nisu spavali, već su pustili ono što su obećali bez propuštanja rokova za druge ranije preuzete obveze.

Dok smo postavljali pilot, naišli smo na novi problem koji bi mogao zatvoriti projekt prije roka: za slanje upozorenja instant messengerima i putem SMS-a bile su nam potrebne dolazne i odlazne veze s Microsoft Azure poslužiteljima (tada smo koristili ovu platformu za slanje upozorenja na Slack) i vanjsku uslugu slanja SMS-a. Ali u ovom projektu sigurnost je bila poseban fokus. U skladu s politikom banke, takve se “rupe” ne smiju otvarati ni pod kojim uvjetima. Sve je moralo raditi iz zatvorene petlje. Ponuđeno nam je korištenje API-ja vlastitih internih servisa koji šalju upozorenja na Slack i putem SMS-a, ali nismo imali priliku spojiti takve servise odmah.

Večer debate s razvojnim timom završila je uspješnom potragom za rješenjem. Preturajući po zaostatku, pronašli smo jedan zadatak za koji nikada nismo imali dovoljno vremena i prioriteta - izraditi plug-in sustav kako bi implementacijski timovi ili naručitelj mogli sami pisati dodatke, proširujući mogućnosti platforme.

Ali ostalo nam je točno mjesec dana, tijekom kojih smo morali sve instalirati, konfigurirati i implementirati automatizaciju.

Prema Sergeju, našem glavnom arhitektu, za implementaciju plug-in sustava potrebno je najmanje mjesec dana.

Nismo imali vremena...

Postojalo je samo jedno rješenje - otići do klijenta i reći sve kako jest. Razgovarajte zajedno o pomicanju roka. I uspjelo je. Dobili smo dodatna 2 tjedna. Imali su i svoje rokove i interne obveze da pokažu rezultate, ali su imali 2 rezervna tjedna. Na kraju smo sve stavili na kocku. Bilo je nemoguće zabrljati. Iskrenost i partnerski pristup opet su se isplatili.

Kao rezultat pilota dobiveno je nekoliko važnih tehničkih rezultata i zaključaka:

Testirali smo novu funkcionalnost za obradu upozorenja

Raspoređeni sustav počeo je ispravno primati upozorenja od Prometheusa i grupirati ih. Upozorenja o problemu s Prometheus klijenta letjela su svakih 30 sekundi (grupiranje po vremenu nije omogućeno), a zanimalo nas je da li ih je moguće grupirati u samom “kišobranu”. Pokazalo se da je to moguće - postavljanje obrade upozorenja u platformi implementirano je skriptom. To omogućuje implementaciju gotovo bilo koje logike za njihovu obradu. Već smo implementirali standardnu ​​logiku u platformu u obliku predložaka - ako ne želite smisliti nešto svoje, možete koristiti gotovu.

Sučelje "Sintetički okidač". Postavljanje obrade dojava iz povezanih nadzornih sustava

Konstruirano stanje "zdravlja" sustava

Na temelju upozorenja kreirani su događaji praćenja koji su utjecali na ispravnost konfiguracijskih jedinica (CU). Implementiramo resursno-uslužni model (RSM), koji može koristiti ili interni CMDB ili povezati vanjski - tijekom pilot projekta klijent nije povezao vlastiti CMDB.

Sučelje za rad s modelom resurs-usluga. Pilot RSM.

Pa, zapravo, klijent konačno ima jedan ekran za praćenje, na kojem su vidljivi događaji iz različitih sustava. Trenutno su na “kišobran” povezana dva sustava - Zabbix i Prometheus, te interni sustav nadzora same platforme.

Analytics sučelje. Jedan zaslon za praćenje.

Pokrenuta automatizacija procesa

Događaji praćenja pokrenuli su pokretanje unaprijed konfiguriranih radnji - slanje upozorenja, pokretanje skripti, registracija/obogaćivanje incidenata - potonje nije isprobano s ovim klijentom jer u pilot projektu nije bilo integracije sa servisnim pultom.

Sučelje postavki radnje. Pošaljite upozorenja Slacku i ponovno pokrenite poslužitelj.

Proširena funkcionalnost proizvoda

Kad smo razgovarali o skriptama za automatizaciju, klijent je tražio podršku za bash i sučelje u kojem se te skripte mogu prikladno konfigurirati. Nova verzija učinila je malo više (mogućnost pisanja potpunih logičkih konstrukcija u Lua s podrškom za cURL, SSH i SNMP) i implementirala je funkcionalnost koja vam omogućuje upravljanje životnim ciklusom skripte (izrada, uređivanje, kontrola verzije , brisanje i arhiviranje).

Sučelje za rad sa skriptama za automatsko iscjeljivanje. Skripta za ponovno pokretanje poslužitelja putem SSH-a.

Glavni nalazi

Tijekom pilota kreirane su i korisničke priče koje poboljšavaju trenutnu funkcionalnost i povećavaju vrijednost za klijenta, evo nekih od njih:

• implementirati mogućnost prosljeđivanja varijabli izravno iz upozorenja u skriptu za automatsko iscjeljivanje;
• dodajte autorizaciju platformi putem Active Directoryja.

Dobili smo još globalnih izazova - "nadograditi" proizvod drugim mogućnostima:

• automatska izgradnja modela resursa i usluga temeljenog na ML-u, a ne na pravilima i agentima (što je sada vjerojatno glavni izazov);
• podrška za dodatne skriptne i logičke jezike (a to će biti JavaScript).

Po mom mišljenju najvažnija stvarOno što ovaj pilot pokazuje dvije su stvari:

1. Partnerski odnos s klijentom ključ je učinkovitosti, kada se učinkovita komunikacija gradi na temelju iskrenosti i otvorenosti, a klijent postaje dio tima koji u kratkom vremenu postiže značajne rezultate.
2. Ni pod kojim uvjetima nije potrebno "prilagođavati" i graditi "štake" - samo sistemska rješenja. Bolje je potrošiti malo više vremena, ali napraviti sustavno rješenje koje će koristiti i drugi klijenti. Usput, to se i dogodilo, sustav dodataka i eliminacija ovisnosti o Azureu dali su dodatnu vrijednost drugim klijentima (pozdrav, Savezni zakon 152).

Izvor: www.habr.com