Per què un banc necessita AIOps i monitoratge paraigua, o en què es basen les relacions amb els clients?

A les publicacions sobre Habré, ja vaig escriure sobre la meva experiència en la creació d'associacions amb el meu equip (aquí parla de com redactar un acord de col·laboració a l'hora d'iniciar un nou negoci per tal que el negoci no s'esfondri). I ara m'agradaria parlar de com establir associacions amb els clients, ja que sense ells no hi haurà res a trencar. Espero que aquest article sigui útil per a startups que comencen a vendre el seu producte a grans empreses.

Actualment estic al capdavant d'una startup anomenada MONQ Digital lab, on el meu equip i jo estem desenvolupant un producte per automatitzar els processos de suport i funcionament de la informàtica corporativa. Entrar al mercat no és una tasca fàcil i vam començar amb una mica de deures, vam passar per experts del mercat, els nostres socis i vam fer la segmentació del mercat. La pregunta principal era entendre "els dolors de qui podem curar millor?"

Els bancs van arribar als 3 segments TOP. I, per descomptat, els primers de la llista van ser Tinkoff i Sberbank. Quan vam visitar els experts del mercat bancari, ens van dir: introduïu-hi el vostre producte i el camí cap al mercat bancari estarà obert. Vam intentar entrar tant allà com allà, però el fracàs ens esperava a Sberbank, i els nois de Tinkoff van resultar molt més oberts a la comunicació productiva amb les startups russes (potser a causa del fet que Sber en aquell moment). comprat gairebé mil milions dels nostres competidors occidentals). En un mes vam començar un projecte pilot. Com va passar, segueix llegint.

Fa molts anys que tractem temes d'operació i seguiment, ara estem implantant el nostre producte en el sector públic, en assegurances, en bancs, en empreses de telecomunicacions, una implementació era amb una companyia aèria (abans del projecte, ni tan sols Penseu que l'aviació era una indústria tan dependent de les TI, i ara realment esperem, malgrat el COVID, que l'empresa sorgeixi i surti).

El producte que fabriquem pertany al programari empresarial, el segment AIOps (Intel·ligència artificial per a operacions de TI, o ITOps). Els principals objectius d'implementar sistemes com el nivell de maduresa del procés a l'empresa augmenta:

1. Apagar incendis: identificar fallades, netejar el flux d'alertes de runes, assignar tasques i incidències als responsables;
2. Augmentar l'eficiència del servei informàtic: reduir el temps de resolució d'incidències, indicar les causes dels errors, augmentar la transparència de l'estat informàtic;
3. Augmentar l'eficiència empresarial: reduir la quantitat de treball manual, reduir riscos, augmentar la fidelització dels clients.

Segons la nostra experiència, els bancs tenen els següents "dolors" amb la supervisió en comú amb totes les grans infraestructures de TI:

• “qui sap què”: hi ha molts departaments tècnics, gairebé tothom té almenys un sistema de seguiment, i la majoria en tenen més d'un;
• “eixam de mosquits” d'alertes: cada sistema en genera centenars i bombardeja amb ells tots els responsables (a vegades també entre departaments). És difícil mantenir constantment el focus de control de cada notificació, la seva urgència i importància s'anivella a causa del gran nombre;
• els grans bancs -els líders del sector volen no només supervisar contínuament els seus sistemes, saber on hi ha fallades, sinó també la veritable màgia de la IA- per fer que els sistemes s'autocontrolin, s'autoprediguin i s'autocorregin.

Quan vam arribar a la primera reunió a Tinkoff, de seguida ens van dir que no tenien problemes amb el seguiment i que res els feia mal, i la pregunta principal era: "Què podem oferir als que ja ho estan fent bé?"

La conversa va ser llarga, vam parlar de com es construeixen els seus microserveis, com funcionen els departaments, quins problemes d'infraestructura són més sensibles, quins són menys sensibles per als usuaris, on es troben els "punts cecs" i quins són els seus objectius i SLA.

