DBA, A Preothood No More

Notă: Această postare de inginerie a fost scrisă de DBA-ul nostru, Silvia Botros și a apărut inițial pe blogul Sysadvent în decembrie 2016.

Companiile au avut și au nevoie de Administratori de baze de date de ani de zile. Datele sunt unul dintre cele mai importante active ale unei afaceri. Aceasta înseamnă că multe companii, odată ce cresc până la punctul în care trebuie să se poată scala rapid, au nevoie de cineva care să se asigure că activul este bine gestionat, performant pentru nevoile produsului și disponibil pentru a fi restaurat în caz de dezastre.

Într-un sens tradițional, slujba DBA înseamnă că ea este singura persoană cu acces la serverele care găzduiesc datele, persoana de contact pentru a crea un nou cluster de baze de date pentru noi caracteristici, persoana care proiectează noi scheme și singura persoană de contact atunci când ceva legat de baza de date se întrerupe într-un mediu de producție.

Deoarece DBA-urile au în mod tradițional astfel de roluri unice, timpul lor este limitat, devine mai greu să vă gândiți la o imagine de ansamblu atunci când sarcinile de zi cu zi sunt copleșite. Este tipic să recurgeți la instrumente fragile precum bash pentru tot felul de sarcini operaționale în terenul DBA. Aveți nevoie de o nouă configurare DB dintr-o instalare curată a sistemului de operare? Luați, validați sau restaurați copii de rezervă? Rotiți partițiile sau date învechite? Când cel mai des folosit instrument este bash scripting, totul arată ca un cui. Sunt sigur că mulți cititori pregătesc tweet-uri pentru a-mi spune cât de puternic este bash, dar vă rog să țineți comentariul până după ce îmi evaluez raționamentul.

Toate acestea sună ca descrierea postului tău ca DBA? Descrierea postului vorbește în detalii despre actualizarea serverelor, crearea și testarea copiilor de rezervă și monitorizare? Cele mai obișnuite postări de locuri de muncă DBA se vor asigura că trebuie să configurați și să configurați „mai multe” servere de baze de date (deoarece se așteaptă ca DBA să le realizeze manual) și să automatizați sarcinile de gestionare a bazei de date cu scripturi (fabricate manual).

Este aceasta într-adevăr o abordare scalabilă pentru ceea ce este adesea o echipă dintr-o organizație în creștere, cu ritm rapid?

Sunt aici pentru a susține că sarcina dvs. nu este să efectuați și să gestionați copii de rezervă, să creați și să gestionați baze de date sau să optimizați interogările. Veți face toate aceste lucruri pe durata muncii dvs., dar scopul principal este să faceți datele afacerii dvs. accesibile și scalabile. Acest lucru nu este doar pentru ca afacerea să ruleze produsul actual, ci și pentru a construi noi caracteristici și pentru a oferi valoare clienților.

De ce

Poate vrei să întrebi, de ce aș face toate astea? Există un argument pentru continuarea executării rolului DBA în mod tradițional: securitatea locului de muncă, nu? Multe organizații tehnologice din zilele noastre fac una sau mai multe dintre următoarele:

• Sunt formați din multe echipe mai mici
• Ele oferă caracteristici prin crearea multor micro-servicii în locul unuia sau mai multor servicii mai mari
• Ei adoptă metodologii agile pentru a accelera livrarea caracteristicilor
• Ei combină operațiunile și inginerie sub o singură conducere
• Aceștia integrează inginerii operaționali cu dezvoltatorii cât mai devreme posibil în procesul de proiectare
• Un siloz DBA în cadrul operațiunilor înseamnă că echipa de operațiuni este mai puțin împuternicită să ajute la depanarea problemelor de producție în propria stivă, uneori nu poate răspunde și rezolva problemele fără asistență și, sincer, mai puțin credibilă în a cere colaborări mai strânse și mai devreme cu echipele de inginerie, dacă acestea sunt. nu exersează ceea ce predică în cadrul Tech Ops.

Deci, ce se poate face pentru a distruge acel siloz și pentru a facilita depanarea altor oameni, pentru a ajuta la scalarea stratului bazei de date și pentru a oferi inginerilor posibilitatea de a proiecta servicii care se pot scala? Majoritatea magazinelor emergente au cel mult un DBA intern. Poate singurul DBA să fie „prezent” la toate întâlnirile de proiectare, să aprobe fiecare schimbare de schemă și să fie de apel pentru o amprentă a bazei de date extinsă, în continuă creștere?

DBA nu mai pot fi gardieni sau magicieni. Un DBA poate și ar trebui să fie o sursă de cunoștințe și expertiză pentru inginerii dintr-o organizație. Ea ar trebui să ajute echipele de livrare nu doar să furnizeze funcții, ci să livreze produse care să se extindă și să le permită să nu se teamă de baza de date. Dar cum poate un DBA să realizeze asta în timp ce face munca zilnică de gestionare a stratului de date? Există o serie de moduri în care dvs., DBA, vă puteți configura pentru excelență.

