Perché una banca ha bisogno di AIOps e di un monitoraggio generale o su cosa si basano le relazioni con i clienti?

Nelle pubblicazioni su Habré, ho già scritto della mia esperienza nella creazione di partenariati con il mio team (qui parla di come stipulare un accordo di partenariato quando si avvia una nuova attività in modo che l'attività non vada in pezzi). E ora vorrei parlare di come costruire partnership con i clienti, poiché senza di loro non ci sarà nulla che andrà in pezzi. Spero che questo articolo possa essere utile alle startup che stanno iniziando a vendere i propri prodotti alle grandi aziende.

Attualmente sono a capo di una startup chiamata MONQ Digital lab, dove io e il mio team stiamo sviluppando un prodotto per automatizzare i processi di supporto e funzionamento dell'IT aziendale. Entrare nel mercato non è un compito facile e abbiamo iniziato con un po’ di compiti a casa, abbiamo consultato esperti di mercato, i nostri partner e abbiamo effettuato la segmentazione del mercato. La domanda principale era capire “quali dolori possiamo guarire meglio?”

Le banche sono entrate nei primi 3 segmenti. E, naturalmente, i primi della lista erano Tinkoff e Sberbank. Quando abbiamo visitato gli esperti del mercato bancario, ci hanno detto: presenta lì il tuo prodotto e la strada verso il mercato bancario sarà aperta. Abbiamo provato ad entrare sia di qua che di là, ma a Sberbank ci aspettava il fallimento, ei ragazzi di Tinkoff si sono rivelati molto più aperti alla comunicazione produttiva con le startup russe (forse a causa del fatto che Sber in quel momento comprato quasi un miliardo di nostri concorrenti occidentali). Nel giro di un mese abbiamo avviato un progetto pilota. Come è successo, continua a leggere.

Ci occupiamo da molti anni di questioni relative al funzionamento e al monitoraggio, ora stiamo implementando il nostro prodotto nel settore pubblico, nelle assicurazioni, nelle banche, nelle società di telecomunicazioni, un'implementazione è avvenuta con una compagnia aerea (prima del progetto non lo sapevamo nemmeno pensiamo che l'aviazione fosse un settore così dipendente dall'IT, e ora speriamo davvero, nonostante il COVID, che la compagnia emerga e decolli).

Il prodotto che realizziamo appartiene al software aziendale, al segmento AIOps (Artificial Intelligence for IT Operations, o ITOps). Gli obiettivi principali dell'implementazione di tali sistemi aumentano il livello di maturità dei processi nell'azienda:

1. Spegnere gli incendi: identificare i guasti, liberare il flusso di allarmi dai detriti, assegnare compiti e incidenti ai responsabili;
2. Aumentare l'efficienza del servizio IT: ridurre i tempi per risolvere gli incidenti, indicare le cause dei guasti, aumentare la trasparenza dello stato IT;
3. Aumentare l’efficienza aziendale: ridurre la quantità di lavoro manuale, ridurre i rischi, aumentare la fidelizzazione dei clienti.

Nella nostra esperienza, le banche hanno i seguenti “dolori” con il monitoraggio in comune con tutte le grandi infrastrutture IT:

• “chissà cosa”: ci sono tanti reparti tecnici, quasi tutti hanno almeno un sistema di monitoraggio, la maggior parte ne ha più di uno;
• “sciame di zanzare” di alert: ogni sistema ne genera centinaia e bombarda con essi tutti i responsabili (a volte anche tra reparti). È difficile mantenere costantemente il focus del controllo su ogni notifica; la loro urgenza e importanza sono livellate a causa del gran numero;
• le grandi banche – i leader del settore vogliono non solo monitorare continuamente i propri sistemi, per sapere dove ci sono i fallimenti, ma anche la vera magia dell’intelligenza artificiale – far sì che i sistemi si automonitorino, si autoprevedano e si autocorreggano.

Quando siamo arrivati ​​al primo incontro a Tinkoff, ci è stato subito detto che non avevano problemi con il monitoraggio e che nulla gli faceva male, e la domanda principale era: “Cosa possiamo offrire a coloro che stanno già andando bene?”

La conversazione è stata lunga, abbiamo discusso di come sono costruiti i loro microservizi, di come funzionano i dipartimenti, quali problemi infrastrutturali sono più delicati, quali sono meno sensibili per gli utenti, dove sono i “punti ciechi” e quali sono i loro obiettivi e SLA.

A proposito, gli SLA della banca sono davvero impressionanti. Ad esempio, la risoluzione di un incidente relativo alla disponibilità della rete con priorità XNUMX potrebbe richiedere solo pochi minuti. Il costo degli errori e dei tempi di inattività in questo caso, ovviamente, è impressionante.

Di conseguenza, abbiamo identificato diverse aree di cooperazione:

1. la prima fase è il monitoraggio generale per aumentare la velocità di risoluzione degli incidenti
2. la seconda fase è l'automazione dei processi per ridurre i rischi e ridurre i costi per il ridimensionamento del reparto IT.

Molti “punti bianchi” potevano essere dipinti con i colori vivaci degli allarmi solo elaborando le informazioni provenienti da diversi sistemi di monitoraggio, poiché era impossibile acquisire direttamente i parametri; era inoltre necessario centralizzare i dati di diversi sistemi di monitoraggio su “un unico schermo” per per comprendere il quadro complessivo di ciò che stava accadendo. Gli “ombrelloni” sono adatti a questo compito e allora abbiamo soddisfatto questi requisiti.

Una cosa molto importante, secondo noi, nei rapporti con i clienti è l'onestà. Dopo la prima conversazione e il calcolo del costo della licenza, è stato detto che, poiché il costo è così basso, potrebbe valere la pena acquistare subito una licenza (rispetto a Dynatrace Klyuch-Astrom dell'articolo sopra sulla banca verde, la nostra la licenza non costa un terzo di miliardo, ma 12mila rubli al mese per 1 gigabyte, per Sber costerebbe molte volte meno). Ma abbiamo subito detto loro cosa abbiamo e cosa no. Forse il rappresentante commerciale di un grande integratore potrebbe dire “sì, possiamo fare tutto, ovviamente compriamo la nostra licenza”, ma noi abbiamo deciso di mettere tutte le carte in tavola. Al momento del lancio, il nostro box non aveva l'integrazione con Prometheus e stava per essere rilasciata una nuova versione con un sottosistema di automazione, ma non l'abbiamo ancora spedita ai clienti.

