Bakit kailangan ng isang bangko ang AIOps at umbrella monitoring, o saan nakabatay ang mga relasyon sa customer?

Sa mga publikasyon sa Habré, nagsulat na ako tungkol sa aking karanasan sa pagbuo ng mga pakikipagsosyo sa aking koponan (dito pinag-uusapan kung paano gumuhit ng isang kasunduan sa pakikipagsosyo kapag nagsisimula ng isang bagong negosyo upang hindi masira ang negosyo). At ngayon gusto kong pag-usapan kung paano bumuo ng mga pakikipagtulungan sa mga kliyente, dahil kung wala sila ay walang magugulo. Umaasa ako na ang artikulong ito ay magiging kapaki-pakinabang sa mga startup na nagsisimulang magbenta ng kanilang produkto sa malalaking negosyo.

Kasalukuyan akong namumuno sa isang startup na tinatawag na MONQ Digital lab, kung saan kami ng aking team ay gumagawa ng isang produkto para sa pag-automate ng mga proseso ng pagsuporta at pagpapatakbo ng corporate IT. Ang pagpasok sa merkado ay hindi isang madaling gawain at nagsimula kami sa isang maliit na araling-bahay, dumaan sa mga eksperto sa merkado, aming mga kasosyo at nagsagawa ng segmentasyon ng merkado. Ang pangunahing tanong ay upang maunawaan kung "kanino ang mga sakit na maaari naming pinakamahusay na pagalingin?"

Nakapasok ang mga bangko sa TOP 3 segment. At siyempre, ang una sa listahan ay sina Tinkoff at Sberbank. Nang bumisita kami sa mga eksperto sa merkado ng pagbabangko, sinabi nila: ipakilala ang iyong produkto doon, at ang landas sa merkado ng pagbabangko ay bukas. Sinubukan naming pumasok doon at doon, ngunit ang kabiguan ay naghihintay sa amin sa Sberbank, at ang mga lalaki mula sa Tinkoff ay naging mas bukas sa produktibong komunikasyon sa mga startup ng Russia (marahil dahil sa katotohanan na si Sber noong panahong iyon binili halos isang bilyon ng ating mga kakumpitensya sa Kanluran). Sa loob ng isang buwan nagsimula kami ng isang pilot project. Paano ito nangyari, basahin mo.

Nakikitungo kami sa mga isyu ng operasyon at pagsubaybay sa loob ng maraming taon, ngayon ay ipinapatupad namin ang aming produkto sa pampublikong sektor, sa insurance, sa mga bangko, sa mga kumpanya ng telecom, isang pagpapatupad ay sa isang airline (bago ang proyekto, hindi namin ginawa isipin na ang aviation ay tulad ng isang IT-dependent na industriya, at Ngayon kami ay talagang umaasa, sa kabila ng COVID, na ang kumpanya ay lalabas at aalis).

Ang produktong ginagawa namin ay nabibilang sa enterprise software, ang AIOps (Artificial Intelligence for IT Operations, o ITOps) na segment. Ang mga pangunahing layunin ng pagpapatupad ng mga naturang sistema bilang ang antas ng proseso ng kapanahunan sa kumpanya ay nagdaragdag:

1. Patayin ang sunog: tukuyin ang mga pagkabigo, alisin ang daloy ng mga alerto mula sa mga labi, magtalaga ng mga gawain at insidente sa mga responsable;
2. Dagdagan ang kahusayan ng serbisyo ng IT: bawasan ang oras upang malutas ang mga insidente, ipahiwatig ang mga sanhi ng mga pagkabigo, dagdagan ang transparency ng katayuan ng IT;
3. Palakihin ang kahusayan sa negosyo: bawasan ang dami ng manu-manong paggawa, bawasan ang mga panganib, dagdagan ang katapatan ng customer.

Sa aming karanasan, ang mga bangko ay may mga sumusunod na "sakit" na may pagsubaybay na karaniwan sa lahat ng malalaking imprastraktura ng IT:

• "sino ang nakakaalam kung ano": maraming mga teknikal na departamento, halos lahat ay may kahit isang sistema ng pagsubaybay, at karamihan ay may higit sa isa;
• "lamok ng lamok" ng mga alerto: bawat sistema ay bumubuo ng daan-daan at binobomba ang lahat ng mga responsable sa kanila (minsan din sa pagitan ng mga departamento). Mahirap na patuloy na mapanatili ang pokus ng kontrol sa bawat abiso, ang kanilang pagkaapurahan at kahalagahan ay nai-level dahil sa malaking bilang;
• malalaking bangko - nais ng mga pinuno ng sektor na hindi lamang patuloy na subaybayan ang kanilang mga sistema, upang malaman kung saan may mga pagkabigo, kundi pati na rin ang tunay na salamangka ng AI - upang gawin ang mga system na self-monitor, hulaan ang sarili at itama ang sarili.

Nang dumating kami sa unang pagpupulong sa Tinkoff, agad kaming sinabihan na wala silang problema sa pagsubaybay at walang nakakasakit sa kanila, at ang pangunahing tanong ay: "Ano ang maiaalok namin para sa mga mahusay na?"

Ang pag-uusap ay mahaba, tinalakay namin kung paano binuo ang kanilang mga microservice, kung paano gumagana ang mga departamento, kung aling mga problema sa imprastraktura ang mas sensitibo, na hindi gaanong sensitibo para sa mga gumagamit, nasaan ang mga "blind spot", at ano ang kanilang mga layunin at SLA.

Siyanga pala, talagang kahanga-hanga ang mga SLA ng bangko. Halimbawa, ang isang priority XNUMX na insidente sa availability ng network ay maaari lamang tumagal ng ilang minuto upang malutas. Ang gastos ng error at downtime dito, siyempre, ay kahanga-hanga.

Bilang resulta, natukoy namin ang ilang mga lugar ng pakikipagtulungan:

1. ang unang yugto ay umbrella monitoring upang mapataas ang bilis ng paglutas ng insidente
2. ang pangalawang yugto ay ang proseso ng automation upang mabawasan ang mga panganib at mabawasan ang mga gastos para sa pag-scale ng IT department.

Maraming "white spot" ang maaaring maipinta sa maliliwanag na kulay ng mga alerto lamang sa pamamagitan ng pagproseso ng impormasyon mula sa ilang mga sistema ng pagsubaybay, dahil imposibleng direktang kumuha ng mga sukatan; kinakailangan din na isentro ang data mula sa iba't ibang mga sistema ng pagsubaybay sa "isang screen" sa pagkakasunud-sunod upang maunawaan ang pangkalahatang larawan ng kung ano ang nangyayari. Ang mga "umbrellas" ay angkop para sa gawaing ito at natugunan namin ang mga kinakailangang ito noon.

Ang isang napakahalagang bagay, sa aming opinyon, sa mga relasyon sa mga kliyente ay katapatan. Matapos ang unang pag-uusap at pagkalkula ng halaga ng lisensya, sinabi na dahil napakababa ng gastos, maaaring sulit na bumili kaagad ng lisensya (kumpara sa Dynatrace Klyuch-Astrom mula sa artikulo sa itaas tungkol sa berdeng bangko, ang aming Ang lisensya ay nagkakahalaga ng hindi isang katlo ng isang bilyon, ngunit 12 libong rubles bawat buwan para sa 1 gigabyte, para sa Sber ito ay nagkakahalaga ng maraming beses na mas mura). Ngunit agad naming sinabi sa kanila kung ano ang mayroon kami at kung ano ang wala. Marahil ay maaaring sabihin ng isang sales representative mula sa isang malaking integrator na "oo, magagawa namin ang lahat, siyempre bilhin ang aming lisensya," ngunit nagpasya kaming ilagay ang lahat ng aming mga card sa mesa. Sa oras ng paglunsad, ang aming kahon ay walang integration sa Prometheus, at isang bagong bersyon na may isang automation subsystem ay malapit nang ilabas, ngunit hindi pa namin ito naipapadala sa mga customer.

Nagsimula ang pilot project, natukoy ang mga hangganan nito at binigyan kami ng 2 buwan. Ang mga pangunahing gawain ay:

• maghanda ng bagong bersyon ng platform at i-deploy ito sa imprastraktura ng bangko
• ikonekta ang 2 sistema ng pagsubaybay (Zabbix at Prometheus);
• magpadala ng mga abiso sa mga responsable sa Slack at sa pamamagitan ng SMS;
• magpatakbo ng mga autohealing script.

Ang unang buwan ng pilot project ay ginugol sa paghahanda ng bagong bersyon ng platform sa super-fast mode para sa mga pangangailangan ng pilot project. Kasama agad sa bagong bersyon ang pagsasama sa Prometheus at auto-healing. Salamat sa aming development team, hindi sila nakatulog nang ilang gabi, ngunit inilabas ang kanilang ipinangako nang hindi nawawala ang mga deadline para sa iba pang dating ginawang mga pangako.

Habang nagse-set up kami ng pilot, nakatagpo kami ng bagong problema na maaaring magsara ng proyekto nang mas maaga sa iskedyul: upang magpadala ng mga alerto sa mga instant messenger at sa pamamagitan ng SMS, kailangan namin ng mga papasok at papalabas na koneksyon sa mga server ng Microsoft Azure (sa panahong iyon, ginamit namin ang platform na ito. upang magpadala ng mga alerto sa Slack) at isang panlabas na serbisyo sa pagpapadala ng SMS. Ngunit sa proyektong ito, ang kaligtasan ay isang partikular na pokus. Alinsunod sa patakaran ng bangko, ang naturang "mga butas" ay hindi mabubuksan sa anumang pagkakataon. Ang lahat ay kailangang gumana mula sa isang saradong loop. Inalok kaming gamitin ang API ng aming sariling mga panloob na serbisyo na nagpapadala ng mga alerto sa Slack at sa pamamagitan ng SMS, ngunit hindi kami nagkaroon ng pagkakataong ikonekta ang mga naturang serbisyo sa labas ng kahon.

Nagtapos ang isang gabi ng debate sa development team sa matagumpay na paghahanap ng solusyon. Sa paghalungkat sa backlog, nakakita kami ng isang gawain kung saan hindi kami nagkaroon ng sapat na oras at priyoridad - upang lumikha ng isang plug-in system upang ang mga team ng pagpapatupad o ang kliyente ay makapagsulat ng mga add-on sa kanilang sarili, na nagpapalawak ng mga kakayahan ng platform.

Ngunit mayroon kaming eksaktong isang buwan na natitira, kung saan kailangan naming i-install ang lahat, i-configure at i-deploy ang automation.

Ayon kay Sergei, ang aming punong arkitekto, ito ay tumatagal ng hindi bababa sa isang buwan upang ipatupad ang plug-in system.

Wala kaming oras...

Mayroon lamang isang solusyon - pumunta sa kliyente at sabihin ang lahat kung ano ito. Talakayin ang shift ng deadline nang magkasama. At ito ay gumana. Binigyan kami ng dagdag na 2 linggo. Mayroon din silang sariling mga deadline at panloob na obligasyon na magpakita ng mga resulta, ngunit mayroon silang 2 reserbang linggo. Sa huli, inilalagay namin ang lahat sa linya. Imposibleng magulo. Nagbunga muli ang katapatan at diskarte sa pakikipagsosyo.

Bilang resulta ng piloto, maraming mahahalagang teknikal na resulta at konklusyon ang nakuha:

Sinubukan namin ang bagong functionality para sa pagproseso ng mga alerto

Ang deployed system ay nagsimulang makatanggap ng tama ng mga alerto mula sa Prometheus at igrupo ang mga ito. Ang mga alerto sa problema mula sa kliyente ng Prometheus ay lumilipad bawat 30 segundo (hindi pinagana ang pagpapangkat ayon sa oras), at iniisip namin kung posible bang igrupo sila sa mismong "payong". Ito ay naging posible - ang pag-set up ng pagproseso ng mga alerto sa platform ay ipinatupad ng isang script. Ginagawa nitong posible na ipatupad ang halos anumang lohika para sa pagproseso ng mga ito. Naipatupad na namin ang karaniwang lohika sa platform sa anyo ng mga template - kung ayaw mong magkaroon ng sarili mong bagay, maaari kang gumamit ng handa na.

"Sintetikong trigger" na interface. Pag-set up ng pagproseso ng mga alerto mula sa mga konektadong sistema ng pagsubaybay

Binuo ang estado ng "kalusugan" ng system

Batay sa mga alerto, ginawa ang mga kaganapan sa pagsubaybay na nakaapekto sa kalusugan ng mga configuration unit (CU). Nagpapatupad kami ng resource-service model (RSM), na maaaring gumamit ng internal CMDB o kumonekta sa external - sa panahon ng pilot project, hindi ikinonekta ng kliyente ang sarili nitong CMDB.

Interface para sa pagtatrabaho sa modelo ng resource-service. Pilot RSM.

Sa katunayan, ang kliyente sa wakas ay may isang solong screen ng pagsubaybay, kung saan makikita ang mga kaganapan mula sa iba't ibang mga system. Sa kasalukuyan, dalawang sistema ang nakakonekta sa "umbrella" - Zabbix at Prometheus, at isang panloob na sistema ng pagsubaybay ng platform mismo.

Interface ng Analytics. Isang screen ng pagsubaybay.

Inilunsad ang automation ng proseso

Ang pagsubaybay sa mga kaganapan ay nag-trigger ng paglunsad ng mga paunang na-configure na pagkilos - pagpapadala ng mga alerto, pagpapatakbo ng mga script, pagrehistro/pagpayaman ng mga insidente - ang huli ay hindi sinubukan sa partikular na kliyenteng ito, dahil sa pilot project walang integration sa service desk.

Interface ng mga setting ng pagkilos. Magpadala ng mga alerto sa Slack at i-reboot ang server.

Pinalawak na functionality ng produkto

Kapag tinatalakay ang mga script ng automation, humingi ang kliyente ng suporta sa bash at isang interface kung saan maginhawang ma-configure ang mga script na ito. Ang bagong bersyon ay nakagawa ng kaunti pa (ang kakayahang magsulat ng mga ganap na lohikal na konstruksyon sa Lua na may suporta para sa cURL, SSH at SNMP) at ipinatupad ang functionality na nagbibigay-daan sa iyong pamahalaan ang life cycle ng isang script (lumikha, mag-edit, kontrol ng bersyon , tanggalin at i-archive).

Interface para sa pagtatrabaho sa mga script ng autohealing. I-reboot ng server ang script sa pamamagitan ng SSH.

Pangunahing natuklasan

Sa panahon ng pilot, nilikha din ang mga kwento ng user na nagpapahusay sa kasalukuyang functionality at nagpapataas ng halaga para sa kliyente, narito ang ilan sa mga ito:

• ipatupad ang kakayahang direktang ipasa ang mga variable mula sa alerto sa autohealing script;
• magdagdag ng pahintulot sa platform sa pamamagitan ng Active Directory.

At nakatanggap kami ng higit pang mga pandaigdigang hamon - upang "buuin" ang produkto na may iba pang mga kakayahan:

• awtomatikong pagbuo ng modelo ng resource-service batay sa ML, sa halip na mga panuntunan at ahente (marahil ang pangunahing hamon ngayon);
• suporta para sa karagdagang mga scripting at logic na wika (at ito ay magiging JavaScript).

Sa aking opinyon, ang pinakamahalagang bagayAng ipinapakita ng pilot na ito ay dalawang bagay:

1. Ang pakikipagsosyo sa kliyente ay ang susi sa pagiging epektibo, kapag ang epektibong komunikasyon ay binuo batay sa katapatan at pagiging bukas, at ang kliyente ay naging bahagi ng isang pangkat na nakakamit ng makabuluhang mga resulta sa maikling panahon.
2. Sa anumang pagkakataon ay hindi kinakailangan na "i-customize" at bumuo ng "mga saklay" - tanging mga solusyon sa system. Mas mainam na gumugol ng kaunting oras, ngunit gumawa ng solusyon sa system na gagamitin ng ibang mga kliyente. Sa pamamagitan ng paraan, ito ang nangyari, ang sistema ng plugin at ang pag-aalis ng pag-asa sa Azure ay nagbigay ng karagdagang halaga sa iba pang mga kliyente (hello, Federal Law 152).

Pinagmulan: www.habr.com