Prečo banka potrebuje AIOps a zastrešujúci monitoring alebo na čom sú založené vzťahy so zákazníkmi?

V publikáciách o Habrém som už písal o svojich skúsenostiach s budovaním partnerstiev s mojím tímom (tu hovorí o tom, ako vyhotoviť spoločenskú zmluvu pri začatí nového podnikania, aby sa podnikanie nerozpadlo). A teraz by som rád hovoril o tom, ako budovať partnerské vzťahy s klientmi, keďže bez nich nebude nič, čo by sa rozpadlo. Dúfam, že tento článok bude užitočný pre startupy, ktoré začínajú predávať svoj produkt veľkým podnikom.

Momentálne vediem startup s názvom MONQ Digital lab, kde s tímom vyvíjame produkt na automatizáciu procesov podpory a prevádzky firemného IT. Vstup na trh nie je ľahká úloha a začali sme s malou domácou úlohou, prešli sme odborníkov na trh, našich partnerov a vykonali sme segmentáciu trhu. Hlavnou otázkou bolo pochopiť, „koho bolesti môžeme najlepšie vyliečiť?

Banky sa dostali do TOP 3 segmentov. A samozrejme, prví na zozname boli Tinkoff a Sberbank. Keď sme navštívili odborníkov na bankový trh, povedali: predstavte tam svoj produkt a cesta na bankový trh bude otvorená. Snažili sme sa vstúpiť tam aj tam, no v Sberbank nás čakal neúspech a chalani z Tinkoff sa ukázali byť oveľa otvorenejší produktívnej komunikácii s ruskými startupmi (možno aj preto, že Sber v tom čase kúpil takmer miliarda našich západných konkurentov). V priebehu mesiaca sme spustili pilotný projekt. Ako sa to stalo, čítajte ďalej.

Problematike prevádzky a monitoringu sa venujeme dlhé roky, teraz náš produkt implementujeme vo verejnom sektore, v poisťovníctve, v bankách, v telekomunikačných spoločnostiach, jedna implementácia bola s leteckou spoločnosťou (pred projektom sme Myslíme si, že letectvo bolo odvetvie závislé od IT a teraz naozaj dúfame, že napriek COVIDu sa spoločnosť objaví a rozbehne sa).

Produkt, ktorý vyrábame, patrí do podnikového softvéru, segmentu AIOps (Artificial Intelligence for IT Operations alebo ITOps). Hlavnými cieľmi implementácie takýchto systémov je zvyšovanie úrovne vyspelosti procesov v spoločnosti:

1. Haste požiare: identifikujte poruchy, vyčistite prúd výstrah od trosiek, prideľte úlohy a incidenty zodpovedným;
2. Zvýšiť efektivitu IT služby: znížiť čas na riešenie incidentov, indikovať príčiny porúch, zvýšiť transparentnosť stavu IT;
3. Zvýšte efektivitu podnikania: znížte množstvo manuálnej práce, znížte riziká, zvýšte lojalitu zákazníkov.

Podľa našich skúseností majú banky tieto „bolesti“ s monitorovaním spoločné so všetkými veľkými IT infraštruktúrami:

• „kto vie čo“: existuje veľa technických oddelení, takmer každý má aspoň jeden monitorovací systém a väčšina z nich má viac ako jeden;
• „roj komárov“ výstrah: každý systém generuje stovky a bombarduje nimi všetkých zodpovedných (niekedy aj medzi oddeleniami). Je ťažké neustále udržiavať zameranie kontroly na každé oznámenie, ich naliehavosť a dôležitosť je kvôli veľkému počtu vyrovnaná;
• veľké banky – sektoroví lídri chcú nielen neustále monitorovať svoje systémy, vedieť, kde sú zlyhania, ale aj skutočnú mágiu AI – zabezpečiť, aby sa systémy samokontrolovali, predpovedali a opravovali.

Keď sme prišli na prvé stretnutie v Tinkoffe, hneď nám povedali, že s monitorovaním nemajú žiadne problémy a nič ich nebolí a hlavná otázka znela: „Čo môžeme ponúknuť tým, ktorým sa už darí?“

Rozhovor bol dlhý, diskutovali sme o tom, ako sú postavené ich mikroslužby, ako fungujú oddelenia, ktoré problémy s infraštruktúrou sú citlivejšie, ktoré menej citlivé pre používateľov, kde sú „slepé miesta“ a aké sú ich ciele a SLA.