Il progetto pilota è iniziato, i suoi confini sono stati determinati e ci sono stati concessi 2 mesi. I compiti principali erano:

• preparare una nuova versione della piattaforma e implementarla nell’infrastruttura della banca
• collegare 2 sistemi di monitoraggio (Zabbix e Prometheus);
• inviare notifiche ai responsabili in Slack e via SMS;
• eseguire script di riparazione automatica.

Il primo mese del progetto pilota è stato dedicato alla preparazione di una nuova versione della piattaforma in modalità super veloce per le esigenze del progetto pilota. La nuova versione include immediatamente l'integrazione con Prometheus e la riparazione automatica. Grazie al nostro team di sviluppo, non hanno dormito per diverse notti, ma hanno mantenuto ciò che avevano promesso senza rispettare le scadenze di altri impegni presi in precedenza.

Mentre stavamo impostando il progetto pilota, abbiamo riscontrato un nuovo problema che avrebbe potuto chiudere il progetto prima del previsto: per inviare avvisi alla messaggistica istantanea e via SMS, avevamo bisogno di connessioni in entrata e in uscita ai server Microsoft Azure (all'epoca utilizzavamo questa piattaforma per inviare avvisi a Slack) e un servizio di invio SMS esterno. Ma in questo progetto la sicurezza è stata un focus particolare. Secondo la politica della banca, tali “buchi” non potevano essere aperti in nessun caso. Tutto doveva funzionare a circuito chiuso. Ci è stato offerto di utilizzare l'API dei nostri servizi interni che inviano avvisi a Slack e tramite SMS, ma non abbiamo avuto l'opportunità di connettere tali servizi immediatamente.

Una serata di dibattito con il team di sviluppo si è conclusa con la ricerca riuscita di una soluzione. Dopo aver frugato nel backlog, abbiamo trovato un compito per il quale non avevamo mai abbastanza tempo e priorità: creare un sistema di plug-in in modo che i team di implementazione o il cliente potessero scrivere autonomamente i componenti aggiuntivi, espandendo le capacità della piattaforma.

Ma ci restava esattamente un mese, durante il quale dovevamo installare tutto, configurare e implementare l'automazione.

Secondo Sergei, il nostro capo architetto, ci vuole almeno un mese per implementare il sistema plug-in.

Non abbiamo avuto tempo...

C'era solo una soluzione: andare dal cliente e dire tutto così com'è. Discutete insieme lo spostamento della scadenza. E ha funzionato. Ci sono state concesse 2 settimane in più. Avevano anche le proprie scadenze e obblighi interni per mostrare i risultati, ma avevano 2 settimane di riserva. Alla fine mettiamo tutto in gioco. Era impossibile sbagliare. L'onestà e l'approccio collaborativo hanno dato ancora una volta i loro frutti.

Come risultato del progetto pilota, sono stati ottenuti numerosi importanti risultati tecnici e conclusioni:

Abbiamo testato la nuova funzionalità per l'elaborazione degli avvisi

Il sistema distribuito ha iniziato a ricevere correttamente gli avvisi da Prometheus e a raggrupparli. Gli avvisi sul problema dal client Prometheus volavano ogni 30 secondi (il raggruppamento per ora non è abilitato) e ci chiedevamo se fosse possibile raggrupparli nell'"ombrello" stesso. Si è scoperto che è possibile: l'impostazione dell'elaborazione degli avvisi nella piattaforma viene implementata tramite uno script. Ciò rende possibile implementare quasi tutte le logiche per elaborarli. Abbiamo già implementato la logica standard nella piattaforma sotto forma di modelli: se non vuoi inventare qualcosa di tuo, puoi utilizzarne uno già pronto.

Interfaccia “trigger sintetico”. Impostazione dell'elaborazione degli avvisi provenienti dai sistemi di monitoraggio collegati

Costruito lo stato di “salute” del sistema

In base agli avvisi, sono stati creati eventi di monitoraggio che hanno influito sull'integrità delle unità di configurazione (CU). Stiamo implementando un modello di servizio risorse (RSM), che può utilizzare un CMDB interno o connetterne uno esterno: durante il progetto pilota il cliente non ha connesso il proprio CMDB.

Interfaccia per lavorare con il modello di servizio-risorsa. Pilota RSM.

Ebbene, infatti, il client ha finalmente un'unica schermata di monitoraggio, dove sono visibili gli eventi provenienti da diversi sistemi. Attualmente all’“ombrello” sono collegati due sistemi, Zabbix e Prometheus, e un sistema di monitoraggio interno della piattaforma stessa.

Interfaccia di analisi. Schermata di monitoraggio unica.

Avviata l'automazione dei processi

Il monitoraggio degli eventi ha innescato il lancio di azioni preconfigurate - invio di avvisi, esecuzione di script, registrazione/arricchimento di incidenti - quest'ultima non è stata provata con questo particolare client, perché nel progetto pilota non era prevista l'integrazione con il service desk.

Interfaccia delle impostazioni delle azioni. Invia avvisi a Slack e riavvia il server.

Funzionalità del prodotto ampliata

Discutendo degli script di automazione, il cliente ha chiesto il supporto di bash e un'interfaccia in cui questi script potessero essere comodamente configurati. La nuova versione ha fatto qualcosa in più (la capacità di scrivere costrutti logici completi in Lua con supporto per cURL, SSH e SNMP) e ha implementato funzionalità che consentono di gestire il ciclo di vita di uno script (creazione, modifica, controllo della versione , elimina e archivia).

Interfaccia per lavorare con script di riparazione automatica. Script di riavvio del server tramite SSH.

Risultati principali

Durante il pilota sono state create anche user story che migliorano le funzionalità attuali e aumentano il valore per il cliente, eccone alcune:

• implementare la possibilità di inoltrare le variabili direttamente dall'avviso allo script di autoriparazione;
• aggiungere l'autorizzazione alla piattaforma tramite Active Directory.

E abbiamo ricevuto sfide più globali: "costruire" il prodotto con altre funzionalità:

• costruzione automatica di un modello di servizi-risorse basato sul ML, piuttosto che su regole e agenti (probabilmente la sfida principale ora);
• supporto per linguaggi di scripting e logici aggiuntivi (e questo sarà JavaScript).

A mio parere, la cosa più importanteCiò che questo pilota mostra sono due cose:

1. Le partnership con il cliente sono la chiave dell'efficacia, quando una comunicazione efficace è costruita sulla base dell'onestà e dell'apertura e il cliente diventa parte di un team che raggiunge risultati significativi in ​​breve tempo.
2. In nessun caso è necessario "personalizzare" e costruire "stampelle" - solo soluzioni di sistema. È meglio dedicare un po’ più di tempo, ma creare una soluzione di sistema che verrà utilizzata da altri clienti. A proposito, questo è quello che è successo, il sistema di plugin e l'eliminazione della dipendenza da Azure hanno fornito valore aggiunto ad altri clienti (ciao, legge federale 152).

Fonte: habr.com