Siamo tutti familiari con i principi del DevOps: costruire piccoli incrementi ben testati, distribuire frequentemente e automatizzare le pipeline per eliminare la necessità di passaggi manuali. Monitoriamo attentamente le nostre applicazioni, impostiamo avvisi, ripristiniamo modifiche problematiche e riceviamo notifiche quando si verificano problemi.
Tuttavia, quando si tratta di database, spesso ci manca lo stesso livello di controllo e visibilità. Il debug dei problemi di performance può essere difficile e potremmo avere difficoltà a capire perché i database rallentino. Le migrazioni e le modifiche degli schemi possono sfuggire al controllo, portando a sfide significative.
Superare questi ostacoli richiede strategie che semplifichino la migrazione e l’adattamento degli schemi, consentendo cambiamenti strutturali efficienti del database con tempi di inattività o impatti sulle prestazioni minimi. È essenziale testare tutti i cambiamenti in modo coeso lungo la pipeline. Esploriamo come questo può essere realizzato.
Automatizza i tuoi test
I database sono soggetti a molti tipi di guasti, eppure spesso non ricevono lo stesso rigoroso testing delle applicazioni. Mentre gli sviluppatori testano tipicamente se le applicazioni possono leggere e scrivere i dati corretti, spesso trascurano come ciò venga realizzato. Aspetti chiave come garantire l’uso corretto degli indici, evitare caricamenti pigri non necessari o verificare l’efficienza delle query spesso passano inosservati.
Ad esempio, ci concentriamo su quante righe restituisce il database ma trascuriamo di analizzare quante righe ha dovuto leggere. Allo stesso modo, le procedure di rollback vengono raramente testate, rendendoci vulnerabili a potenziali perdite di dati con ogni modifica. Per affrontare queste lacune, abbiamo bisogno di test automatizzati completi che rilevino i problemi in modo proattivo, riducendo al minimo la necessità di interventi manuali.
Spesso ci affidiamo ai test di carico per identificare problemi di prestazioni e, sebbene possano rivelare se le nostre query sono abbastanza rapide per la produzione, presentano notevoli svantaggi. Innanzitutto, i test di carico sono costosi da costruire e mantenere, richiedendo una gestione attenta della conformità al GDPR, dell’anonimizzazione dei dati e delle applicazioni con stato. Inoltre, si svolgono troppo tardi nella pipeline di sviluppo. Quando i test di carico rivelano problemi, le modifiche sono già state implementate, esaminate e integrate, costringendoci a tornare al punto di partenza e potenzialmente a ricominciare da capo. Infine, i test di carico richiedono molto tempo, spesso richiedendo ore per riempire le cache e convalidare l’affidabilità dell’applicazione, rendendoli meno pratici per rilevare i problemi precocemente.
Le migrazioni dello schema spesso ricadono al di fuori dell’ambito dei nostri test. Di solito, eseguiamo suite di test solo dopo che le migrazioni sono completate, il che significa che non valutiamo quanto tempo hanno impiegato, se hanno attivato riscritture di tabelle o se hanno causato colli di bottiglia nelle prestazioni. Questi problemi spesso passano inosservati durante il testing e diventano evidenti solo quando vengono distribuiti in produzione.
Un’altra sfida è che testiamo con database troppo piccoli per scoprire i problemi di prestazioni in anticipo. Questa dipendenza da test inadeguati può portare a un dispendio di tempo nei test di carico e lascia aspetti critici, come le migrazioni di schema, completamente non testati. Questa mancanza di copertura riduce la nostra velocità di sviluppo, introduce problemi che rompono l’applicazione e ostacola l’agilità.
La soluzione a queste sfide risiede nell’implementare delle guide per i database. Le guide per i database valutano le query, le migrazioni di schema, le configurazioni e i design dei database mentre scriviamo codice. Invece di fare affidamento sui run della pipeline o su lunghi test di carico, questi controlli possono essere eseguiti direttamente nell’IDE o nell’ambiente di sviluppo. Sfruttando l’osservabilità e le proiezioni del database di produzione, le guide valutano i piani di esecuzione, le statistiche e le configurazioni, assicurando che tutto funzioni senza intoppi dopo il deployment.
Costruire l’Osservabilità Attorno ai Database
Quando distribuiamo in produzione, la dinamica del sistema può cambiare nel tempo. Il carico della CPU può aumentare, l’uso della memoria potrebbe crescere, i volumi di dati potrebbero espandersi e i modelli di distribuzione dei dati potrebbero cambiare. Identificare rapidamente questi problemi è essenziale, ma non è sufficiente. Gli attuali strumenti di monitoraggio ci sommergono con segnali grezzi, lasciandoci a mettere insieme il ragionamento. Ad esempio, potrebbero indicare un aumento del carico della CPU ma non spiegare perché sia accaduto. L’onere di indagare e identificare le cause profonde ricade interamente su di noi. Questo approccio è obsoleto e inefficiente.
Per muoverci veramente velocemente, dobbiamo passare dal monitoraggio tradizionale alla piena osservabilità. Invece di essere sommersi da dati grezzi, abbiamo bisogno di informazioni utili che ci aiutino a capire la causa principale dei problemi. Le protezioni del database offrono questa trasformazione. Collegano i punti, mostrando come vari fattori siano correlati, individuando il problema e suggerendo soluzioni. Invece di osservare semplicemente un picco di utilizzo della CPU, le protezioni ci aiutano a capire che una recente distribuzione ha alterato una query, causando un bypass dell’indice, che ha portato all’aumento del carico della CPU. Con questa chiarezza, possiamo agire con decisione, correggendo la query o l’indice per risolvere il problema. Questo passaggio dal “vedere” al “capire” è fondamentale per mantenere la velocità e l’affidabilità.
La prossima evoluzione nella gestione dei database è il passaggio dall’indagine automatica dei problemi alla risoluzione automatica. Molti problemi possono essere risolti automaticamente con sistemi ben integrati. Gli strumenti di osservabilità possono analizzare problemi di prestazioni e affidabilità e generare le modifiche di codice o configurazione necessarie per risolverli. Queste correzioni possono essere applicate automaticamente o richiedere un’approvazione esplicita, garantendo che i problemi vengano affrontati immediatamente con il minimo sforzo da parte vostra.
Oltre a risolvere i problemi rapidamente, l’obiettivo finale è prevenire che i problemi si verifichino in primo luogo. I continui rollback o fallimenti ostacolano il progresso e l’agilità. La vera agilità non si ottiene risolvendo rapidamente i problemi, ma progettando sistemi in cui i problemi raramente si verificano. Sebbene questa visione possa richiedere passi incrementali per essere raggiunta, rappresenta la direzione ultima per l’innovazione.
Metis ti consente di superare queste sfide. Valuta le tue modifiche prima che vengano impegnate nel repository, analizzando query, migrazioni di schema, piani di esecuzione, prestazioni e correttezza lungo le tue pipeline. Metis si integra perfettamente con i flussi di lavoro CI/CD, impedendo che modifiche difettose raggiungano la produzione. Ma va oltre: offre una profonda osservabilità nel tuo database di produzione analizzando metriche e tracciando distribuzioni, estensioni e configurazioni. Risolve automaticamente i problemi quando possibile e ti avvisa quando è necessaria un’intervento manuale. Con Metis, puoi muoverti più velocemente e automatizzare ogni aspetto della tua pipeline CI/CD, garantendo una gestione del database più fluida e affidabile.
È necessario che tutti partecipino
L’osservabilità del database riguarda la prevenzione proattiva dei problemi, l’avanzamento verso una comprensione e risoluzione automatizzate e l’incorporamento di controlli specifici per il database durante tutto il processo di sviluppo. Affidarsi a strumenti e flussi di lavoro obsoleti non è più sufficiente; abbiamo bisogno di soluzioni moderne che si adattino alle complessità odierne. Le barriere di protezione del database forniscono questo supporto. Aiutano gli sviluppatori a evitare di creare codice inefficiente, analizzare schemi e configurazioni e convalidare ogni fase del ciclo di vita dello sviluppo del software all’interno delle nostre pipeline.
Le protezioni stradali trasformano anche i dati grezzi di monitoraggio in spunti per l’azione, spiegando non solo cosa è andato storto ma come risolverlo. Questa capacità è essenziale in tutti i settori, poiché la complessità dei sistemi continuerà ad aumentare. Per rimanere al passo, dobbiamo abbracciare strumenti e processi innovativi che ci consentano di muoverci più velocemente e in modo più efficiente.
Source:
https://dzone.com/articles/testing-is-a-cross-cutting-concern-so-are-databases