ProHoster > Blogs > Administrācija > Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Publikācijās par HabrĆ© es jau rakstÄ«ju par savu pieredzi partnerattiecÄ«bu veidoÅ”anā ar savu komandu (Å”eit runā par to, kā noformēt partnerÄ«bas lÄ«gumu, uzsākot jaunu biznesu, lai bizness neizjuktu). Un tagad es gribētu runāt par to, kā veidot partnerattiecÄ«bas ar klientiem, jo ā€‹ā€‹bez viņiem nebÅ«s ko sabrukt. Es ceru, ka Å”is raksts bÅ«s noderÄ«gs jaunizveidotiem uzņēmumiem, kuri sāk pārdot savu produktu lieliem uzņēmumiem.

PaÅ”laik vadu jaunuzņēmumu MONQ Digital lab, kurā es un mana komanda izstrādājam produktu korporatÄ«vās IT atbalsta un darbÄ«bas procesu automatizÄ“Å”anai. IeieÅ”ana tirgÅ« nav viegls uzdevums, un mēs sākām ar nelielu mājasdarbu, izgājām cauri tirgus ekspertiem, mÅ«su partneriem un veicām tirgus segmentāciju. Galvenais jautājums bija saprast "kuru sāpes mēs varam vislabāk izārstēt?"

Bankas iekļuva TOP 3 segmentos. Un, protams, pirmie sarakstā bija Tinkoff un Sberbank. Kad viesojāmies pie banku tirgus ekspertiem, viņi teica: ieviesiet tur savu produktu, un ceļŔ uz banku tirgu bÅ«s atvērts. Mēģinājām iekļūt gan tur, gan tur, taču Sberbankā mÅ«s gaidÄ«ja neveiksme, un Tinkoff puiÅ”i izrādÄ«jās daudz atvērtāki produktÄ«vai komunikācijai ar Krievijas startupiem (varbÅ«t tāpēc, ka Sber tolaik nopirka gandrÄ«z miljards mÅ«su Rietumu konkurentu). MēneÅ”a laikā sākām pilotprojektu. Kā tas notika, lasiet tālāk.

Ar darbÄ«bas un uzraudzÄ«bas jautājumiem nodarbojamies jau daudzus gadus, tagad savu produktu ievieÅ”am valsts sektorā, apdroÅ”ināŔanā, bankās, telekomunikāciju kompānijās, viena realizācija bija ar aviokompāniju (pirms projekta pat neveicām domāju, ka aviācija bija tik no IT atkarÄ«ga nozare, un tagad mēs patieŔām ceram, neskatoties uz COVID, ka uzņēmums parādÄ«sies un pacelsies).

MÅ«su ražotais produkts pieder uzņēmuma programmatÅ«ras segmentam AIOps (mākslÄ«gais intelekts IT operācijām jeb ITOps). Tādu sistēmu ievieÅ”anas galvenie mērÄ·i, kā procesa brieduma lÄ«menis uzņēmumā paaugstinās:

  1. Dzēsiet ugunsgrēkus: identificējiet kļūmes, attÄ«riet brÄ«dinājumu straumi no gruveÅ”iem, nododiet atbildÄ«gos uzdevumus un incidentus;
  2. Paaugstināt IT servisa efektivitāti: samazināt incidentu risināŔanas laiku, norādÄ«t kļūmju cēloņus, palielināt IT statusa caurskatāmÄ«bu;
  3. Paaugstināt biznesa efektivitāti: samazināt roku darba apjomu, samazināt riskus, palielināt klientu lojalitāti.

Mūsu pieredze liecina, ka bankām ir Ŕādas "sāpes" ar monitoringu, kas ir kopīgas ar visām lielajām IT infrastruktūrām:

  • ā€œkas zina, koā€: ir daudz tehnisko nodaļu, gandrÄ«z katram ir vismaz viena uzraudzÄ«bas sistēma, un lielākajai daļai ir vairāk nekā viena;
  • BrÄ«dinājumu ā€œmoskÄ«tu barsā€: katra sistēma Ä£enerē simtus un ar tiem bombardē visus atbildÄ«gos (dažreiz arÄ« starp nodaļām). Ir grÅ«ti pastāvÄ«gi saglabāt kontroles fokusu uz katru paziņojumu, to steidzamÄ«ba un nozÄ«me ir izlÄ«dzināta lielā skaita dēļ;
  • lielās bankas ā€“ sektora lÄ«deri vēlas ne tikai nepārtraukti uzraudzÄ«t savas sistēmas, zināt, kur ir atteices, bet arÄ« Ä«sto AI burvÄ«bu ā€“ likt sistēmām paÅ”pārraudzÄ«t, paÅ”prognozēt un paÅ”labot.