Managementul configurației

Acesta este unul foarte important. DBA tind să prefere instrumentele vechi, cum ar fi bash, pentru configurarea bazei de date. Am făcut aluzie la asta mai devreme și nu am nimic împotriva utilizării bash în sine. Îl folosesc foarte mult, de fapt. Dar nu este instrumentul potrivit pentru configurarea clusterului. Mai ales dacă restul operațiunilor NU folosește Bash pentru a gestiona restul arhitecturii. Este adevărat că și inginerii operaționali îl cunosc pe Bash, dar dacă gestionează restul infrastructurii cu un instrument precum Chef sau Puppet și bazele de date sunt gestionate în mare parte prin scripturi realizate manual, scrise de DBA, le impuți o obstacol de a furniza. ajutor atunci când este nevoie de o schimbare urgentă.

Mai mult decât atât, devine mai greu să ajuți echipele de inginerie să se autoservice și să dețină crearea noilor clustere de care au nevoie pentru noua caracteristică „foo”. Tu devii „blocatorul” pentru finalizarea lucrărilor. Familiarizarea cu gestionarea configurației la compania dvs. este, de asemenea, un avantaj în două sensuri. Pe măsură ce vă familiarizați cu modul în care este gestionată infrastructura, cunoașteți standardele echipei, vă familiarizați mai mult cu stiva și sunteți capabil să colaborați la schimbări care afectează în cele din urmă scara produsului.

Un DBA care este adaptat la produsul și infrastructura organizației de inginerie în ansamblu este de neprețuit.

Runbook-uri

Acesta este, din punct de vedere tehnic, un subset al documentației pe care trebuie să o scrieți, dar din experiența mea sa dovedit mult mai util, încât cred că trebuie subliniat separat. Când spun runbook-uri, spun în mod specific un document scris pentru un public care NU este un DBA. Există o mulțime de probleme DB de producție pe care le putem întâlni ca DBA, care sunt ușor de depanat și rezolvat. Tindem să subestimăm acea memorie musculară și cădem în tiparul „doar trimite-mi pagina” și „avem grijă de lucruri”.

Dacă echipa dvs. de operațiuni este ca a mea, unde sunteți singurul DBA, probabil înseamnă că altcineva din echipă este prima linie de apărare atunci când paginile de evenimente legate de DB. O documentație simplă despre cum să faceți depanarea inițială, colectarea datelor, poate ajuta restul echipei de operațiuni să se simtă confortabil cu stratul bazei de date și mai familiarizat cu modul în care îl monitorizăm și îl depanăm. Chiar dacă acel eveniment duce în continuare la paginarea DBA, încet, dar sigur, runbook-ul devine un loc în care toată lumea poate adăuga cunoștințele dobândite.

În plus, adaug un link către secțiunea runbook aferentă (utilizați ancore!) la descrierile paginilor care merg la pager. Acest lucru este incredibil de util pentru cineva care este paginat de o gazdă a bazei de date la ora 3:00 pentru a găsi un loc de început. Aceste lucruri pot părea mici, dar din experiența mea au făcut un drum lung în spargerea barierelor mentale pentru echipa mea de operațiuni care lucrează la nivelul bazei de date atunci când este necesar.

Ca preferință personală, le scriu ca documente de reducere în interiorul depozitelor mele de cărți de bucate pentru bucătar. Aceasta se încadrează perfect într-un model de solicitare de extragere, revizuire și îmbinare și devine o parte integrantă a modelului cărților de bucate ale bazelor de date. Pe măsură ce echipele de inginerie încep să-și creeze propriile, runbook-urile devin un șablon familiar, pe măsură ce noi grupuri de baze de date apar peste tot.

Vizibilitate

Ne plac ecranele terminalelor noastre. Ii iubim. Cele mai populare instrumente din MySQL sunt încă instrumentele terminale care trăiesc direct pe gazdele db și care au nevoie de cunoștințe prealabile despre ele și despre cum să le folosească. Vorbesc despre lucruri precum innotop și shell-ul MySQL. Acestea sunt bune și totuși utile, dar sunt create pentru DBA. Dacă nu doriți să fiți portarul la întrebări precum „există întârziere de replicare chiar acum?” trebuie să ai instrumente mai bune pentru a face orice sănătate a clusterului, acum și istoric, disponibilă și ușor de digerat pentru toți membrii echipei. Am câteva exemple în acest domeniu:

Orchestrator

