Abbiamo pensato di creare un sistema di monitoraggio nella fase di formazione dei team di prodotto. È diventato chiaro che la nostra attività, lo sfruttamento, non rientra in queste squadre. Perché?
Il fatto è che tutti i nostri team sono costruiti attorno a singoli sistemi informativi, microservizi e fronti, quindi i team non vedono la salute generale dell'intero sistema nel suo complesso. Ad esempio, potrebbero non sapere in che modo alcune piccole parti nel backend profondo influiscono sul front-end. Il loro ambito di interesse è limitato ai sistemi con cui il loro sistema è integrato. Se una squadra e il suo servizio A non hanno quasi alcun collegamento con il servizio B, tale servizio è quasi invisibile alla squadra.
Il nostro team, a sua volta, lavora con sistemi fortemente integrati tra loro: ci sono molte connessioni tra loro, questa è un'infrastruttura molto grande. E il funzionamento del negozio online dipende da tutti questi sistemi (di cui, tra l'altro, ne abbiamo un numero enorme).
Quindi si scopre che il nostro dipartimento non appartiene a nessuna squadra, ma si trova un po' di lato. In tutta questa storia, il nostro compito è comprendere in modo completo come funzionano i sistemi informativi, le loro funzionalità, integrazioni, software, rete, hardware e come tutto questo è collegato tra loro.
La piattaforma su cui operano i nostri negozi online si presenta così:
- anteriore
- ufficio nel mezzo
- back office
Non importa quanto vorremmo, non succede che tutti i sistemi funzionino in modo fluido e impeccabile. Il punto, ancora una volta, è il numero di sistemi e integrazioni: con qualcosa come il nostro, alcuni incidenti sono inevitabili, nonostante la qualità dei test. Inoltre, sia all'interno di un sistema separato che in termini di integrazione. Ed è necessario monitorare lo stato dell'intera piattaforma in modo completo e non solo una sua singola parte.
Idealmente, il monitoraggio dello stato a livello di piattaforma dovrebbe essere automatizzato. E siamo arrivati al monitoraggio come parte inevitabile di questo processo. Inizialmente, è stato costruito solo per la parte in prima linea, mentre gli specialisti di rete, gli amministratori di software e hardware avevano e hanno tuttora i propri sistemi di monitoraggio livello per livello. Tutte queste persone hanno seguito il monitoraggio solo al proprio livello; nessuno aveva nemmeno una comprensione completa.
Se ad esempio una macchina virtuale si blocca, nella maggior parte dei casi lo sa solo l'amministratore responsabile dell'hardware e della macchina virtuale. In questi casi, il team in prima linea ha visto il fatto stesso del crash dell'applicazione, ma non disponeva di dati sul crash della macchina virtuale. E l'amministratore può sapere chi è il cliente e avere un'idea approssimativa di ciò che è attualmente in esecuzione su questa macchina virtuale, a condizione che si tratti di una sorta di progetto di grandi dimensioni. Molto probabilmente non sa dei più piccoli. In ogni caso, l'amministratore deve rivolgersi al proprietario e chiedere cosa c'era su questa macchina, cosa deve essere ripristinato e cosa deve essere modificato. E se qualcosa di veramente serio si rompeva, cominciavano a girare in tondo, perché nessuno vedeva il sistema nel suo insieme.
In definitiva, storie così disparate influenzano l'intero frontend, gli utenti e la nostra funzione aziendale principale: le vendite online. Poiché non facciamo parte di un team, ma ci occupiamo della gestione di tutte le applicazioni di e-commerce nell'ambito di un negozio online, ci siamo impegnati a creare un sistema di monitoraggio completo per la piattaforma di e-commerce.
Struttura del sistema e stack
Abbiamo iniziato identificando diversi livelli di monitoraggio per i nostri sistemi, all'interno dei quali avremmo dovuto raccogliere parametri. E tutto questo doveva essere combinato, ed è quello che abbiamo fatto nella prima fase. Ora, in questa fase, stiamo finalizzando la raccolta di parametri della massima qualità in tutti i nostri livelli al fine di creare una correlazione e comprendere come i sistemi si influenzano a vicenda.
La mancanza di un monitoraggio completo nelle fasi iniziali del lancio dell'applicazione (poiché abbiamo iniziato a costruirla quando la maggior parte dei sistemi erano in produzione) ha portato al fatto che avevamo un debito tecnico significativo per impostare il monitoraggio dell'intera piattaforma. Non potevamo permetterci di concentrarci sulla creazione del monitoraggio di un sistema informatico e sulla sua elaborazione dettagliata, poiché il resto dei sistemi rimarrebbe senza monitoraggio per un certo periodo. Per risolvere questo problema, abbiamo identificato un elenco delle metriche più necessarie per valutare lo stato del sistema informativo per livello e abbiamo iniziato a implementarlo.
Pertanto, hanno deciso di mangiare l'elefante in alcune parti.
Il nostro sistema è composto da:
- hardware;
- sistema operativo;
- Software;
- Parti dell'interfaccia utente nell'applicazione di monitoraggio;
- metriche aziendali;
- applicazioni di integrazione;
- informazioni di sicurezza;
- reti;
- bilanciatore del traffico.
Al centro di questo sistema c’è il monitoraggio stesso. Per comprendere in generale lo stato dell'intero sistema, è necessario sapere cosa sta succedendo con le applicazioni su tutti questi livelli e nell'intero set di applicazioni.
Quindi, riguardo allo stack.
Utilizziamo software open source. Al centro abbiamo Zabbix, che utilizziamo principalmente come sistema di allerta. Tutti sanno che è l'ideale per il monitoraggio delle infrastrutture. Cosa significa questo? Esattamente quelle metriche di basso livello di cui dispone ogni azienda che mantiene il proprio data center (e Sportmaster ha i propri data center): temperatura del server, stato della memoria, raid, metriche dei dispositivi di rete.
Abbiamo integrato Zabbix con il messenger Telegram e Microsoft Teams, che vengono utilizzati attivamente nei team. Zabbix copre il livello della rete vera e propria, dell'hardware e di alcuni software, ma non è una panacea. Arricchiamo questi dati da alcuni altri servizi. Ad esempio, a livello hardware, ci colleghiamo direttamente tramite API al nostro sistema di virtualizzazione e raccogliamo dati.
Cos'altro. Oltre a Zabbix, utilizziamo Prometheus, che ci consente di monitorare le metriche in un'applicazione in ambiente dinamico. Cioè, possiamo ricevere le metriche dell'applicazione tramite un endpoint HTTP e non preoccuparci di quali metriche caricarvi e quali no. Sulla base di questi dati è possibile sviluppare query analitiche.
Le origini dati per altri livelli, ad esempio le metriche aziendali, sono divise in tre componenti.
Innanzitutto, si tratta di sistemi aziendali esterni, Google Analytics, raccogliamo metriche dai log. Da loro otteniamo dati sugli utenti attivi, sulle conversioni e su tutto ciò che riguarda l'attività. In secondo luogo, questo è un sistema di monitoraggio dell'interfaccia utente. Dovrebbe essere descritto in modo più dettagliato.
Una volta abbiamo iniziato con i test manuali e siamo cresciuti fino a diventare test automatici di funzionalità e integrazioni. Da questo abbiamo effettuato il monitoraggio, lasciando solo la funzionalità principale, e ci siamo affidati a marcatori quanto più stabili possibile e che non cambiano spesso nel tempo.
La nuova struttura dei team implica che tutte le attività relative alle applicazioni siano limitate ai team di prodotto, quindi abbiamo smesso di eseguire test puri. Invece, abbiamo effettuato il monitoraggio dell'interfaccia utente dai test, scritti in Java, Selenium e Jenkins (utilizzati come sistema per l'avvio e la generazione di report).
Abbiamo fatto molti test, ma alla fine abbiamo deciso di seguire la strada principale, la metrica di massimo livello. E se avremo molti test specifici, sarà difficile mantenere aggiornati i dati. Ogni versione successiva danneggerà in modo significativo l'intero sistema e tutto ciò che faremo sarà risolverlo. Pertanto, ci siamo concentrati su aspetti fondamentali che raramente cambiano e li monitoriamo solo.
Infine, in terzo luogo, la fonte dei dati è un sistema di registrazione centralizzato. Utilizziamo Elastic Stack per i log e quindi possiamo inserire questi dati nel nostro sistema di monitoraggio per le metriche aziendali. Oltre a tutto questo, disponiamo del nostro servizio API di monitoraggio, scritto in Python, che interroga qualsiasi servizio tramite API e raccoglie i dati da essi in Zabbix.
Un altro attributo indispensabile del monitoraggio è la visualizzazione. Il nostro è basato su Grafana. Si distingue dagli altri sistemi di visualizzazione in quanto consente di visualizzare metriche provenienti da diverse origini dati sulla dashboard. Possiamo raccogliere parametri di primo livello per un negozio online, ad esempio il numero di ordini effettuati nell'ultima ora dal DBMS, parametri sulle prestazioni per il sistema operativo su cui è in esecuzione questo negozio online da Zabbix e parametri per le istanze di questa applicazione da Prometeo. E tutto questo sarà su un'unica dashboard. Chiaro e accessibile.
Vorrei sottolineare la sicurezza: stiamo attualmente finalizzando il sistema, che in seguito integreremo con il sistema di monitoraggio globale. A mio avviso, i principali problemi che l’e-commerce deve affrontare nel campo della sicurezza informatica sono legati ai bot, ai parser e alla forza bruta. Dobbiamo tenere d’occhio questo aspetto, perché tutto ciò può incidere in modo critico sia sul funzionamento delle nostre applicazioni che sulla nostra reputazione dal punto di vista aziendale. E con lo stack scelto copriamo con successo questi compiti.
Un altro punto importante è che il livello di applicazione viene assemblato da Prometheus. Anche lui stesso è integrato con Zabbix. E abbiamo anche sitespeed, un servizio che ci permette di visualizzare parametri come la velocità di caricamento della nostra pagina, i colli di bottiglia, il rendering della pagina, il caricamento degli script, ecc., inoltre è integrato tramite API. Quindi le nostre metriche vengono raccolte in Zabbix e, di conseguenza, avvisiamo anche da lì. Tutti gli alert al momento vengono inviati sulle principali modalità di invio (per ora si tratta di email e telegram, recentemente si è collegato anche MS Teams). Sono previsti piani per aggiornare gli avvisi a uno stato tale che i robot intelligenti funzionino come un servizio e forniscano informazioni di monitoraggio a tutti i team di prodotto interessati.
Per noi le metriche sono importanti non solo per i singoli sistemi informativi, ma anche metriche generali per l'intera infrastruttura utilizzata dalle applicazioni: cluster di server fisici su cui girano le macchine virtuali, bilanciatori del traffico, Network Load Balancer, la rete stessa, utilizzo dei canali di comunicazione . Inoltre metriche per i nostri data center (ne abbiamo diversi e l'infrastruttura è piuttosto grande).
I vantaggi del nostro sistema di monitoraggio sono che con il suo aiuto vediamo lo stato di salute di tutti i sistemi e possiamo valutare il loro impatto reciproco e sulle risorse condivise. E, in definitiva, ci consente di impegnarci nella pianificazione delle risorse, che è anche nostra responsabilità. Gestiamo le risorse del server: un pool all'interno dell'e-commerce, commissioniamo e smantellamo nuove apparecchiature, acquistiamo nuove apparecchiature aggiuntive, conduciamo un audit sull'utilizzo delle risorse, ecc. Ogni anno i team pianificano nuovi progetti, sviluppano i loro sistemi ed è importante per noi fornire loro le risorse.
E con l'aiuto dei parametri, vediamo l'andamento del consumo di risorse da parte dei nostri sistemi informativi. E sulla base di essi possiamo pianificare qualcosa. A livello di virtualizzazione, raccogliamo dati e vediamo informazioni sulla quantità disponibile di risorse per data center. E già all’interno del data center è possibile vedere il riciclo, l’effettiva distribuzione e il consumo delle risorse. Inoltre, sia con server autonomi e macchine virtuali che con cluster di server fisici su cui tutte queste macchine virtuali girano vigorosamente.
prospettive
Ora abbiamo il nucleo del sistema nel suo complesso pronto, ma ci sono ancora molte cose su cui bisogna lavorare. Come minimo, si tratta di un livello di sicurezza delle informazioni, ma è anche importante raggiungere la rete, sviluppare avvisi e risolvere il problema della correlazione. Abbiamo molti livelli e sistemi e su ogni livello ci sono molte più metriche. Risulta essere una matrioska al grado di una matrioska.
Il nostro compito è, in definitiva, creare gli avvisi giusti. Ad esempio, se si verificasse un problema con l'hardware, ancora una volta, con una macchina virtuale e fosse presente un'applicazione importante e non fosse stato eseguito in alcun modo il backup del servizio. Scopriamo che la macchina virtuale è morta. Quindi le metriche aziendali ti avviseranno: gli utenti sono scomparsi da qualche parte, non c'è conversione, l'interfaccia utente nell'interfaccia non è disponibile, anche software e servizi sono morti.
In questa situazione riceveremo spam dagli alert, e questo non rientra più nel formato di un vero e proprio sistema di monitoraggio. Si pone la questione della correlazione. Pertanto, idealmente, il nostro sistema di monitoraggio dovrebbe dire: “Ragazzi, la vostra macchina fisica è morta, e con essa questa applicazione e questi parametri”, con l’aiuto di un avviso, invece di bombardarci furiosamente con un centinaio di avvisi. Dovrebbe riportare la cosa principale: la causa, che aiuta a eliminare rapidamente il problema grazie alla sua localizzazione.
Il nostro sistema di notifica e l'elaborazione degli avvisi si basano su un servizio di hotline attivo XNUMX ore su XNUMX. Tutti gli avvisi considerati indispensabili e inclusi nella lista di controllo vengono inviati lì. Ogni avviso deve avere una descrizione: cosa è successo, cosa significa effettivamente, cosa influenza. E anche un collegamento alla dashboard e le istruzioni su cosa fare in questo caso.
Riguarda i requisiti per creare un avviso. Allora la situazione può svilupparsi in due direzioni: o c'è un problema che deve essere risolto, oppure si è verificato un guasto nel sistema di monitoraggio. Ma in ogni caso, devi andare a capirlo.
In media riceviamo ormai circa un centinaio di avvisi al giorno, tenendo conto del fatto che la correlazione degli avvisi non è stata ancora configurata correttamente. E se dobbiamo eseguire lavori tecnici e spegniamo forzatamente qualcosa, il loro numero aumenta in modo significativo.
Oltre a monitorare i sistemi che gestiamo e a raccogliere parametri considerati importanti dalla nostra parte, il sistema di monitoraggio ci consente di raccogliere dati per i team di prodotto. Possono influenzare la composizione dei parametri all'interno dei sistemi informativi che monitoriamo.
Il nostro collega potrebbe venire e chiedere di aggiungere qualche metrica che sarà utile sia per noi che per il team. Oppure, ad esempio, il team potrebbe non avere abbastanza delle metriche di base di cui disponiamo; ha bisogno di monitorarne alcune specifiche. In Grafana creiamo uno spazio per ogni squadra e concediamo i diritti di amministratore. Inoltre, se un team ha bisogno di dashboard, ma lui stesso non può/non sa come farlo, lo aiutiamo.
Poiché siamo fuori dal flusso della creazione di valore del team, dei loro rilasci e della pianificazione, stiamo gradualmente giungendo alla conclusione che i rilasci di tutti i sistemi avvengono senza soluzione di continuità e possono essere implementati quotidianamente senza coordinamento con noi. Ed è importante per noi monitorare questi rilasci, perché potrebbero potenzialmente influenzare il funzionamento dell’applicazione e rompere qualcosa, e questo è fondamentale. Per gestire le versioni utilizziamo Bamboo, da dove riceviamo dati tramite API e possiamo vedere quali versioni sono state rilasciate in quali sistemi informativi e il loro stato. E la cosa più importante è a che ora. Sovrapponiamo i marcatori di rilascio alle principali metriche critiche, il che è visivamente molto indicativo in caso di problemi.
In questo modo possiamo vedere la correlazione tra le nuove versioni e i problemi emergenti. L'idea principale è capire come funziona il sistema a tutti i livelli, localizzare rapidamente il problema e risolverlo altrettanto rapidamente. Dopotutto, capita spesso che ciò che richiede più tempo non sia la risoluzione del problema, ma la ricerca della causa.
E in questo ambito in futuro vogliamo puntare sulla proattività. Idealmente, vorrei essere informato in anticipo di un problema imminente, e non dopo, in modo da poterlo prevenire anziché risolverlo. A volte si verificano falsi allarmi del sistema di monitoraggio, sia per errori umani che per cambiamenti nell'applicazione, e noi lavoriamo su questo, ne debugghiamo e proviamo ad avvisare gli utenti che lo utilizzano con noi prima di qualsiasi manipolazione del sistema di monitoraggio , oppure svolgere queste attività nella finestra tecnica.
Quindi il sistema è stato lanciato e funziona con successo dall'inizio della primavera... e sta mostrando profitti molto reali. Naturalmente questa non è la versione finale; introdurremo molte altre funzionalità utili. Ma al momento, con così tante integrazioni e applicazioni, il monitoraggio dell’automazione è davvero inevitabile.
Se monitori anche progetti di grandi dimensioni con un numero significativo di integrazioni, scrivi nei commenti quale soluzione miracolosa hai trovato per questo.
Fonte: habr.com