Mimochodom, zmluvy SLA banky sú skutočne pôsobivé. Napríklad, vyriešenie incidentu dostupnosti siete s prioritou XNUMX môže trvať len niekoľko minút. Náklady na chyby a prestoje sú tu, samozrejme, pôsobivé.

V dôsledku toho sme identifikovali niekoľko oblastí spolupráce:

1. prvou fázou je zastrešujúce monitorovanie na zvýšenie rýchlosti riešenia incidentov
2. druhou fázou je automatizácia procesov na zníženie rizík a zníženie nákladov na škálovanie IT oddelenia.

Niekoľko „bielych škvŕn“ bolo možné zafarbiť do jasných farieb výstrah iba spracovaním informácií z niekoľkých monitorovacích systémov, pretože nebolo možné priamo prijímať metriky; bolo tiež potrebné centralizovať údaje z rôznych monitorovacích systémov na „jednu obrazovku“, aby pochopiť celkový obraz toho, čo sa stalo. Na túto úlohu sú vhodné „dáždniky“ a vtedy sme tieto požiadavky splnili.

Veľmi dôležitá vec vo vzťahoch s klientmi je podľa nás úprimnosť. Po prvom rozhovore a prepočte nákladov na licenciu zaznelo, že keďže sú náklady také nízke, možno by stálo za to si licenciu hneď kúpiť (v porovnaní s Dynatrace Klyuch-Astrom z vyššie uvedeného článku o zelenej banke, naša licencia stojí nie tretinu miliardy, ale 12 1 rubľov mesačne za XNUMX gigabajt, pre Sber by to stálo niekoľkonásobne lacnejšie). Ale hneď sme im povedali, čo máme a čo nie. Možno by obchodný zástupca veľkého integrátora mohol povedať „áno, môžeme urobiť všetko, samozrejme, kúpiť našu licenciu“, ale rozhodli sme sa vyložiť všetky karty na stôl. V čase uvedenia na trh náš box nemal integráciu s Prometheusom a chystala sa vydanie novej verzie s automatizačným subsystémom, no zatiaľ sme ju zákazníkom nedodali.

Začal sa pilotný projekt, určili sa jeho hranice a dostali sme 2 mesiace. Hlavnými úlohami boli:

• pripraviť novú verziu platformy a nasadiť ju do infraštruktúry banky
• pripojiť 2 monitorovacie systémy (Zabbix a Prometheus);
• posielať upozornenia zodpovedným osobám v Slacku a prostredníctvom SMS;
• spustiť autohealing skripty.

Prvý mesiac pilotného projektu prebiehala príprava novej verzie platformy v superrýchlom režime pre potreby pilotného projektu. Nová verzia okamžite zahŕňa integráciu s Prometheus a auto-healing. Vďaka nášmu vývojovému tímu niekoľko nocí nespali, ale zverejnili to, čo sľúbili, bez toho, aby zmeškali termíny pre iné predtým prijaté záväzky.

Počas nastavovania pilotného programu sme narazili na nový problém, ktorý by mohol ukončiť projekt pred plánovaným termínom: na odosielanie upozornení do instant messengerov a prostredníctvom SMS sme potrebovali prichádzajúce a odchádzajúce pripojenia k serverom Microsoft Azure (v tom čase sme používali túto platformu na odosielanie upozornení na Slack) a externú službu odosielania SMS. V tomto projekte sa však kládol osobitný dôraz na bezpečnosť. V súlade s politikou banky takéto „diery“ nebolo možné za žiadnych okolností otvárať. Všetko muselo fungovať z uzavretej slučky. Bolo nám ponúknuté použiť API našich vlastných interných služieb, ktoré posielajú upozornenia do Slacku a cez SMS, ale nemali sme možnosť pripojiť takéto služby hneď po vybalení.

Večerná debata s vývojovým tímom skončila úspešným hľadaním riešenia. Po prehrabaní nevybavených vecí sme našli jednu úlohu, na ktorú sme nikdy nemali dosť času a priorít – vytvoriť zásuvný systém, aby si implementačné tímy alebo klient mohli sami písať doplnky a rozširovať možnosti platformy.

Ostával nám ale presne mesiac, počas ktorého sme museli všetko nainštalovať, nakonfigurovať a nasadiť automatizáciu.

Podľa nášho hlavného architekta Sergeja trvá implementácia zásuvného systému minimálne mesiac.

Nemali sme čas...

Bolo len jedno riešenie – ísť za klientom a povedať všetko tak, ako to je. Diskutujte spolu o posune termínu. A podarilo sa. Dostali sme 2 týždne navyše. Mali tiež svoje vlastné termíny a interné povinnosti ukázať výsledky, ale mali 2 rezervné týždne. Na záver všetko dáme na linku. Pokaziť sa nedalo. Poctivosť a partnerský prístup sa opäť vyplatili.