Kad ieradāmies uz pirmo tikÅ”anos Tinkoff, mums uzreiz teica, ka viņiem nav nekādu problēmu ar uzraudzÄ«bu un nekas nesāp, un galvenais jautājums bija: "Ko mēs varam piedāvāt tiem, kam jau klājas labi?"

Saruna bija gara, pārrunājām, kā tiek veidoti viņu mikropakalpojumi, kā strādā nodaļas, kuras infrastruktÅ«ras problēmas ir jÅ«tÄ«gākas, kuras mazāk jÅ«tÄ«gas lietotājiem, kur ir ā€œaklās zonasā€, kādi ir to mērÄ·i un SLA.

Starp citu, bankas SLA ir patieŔām iespaidÄ«gi. Piemēram, 1. prioritātes tÄ«kla pieejamÄ«bas incidenta atrisināŔana var aizņemt tikai dažas minÅ«tes. Kļūdu un dÄ«kstāves izmaksas Å”eit, protams, ir iespaidÄ«gas.

Rezultātā mēs noteicām vairākas sadarbības jomas:

  1. pirmais posms ir jumta uzraudzība, lai palielinātu incidentu atrisināŔanas ātrumu
  2. otrais posms ir procesu automatizācija, lai samazinātu riskus un samazinātu IT nodaļas mērogoÅ”anas izmaksas.

Vairākus ā€œbaltos plankumusā€ brÄ«dinājumu koŔās krāsās varēja iekrāsot, tikai apstrādājot informāciju no vairākām uzraudzÄ«bas sistēmām, jo ā€‹ā€‹nebija iespējams tieÅ”i ņemt metriku, kā arÄ« bija nepiecieÅ”ams centralizēt datus no dažādām uzraudzÄ«bas sistēmām ā€œvienā ekrānāā€. lai saprastu kopējo ainu par notiekoÅ”o. ā€œLietussargiā€ ir piemēroti Å”im uzdevumam, un mēs toreiz izpildÄ«jām Ŕīs prasÄ«bas.

Ä»oti svarÄ«ga lieta, mÅ«suprāt, attiecÄ«bās ar klientiem ir godÄ«gums. Pēc pirmās sarunas un licences izmaksu aprēķināŔanas tika teikts, ka, tā kā izmaksas ir tik zemas, iespējams, ir vērts iegādāties licenci uzreiz (salÄ«dzinot ar Dynatrace Klyuch-Astrom no raksta par zaļo banku, mÅ«su licence maksā nevis treÅ”daļu miljarda, bet 12 tÅ«kstoÅ”us rubļu mēnesÄ« par 1 gigabaitu, Sberam tas izmaksātu vairākas reizes lētāk). Bet mēs viņiem uzreiz pastāstÄ«jām, kas mums ir un kas mums nav. VarbÅ«t tirdzniecÄ«bas pārstāvis no liela integratora varētu teikt: ā€œJā, mēs varam visu, protams, iegādājieties mÅ«su licenciā€, taču mēs nolēmām visas savas kartÄ«tes nolikt uz galda. PalaiÅ”anas brÄ«dÄ« mÅ«su kastē nebija integrācijas ar Prometheus, un drÄ«zumā tika izlaista jauna versija ar automatizācijas apakÅ”sistēmu, taču mēs to vēl neesam nosÅ«tÄ«juÅ”i klientiem.

Sākās pilotprojekts, tika noteiktas tā robežas un mums tika doti 2 mēneÅ”i. Galvenie uzdevumi bija:

  • sagatavot jaunu platformas versiju un izvietot to bankas infrastruktÅ«rā
  • savienot 2 uzraudzÄ«bas sistēmas (Zabbix un Prometheus);
  • nosÅ«tÄ«t paziņojumus atbildÄ«gajiem Slack un ar SMS palÄ«dzÄ«bu;
  • palaist automātiskās dziedināŔanas skriptus.

