DBA, non più un sacerdozio

Nota: questo post di ingegneria è stato scritto dalla nostra DBA, Silvia Botros ed è apparso originariamente sul blog Sysadvent a dicembre 2016.

Le aziende hanno avuto e hanno avuto bisogno di amministratori di database per anni. I dati sono una delle risorse più importanti di un'azienda. Ciò significa che molte aziende, una volta cresciute al punto da dover essere in grado di scalare rapidamente, hanno bisogno di qualcuno che si assicuri che le risorse siano ben gestite, performanti per le esigenze del prodotto e disponibili per il ripristino in caso di disastri.

In senso tradizionale, il lavoro del DBA significa che è l'unica persona con accesso ai server che ospitano i dati, la persona di riferimento per creare un nuovo cluster di database per nuove funzionalità, la persona per progettare nuovi schemi e l'unica persona da contattare quando qualcosa relativo al database si interrompe in un ambiente di produzione.

Poiché i DBA tradizionalmente hanno ruoli così unici che il loro tempo è prezioso, diventa più difficile pensare in grande quando le attività quotidiane sono sopraffatte. È tipico ricorrere a strumenti fragili come bash per tutti i tipi di attività operative nella terra di DBA. Hai bisogno di una nuova configurazione del DB da un'installazione pulita del sistema operativo? Eseguire, convalidare o ripristinare i backup? Ruotare partizioni o dati obsoleti? Quando il tuo strumento più comunemente usato è lo scripting bash, tutto sembra un chiodo. Sono sicuro che molti lettori stanno preparando tweet per dirmi quanto sia potente bash, ma per favore mantieni il tuo commento fino a dopo aver valutato il mio ragionamento.

Tutto questo suona come la tua descrizione del lavoro come DBA? La descrizione del lavoro parla in dettaglio dell'aggiornamento dei server, della creazione e del test dei backup e del monitoraggio? La maggior parte degli annunci di lavoro DBA tipici si assicurerà di dire che è necessario configurare e configurare server di database "più" (perché l'aspettativa è che i DBA li creino manualmente) e automatizzare le attività di gestione del database con script (realizzati a mano).

È davvero un approccio scalabile per quello che spesso è un team di uno in un'organizzazione in crescita e dal ritmo frenetico?

Sono qui per sostenere che il tuo lavoro non è eseguire e gestire backup, creare e gestire database o ottimizzare le query. Farai tutte queste cose nell'arco del tuo lavoro, ma l'obiettivo principale è rendere i dati della tua azienda accessibili e scalabili. Questo non è solo per l'azienda per eseguire il prodotto attuale, ma anche per creare nuove funzionalità e fornire valore ai clienti.

Come mai

Potresti chiedere, perché dovrei fare tutto questo? C'è un argomento per continuare a svolgere il ruolo di DBA tradizionalmente: sicurezza del lavoro, giusto? Molte organizzazioni tecnologiche oggigiorno eseguono una o più delle seguenti operazioni:

• Sono formati da molte squadre più piccole
• Forniscono funzionalità creando molti microservizi al posto di uno o pochi servizi più grandi
• Adottano metodologie agili per accelerare la consegna delle funzionalità
• Combinano operazioni e ingegneria sotto un'unica guida
• Incorporano gli ingegneri operativi con gli sviluppatori il prima possibile nel processo di progettazione
• Un silo DBA all'interno delle operazioni significa che il team operativo ha meno poteri per aiutare a eseguire il debug dei problemi di produzione nel proprio stack, a volte non è in grado di rispondere e risolvere i problemi senza assistenza e francamente meno credibile nel richiedere collaborazioni più strette e tempestive con i team di progettazione se lo sono Non mettere in pratica ciò che predicano all'interno di Tech Ops.

Quindi cosa si può fare per rompere quel silo e rendere più facile il debug per altre persone, aiutare a scalare il livello del database e consentire agli ingegneri di progettare servizi scalabili? La maggior parte dei negozi emergenti ha al massimo un DBA interno. L'unico DBA può essere "presente" in tutte le riunioni di progettazione, approvare ogni modifica dello schema ed essere reperibile per un'impronta di database tentacolare e in continua crescita?

I DBA non possono più essere guardiani o maghi. Un DBA può e dovrebbe essere una fonte di conoscenza e competenza per gli ingegneri di un'organizzazione. Dovrebbe aiutare i team di consegna non solo a fornire funzionalità, ma anche a fornire prodotti che scalano e consentono loro di non temere il database. Ma come può un DBA raggiungere questo obiettivo mentre svolge il lavoro quotidiano di gestione del livello dati? Ci sono molti modi in cui tu, il DBA, puoi configurarti per l'eccellenza.

