DBAs, kein Priestertum mehr

Hinweis: Dieser technische Beitrag wurde von unserer DBA Silvia Botros geschrieben und erschien ursprünglich im Dezember 2016 im Sysadvent-Blog.

Unternehmen haben und brauchen seit Jahren Datenbankadministratoren. Daten gehören zu den wichtigsten Vermögenswerten eines Unternehmens. Das bedeutet, dass viele Unternehmen, sobald sie zu dem Punkt wachsen, an dem sie in der Lage sein müssen, schnell zu skalieren, jemanden brauchen, der sicherstellt, dass die Assets gut verwaltet werden, für die Produktanforderungen leistungsfähig sind und im Katastrophenfall für die Wiederherstellung verfügbar sind.

Im traditionellen Sinne bedeutet der Job des DBA, dass er die einzige Person ist, die Zugriff auf die Server hat, auf denen die Daten gehostet werden, die Person, die neue Datenbankcluster für neue Funktionen erstellt, die Person, die neue Schemas entwirft, und die einzige Person, die kontaktiert werden kann, wenn irgendetwas im Zusammenhang mit Datenbanken in einer Produktionsumgebung ausfällt.

Da DBAs traditionell so einzigartige Rollen haben, ist ihre Zeit knapp, und es wird schwieriger, das große Ganze zu sehen, wenn die täglichen Aufgaben überfordern. Es ist üblich, für alle möglichen operativen Aufgaben im DBA-Land auf spröde Tools wie bash zurückzugreifen. Benötigen Sie ein neues DB-Setup von einer sauberen Betriebssysteminstallation? Backups erstellen, validieren oder wiederherstellen? Partitionen rotieren oder veraltete Daten? Wenn Ihr am häufigsten verwendetes Werkzeug Bash-Scripting ist, sieht alles wie ein Nagel aus. Ich bin sicher, dass viele Leser Tweets vorbereiten, um mir zu sagen, wie mächtig Bash ist, aber bitte warten Sie mit Ihrem Kommentar, bis Sie meine Argumentation bewertet haben.

Klingt das alles nach Ihrer Stellenbeschreibung als DBA? Beschreibt die Stellenbeschreibung detailliert das Upgraden von Servern, das Erstellen und Testen von Backups und das Monitoring? Die meisten typischen Stellenausschreibungen für DBAs stellen sicher, dass Sie „mehrere“ Datenbankserver konfigurieren und einrichten müssen (weil erwartet wird, dass DBAs sie von Hand erstellen) und Datenbankverwaltungsaufgaben mit (handgefertigten) Skripten automatisieren.

Ist das wirklich ein skalierbarer Ansatz für das, was in einer wachsenden, schnelllebigen Organisation oft ein Ein-Mann-Team ist?

Ich bin hier, um zu argumentieren, dass Ihre Aufgabe nicht darin besteht, Backups durchzuführen und zu verwalten, Datenbanken zu erstellen und zu verwalten oder Abfragen zu optimieren. Sie werden all diese Dinge im Rahmen Ihrer Arbeit tun, aber das Hauptziel besteht darin, die Daten Ihres Unternehmens zugänglich und skalierbar zu machen. Dies dient nicht nur dazu, das aktuelle Produkt zu betreiben, sondern auch, um neue Funktionen zu entwickeln und den Kunden einen Mehrwert zu bieten.

Warum

Vielleicht möchten Sie fragen, warum sollte ich irgendetwas davon tun? Es gibt ein Argument dafür, die DBA-Rolle traditionell weiterzuführen: Arbeitsplatzsicherheit, oder? Viele Tech-Organisationen tun heutzutage eines oder mehrere der folgenden Dinge:

• Sie bestehen aus vielen kleineren Teams
• Sie bieten Funktionen, indem sie anstelle eines oder weniger größerer Dienste viele Mikrodienste erstellen
• Sie wenden agile Methoden an, um die Bereitstellung von Funktionen zu beschleunigen
• Sie vereinen Operations und Engineering unter einer Führung
• Sie betten Betriebsingenieure mit Entwicklern so früh wie möglich in den Designprozess ein
• Ein DBA-Silo innerhalb des Betriebs bedeutet, dass das Betriebsteam weniger befugt ist, beim Debuggen von Produktionsproblemen in seinem eigenen Stack zu helfen, manchmal nicht in der Lage ist, ohne Unterstützung zu reagieren und Probleme zu beheben, und offen gesagt weniger glaubwürdig ist, wenn es darum geht, eine engere und frühere Zusammenarbeit mit den Engineering-Teams zu fordern, wenn dies der Fall ist nicht praktizieren, was sie innerhalb der Tech Ops predigen.