Pilotprojekta pirmais mēnesis pagāja, gatavojot jaunu platformas versiju superātrā režīmā pilotprojekta vajadzÄ«bām. Jaunā versija nekavējoties ietver integrāciju ar Prometheus un automātisko dziedināŔanu. Pateicoties mÅ«su izstrādes komandai, viņi vairākas naktis negulēja, bet izpildÄ«ja to, ko solÄ«ja, nenokavējot termiņus citām iepriekÅ” uzņemtajām saistÄ«bām.

Izmēģinājuma iestatÄ«Å”anas laikā mēs saskārāmies ar jaunu problēmu, kas varēja slēgt projektu pirms termiņa: lai nosÅ«tÄ«tu brÄ«dinājumus tÅ«lÄ«tējiem ziņojumapmaiņas lÄ«dzekļiem un ar Ä«sziņām, mums bija nepiecieÅ”ami ienākoÅ”ie un izejoÅ”ie savienojumi ar Microsoft Azure serveriem (tolaik izmantojām Å”o platformu lai nosÅ«tÄ«tu brÄ«dinājumus Slack) un ārējā sÅ«tÄ«Å”anas pakalpojuma SMS. Taču Å”ajā projektā Ä«paÅ”a uzmanÄ«ba tika pievērsta droŔībai. Saskaņā ar bankas politiku Ŕādas ā€œcaurÄ«tesā€ nekādā gadÄ«jumā nedrÄ«kstēja atvērties. Visam bija jādarbojas no slēgta cikla. Mums tika piedāvāts izmantot mÅ«su paÅ”u iekŔējo pakalpojumu API, kas sÅ«ta brÄ«dinājumus Slack un ar SMS palÄ«dzÄ«bu, taču mums nebija iespējas pieslēgt Ŕādus pakalpojumus no kastes.

DebaÅ”u vakars ar izstrādes komandu beidzās ar veiksmÄ«gu risinājuma meklÄ“Å”anu. Rakņājoties pa atpalicÄ«bu, atradām vienu uzdevumu, kuram nekad nepietika laika un prioritātes ā€“ izveidot spraudņu sistēmu, lai ievieÅ”anas komandas vai klients paÅ”i varētu rakstÄ«t papildinājumus, paplaÅ”inot platformas iespējas.

Taču mums bija palicis tieÅ”i mēnesis, kura laikā bija jāinstalē viss, jākonfigurē un jāievieto automatizācija.

Pēc mÅ«su galvenā arhitekta Sergeja teiktā, spraudņu sistēmas ievieÅ”ana prasa vismaz mēnesi.

Mums nebija laika...

Bija tikai viens risinājums - aiziet pie klienta un izstāstÄ«t visu kā ir. Kopā pārrunājiet termiņa maiņu. Un tas strādāja. Mums tika dotas papildu 2 nedēļas. Viņiem bija arÄ« savi termiņi un iekŔējie pienākumi uzrādÄ«t rezultātus, bet viņiem bija 2 rezerves nedēļas. Beigās visu nolikām uz lÄ«nijas. Sajukt nebija iespējams. GodÄ«gums un partnerÄ«bas pieeja atkal atmaksājās.

Izmēģinājuma rezultātā tika iegūti vairāki svarīgi tehniskie rezultāti un secinājumi:

Mēs pārbaudījām jauno brīdinājumu apstrādes funkcionalitāti

Izvietotā sistēma sāka pareizi saņemt brÄ«dinājumus no Prometheus un grupēt tos. BrÄ«dinājumi par problēmu no Prometheus klienta lidoja ik pēc 30 sekundēm (grupÄ“Å”ana pēc laika nav iespējota), un mēs domājām, vai bÅ«tu iespējams tos grupēt paŔā ā€œlietussargāā€. IzrādÄ«jās, ka tas ir iespējams ā€“ brÄ«dinājumu apstrādes iestatÄ«Å”ana platformā tiek realizēta ar skriptu. Tas ļauj Ä«stenot gandrÄ«z jebkuru loÄ£iku to apstrādei. Mēs jau esam platformā ieviesuÅ”i standarta loÄ£iku veidņu veidā - ja nevēlaties izdomāt kaut ko savu, varat izmantot gatavu.

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

"Sintētiskā sprÅ«da" saskarne. BrÄ«dinājumu apstrādes iestatÄ«Å”ana no pievienotajām uzraudzÄ«bas sistēmām

Konstruēja sistēmas ā€œveselÄ«basā€ stāvokli