Gestione della configurazione

Questo è molto importante. I DBA tendono a preferire strumenti della vecchia scuola come bash per la configurazione del database. Ho accennato a questo prima e non ho nulla contro l'uso di bash stesso. Lo uso molto, in realtà. Ma non è lo strumento giusto per la configurazione del cluster. Soprattutto se il resto delle operazioni NON utilizza Bash per gestire il resto dell'architettura. È vero che anche gli ingegneri operativi conoscono Bash, ma se gestiscono il resto dell'infrastruttura con uno strumento come Chef o Puppet e i database sono gestiti principalmente da script artigianali scritti dal DBA, stai imponendo loro un ostacolo a fornire aiuto quando è necessario un cambiamento urgente.

Inoltre, diventa più difficile aiutare i team di ingegneri a gestire autonomamente e possedere la creazione dei nuovi cluster di cui hanno bisogno per la nuova funzionalità "foo". Diventi il ​​"blocco" per il completamento del lavoro. Anche acquisire familiarità con la gestione della configurazione nella tua azienda è un vantaggio a due vie. Man mano che acquisisci familiarità con il modo in cui viene gestita l'infrastruttura, conosci gli standard del team, acquisisci familiarità con lo stack e sei in grado di collaborare alle modifiche che alla fine influiscono sulla scala del prodotto.

Un DBA che sia sintonizzato sul prodotto e sull'infrastruttura dell'organizzazione di ingegneria nel suo insieme è inestimabile.

Runbook

Questo è tecnicamente un sottoinsieme della documentazione che devi scrivere, ma nella mia esperienza si è dimostrato molto più utile che ritengo debba essere indicato separatamente. Quando dico runbook, sto specificando un documento scritto per un pubblico che NON è un DBA. Ci sono molti problemi di DB di produzione che potremmo incontrare come DBA di cui è semplice eseguire il debug e risolverli. Tendiamo a sottovalutare quella memoria muscolare e cadiamo nello schema di "mandami semplicemente la pagina" e "pensiamo alle cose".

Se il tuo team operativo è come il mio in cui sei l'unico DBA, probabilmente significa che qualcun altro nel team è la prima linea di difesa quando un evento relativo al DB pagine. Una semplice documentazione su come eseguire il debug iniziale, la raccolta dei dati, può fare molto per rendere il resto del team operativo a proprio agio con il livello del database e più familiarità con il modo in cui lo monitoriamo ed eseguiamo il debug. Anche se quell'evento si traduce ancora nel paging del DBA, lentamente ma inesorabilmente, il runbook diventa un luogo in cui tutti possono aggiungere le conoscenze acquisite.

Inoltre, aggiungo un collegamento alla relativa sezione del runbook (usa le ancore!) Alle descrizioni delle pagine che vanno al cercapersone. Questo è incredibilmente utile per qualcuno che viene chiamato da un host di database alle 3 del mattino per trovare un punto di partenza. Queste cose possono sembrare piccole, ma nella mia esperienza hanno fatto molto nell'infrangere le barriere mentali per il mio team operativo che lavora sul livello del database quando necessario.

Come preferenza personale, li scrivo come documenti di markdown all'interno dei miei repository di libri di cucina dello chef. Ciò rientra perfettamente in un modello di richiesta pull, revisione e unione e diventa parte integrante del modello dei libri di cucina dei database. Quando i team di ingegneri iniziano a crearne di propri, i runbook diventano un modello familiare man mano che nuovi cluster di database spuntano ovunque.

Visibilità

Ci piacciono i nostri schermi dei terminali. Li amiamo. Gli strumenti più popolari nella terra di MySQL sono ancora strumenti terminali che risiedono direttamente sugli host db e che richiedono una conoscenza preliminare di essi e di come usarli. Sto parlando di cose come innotop e la shell MySQL. Questi vanno bene e sono comunque utili, ma sono creati per i DBA. Se non vuoi essere il custode di domande come "c'è un ritardo di replica in questo momento?" è necessario disporre di strumenti migliori per rendere l'integrità di qualsiasi cluster, ora e storicamente, disponibile e facile da assimilare per tutti i membri del team. Ho alcuni esempi in quest'arena:

Orchestratore

