Datenbank-Zuverlässigkeitstechnik

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Buch möchten wir dir einen Rahmen für die nächste Generation des Datenbankprofis aufzeigen: den Database Reliability Engineer(DBRE). Überdenke deine vorgefassten Meinungen darüber, wie der Beruf des Datenbankadministrators aussieht. Jeder Software- oder Systemingenieur, der schon einmal mit diesen mysteriösen Wesen zu tun hatte, hat wahrscheinlich eine Menge dieser vorgefassten Meinungen.

Traditionell kennen sich Datenbankadministratoren (DBAs) mit den Interna von Datenbanken (DBs) bestens aus; sie haben den Optimierer, die Abfrage-Engine und das Tuning und die Entwicklung hochleistungsfähiger, spezialisierter Systeme verinnerlicht und gelebt. Wenn sie sich andere Fähigkeiten aneignen mussten, um ihre Datenbanken besser laufen zu lassen, taten sie das. Sie lernten, wie sie die Last auf die CPUs oder Festplattenspindeln verteilen, wie sie ihre DB so konfigurieren, dass sie die CPU-Affinität nutzt, und wie sie Speichersubsysteme bewerten können.

Wenn der DBA auf Sichtbarkeitsprobleme stieß, lernte er, wie er Graphen für die Dinge erstellen kann, die er als Schlüsselmetriken identifiziert hatte. Wenn sie an architektonische Grenzen stießen, lernten sie etwas über Caching-Tiers. Wenn sie an die Grenzen einzelner Knoten stießen, lernten sie neue Designmuster wie Sharding kennen (und trieben deren Entwicklung mit voran). Gleichzeitig beherrschten sie neue Betriebstechniken wie Cache-Invalidierung, Daten-Rebalancing und rollierende DB-Änderungen.

Aber lange, lange Zeit waren DBAs damit beschäftigt, Silos und Schneeflocken zu basteln. Ihre Werkzeuge waren unterschiedlich, ihre Hardware war unterschiedlich und ihre Sprachen waren unterschiedlich. Die DBAs schrieben SQL, die Systemingenieure Perl, die Softwareentwickler C++, die Webentwickler PHP und die Netzwerkingenieure bastelten ihre eigenen perfekten Geräte. Nur die Hälfte der Teams benutzte Versionskontrolle, und sie sprachen nicht miteinander und betraten auch nicht das Revier der anderen. Wie sollten sie auch? Es war, als würde man ein fremdes Land betreten.

Die Tage, in denen sich dieses Modell als effektiv und nachhaltig erweisen kann, sind gezählt. Dieses Buch ist eine Betrachtung der Zuverlässigkeitstechnik durch die Brille der Datenbanktechnik. Wir haben nicht vor, in diesem Buch alles Mögliche zu behandeln. Stattdessen beschreiben wir das, was wir für wichtig halten, durch die Brille deiner Erfahrung. Dieser Rahmen kann dann auf verschiedene Datenbanksysteme, Architekturen und Organisationen angewendet werden.

Warum wir dieses Buch geschrieben haben

Dieses Buch ist seit etwa fünf Jahren ein Traum von uns. Laine kam ohne eine formale technische Ausbildung zur DBA-Rolle. Sie war weder Softwareentwicklerin noch Systemadministratorin, sondern entschied sich nach ihrem Musik- und Theaterstudium für eine technische Laufbahn. Mit diesem Hintergrund fühlte sie sich von den Ideen der Struktur, der Harmonie, des Kontrapunkts und der Orchestrierung in Datenbanken angesprochen.

Seitdem hat sie wahrscheinlich hundert verschiedene DBAs eingestellt, unterrichtet, angeleitet und mit ihnen gearbeitet. Wir Datenbankfachleute sind ein bunter Haufen. Einige kommen aus der Softwarebranche, andere aus der Systembranche. Einige kamen sogar aus dem Bereich der Datenanalytik und der Wirtschaft. Was die Besten jedoch immer auszeichnete, waren ihre Leidenschaft und ihr Verantwortungsgefühl für die Sicherheit und Verfügbarkeit der Unternehmensdaten. Wir erfüllten unsere Rolle als Datenverwalter mit einem Eifer, der an Ungesundheit grenzte. Aber wir fungierten auch als Dreh- und Angelpunkt zwischen den Softwareentwicklern und den Systemingenieuren. Man könnte sagen, wir waren die ursprünglichen DevOps, mit einem Fuß in jeder Welt.

Charitys Hintergrund liegt im operativen Bereich und in der Startup-Kultur. Sie hat eine glorreiche Vergangenheit im schnellen Aufbau von Infrastrukturen, im Treffen schneller Entscheidungen, die ein Startup zum Erfolg führen können, im Eingehen von Risiken und im Treffen schwieriger Entscheidungen auf der Grundlage stark begrenzter Ressourcen. Meistens erfolgreich, mehr oder weniger. Sie ist eine zufällige DBA, die Daten liebt. Sie hat immer in Betriebsteams gearbeitet, für die es keine spezialisierten DBAs gab, so dass sich die Teams für Softwareentwicklung und Betriebstechnik diese Arbeit schließlich teilten.