Pamatojoties uz brÄ«dinājumiem, tika izveidoti uzraudzÄ«bas notikumi, kas ietekmēja konfigurācijas vienÄ«bu (CU) stāvokli. Mēs ievieÅ”am resursu-pakalpojuma modeli (RSM), kurā var izmantot vai nu iekŔējo CMDB, vai pieslēgt ārējo - pilotprojekta laikā klients nav pieslēdzis savu CMDB.

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Interfeiss darbam ar resursa-pakalpojuma modeli. Pilots RSM.

Nu, patiesÄ«bā klientam beidzot ir viens uzraudzÄ«bas ekrāns, kurā ir redzami notikumi no dažādām sistēmām. PaÅ”laik ar ā€œlietussarguā€ ir savienotas divas sistēmas - Zabbix un Prometheus, kā arÄ« paÅ”as platformas iekŔējā uzraudzÄ«bas sistēma.

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Analytics saskarne. Viens uzraudzības ekrāns.

Uzsākta procesu automatizācija

Notikumu pārraudzÄ«ba izraisÄ«ja iepriekÅ” konfigurētu darbÄ«bu palaiÅ”anu - brÄ«dinājumu sÅ«tÄ«Å”anu, skriptu palaiÅ”anu, incidentu reÄ£istrÄ“Å”anu/bagātināŔanu - pēdējā netika izmēģināta ar Å”o konkrēto klientu, jo pilotprojektā nebija integrācijas ar apkalpoÅ”anas dienestu.

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Darbības iestatījumu saskarne. Nosūtiet brīdinājumus uz Slack un restartējiet serveri.

PaplaŔināta produkta funkcionalitāte

Apspriežot automatizācijas skriptus, klients lÅ«dza bash atbalstu un saskarni, kurā Å”os skriptus varētu ērti konfigurēt. Jaunajā versijā ir paveikts nedaudz vairāk (iespēja rakstÄ«t pilnvērtÄ«gas loÄ£iskās konstrukcijas Lua ar atbalstu cURL, SSH un SNMP) un ieviesta funkcionalitāte, kas ļauj pārvaldÄ«t skripta dzÄ«ves ciklu (izveidot, rediģēt, versiju kontroli , dzēst un arhivēt).

Kāpēc bankai ir nepiecieÅ”ami AIOps un jumta uzraudzÄ«ba vai uz ko balstās attiecÄ«bas ar klientiem?

Interfeiss darbam ar automātiskās dziedināŔanas skriptiem. Servera atsāknÄ“Å”anas skripts, izmantojot SSH.

Galvenie secinājumi

Pilota laikā tika izveidoti arÄ« lietotāju stāsti, kas uzlabo paÅ”reizējo funkcionalitāti un palielina vērtÄ«bu klientam, Å”eit ir daži no tiem:

  • ieviest iespēju pārsÅ«tÄ«t mainÄ«gos tieÅ”i no brÄ«dinājuma uz automātiskās dziedināŔanas skriptu;
  • pievienojiet platformai autorizāciju, izmantojot Active Directory.

Un mēs saņēmām vēl globālākus izaicinājumus - ā€œuzbÅ«vētā€ produktu ar citām iespējām:

  • automātiska resursu un pakalpojumu modeļa izveide, pamatojoties uz ML, nevis noteikumiem un aÄ£entiem (iespējams, Å”obrÄ«d tas ir galvenais izaicinājums);
  • atbalsts papildu skriptu un loÄ£ikas valodām (un tas bÅ«s JavaScript).

Pēc manām domām, vissvarīgākā lietaŠis pilots parāda divas lietas:

  1. Partnerattiecības ar klientu ir efektivitātes atslēga, kad efektīva komunikācija tiek veidota uz godīguma un atklātības pamata, un klients kļūst par daļu no komandas, kas īsā laikā sasniedz nozīmīgus rezultātus.
  2. Nekādā gadÄ«jumā nav nepiecieÅ”ams ā€œpielāgotā€ un veidot ā€œkruÄ·usā€ - tikai sistēmas risinājumus. Labāk ir pavadÄ«t nedaudz vairāk laika, bet izveidot sistēmas risinājumu, ko izmantos citi klienti. Starp citu, tas notika, spraudņu sistēma un atkarÄ«bas no Azure likvidÄ“Å”ana sniedza papildu vērtÄ«bu citiem klientiem (sveicināti, Federālais likums 152).

Avots: www.habr.com

Pievieno komentāru