Folosim replici de citire pentru a distribui acea încărcare departe de primar, ceea ce înseamnă că odată ce decalajul atinge un anumit prag, acesta devine un eveniment de asistență pentru clienți. Este important să fie mai ușor pentru oricine din companie să știe la un moment dat dacă vreun cluster se confruntă cu întârzieri, ce servere sunt din acel cluster și dacă vreuna dintre gazde a căzut. Orchestrator este un instrument excelent în această privință, deoarece face vizualizarea clusterelor și a sănătății lor la o fereastră de browser.

Grafana/Graphit

Metricurile pentru stratul DB trebuie să locuiască în același loc în care sunt metricile pentru restul infrastructurii. Este important ca echipa să poată juxtapune aceste valori una lângă alta. Și este important să aveți o modalitate ușoară de a vedea valorile istorice pentru orice cluster DB. Deși este posibil să aveți o preferință personală pentru cactusi sau munin, sau șabloane artizanale pe care le-ați scris de-a lungul anilor, dacă valorile pe care le utilizați pentru a investiga problemele nu sunt în același loc cu celelalte valori ale infrastructurii, aceasta creează o barieră pentru alți ingineri ocupați – și vor fi mai puțin înclinați să vă folosească uneltele în detrimentul celor care sunt folosite în altă parte. Grafitul este utilizat pe scară largă pentru ingerarea de valori în echipele moderne de infrastructură, iar Grafana este un front-end de tablouri de bord utilizat pe scară largă pentru metrici și analize.

Performanța interogărilor

Folosim VividCortex pentru a urmări interogările noastre privind clusterele critice și, deși acest articol nu este menit să fie o reclamă pentru un serviciu plătit, voi spune că trebuie să aveți capacitatea de a inspecta efectul implementărilor și modificărilor codului asupra interogărilor care rulează și interogați performanța ceva care nu are nevoie de acces special la jurnale și să le strângeți manual. Dacă VividCortex nu este o posibilitate (deși, serios, sunt minunate!), există alte produse și instrumente open source care pot captura chiar și doar jurnalul lent și îl pot pune într-o pagină web ușor de citit pentru ca persoanele care nu sunt DBA să le inspecteze și vedeți efectul codului lor. Punctul important aici este că, dacă oferiți mijloacele pentru a vedea datele, inginerii vor folosi acele date și vor face tot posibilul pentru a menține lucrurile eficiente. Dar face parte din munca ta să faci acel acces disponibil și nu un truc special DBA.

Combate oboseala pagerului

Multe organizații nu includ scalarea stratului bazei de date ca un imperativ foarte timpuriu în designul stivei lor – și nu ar trebui. În primele zile ale unei companii, nu ar trebui să vă faceți griji cu privire la modul în care veți limita apelurile API dacă nimeni nu folosește încă API-ul. Dar este potrivit să luăm în considerare câțiva ani mai târziu, când produsul a câștigat popularitate și acel apel API care a lovit un tabel de câteva mii de rânduri de către o mână de clienți este acum un tabel de mai multe milioane de rânduri și câteva clienți ați creat joburi cron care inundă acel API în fiecare dimineață la ora 6 AM în fusul dvs. orar.

Este nevoie de multă muncă pentru a schimba stratul de aplicație al oricărui produs pentru a proteja infrastructura și, între timp, permiterea activității false a bazei de date să provoace oboseala paginar este un mare pericol atât pentru tine, cât și pentru restul organizației operaționale. Familiarizați-vă cu instrumente precum pt-kill, care pot fi utilizate într-un mod rapid pentru a împiedica o gazdă a bazei de date să aibă timpi de nefuncționare majori din cauza volumului neplanificat. Faceți cunoscută utilizarea acestui instrument și comunicați acțiunea și efectul acesteia echipei de inginerie care deține miza, dar este nesănătos să încercați să absorbiți durerea de la ceva ce nu puteți schimba direct și, în cele din urmă, nu va fi benefic pentru a ajuta echipele de inginerie ' învață cum să faci față durerilor de creștere.

Există o mulțime de moduri în care munca unui DBA este unică pentru rolul ei în comparație cu restul echipei de operațiuni, dar asta nu înseamnă că trebuie să fie o preoție magică pe care nimeni nu o poate aborda. Acești pași contribuie în mare măsură la transparența muncii tale, dar cel mai important este să-ți abordezi munca nu ca un gardian al unei grădini de aur a bazei de date, ci ca un expert în domeniu, care poate oferi sfaturi și poate ajuta la dezvoltarea inginerilor cu care lucrezi și a oferi mai mult valoare pentru afacere decât backup-urile și reglarea interogărilor (dar și acestea sunt distractive!).

Mulțumiri speciale minunatei echipe de operațiuni de la Sendgrid, care continuă să mă învețe multe lucruri, și organizatorilor de caritate pentru că au creat titlul acestei postări. Și consultați mai multe postări despre DBA aici.