Výsledkom pilotného projektu bolo niekoľko dôležitých technických výsledkov a záverov:

Testovali sme novú funkcionalitu spracovania upozornení

Nasadený systém začal správne prijímať upozornenia od Prometheus a zoskupovať ich. Upozornenia na problém od klienta Prometheus lietali každých 30 sekúnd (zoskupovanie podľa času nie je povolené) a zaujímalo nás, či by bolo možné ich zoskupiť do samotného „dáždnika“. Ukázalo sa, že je to možné – nastavenie spracovania upozornení v platforme je realizované skriptom. To umožňuje implementovať takmer akúkoľvek logiku na ich spracovanie. Do platformy sme už implementovali štandardnú logiku vo forme šablón – ak nechcete vymýšľať niečo vlastné, môžete použiť hotovú.

Rozhranie „Syntetický spúšťač“. Nastavenie spracovania upozornení z pripojených monitorovacích systémov

Vytvoril stav „zdravia“ systému

Na základe upozornení boli vytvorené monitorovacie udalosti, ktoré ovplyvnili zdravie konfiguračných jednotiek (CU). Implementujeme zdrojovo-servisný model (RSM), ktorý môže využívať buď internú CMDB alebo pripojiť externú – počas pilotného projektu klient nepripájal vlastnú CMDB.

Rozhranie pre prácu s modelom zdrojov a služieb. Pilotný RSM.

V skutočnosti má klient konečne jednu monitorovaciu obrazovku, kde sú viditeľné udalosti z rôznych systémov. V súčasnosti sú na „dáždnik“ pripojené dva systémy – Zabbix a Prometheus a interný monitorovací systém samotnej platformy.

Rozhranie Analytics. Jedna monitorovacia obrazovka.

Spustená automatizácia procesov

Monitorovanie udalostí spustilo spustenie vopred nakonfigurovaných akcií - odosielanie upozornení, spúšťanie skriptov, registrácia/obohacovanie incidentov - to posledné nebolo skúšané s týmto konkrétnym klientom, pretože v pilotnom projekte nedošlo k integrácii so servisným pultom.

Rozhranie nastavení akcií. Pošlite upozornenia na Slack a reštartujte server.

Rozšírená funkčnosť produktu

Pri diskusii o automatizačných skriptoch klient požiadal o podporu bash a rozhranie, v ktorom by sa tieto skripty dali pohodlne nakonfigurovať. Nová verzia urobila trochu viac (možnosť písať plnohodnotné logické konštrukcie v jazyku Lua s podporou cURL, SSH a SNMP) a implementovala funkcionalitu, ktorá umožňuje riadiť životný cyklus skriptu (vytvárať, upravovať, kontrolovať verzie odstrániť a archivovať).

Rozhranie pre prácu s autohealing skriptami. Skript na reštart servera cez SSH.

Kľúčové zistenia

Počas pilotného projektu boli vytvorené aj používateľské príbehy, ktoré zlepšujú súčasnú funkcionalitu a zvyšujú hodnotu pre klienta, tu sú niektoré z nich:

• implementovať schopnosť posielať premenné priamo z upozornenia do skriptu autohealingu;
• pridať autorizáciu na platformu cez Active Directory.

A dostali sme ďalšie globálne výzvy – „vybudovať“ produkt s ďalšími schopnosťami:

• automatické vytváranie modelu služieb zdrojov založeného na ML, a nie na pravidlách a agentoch (pravdepodobne hlavná výzva súčasnosti);
• podpora ďalších skriptovacích a logických jazykov (a to bude JavaScript).

Podľa môjho názoru najdôležitejšia vecTento pilotný projekt ukazuje dve veci:

1. Kľúčom k efektivite sú partnerstvá s klientom, kedy je efektívna komunikácia postavená na úprimnosti a otvorenosti a klient sa stáva súčasťou tímu, ktorý v krátkom čase dosahuje výrazné výsledky.
2. Za žiadnych okolností nie je potrebné „prispôsobovať“ a stavať „barle“ – iba systémové riešenia. Je lepšie stráviť trochu viac času, ale vytvoriť systémové riešenie, ktoré využijú ďalší klienti. Mimochodom, stalo sa to, plugin systém a odstránenie závislosti na Azure poskytli ďalšiu hodnotu ďalším klientom (ahoj, federálny zákon 152).

Zdroj: hab.com