Was kann also getan werden, um dieses Silo zu sprengen und anderen Leuten das Debuggen zu erleichtern, die Datenbankschicht zu skalieren und Ingenieure in die Lage zu versetzen, skalierbare Dienste zu entwickeln? Die meisten aufstrebenden Shops haben höchstens einen internen DBA. Kann der eine DBA bei allen Design-Meetings „anwesend“ sein, jede Schemaänderung genehmigen und für eine weitläufige, ständig wachsende Datenbank auf Abruf bereitstehen?

DBAs können nicht länger Gatekeeper oder Zauberer sein. Ein DBA kann und sollte eine Wissens- und Erfahrungsquelle für Ingenieure in einer Organisation sein. Sie sollte den Bereitstellungsteams dabei helfen, nicht nur Funktionen zu liefern, sondern Produkte zu liefern, die skalierbar sind und sie befähigen, die Datenbank nicht zu fürchten. Aber wie kann ein DBA das erreichen, während er die tägliche Arbeit der Verwaltung der Datenschicht erledigt? Es gibt eine Reihe von Möglichkeiten, wie Sie als DBA Spitzenleistungen erbringen können.

Konfigurationsmanagement

Das ist sehr wichtig. DBAs bevorzugen in der Regel Old-School-Tools wie Bash für die Datenbankeinrichtung. Ich habe vorhin darauf angespielt und ich habe nichts dagegen, bash selbst zu verwenden. Ich benutze es tatsächlich sehr oft. Aber es ist nicht das richtige Werkzeug für die Cluster-Einrichtung. Vor allem, wenn der Rest der Operationen Bash NICHT verwendet, um den Rest der Architektur zu verwalten. Es stimmt, dass Operations Engineers Bash auch kennen, aber wenn sie den Rest der Infrastruktur mit einem Tool wie Chef oder Puppet verwalten und die Datenbanken hauptsächlich von handgefertigten Skripten verwaltet werden, die vom DBA geschrieben wurden, erlegen Sie ihnen ein Hindernis auf helfen, wenn eine dringende Änderung erforderlich ist.

Darüber hinaus wird es schwieriger, Engineering-Teams dabei zu helfen, die Erstellung der neuen Cluster, die sie für das neue Feature „foo“ benötigen, selbst zu verwalten und zu übernehmen. Sie werden zum „Blocker“, der die Arbeit abschließt. Auch das Kennenlernen des Konfigurationsmanagements in Ihrem Unternehmen ist ein wechselseitiger Vorteil. Wenn Sie sich mit der Verwaltung der Infrastruktur vertraut machen, lernen Sie die Standards des Teams kennen, lernen den Stack besser kennen und können an Änderungen mitarbeiten, die sich letztendlich auf die Produktskalierung auswirken.

Ein DBA, der mit dem Produkt und der Infrastruktur der technischen Organisation als Ganzes vertraut ist, ist von unschätzbarem Wert.

Laufbücher

Dies ist technisch gesehen eine Teilmenge der Dokumentation, die Sie schreiben müssen, aber meiner Erfahrung nach hat es sich als weitaus nützlicher erwiesen, dass ich der Meinung bin, dass darauf gesondert hingewiesen werden muss. Wenn ich Runbooks sage, meine ich ausdrücklich ein Dokument, das für ein Publikum geschrieben wurde, das KEIN DBA ist. Es gibt viele Probleme mit Produktions-DBs, auf die wir als DBAs stoßen können, die für uns einfach zu debuggen und zu lösen sind. Wir neigen dazu, dieses Muskelgedächtnis zu unterschätzen und fallen in das Muster „Schick mir einfach die Seite“ und wir „kümmern uns um die Dinge“.

Wenn Ihr Operations-Team wie meines ist und Sie der einzige DBA sind, bedeutet dies wahrscheinlich, dass jemand anderes im Team die erste Verteidigungslinie ist, wenn ein DB-bezogenes Ereignis auftritt. Eine einfache Dokumentation zum anfänglichen Debugging und zur Datenerfassung kann viel dazu beitragen, dass sich der Rest des Betriebsteams mit der Datenbankschicht vertraut macht und besser damit vertraut ist, wie wir sie überwachen und debuggen. Auch wenn dieses Ereignis immer noch dazu führt, dass der DBA ausgerufen wird, wird das Runbook langsam aber sicher zu einem Ort, an dem jeder erworbenes Wissen hinzufügen kann.

Außerdem füge ich den Seitenbeschreibungen, die zum Pager gehen, einen Link zum zugehörigen Runbook-Abschnitt hinzu (verwenden Sie Anker!). Dies ist unglaublich hilfreich für jemanden, der um 3 Uhr morgens von einem Datenbank-Host angerufen wird, um einen Startpunkt zu finden. Diese Dinge mögen klein erscheinen, aber meiner Erfahrung nach haben sie einen großen Beitrag dazu geleistet, mentale Barrieren für mein Betriebsteam zu überwinden, das bei Bedarf auf Datenbankebene arbeitet.

Als persönliche Vorliebe schreibe ich diese als Markdown-Dokumente in meine Kochbuch-Repositories. Dies fügt sich nahtlos in ein Pull-Request-, Review- und Merge-Muster ein und wird zu einem integralen Bestandteil des Cookbook-Musters der Datenbanken. Wenn Engineering-Teams anfangen, ihre eigenen zu erstellen, werden die Runbooks zu einer vertrauten Vorlage, wenn überall neue Datenbank-Cluster entstehen.

Sichtweite

Wir mögen unsere Terminalbildschirme. Wir lieben sie. Die beliebtesten Tools im MySQL-Land sind immer noch Terminal-Tools, die direkt auf den db-Hosts leben und Vorkenntnisse über sie und ihre Verwendung erfordern. Ich spreche von Dingen wie Innotop und der MySQL-Shell. Diese sind in Ordnung und immer noch hilfreich, aber sie wurden für DBAs erstellt. Wenn Sie nicht der Torwächter für Fragen wie „Gibt es gerade eine Replikationsverzögerung?“ sein möchten. Sie benötigen bessere Tools, um die aktuelle und historische Clusterintegrität für alle Teammitglieder verfügbar und leicht verdaulich zu machen. Ich habe ein paar Beispiele in diesem Bereich:

Orchestrator

Wir verwenden Lesereplikate, um diese Last vom primären zu verteilen, was bedeutet, dass die Verzögerung, sobald sie einen bestimmten Schwellenwert erreicht, zu einem Kundensupportereignis wird. Es ist wichtig, dass jeder im Unternehmen jederzeit erkennen kann, ob bei einem Cluster Verzögerungen auftreten, welche Server in diesem Cluster vorhanden sind und ob einer der Hosts ausgefallen ist. Orchestrator ist in dieser Hinsicht ein großartiges Tool, da es die Visualisierung von Clustern und ihrem Zustand in einem Browserfenster entfernt macht.

Grafana/Graphit

Metriken für den DB-Layer müssen sich an derselben Stelle wie Metriken für den Rest der Infrastruktur befinden. Es ist wichtig, dass das Team diese Metriken nebeneinander stellen kann. Und es ist wichtig, eine einfache Möglichkeit zu haben, historische Metriken für jeden DB-Cluster anzuzeigen. Während Sie vielleicht eine persönliche Vorliebe für Cacti oder Munin oder handwerkliche Vorlagen haben, die Sie im Laufe der Jahre geschrieben haben, wenn die Metriken, die Sie zur Untersuchung von Problemen verwenden, nicht an der gleichen Stelle stehen wie die übrigen Infrastrukturmetriken, stellt dies ein Hindernis dar andere vielbeschäftigte Ingenieure – und sie werden weniger geneigt sein, Ihre Werkzeuge gegenüber denen zu verwenden, die anderswo verwendet werden. Graphite wird häufig für die Aufnahme von Metriken in modernen Infrastrukturteams verwendet, und Grafana ist ein weit verbreitetes Dashboarding-Front-End für Metriken und Analysen.

Leistung abfragen

Wir verwenden VividCortex, um unsere Abfragen in kritischen Clustern zu verfolgen, und obwohl dieser Artikel keine Werbung für einen kostenpflichtigen Dienst sein soll, möchte ich sagen, dass Sie die Möglichkeit haben müssen, die Auswirkungen von Bereitstellungen und Codeänderungen auf laufende Abfragen zu überprüfen und Abfrageleistung etwas, das keinen besonderen Zugriff auf Protokolle und deren manuelle Verarbeitung benötigt. Wenn VividCortex keine Möglichkeit ist (obwohl sie im Ernst großartig sind!), gibt es andere Produkte und Open-Source-Tools, die sogar nur das langsame Protokoll erfassen und es auf einer leicht lesbaren Webseite für Nicht-DBAs zur Überprüfung bereitstellen können und sehen Sie die Wirkung ihres Codes. Der wichtige Punkt hier ist, dass Ingenieure diese Daten verwenden und ihr Bestes tun, um die Dinge effizient zu halten, wenn Sie die Mittel zum Anzeigen der Daten bereitstellen. Aber es ist Teil Ihrer Aufgabe, diesen Zugang verfügbar zu machen, und kein spezieller DBA-Trick.

Bekämpfen Sie die Pager-Müdigkeit

Viele Organisationen berücksichtigen die Skalierung der Datenbankebene nicht als sehr frühe Notwendigkeit in ihrem Stack-Design – und das sollten sie auch nicht. In den frühen Tagen eines Unternehmens sollten Sie sich keine Gedanken darüber machen, wie Sie API-Aufrufe drosseln, wenn noch niemand die API verwendet. Aber es ist angebracht, einige Jahre später darüber nachzudenken, wenn das Produkt an Fahrt gewonnen hat und dieser API-Aufruf, der von einer Handvoll Kunden auf eine Tabelle mit einigen tausend Zeilen traf, jetzt eine Tabelle mit mehreren Millionen Zeilen und ein paar Kunden ist haben Cron-Jobs erstellt, die diese API jeden Morgen um 6 Uhr in Ihrer Zeitzone überfluten.

Es erfordert viel Arbeit, die Anwendungsschicht eines Produkts zum Schutz der Infrastruktur zu ändern, und in der Zwischenzeit ist es eine große Gefahr für Sie und den Rest der Betriebsorganisation, zuzulassen, dass unerwünschte Datenbankaktivitäten zu Pager-Ermüdung führen. Machen Sie sich mit Tools wie pt-kill vertraut, die im Handumdrehen verwendet werden können, um einen Datenbankhost vor größeren Ausfallzeiten aufgrund ungeplanter Datenmengen zu bewahren. Machen Sie die Verwendung dieses Tools bekannt und teilen Sie die Aktion und ihre Auswirkungen dem beteiligten Ingenieurteam mit, aber es ist ungesund, zu versuchen, den Schmerz von etwas zu absorbieren, das Sie nicht direkt ändern können, und es wird letztendlich nicht von Vorteil sein, den Ingenieurteams zu helfen „Lernen Sie, mit Wachstumsschmerzen umzugehen.

Es gibt viele Möglichkeiten, wie die Arbeit einer DBA für ihre Rolle im Vergleich zum Rest des Betriebsteams einzigartig ist, aber das bedeutet nicht, dass es eine magische Priesterschaft sein muss, an die sich niemand herantasten kann. Diese Schritte tragen wesentlich dazu bei, Ihre Arbeit transparent zu machen, aber am wichtigsten ist, dass Sie Ihre Arbeit nicht als Torwächter zu einem goldenen Garten von Datenbankhosts angehen, sondern als Fachexperte, der Sie beraten und dabei helfen kann, die Ingenieure, mit denen Sie zusammenarbeiten, auszubauen und mehr bereitzustellen Wert für das Unternehmen als Backups und Abfrageoptimierung (aber das macht auch Spaß!).

Besonderer Dank geht an das wunderbare Betriebsteam von Sendgrid, das mir weiterhin viele Dinge beibringt, und an Charity Majors für die Prägung des Titels dieses Beitrags. Weitere Beiträge über DBAs finden Sie hier.