Per cert, els SLA del banc són realment impressionants. Per exemple, un incident de disponibilitat de xarxa de prioritat XNUMX només pot trigar uns minuts a resoldre's. El cost de l'error i el temps d'inactivitat aquí, per descomptat, és impressionant.

Com a resultat, hem identificat diverses àrees de cooperació:

1. la primera etapa és el control de paraigües per augmentar la velocitat de resolució d'incidències
2. la segona etapa és l'automatització de processos per reduir els riscos i reduir els costos per escalar el departament de TI.

Diversos "punts blancs" es podien pintar amb els colors brillants de les alertes només processant la informació de diversos sistemes de monitorització, ja que era impossible prendre mètriques directament; també era necessari centralitzar les dades de diferents sistemes de monitoratge en "una pantalla" per tal per entendre el panorama general del que estava passant. Els "paraigües" són adequats per a aquesta tasca i vam complir aquests requisits aleshores.

Una cosa molt important, al nostre parer, en les relacions amb els clients és l'honestedat. Després de la primera conversa i el càlcul del cost de la llicència, es va dir que, com que el cost és tan baix, potser val la pena comprar una llicència immediatament (en comparació amb Dynatrace Klyuch-Astrom de l'article anterior sobre el banc verd, el nostre la llicència no costa un terç de mil milions, sinó 12 mil rubles al mes per 1 gigabyte, per a Sber costaria diverses vegades més barat). Però de seguida els vam dir què tenim i què no. Potser un representant de vendes d'un gran integrador podria dir "sí, ho podem fer tot, per descomptat comprar la nostra llicència", però vam decidir posar totes les nostres cartes sobre la taula. En el moment del llançament, la nostra caixa no tenia integració amb Prometheus i estava a punt de llançar-se una nova versió amb un subsistema d'automatització, però encara no l'hem enviat als clients.

Va començar el projecte pilot, es van determinar els seus límits i ens van donar 2 mesos. Les tasques principals eren:

• preparar una nova versió de la plataforma i desplegar-la a la infraestructura del banc
• connectar 2 sistemes de monitorització (Zabbix i Prometheus);
• enviar notificacions als responsables a Slack i per SMS;
• executar scripts de curació automàtica.

El primer mes del projecte pilot es va dedicar a preparar una nova versió de la plataforma en mode súper ràpid per a les necessitats del projecte pilot. La nova versió inclou immediatament la integració amb Prometheus i la curació automàtica. Gràcies al nostre equip de desenvolupament, no van dormir durant diverses nits, però van alliberar el que van prometre sense perdre els terminis per a altres compromisos anteriors.

Mentre estàvem configurant el pilot, ens vam trobar amb un nou problema que podria tancar el projecte abans del previst: per enviar alertes a missatgeria instantània i per SMS, necessitàvem connexions entrants i sortints als servidors de Microsoft Azure (aleshores vam utilitzar aquesta plataforma). per enviar alertes a Slack) i un servei d'enviament extern de SMS. Però en aquest projecte, la seguretat era un focus particular. D'acord amb la política del banc, aquests "forats" no es podrien obrir sota cap circumstància. Tot havia de funcionar des d'un bucle tancat. Ens van oferir utilitzar l'API dels nostres propis serveis interns que envien alertes a Slack i per SMS, però no vam tenir l'oportunitat de connectar aquests serveis de manera immediata.

Una vetllada de debat amb l'equip de desenvolupament va acabar amb una recerca exitosa d'una solució. Després d'haver buscat l'endarreriment, vam trobar una tasca per a la qual mai no vam tenir prou temps i prioritat: crear un sistema de complements perquè els equips d'implementació o el client poguessin escriure complements ells mateixos, ampliant les capacitats de la plataforma.

Però ens quedava exactament un mes, durant el qual vam haver d'instal·lar-ho tot, configurar i desplegar l'automatització.

Segons Sergei, el nostre arquitecte en cap, es necessita almenys un mes per implementar el sistema de connectors.

No hem tingut temps...