Usiamo le repliche di lettura per distribuire quel carico lontano dal primario, il che significa che una volta che il ritardo raggiunge una certa soglia, diventa un evento di assistenza clienti. È importante rendere più semplice per chiunque nell'azienda sapere in qualsiasi momento se un cluster presenta un ritardo, quali sono i server in quel cluster e se uno qualsiasi degli host si è interrotto. Orchestrator è un ottimo strumento in tal senso perché rende la visualizzazione dei cluster e della loro salute a una finestra del browser.

Grafana/Grafite

Le metriche per il livello DB devono risiedere nello stesso posto in cui si trovano le metriche per il resto dell'infrastruttura. È importante che il team sia in grado di giustapporre queste metriche fianco a fianco. Ed è importante disporre di un modo semplice per visualizzare le metriche storiche per qualsiasi cluster di database. Sebbene tu possa avere una preferenza personale per cactus o munin o modelli artigianali che hai scritto nel corso degli anni, se le metriche che usi per indagare sui problemi non sono nella stessa posizione del resto delle metriche dell'infrastruttura, crea una barriera per altri ingegneri impegnati e saranno meno inclini a utilizzare i tuoi strumenti rispetto a quelli che sono in uso altrove. La grafite è ampiamente utilizzata per l'acquisizione di metriche nei moderni team dell'infrastruttura e Grafana è un front-end di dashboard ampiamente utilizzato per metriche e analisi.

Prestazioni di query

Usiamo VividCortex per tenere traccia delle nostre query sui cluster critici e, sebbene questo articolo non intenda essere una pubblicità per un servizio a pagamento, dirò che è necessario avere la possibilità di ispezionare l'effetto delle distribuzioni e delle modifiche al codice sulle query in esecuzione e prestazioni di query qualcosa che non necessita di un accesso speciale ai registri e di elaborarli manualmente. Se VividCortex non è una possibilità (anche se, sul serio, sono fantastici!), Ci sono altri prodotti e strumenti open source in grado di catturare anche solo il registro lento e inserirlo in una pagina Web di facile lettura che i non DBA possono ispezionare e vedere l'effetto del loro codice. Il punto importante qui è che se fornisci i mezzi per vedere i dati, gli ingegneri li utilizzeranno e faranno del loro meglio per mantenere le cose efficienti. Ma fa parte del tuo lavoro rendere disponibile quell'accesso e non uno speciale trucco DBA.

Combatti la fatica del cercapersone

Molte organizzazioni non considerano il ridimensionamento del livello di database un imperativo molto precoce nella progettazione dello stack, e non dovrebbero. All'inizio di un'azienda, non dovresti preoccuparti di come limiterai le chiamate API se nessuno sta ancora utilizzando l'API. Ma è opportuno considerare alcuni anni dopo, quando il prodotto ha guadagnato popolarità e quella chiamata API che stava raggiungendo una tabella di poche migliaia di righe da una manciata di clienti è ora una tabella multimilionaria e un paio di clienti hanno creato lavori cron che inondano quell'API ogni mattina alle 6 del mattino nel tuo fuso orario.

È necessario molto lavoro per modificare il livello dell'applicazione di qualsiasi prodotto per proteggere l'infrastruttura e, nel frattempo, consentire a attività spurie del database di causare l'affaticamento del cercapersone è un grosso pericolo sia per l'utente che per il resto dell'organizzazione operativa. Acquisisci familiarità con strumenti come pt-kill che possono essere utilizzati in un attimo per evitare che un host di database abbia gravi tempi di inattività a causa di un volume non pianificato. Rendi noto l'uso di quello strumento e comunica l'azione e il suo effetto al team di ingegneri della partecipazione, ma non è salutare cercare di assorbire il dolore da qualcosa che non puoi cambiare direttamente e alla fine non sarà utile per aiutare i team di ingegneri ' impara come affrontare i dolori della crescita.

Ci sono molti modi in cui il lavoro di un DBA è unico per il suo ruolo rispetto al resto del team operativo, ma ciò non significa che debba essere un sacerdozio magico a cui nessuno può avvicinarsi. Questi passaggi contribuiscono notevolmente a rendere il tuo lavoro trasparente, ma soprattutto si avvicina al tuo lavoro non come gatekeeper in un giardino d'oro di host di database, ma come esperto in materia che può fornire consigli e aiutare a far crescere gli ingegneri con cui lavori e fornire di più valore per l'azienda rispetto ai backup e all'ottimizzazione delle query (ma anche quelli sono divertenti!).

Un ringraziamento speciale al meraviglioso team operativo di Sendgrid che continua a insegnarmi molte cose e ai Charity Majors per aver coniato il titolo di questo post. E controlla altri post sui DBA qui.