Abbiamo iniziato a pensare alla creazione di un sistema di monitoraggio nella fase di formazione dei team di prodotto. È diventato chiaro che il nostro ambito — l'operatività — non rientra in questi team. Perché?
Il fatto è che tutte le nostre squadre sono costruite attorno a sistemi informativi separati, microservizi e front-end, quindi lo stato complessivo di salute dell'intero sistema non è visibile ai team. Ad esempio, potrebbero non sapere come una piccola parte nel profondo back-end influisca sulla parte front-end. I loro interessi sono limitati ai sistemi con cui è integrato il loro sistema. Se il team e il suo servizio A non sono praticamente collegati al servizio B, allora quel servizio è quasi invisibile per il team.
Il nostro team, a sua volta, lavora con sistemi che sono altamente integrati tra loro: ci sono molti legami tra di loro, ed è una grande infrastruttura. E il funzionamento di tutti questi sistemi (che, a proposito, sono moltissimi) dipende dal negozio online.
Ecco perché il nostro reparto non appartiene a nessun team, ma si trova un po' da parte. In tutta questa storia, il nostro compito è comprendere nel complesso come funzionano i sistemi informativi, la loro funzionalità, le integrazioni, il software, la rete, l'hardware e come tutto ciò sia interconnesso.
La piattaforma su cui funzionano i nostri negozi online appare così:
- front
- middle-office
- back-office
Per quanto ci piacerebbe, non esiste una situazione in cui tutti i sistemi funzionino senza intoppi e perfettamente. Il problema, ancora una volta, è il numero di sistemi e integrazioni: in un contesto come il nostro, alcuni incidenti sono inevitabili, nonostante la qualità dei test. Ciò vale sia all'interno di un singolo sistema, sia in termini della loro integrazione. E bisogna monitorare lo stato dell'intera piattaforma in modo complessivo, e non solo una sua parte.
Idealmente, la sorveglianza dello stato di salute dell'intera piattaforma dovrebbe essere automatizzata. E siamo giunti al monitoraggio come parte inevitabile di questo processo. Inizialmente era stato costruito solo per la parte front-end, mentre i sistemi di monitoraggio propri per livelli erano già presenti e ci sono ancora per i networker, gli amministratori di software e hardware. Tutte queste persone monitoravano solamente al loro livello, senza una comprensione complessiva.
Ad esempio, se una macchina virtuale si guasta, nella maggior parte dei casi solo l'amministratore responsabile dell'hardware e della macchina virtuale ne è a conoscenza. Il team frontale in questi casi ha visto solo il fatto che l'applicazione è caduta, ma non aveva dati sulla caduta della macchina virtuale. L'amministratore può sapere chi è il cliente e avere un'idea di cosa stia attualmente girando su quella macchina virtuale, purché si tratti di un progetto di grandi dimensioni. Per progetti più piccoli, probabilmente non ne è a conoscenza. In ogni caso, l'amministratore deve andare dal proprietario, chiedere cosa ci fosse su quella macchina, cosa deve essere ripristinato e cosa cambiare. E se si guastava qualcosa di molto serio, iniziava la corsa a vuoto, perché nessuno vedeva il sistema nel suo complesso.
In fin dei conti, queste storie frammentarie influenzano l'intero frontend, gli utenti e la nostra funzione aziendale principale: le vendite online. Poiché non facciamo parte dei team e ci occupiamo dell'operatività di tutte le applicazioni ecommerce all'interno del negozio online, ci siamo assunti il compito di creare un sistema di monitoraggio complesso per la piattaforma ecommerce.
Struttura del sistema e stack
Abbiamo iniziato isolando diversi strati di monitoraggio per i nostri sistemi, nei quali sarà necessario raccogliere metriche. Tutto questo doveva essere integrato, cosa che abbiamo fatto nella prima fase. Attualmente stiamo perfezionando la raccolta delle metriche per tutti i nostri strati, per costruire correlazioni e capire come i sistemi influenzano l'uno l'altro.
L'assenza di un monitoraggio complessivo nelle fasi iniziali del lancio delle applicazioni (poiché abbiamo iniziato a costruirlo quando gran parte dei sistemi era già in esercizio) ha portato a un significativo debito tecnico nella configurazione del monitoraggio di tutta la piattaforma. Non potevamo permetterci di concentrarci sulla configurazione del monitoraggio di un singolo sistema informativo e di lavorare in dettaglio su di esso, poiché gli altri sistemi sarebbero rimasti senza monitoraggio per un certo periodo. Per risolvere questo problema, abbiamo definito un elenco delle metriche più necessarie per valutare lo stato del sistema informativo per strati e abbiamo iniziato a implementarlo.
Perciò, abbiamo deciso di affrontare l'elefante a pezzi.
Il nostro sistema è composto da:
- hardware;
- sistema operativo;
- software;
- UI-parti nell'applicazione di monitoraggio;
- metriche aziendali;
- applicazioni di integrazione;
- sicurezza informatica;
- rete;
- bilanciatore di carico.
Al centro di questo sistema c'è propriamente il monitoraggio. Per comprendere lo stato dell'intero sistema, è necessario sapere cosa sta succedendo con le applicazioni su tutti questi livelli e in relazione a tutte queste applicazioni.
Ecco qui, riguardo lo stack.
Utilizziamo software open source. Al centro abbiamo Zabbix, che utilizziamo principalmente come sistema di allerta. È noto che è perfetto per il monitoraggio dell'infrastruttura. Cosa intendiamo? Proprio quelle metriche a basso livello che ogni azienda con il proprio data center (e Sportmaster ha i propri data center) possiede: temperatura del server, stato della memoria, del RAID, metriche dei dispositivi di rete.
Abbiamo integrato Zabbix con il messenger Telegram e Microsoft Teams, ampiamente utilizzati nei team. Zabbix copre il livello della rete fisica, dell'hardware e parzialmente del software, ma non è una panacea. Arricchiamo questi dati con alcune altre fonti. Ad esempio, per il livello hardware ci colleghiamo direttamente tramite API nel nostro sistema di virtualizzazione e raccogliamo i dati.
Cosa altro. Oltre a Zabbix, utilizziamo Prometheus, che consente di monitorare le metriche nelle applicazioni in ambienti dinamici. Questo significa che possiamo ottenere le metriche dell'applicazione tramite endpoint HTTP e non preoccuparci di quali metriche caricare. Sulla base di questi dati, possiamo elaborare query analitiche.
Le fonti di dati per gli altri livelli, ad esempio, metriche aziendali, sono divise in tre parti.
Innanzitutto, si tratta di sistemi aziendali esterni, Google Analytics, raccogliamo metriche dai log. Da essi otteniamo dati sugli utenti attivi, la conversione e tutto il resto legato al business. In secondo luogo, è il sistema di monitoraggio UI. A questo proposito, vale la pena soffermarsi di più.
Qualche tempo fa, abbiamo iniziato con il testing manuale e questo è evoluto in test automatici delle funzionalità e delle integrazioni. Da questo abbiamo sviluppato il monitoraggio, mantenendo solo le funzionalità principali e legandoci a indicatori che sono massimamente stabili e che non cambiano frequentemente nel tempo.
La nuova struttura dei team implica che tutta l'attività relativa alle applicazioni sia concentrata sui team di prodotto, quindi ci siamo fermati a fare test puri. Invece, abbiamo trasformato i test in monitoraggio UI, sviluppato in Java, Selenium e Jenkins (utilizzato come sistema di avvio e generazione di report).
Avevamo molti test, ma alla fine abbiamo deciso di puntare su una metrica di alto livello. E se avessimo molti test specifici, sarebbe difficile mantenere la validità dei dati. Ogni rilascio successivo romperà significativamente l'intero sistema, e noi ci occuperemo solo di ripararlo. Pertanto, ci siamo concentrati su cose fondamentali che cambiano raramente, monitorando solo quelle.
Infine, in terzo luogo, la fonte dei dati è un sistema centralizzato di logging. Per i log utilizziamo Elastic Stack, e poi possiamo importare questi dati nel nostro sistema di monitoraggio delle metriche aziendali. Inoltre, funziona il nostro servizio Monitoring API, sviluppato in Python, che interroga qualsiasi servizio tramite API e raccoglie dati da essi in Zabbix.
Un altro attributo indispensabile per il monitoraggio è la visualizzazione. La nostra si basa su Grafana. Tra i vari sistemi di visualizzazione, si distingue perché nel dashboard è possibile visualizzare metriche da diverse fonti di dati. Possiamo raccogliere metriche di alto livello da un negozio online, ad esempio, il numero di ordini effettuati nell'ultima ora da un database, metriche di prestazioni del sistema operativo su cui è in esecuzione questo negozio online da Zabbix, e le metriche delle istanze di questa applicazione da Prometheus. E tutto ciò sarà su un unico dashboard. Chiaro e accessibile.
Ribadisco sulla sicurezza: stiamo attualmente perfezionando un sistema che in seguito integreremo con il sistema globale di monitoraggio. A mio avviso, le problematiche principali che l'e-commerce affronta nel campo della sicurezza informatica sono legate a bot, parser e attacchi di forza bruta. È importante monitorare tutto ciò, poiché può influenzare in modo critico sia il funzionamento delle nostre applicazioni che la reputazione dal punto di vista commerciale. E con lo stack scelto, stiamo affrontando con successo queste sfide.
Un altro aspetto importante è che il livello delle applicazioni viene raccolto da Prometheus. Anche noi abbiamo l'integrazione con Zabbix. Inoltre, abbiamo sitespeed, un servizio che ci consente di monitorare parametri come la velocità di caricamento della nostra pagina, i colli di bottiglia, il rendering della pagina, il caricamento degli script e altro, ed è anche integrato tramite API. Quindi, le metriche vengono raccolte in Zabbix e monitoriamo gli alert anche da lì. Tutti gli alert vengono attualmente inviati ai principali metodi di invio (al momento sono email e telegram, abbiamo recentemente aggiunto MS Teams). Abbiamo in programma di migliorare il sistema di alerting in modo che bot intelligenti funzionino come servizio e forniscano informazioni sul monitoraggio a tutti i team di prodotto interessati.
Per noi sono importanti le metriche non solo dei singoli sistemi informativi, ma anche le metriche generali relative a tutta l'infrastruttura utilizzata dalle applicazioni: cluster server fisici, su cui girano le macchine virtuali, i bilanciatori di carico, i Network Load Balancer, la rete stessa, e l'utilizzo delle connessioni. Inoltre, metriche sui nostri centri di elaborazione dati (ne abbiamo diversi e l'infrastruttura è di dimensioni considerevoli).
I vantaggi del nostro sistema di monitoraggio sono che ci permette di vedere lo stato di funzionamento di tutti i sistemi, di valutare il loro impatto reciproco e sulle risorse comuni. Alla fine, consente anche di pianificare le risorse, che rientra nella nostra area di responsabilità. Gestiamo le risorse server — un pool nell'ambito dell'e-commerce, introduciamo e ritiriamo dalla produzione nuove attrezzature, acquisiamo nuovo hardware, realizziamo audit sull'utilizzo delle risorse e altro. Ogni anno i team pianificano nuovi progetti, sviluppano i propri sistemi, ed è importante per noi garantire loro le risorse necessarie.
E tramite le metriche vediamo la tendenza nell'utilizzo delle risorse da parte dei nostri sistemi informativi. Sulla base di esse possiamo già pianificare qualcosa. A livello di virtualizzazione raccogliamo dati e vediamo informazioni sulla quantità di risorse disponibili suddivise per centri di elaborazione dati. E all'interno del centro di elaborazione dati si possono osservare sia l'utilizzo che la distribuzione effettiva delle risorse, il loro consumo. Questo vale sia per i server standalone che per le macchine virtuali e i cluster di server fisici, su cui queste macchine virtuali funzionano attivamente.
Prospettive
Attualmente abbiamo a disposizione il core del sistema nel suo complesso, ma ci sono ancora vari aspetti su cui lavorare. Al minimo, questo include il livello di sicurezza informatica, ma è altrettanto importante arrivare alla rete, sviluppare l'allerta e risolvere la questione della correlazione. Abbiamo molti livelli e sistemi, e su ogni livello ci sono molte metriche. Risulta quindi una matrioska di livello matrjoska.
Il nostro obiettivo finale è creare allerta corrette. Ad esempio, se c'è un problema con la parte hardware, di nuovo, con una macchina virtuale, e vi era un'applicazione importante, e il servizio non era in alcun modo riservato. Scopriremo che la macchina virtuale è morta. Poi verranno allertate le metriche di business: gli utenti sono scomparsi, non ci sono conversioni, l'interfaccia utente è inaccessibile, il software e i servizi sono anch'essi morti.
In questa situazione, riceveremo un sovraccarico di allerta, e questo non rientra nel formato di un sistema di monitoraggio corretto. Si pone quindi la questione della correlazione. Pertanto, idealmente, il nostro sistema di monitoraggio dovrebbe dire: «Ragazzi, la vostra macchina fisica è morta, e insieme ad essa questa applicazione e tali metriche», tramite un'unica allerta invece di sommergerci con centinaia di allerta. Deve comunicare l'essenziale: la causa, contribuendo così alla tempestività nella risoluzione del problema grazie alla sua localizzazione.
Il nostro sistema di notifiche e gestione delle allerta è costruito attorno a un servizio di hotline attivo 24 ore su 24. Tutte le allerta che consideriamo critiche e che rientrano nella checklist vengono inviate lì. Ogni allerta deve avere necessariamente una descrizione: cosa è successo, cosa significa, quali sono le conseguenze. Inoltre, un link al dashboard e istruzioni su cosa fare in questo caso.
Questi sono tutti i requisiti per la costruzione delle allerta. Successivamente, la situazione può evolversi in due direzioni: o c'è un problema che deve essere risolto, o c'è stato un guasto nel sistema di monitoraggio. Ma in ogni caso, bisogna andare e indagare.
In media, ora riceviamo circa un centinaio di allerta al giorno, considerando che la correlazione delle allerta non è ancora configurata correttamente. E se è necessario eseguire lavori tecnici, e disattiviamo forzatamente qualcosa, il loro numero aumenta drasticamente.
Oltre al monitoraggio dei sistemi che gestiamo e alla raccolta delle metriche che consideriamo importanti, il sistema di monitoraggio consente di raccogliere dati per i team di prodotto. Questi possono influenzare la composizione delle metriche all'interno dei sistemi informativi che monitoriamo.
Il nostro collega può venire e chiedere di aggiungere qualche metrica che risulterà utile sia a noi che al team. Oppure, ad esempio, il team potrebbe non essere soddisfatto delle metriche di base che abbiamo, avendo bisogno di monitorare qualcosa di specifico. In Grafana creiamo uno spazio per ogni team e concediamo diritti di amministratore. Inoltre, se il team ha bisogno di dashboard e non riesce/non sa come farle, li aiutiamo.
Dal momento che siamo al di fuori del flusso di creazione di valore del team, dei loro rilasci e pianificazioni, stiamo progressivamente arrivando a un punto in cui i rilasci di tutti i sistemi sono senza interruzioni e possono essere distribuiti quotidianamente, senza bisogno di coordinarli con noi. È per noi importante monitorare questi rilasci, poiché potrebbero potenzialmente influenzare il funzionamento dell'applicazione e causare problemi, il che è critico. Per gestire i rilasci utilizziamo Bamboo, da cui otteniamo dati tramite API e possiamo vedere quali rilasci sono stati effettuati in quali sistemi informativi e il loro stato. E la cosa più importante: a che ora. I marcatori sui rilasci li sovrapponiamo alle metriche critiche principali, il che è visivamente molto indicativo in caso di problemi.
In questo modo possiamo vedere la correlazione tra i nuovi rilasci e i problemi che sorgono. L'idea principale è comprendere come funziona il sistema a tutti i livelli, localizzare rapidamente il problema e altrettanto rapidamente risolverlo. Infatti, spesso il maggior tempo viene speso non per risolvere il problema, ma per trovare la causa.
E in questa direzione vogliamo concentrarci sulla proattività in futuro. Idealmente, ci piacerebbe essere informati in anticipo riguardo a un problema imminente, piuttosto che dopo che è accaduto, in modo da poterci occupare della sua prevenzione, e non della soluzione. A volte si verificano falsi allarmi nel sistema di monitoraggio, sia a causa di errori umani che a causa di modifiche nell'applicazione. E stiamo lavorando su questo, affinando il sistema e cercando di avvertire gli utenti che lo utilizzano insieme a noi di qualsiasi intervento sul sistema di monitoraggio, oppure di effettuare queste operazioni in un intervallo di manutenzione.
Quindi, il sistema è stato avviato e funziona con successo dall'inizio della primavera... e mostra profitti abbastanza reali. Certo, questa non è la sua versione finale, intendiamo implementare molte altre utilità. Ma proprio ora, data l'enorme quantità di integrazioni e applicazioni, senza l'automazione del monitoraggio non è davvero possibile procedere.
Se anche voi monitorate grandi progetti con un numero significativo di integrazioni, scrivete nei commenti quale 'proiettile d'argento' avete trovato per questo.
Fonte: habr.com