Da wir dies schon so lange und mit unterschiedlicher Vergangenheit tun, haben wir die Trends des letzten Jahrzehnts erkannt und uns zu eigen gemacht. Das Leben der DBAs war oft von Mühsal und Unsichtbarkeit geprägt. Jetzt haben wir die Werkzeuge und die kollektive Unterstützung, um die Rolle des DBA in die eines erstklassigen Bürgers zu verwandeln und uns auf die Bereiche zu konzentrieren, in denen der DBA den größten Nutzen bringen kann.

Mit diesem Buch wollten wir der nächsten Generation von Ingenieurinnen und Ingenieuren helfen, eine wirklich glückliche und produktive Karriere zu machen und den Einfluss der vorherigen Generationen fortzusetzen.

Für wen dieses Buch ist

Dieses Buch richtet sich an alle, die sich für das Design, den Aufbau und den Betrieb von zuverlässigen Datenspeichern interessieren. Vielleicht bist du ein Softwareentwickler, der sein Wissen über Datenbanken erweitern möchte. Vielleicht bist du auch ein Systemingenieur, der das Gleiche tun möchte. Wenn du ein Datenbankprofi bist, der seine Fähigkeiten ausbauen möchte, wirst du hier ebenfalls fündig. Wenn du neu in der Branche bist, sollte dir dieses Buch ebenfalls ein solides Verständnis vermitteln können. Dieses Buch ist schließlich ein Rahmenwerk.

Wir gehen davon aus, dass du bereits über grundlegende technische Kenntnisse in der Linux/Unix-Systemadministration sowie in Web- und/oder Cloud-Architekturen verfügst. Wir gehen auch davon aus, dass du ein Ingenieur bist, der einen von zwei Wegen einschlägt. Auf dem einen Weg verfügst du über fundierte Kenntnisse in einer anderen Disziplin, z.B. Systemadministration oder Softwareentwicklung, und bist daran interessiert, dein technisches Wissen um die Disziplin der Datenbanktechnik zu erweitern. Auf der anderen Seite stehst du am Anfang oder in der Mitte deiner Karriere und möchtest deine technische Tiefe als Spezialist für Datenbanktechnik ausbauen.

Wenn du im Management oder sogar im Projektmanagement tätig bist, kannst du dieses Buch nutzen, um die Anforderungen an die Datenbanksysteme zu verstehen, die deine Dienste unterstützen werden. Wir sind der festen Überzeugung, dass das Management die Betriebs- und Datenbankprinzipien verstehen muss, um die Erfolgswahrscheinlichkeit seiner Teams und Projekte zu erhöhen.

Vielleicht bist du auch jemand ohne einen traditionellen technischen Hintergrund. Vielleicht bist du ein "zufälliger DBA", der als Business Analyst ins kalte Wasser gesprungen ist und so gelernt hat, wie man Datenbanken bedient. Es gibt viele Datenbankprofis, die eher über Excel als über einen Entwicklungs- oder Systemjob in die Datenbankwelt gekommen sind.

Wie dieses Buch aufgebaut ist

In diesem Buch präsentieren wir die Informationen in zwei Abschnitten. Der erste Abschnitt ist der Kernlehrplan für den Betrieb. Das sind die Grundlagen des Betriebs, die jeder Datenbankingenieur, Softwareentwickler und sogar Produktverantwortliche kennen sollte. Danach geht es um Daten: Modellierung, Speicherung, Replikation, Zugriff und vieles mehr. Hier besprechen wir auch Architekturentscheidungen und Datenpipelines. Das sollte spannend sein!

Es gibt einen Grund dafür, dass diese Geschichte sehr operativ ausgerichtet ist: Du kannst kein guter "DBRE" sein, ohne ein guter "RE" zu sein. Und das kannst du nur sein, wenn du ein guter "E" bist. Der moderne DBRE ist darauf spezialisiert, datenbezogene Probleme zu verstehen, die auf den Grundlagen der Systemtechnik beruhen.

Aber der Punkt ist, dass jeder Ingenieur Datendienste betreiben kann. Wir sprechen jetzt dieselben Sprachen. Wir verwenden dieselben Repos und dieselben Codeüberprüfungsprozesse. Die Betreuung von Datenbanken ist eine Erweiterung des Operations Engineerings - ein cremiger Zuckerguss aus speziellem Wissen und Bewusstsein auf dem Kuchen, der den Betrieb von Systemen im großen Maßstab ermöglicht - genauso wie ein hervorragender Netzwerkingenieur zuerst wissen muss, wie man ein Ingenieur ist, und dann zusätzliche Dinge darüber wissen muss, wie man den Datenverkehr handhabt, wovor man Angst haben muss, was die bewährten Methoden sind, wie man die Netzwerktopologie bewertet und so weiter.

Hier ist eine Übersicht darüber, was dich in den einzelnen Kapiteln erwartet:

Kapitel 1 ist eine Einführung in das Konzept des Database Reliability Engineering. Wir beginnen mit den Leitprinzipien, gehen dann zum betriebszentrierten Kern über und geben schließlich einen Rahmen für die Entwicklung einer Vision für DBRE auf der Grundlage der Maslowschen Bedürfnishierarchie.