Només hi havia una solució: anar al client i explicar-ho tot tal com és. Parleu junts sobre el canvi de termini. I va funcionar. Ens van donar 2 setmanes més. També tenien els seus propis terminis i obligacions internes per mostrar resultats, però tenien 2 setmanes de reserva. Al final, ho posem tot en joc. Era impossible fer malbé. L'honestedat i un enfocament d'associació van tornar a donar els seus fruits.

Com a resultat del pilot, es van obtenir diversos resultats tècnics i conclusions importants:

Hem provat la nova funcionalitat per processar alertes

El sistema desplegat va començar a rebre correctament les alertes de Prometheus i a agrupar-les. Les alertes del problema del client de Prometheus volaven cada 30 segons (l'agrupació per temps no està habilitada), i ens preguntàvem si seria possible agrupar-les en el mateix “paraigua”. Va resultar que és possible: la configuració del processament d'alertes a la plataforma s'implementa mitjançant un script. Això fa possible implementar gairebé qualsevol lògica per processar-los. Ja hem implementat la lògica estàndard a la plataforma en forma de plantilles; si no voleu crear alguna cosa pròpia, podeu utilitzar-ne una de feta.

Interfície "disparador sintètic". Configuració del processament d'alertes dels sistemes de monitorització connectats

Construït l'estat de "salut" del sistema

A partir de les alertes, es van crear esdeveniments de monitorització que van afectar la salut de les unitats de configuració (CU). Estem implementant un model de servei de recursos (RSM), que pot utilitzar un CMDB intern o connectar-ne un extern; durant el projecte pilot, el client no va connectar el seu propi CMDB.

Interfície per treballar amb el model de recursos-servei. Pilot RSM.

Bé, de fet, finalment el client té una única pantalla de monitorització, on són visibles els esdeveniments de diferents sistemes. Actualment, dos sistemes estan connectats al "paraigua": Zabbix i Prometheus, i un sistema de control intern de la pròpia plataforma.

Interfície analítica. Pantalla de monitoratge única.

S'ha posat en marxa l'automatització de processos

La supervisió d'esdeveniments va desencadenar el llançament d'accions preconfigurades: enviament d'alertes, execució de scripts, registre/enriquiment d'incidències; aquesta última no es va provar amb aquest client en particular, perquè en el projecte pilot no hi havia integració amb el servei de servei.

Interfície de configuració d'acció. Envieu alertes a Slack i reinicieu el servidor.

Funcionalitat del producte ampliada

Quan es parlava dels scripts d'automatització, el client va demanar suport de bash i una interfície en què aquests scripts es poguessin configurar còmodament. La nova versió ha fet una mica més (la capacitat d'escriure construccions lògiques completes a Lua amb suport per a cURL, SSH i SNMP) i ha implementat una funcionalitat que permet gestionar el cicle de vida d'un script (crear, editar, controlar de versions). , suprimir i arxivar).

Interfície per treballar amb scripts de curació automàtica. Script de reinici del servidor mitjançant SSH.

Principals conclusions

Durant el pilot, també s'han creat històries d'usuari que milloren la funcionalitat actual i augmenten el valor per al client, aquestes són algunes d'elles:

• implementar la capacitat de reenviar variables directament des de l'alerta a l'script d'autocuració;
• afegir autorització a la plataforma mitjançant Active Directory.

I vam rebre més reptes globals: "construir" el producte amb altres capacitats:

• construcció automàtica d'un model de recursos-servei basat en ML, en lloc de regles i agents (probablement el principal repte ara);
• suport per a llenguatges de script i lògics addicionals (i això serà JavaScript).

Al meu entendre, el més importantEl que mostra aquest pilot són dues coses:

1. Les associacions amb el client són la clau de l'eficàcia, quan una comunicació eficaç es construeix sobre la base de l'honestedat i l'obertura, i el client passa a formar part d'un equip que aconsegueix resultats significatius en poc temps.
2. En cap cas és necessari "personalitzar" i construir "mulletes", només solucions del sistema. És millor dedicar una mica més de temps, però fer una solució de sistema que la faran servir altres clients. Per cert, això és el que va passar, el sistema de connectors i l'eliminació de la dependència d'Azure van aportar un valor addicional a altres clients (hola, Llei Federal 152).

Font: www.habr.com