In Kapitel 2 beginnen wir mit den Anforderungen an den Servicegrad. Diese sind genauso wichtig wie die Anforderungen an die Funktionen eines Produkts. In diesem Kapitel erfahren wir, was Serviceanforderungen sind und wie man sie definiert, was nicht so einfach ist, wie es klingt. Anschließend besprechen wir, wie man diese Anforderungen im Laufe der Zeit messen und mit ihnen arbeiten kann.

In Kapitel 3 geht es um Risikobewertung und -management. Nach einer grundlegenden Diskussion über Risiken wird ein praktischer Prozess für die Einbeziehung der Risikobewertung in die System- und Datenbankentwicklung erörtert. Dabei wird auch auf Fallstricke und komplexe Zusammenhänge hingewiesen.

In Kapitel 4 besprechen wir die operative Sichtbarkeit. Hier geht es um Kennzahlen und Ereignisse und darum, wie man einen Plan dafür erstellt, was man zu messen beginnt und was im Laufe der Zeit verbessert werden soll. Wir befassen uns mit den Komponenten von Überwachungssystemen und den Kunden, die sie nutzen.

In den Kapiteln 5 und 6 tauchen wir dann in die Infrastrukturtechnik und das Infrastrukturmanagement ein. In diesem Abschnitt besprechen wir die Grundsätze für den Aufbau von Hosts für Datenspeicher. Wir werden uns mit Virtualisierung und Containerisierung, Konfigurationsmanagement, Automatisierung und Orchestrierung beschäftigen, um dir zu helfen, all die beweglichen Teile zu verstehen, die für den Aufbau dieser Systeme, die Daten speichern und darauf zugreifen, erforderlich sind.

Kapitel 7 ist die Sicherung und Wiederherstellung. Das ist vielleicht das Wichtigste, was die DBE beherrschen muss. Wenn Daten verloren gehen, ist das Spiel vorbei. Ausgehend von den Anforderungen an die Service Levels bewerten wir geeignete Sicherungs- und Wiederherstellungsmethoden, die Skalierung und die Prüfung dieses wichtigen und oft übersehenen Aspekts des Betriebs.

In Kapitel 8 geht es um das Versionsmanagement. Wie testen, erstellen und verteilen wir Änderungen an Datenspeichern? Was ist mit Änderungen am Datenzugriffscode und an SQL? Bereitstellung, Integration und Auslieferung sind der Hauptteil dieses Kapitels.

Kapitel 9 ist der Sicherheit gewidmet. Datensicherheit ist entscheidend für das Überleben eines Unternehmens. In diesem Kapitel geht es um Strategien für die Planung und das Management der Sicherheit in sich ständig weiterentwickelnden Dateninfrastrukturen.

Kapitel 10 befasst sich mit der Speicherung, Indizierung und Replikation von Daten. Wir besprechen, wie relationale Daten gespeichert werden, und vergleichen dies mit sortierten Strings und logstrukturierten Merge-Bäumen. Nachdem wir die Indexierungsvarianten besprochen haben, werden wir die Topologien der Datenreplikation untersuchen.

Kapitel 11 ist unser Feldführer für Datenspeicher. Hier besprechen wir eine Vielzahl von Eigenschaften, auf die du bei Datenspeichern achten solltest, die du evaluieren oder betreiben wirst. Dazu gehören sowohl konzeptionelle Eigenschaften, die für Anwendungsentwickler und -architekten von großer Bedeutung sind, als auch interne Eigenschaften, die sich auf die physische Implementierung der Datenspeicher konzentrieren.

In Kapitel 12 befassen wir uns mit einigen der gängigsten Architekturmuster für verteilte Datenbanken und den Pipelines, die sie beinhalten. Wir beginnen mit einem Blick auf die architektonischen Komponenten, die typischerweise in einem Datenbank-Ökosystem zu finden sind, sowie auf ihre Vorteile, Komplexität und allgemeine Verwendung. Dann erkunden wir Architekturen und Pipelines, oder zumindest einige Beispiele.

In Kapitel 13 schließlich erörtern wir, wie du eine Kultur des Database Reliability Engineering in deiner Organisation aufbauen kannst. Wir untersuchen die verschiedenen Möglichkeiten, wie du die Rolle des DBRE von der eines Administrators zu der eines Ingenieurs in den heutigen Unternehmen umwandeln kannst.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

O'Reilly Safari

Hinweis

Safari (ehemals Safari Books Online) ist eine mitgliederbasierte Schulungs- und Nachschlageplattform für Unternehmen, Behörden, Lehrkräfte und Einzelpersonen.

Mitglieder haben Zugang zu Tausenden von Büchern, Schulungsvideos, Lernpfaden, interaktiven Tutorials und kuratierten Playlists von über 250 Verlagen, darunter O'Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett und Course Technology, um nur einige zu nennen.

Weitere Informationen erhältst du unter http://oreilly.com/safari.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter http://bit.ly/database-reliability-engineering aufrufen .

Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an [e-mail].

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia