Kapitel 1. Einführung in das Database Reliability Engineering
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Unser Ziel mit diesem Buch ist es, dir, dem Leser, einen Leitfaden und einen Rahmen zu bieten, der dich auf dem Weg zu einem wirklich exzellenten Database Reliability Engineer (DBRE) weiterbringt. Bei der Namensgebung des Buches haben wir uns dafür entschieden, den Begriff " Reliability Engineer" und nicht "Administrator" zu verwenden.
Ben Treynor, VP of Engineering bei Google, sagt Folgendes über Zuverlässigkeitstechnik:
Im Grunde genommen wird die Arbeit, die bisher von einem Betriebsteam erledigt wurde, von Ingenieuren mit Software-Know-how erledigt, wobei man sich darauf verlässt, dass diese Ingenieure von Natur aus dazu veranlagt und in der Lage sind, menschliche Arbeit durch Automatisierung zu ersetzen.
Die Datenbankexperten von heute müssen Ingenieure sein, keine Administratoren. Wir bauen Dinge. Wir erschaffen Dinge. Als Ingenieure, die Devops praktizieren, sitzen wir alle im selben Boot, und nichts ist das Problem von jemand anderem. Als Ingenieure wenden wir wiederholbare Prozesse, fundiertes Wissen und Expertenwissen an, um Produktionsdatenspeicher und die darin enthaltenen Datenstrukturen zu entwerfen, aufzubauen und zu betreiben. Als Datenbank-Zuverlässigkeitsingenieure müssen wir die Betriebsprinzipien und das tiefe Datenbankwissen, das wir besitzen, noch einen Schritt weiter bringen.
Wenn du dir die Nicht-Speicherkomponenten der heutigen Infrastrukturen ansiehst, wirst du feststellen, dass diese Systeme leicht programmgesteuert und oft automatisch aufgebaut, betrieben und zerstört werden können. Die Lebensdauer dieser Komponenten kann in Tagen, manchmal sogar in Stunden oder Minuten gemessen werden. Wenn eine Komponente ausfällt, gibt es jede Menge andere, die einspringen und die Qualität der Dienste auf dem erwarteten Niveau halten.
Unser nächstes Ziel ist es, dass du einen Rahmen von Prinzipien und Praktiken für die Entwicklung, den Aufbau und den Betrieb von Datenspeichern innerhalb der Paradigmen des Reliability Engineering und der Devops-Kulturen erwirbst. Du kannst dieses Wissen auf jede Datenbanktechnologie oder -umgebung anwenden, in der du in jeder Phase des Wachstums deines Unternehmens arbeiten musst.
Leitprinzipien des DBRE
Als wir uns hingesetzt haben, um dieses Buch zu schreiben, war eine der ersten Fragen, die wir uns gestellt haben, die nach den Grundsätzen dieser neuen Version des Datenbankberufs. Wenn wir die Art und Weise, wie die Menschen an die Entwicklung und Verwaltung von Datenspeichern herangehen, neu definieren wollten, mussten wir die Grundlagen für die Verhaltensweisen festlegen, für die wir eintreten wollten.
Schützen Sie die Daten
Traditionell war der Schutz von Daten schon immer ein Grundprinzip von Datenbankexperten und ist es auch heute noch. Der allgemein akzeptierte Ansatz wurde über die folgenden Wege versucht:
Eine strikte Aufgabentrennung zwischen dem Software- und dem Datenbank-Ingenieur
Strenge, regelmäßig getestete Sicherungs- und Wiederherstellungsprozesse
Gut geregelte und regelmäßig geprüfte Sicherheitsverfahren
Teure Datenbanksoftware mit starken Haltbarkeitsgarantien
Teure Speicherung mit Redundanz aller Komponenten
Umfassende Kontrolle von Änderungen und Verwaltungsaufgaben
In Teams mit kollaborativen Kulturen kann die strikte Aufgabentrennung nicht nur lästig sein, sondern auch Innovation und Geschwindigkeit einschränken. In Kapitel 8, Release Management, werden wir Möglichkeiten erörtern, Sicherheitsnetze zu schaffen und die Notwendigkeit der Aufgabentrennung zu verringern. Außerdem konzentrieren sich diese Umgebungen mehr auf Tests, Automatisierung und Schadensbegrenzung als auf umfassende Änderungskontrollen.
Immer häufiger entscheiden sich Architekten und Ingenieure für Open-Source-Datenspeicher, die keine Haltbarkeit garantieren können, wie es beispielsweise Oracle in der Vergangenheit getan hat. Manchmal bringt diese geringere Haltbarkeit einem Team, das schnell skalieren will, die nötigen Leistungsvorteile. Die Wahl des richtigen Datenspeichers und das Verständnis für die Auswirkungen dieser Entscheidungen werden in Kapitel 11 behandelt. Die Erkenntnis, dass es je nach den zu verwaltenden Daten mehrere Tools gibt, und die richtige Wahl, wird immer mehr zur Norm.
Auch die zugrunde liegende Speicherung hat sich stark verändert. In einer Welt, in der Systeme häufig virtualisiert werden, finden Netzwerk- und flüchtige Speicherung ihren Platz im Datenbankdesign. Wir werden dies in Kapitel 5 näher erläutern.
Der neue Ansatz zum Datenschutz könnte eher so aussehen:
Verantwortung für die Daten, die von funktionsübergreifenden Teams geteilt werden.
Standardisierte und automatisierte Sicherungs- und Wiederherstellungsprozesse mit dem Segen von DBRE.
Standardisierte Sicherheitsrichtlinien und -verfahren, die von den DBRE- und Sicherheitsteams abgesegnet wurden.
Alle Richtlinien werden durch automatische Bereitstellung und Implementierung durchgesetzt.
Die Datenanforderungen diktieren den Datenspeicher, wobei die Bewertung der Anforderungen an die Haltbarkeit Teil des Entscheidungsprozesses ist.
Vertrauen auf automatisierte Prozesse, Redundanz und eingespielte Abläufe statt auf teure, komplizierte Hardware.
Änderungen, die in die Automatisierung der Bereitstellung und der Infrastruktur einfließen, mit Schwerpunkt auf Tests, Fallback und Schadensbegrenzung.
Selbstbedienung in großem Maßstab
Ein talentierter DBRE ist ein weitaus selteneres Gut als ein Site Reliability Engineer (SRE). Die meisten Unternehmen können sich nicht mehr als einen oder zwei leisten und behalten. Deshalb müssen wir den größtmöglichen Wert schaffen, indem wir Selbstbedienungsplattformen für die Teams schaffen. Durch die Festlegung von Standards und die Bereitstellung von Werkzeugen können die Teams neue Dienste einführen und entsprechende Änderungen in der erforderlichen Geschwindigkeit vornehmen, ohne sich auf einen überlasteten Datenbankingenieur zu verlassen. Beispiele für diese Art von Selbstbedienungsmethoden sind:
Stelle sicher, dass die richtigen Metriken von den Datenspeichern gesammelt werden, indem du die richtigen Plug-ins bereitstellst.
Erstellung von Sicherungs- und Wiederherstellungsprogrammen, die für neue Datenspeicher eingesetzt werden können.
Festlegung von Referenzarchitekturen und -konfigurationen für Datenspeicher, die für den Betrieb freigegeben sind und von Teams eingesetzt werden können.
Zusammenarbeit mit der Sicherheitsbehörde, um Standards für den Einsatz von Datenspeichern zu definieren.
Erstellung von sicheren Bereitstellungsmethoden und Testskripten für die anzuwendenden Datenbankänderungen.
Mit anderen Worten: Ein effektiver DBRE funktioniert, indem er andere befähigt und sie anleitet, anstatt als Gatekeeper zu fungieren.
Beseitigung der Mühsal
Die Google SRE-Teams verwenden häufig den Ausdruck "Elimination of Toil", der in Kapitel 5 des Google SRE-Buches behandelt wird. In dem Buch wird "Mühe" definiert als:
Arbeit ist die Art von Arbeit, die mit dem Betrieb eines Produktionsdienstes verbunden ist. Sie ist in der Regel manuell, repetitiv, automatisierbar, taktisch, ohne bleibenden Wert und skaliert linear mit dem Wachstum des Dienstes.
Ein effektiver Einsatz von Automatisierung und Standardisierung ist notwendig, um sicherzustellen, dass die DBREs nicht durch Arbeit überlastet werden. Im Laufe dieses Buches werden wir Beispiele für DBRE-spezifische Mühen und Ansätze zu deren Minderung aufzeigen. Allerdings ist das Wort "Arbeit" immer noch sehr vage und mit vielen Vorurteilen behaftet, die von Person zu Person unterschiedlich sind. Wenn wir in diesem Buch von Arbeit sprechen, meinen wir vor allem manuelle Tätigkeiten, die sich wiederholen, nicht kreativ sind und keine Herausforderung darstellen.
Datenbanken sind keine besonderen Schneeflocken
Unsere Systeme sind nicht mehr oder weniger wichtig als alle anderen Komponenten, die den Bedürfnissen des Unternehmens dienen. Wir müssen uns um Standardisierung, Automatisierung und Ausfallsicherheit bemühen. Entscheidend ist dabei die Vorstellung, dass die Komponenten von Datenbank-Clustern nicht heilig sind. Wir sollten in der Lage sein, jede Komponente zu verlieren und sie effizient und ohne Sorge zu ersetzen. Fragile Datenspeicher in gläsernen Räumen gehören der Vergangenheit an.
Die Metapher von Haustieren und Rindern wird oft verwendet, um den Unterschied zwischen einer besonderen Schneeflocke und einer gewöhnlichen Dienstkomponente zu verdeutlichen. Das Original geht an Bill Baker, Microsoft Distinguished Engineer. Ein Server ist ein Haustier, das du fütterst, pflegst und wieder gesund pflegst, wenn es krank ist. Er hat auch einen Namen. Bei Travelocity im Jahr 2000 waren unsere Server Simpsons-Figuren, und unsere beiden SGI-Server, auf denen Oracle lief, hießen Patty und Selma. Ich verbrachte so viele Stunden mit diesen Mädels in späten Nächten. Sie waren sehr pflegeintensiv!
Rinderserver haben Nummern, keine Namen. Du verbringst keine Zeit damit, Server anzupassen, geschweige denn, dich bei einzelnen Hosts anzumelden. Wenn sie Anzeichen von Krankheit zeigen, tötest du sie aus der Herde. Natürlich solltest du die gekeulten Rinder für die Forensik aufbewahren, wenn du ungewöhnliche Mengen an Krankheiten feststellst. Aber wir wollen diese Metapher nicht noch weiter ausschmücken.
Datenspeicher gehören zu den letzten Überbleibseln des "Pethos". Schließlich enthalten sie "die Daten" und können nicht wie austauschbares Vieh mit kurzer Lebensdauer und vollständiger Standardisierung behandelt werden. Was ist mit den speziellen Replikationsregeln für unser Reporting Replikat? Was ist mit den unterschiedlichen Konfigurationen für den redundanten Standby der Primärdaten?
Beseitige die Barrieren zwischen Software und Betrieb
Deine Infrastruktur, Konfigurationen, Datenmodelle und Skripte sind alle Teil der Software. Studiere und beteilige dich am Entwicklungszyklus der Software wie jeder andere Ingenieur auch. Kodieren, testen, integrieren, bauen, testen und einsetzen. Haben wir das Testen erwähnt?
Für jemanden, der aus dem operativen Bereich kommt und Skripte schreibt, ist das vielleicht der schwierigste Paradigmenwechsel. Die Art und Weise, wie Softwareentwickler/innen sich in einem Unternehmen bewegen, und die Systeme und Dienste, die für die Bedürfnisse des Unternehmens entwickelt werden, können nicht miteinander harmonieren. Softwareentwicklungs-Organisationen haben ganz bestimmte Vorgehensweisen bei der Entwicklung, dem Testen und der Bereitstellung von Funktionen und Anwendungen.
In einer traditionellen Umgebung war der zugrunde liegende Prozess des Entwerfens, Erstellens, Testens und Überführens der Infrastruktur und der damit verbundenen Dienste in die Produktion zwischen Softwareentwicklung (SWE), Systemtechnik (SE) und DBA getrennt. Der oben beschriebene Paradigmenwechsel drängt darauf, diese Diskrepanz zu beseitigen, was bedeutet, dass DBREs und Systemingenieure ähnliche Methoden anwenden müssen, um ihre Aufträge zu erledigen.
Softwareentwickler/innen müssen den Betrieb lernen!
Allzu oft wird Betriebsleuten gesagt, dass sie lernen sollen "zu coden oder nach Hause zu gehen". Dem stimme ich zwar zu, aber auch das Gegenteil muss der Fall sein. Softwareentwickler, die nicht dazu angehalten und angeleitet werden, die Prinzipien und Praktiken des Betriebs und der Infrastruktur zu erlernen, werden anfälligen, nicht leistungsfähigen und potenziell unsicheren Code erstellen. Das Impedanzgefälle lässt sich nur beseitigen, wenn alle Teams an einen Tisch gebracht werden!
DBREs können auch direkt in ein Softwareentwicklungsteam eingebettet sein, in der gleichen Codebasis arbeiten, untersuchen, wie der Code mit den Datenspeichern interagiert, und den Code im Hinblick auf Leistung, Funktionalität und Zuverlässigkeit modifizieren. Die Beseitigung dieser organisatorischen Hindernisse führt zu einer Verbesserung der Zuverlässigkeit, Leistung und Geschwindigkeit, die um Größenordnungen höher ist als bei traditionellen Modellen.
Überblick über den Kern der Operationen
Eine der Kernkompetenzen des DBRE ist der Betrieb. Das sind die Bausteine für den Entwurf, das Testen, den Aufbau und den Betrieb eines Systems mit nicht trivialen Anforderungen an Größe und Zuverlässigkeit. Das heißt, wenn du Datenbankingenieur/in werden willst, musst du diese Dinge wissen.
Der Betrieb ist auf der Makroebene keine Rolle. Der Betrieb ist die Summe aller Fähigkeiten, Kenntnisse und Werte, die dein Unternehmen im Zusammenhang mit der Bereitstellung und Wartung von Qualitätssystemen und -software aufgebaut hat. Das sind sowohl deine impliziten Werte als auch deine expliziten Werte, Gewohnheiten, Stammeswissen und Belohnungssysteme. Jeder, vom technischen Support über die Produktmitarbeiter bis hin zum CEO, ist an den betrieblichen Ergebnissen beteiligt.
Allzu oft wird das nicht gut gemacht. Viele Unternehmen haben eine miserable Betriebskultur, die jeden ausbrennt, der sich ihr nähert. Das kann der Disziplin einen schlechten Ruf einbringen, an den viele denken, wenn sie an Jobs im operativen Bereich denken, sei es im System-, Datenbank- oder Netzwerkbereich. Trotzdem ist die Betriebskultur eine Eigenschaft, die sich aus der Art und Weise ergibt, wie dein Unternehmen seinen technischen Auftrag erfüllt. Wenn du uns also erzählst, dass es in deinem Unternehmen keine Ops gibt, werden wir dir das nicht abnehmen.
Vielleicht bist du ein Softwareentwickler oder ein Befürworter von Infrastruktur und Plattformen als Service. Vielleicht bezweifelst du, dass der Betrieb eine Notwendigkeit für den unerschrockenen Datenbankingenieur ist. Die Vorstellung, dass Softwareentwickler/innen durch Serverless-Computing-Modelle von der Notwendigkeit befreit werden, sich um die betrieblichen Auswirkungen zu kümmern, ist schlichtweg falsch. Es ist genau das Gegenteil der Fall. Es ist eine schöne neue Welt, in der es keine eingebetteten Betriebsteams gibt - in der die Leute, die das Operations Engineering für dich übernehmen, Google SREs und AWS Systemingenieure und PagerDuty und DataDog und so weiter sind. Dies ist eine Welt, in der Anwendungsingenieure in den Bereichen Betrieb, Architektur und Leistung viel besser sein müssen, als sie es derzeit sind.
Hierarchie der Bedürfnisse
Einige von euch werden dieses Buch mit Erfahrung in Unternehmen und andere in Start-ups lesen. Wenn wir uns den Systemen nähern und darüber nachdenken, lohnt es sich, darüber nachzudenken, was du am ersten Tag tun würdest, wenn du die Verantwortung für den Betrieb eines Datenbanksystems übernimmst. Hast du Backups? Funktionieren sie? Bist du dir sicher? Gibt es ein Replikat, auf das du fehlschlagen kannst? Weißt du, wie man das macht? Befindet sie sich an der gleichen Steckdosenleiste, dem gleichen Router, der gleichen Hardware oder Verfügbarkeitszone wie die primäre? Erkennst du, wenn die Backups irgendwie fehlschlagen? Und wie?
Mit anderen Worten: Wir müssen über eine Hierarchie der Datenbankbedürfnisse sprechen.
Für den Menschen ist die Maslowsche Bedürfnispyramide eine Pyramide von Wünschen, die befriedigt werden müssen, damit wir aufblühen: physiologisches Überleben, Sicherheit, Liebe und Zugehörigkeit, Wertschätzung und Selbstverwirklichung. An der Basis der Pyramide stehen die grundlegendsten Bedürfnisse, wie das Überleben. Jede Stufe geht grob auf die nächste über - Überleben vor Sicherheit, Sicherheit vor Liebe und Zugehörigkeit und so weiter. Wenn die ersten vier Ebenen befriedigt sind, erreichen wir die Selbstverwirklichung, in der wir sicher erforschen, spielen und erschaffen können und unser einzigartiges Potenzial voll ausschöpfen können. Das bedeutet es also für uns Menschen. Lasst uns das als Metapher für die Bedürfnisse von Datenbanken verwenden.
Überleben und Sicherheit
Die wichtigsten Anforderungen an deine Datenbank sind Backups, Replikation und Failover. Hast du eine Datenbank? Ist sie am Leben? Kannst du sie anpingen? Reagiert deine Anwendung? Bekommt sie ein Back-up? Funktionieren Wiederherstellungen? Woran merkst du, wenn das nicht mehr der Fall ist?
Sind deine Daten sicher? Gibt es mehrere Live-Kopien deiner Daten? Weißt du, wie du einen Failover durchführen kannst? Sind deine Kopien über mehrere physische Verfügbarkeitszonen oder mehrere Stromleisten und Racks verteilt? Sind deine Backups konsistent? Kannst du sie zu einem bestimmten Zeitpunkt wiederherstellen? Erkennst du, wenn deine Daten beschädigt werden? Und wie? Diese Fragen werden wir im Abschnitt "Backup und Wiederherstellung" genauer untersuchen.
Dies ist auch der Zeitpunkt, an dem du dich auf die Skalierung vorbereitest. Eine verfrühte Skalierung ist nicht ratsam, aber du solltest Sharding, Wachstum und Skalierung jetzt in Betracht ziehen, wenn du die IDs für wichtige Datenobjekte, Speichersysteme und die Architektur festlegst.
Liebe und Zugehörigkeit
Bei Love and belonging geht es darum, deine Daten zu einem erstklassigen Bestandteil deiner Softwareentwicklungsprozesse zu machen. Es geht darum, Silos zwischen deinen Datenbanken und dem Rest deiner Systeme aufzubrechen. Dies ist sowohl technisch als auch kulturell bedingt, weshalb man es auch einfach als "Devops-Bedürfnis" bezeichnen könnte. Auf einer hohen Ebene bedeutet es, dass die Verwaltung deiner Datenbanken (so weit wie möglich) so aussehen und sich anfühlen sollte wie die Verwaltung deiner anderen Systeme. Es bedeutet auch, dass du kulturell die Fluidität und Querschnittsfunktionalität förderst. Die Phase der Liebe und Zugehörigkeit ist die Phase, in der du langsam aufhörst, dich als root einzuloggen und Cowboy-Befehle auszuführen.
Hier beginnt die Anwendung der gleichen Verfahren zur Codeüberprüfung und Bereitstellung. Die Datenbankinfrastruktur und -bereitstellung sollte Teil des gleichen Prozesses sein wie alle anderen Architekturkomponenten. Die Arbeit mit den Daten sollte sich konsistent zu allen anderen Teilen der Anwendung anfühlen, damit jeder das Gefühl hat, dass er die Datenbankumgebung nutzen und unterstützen kann.
Widerstehe dem Drang, deinen Entwicklern Angst einzuflößen. Das ist ganz einfach und sehr verlockend, denn es fühlt sich besser an, wenn du das Gefühl hast, die Kontrolle zu haben. Das ist es aber nicht - und das hast du auch nicht. Es ist für alle viel besser, wenn du diese Energie in den Aufbau von Leitplanken investierst, damit es für niemanden schwieriger ist, Dinge versehentlich zu zerstören. Kläre alle auf und befähige sie, ihre eigenen Veränderungen vorzunehmen. Sprich gar nicht erst darüber, wie du Misserfolge verhindern kannst, denn das ist unmöglich. Mit anderen Worten: Schaffe widerstandsfähige Systeme und ermutige alle, so viel wie möglich mit dem Datenspeicher zu arbeiten.
Esteem
Wertschätzung ist das höchste der Bedürfnisse in der Pyramide. Für Menschen bedeutet das Respekt und Beherrschung. Für Datenbanken bedeutet dies Dinge wie Beobachtbarkeit, Fehlersuche, Introspektion und Instrumentierung. Es geht darum, dein Speichersystem selbst zu verstehen, aber auch darum, Ereignisse im gesamten Stack zu korrelieren. Auch in dieser Phase gibt es zwei Aspekte: Zum einen geht es darum, wie sich deine Produktionsdienste in dieser Phase entwickeln, und zum anderen um deine Menschen.
Deine Dienste sollten dir sagen, ob sie gut oder schlecht laufen oder ob sie Fehlerraten aufweisen. Du solltest nie auf eine Grafik schauen müssen, um das herauszufinden. Wenn deine Dienste ausgereift sind, verlangsamt sich das Tempo der Veränderungen ein wenig, da deine Entwicklung vorhersehbarer wird. Da du in der Produktion arbeitest, lernst du jeden Tag mehr über die Schwächen, das Verhalten und die Fehlerbedingungen deines Speichersystems. Das ist vergleichbar mit den Teenagerjahren in der Dateninfrastruktur. Was du mehr als alles andere brauchst, ist Transparenz über das, was vor sich geht. Je komplexer dein Produkt ist, desto mehr bewegliche Teile gibt es und desto mehr Entwicklungszyklen musst du für die Entwicklung der Tools aufwenden, die du brauchst, um herauszufinden, was passiert.
Du brauchst auch Knöpfe. Du brauchst die Möglichkeit, die Qualität des Dienstes selektiv zu verschlechtern, anstatt ihn komplett herunterzufahren, z. B.:
Flaggen, mit denen du die Website in den Nur-Lese-Modus versetzen kannst
Bestimmte Funktionen deaktivieren
Schreiben in der Warteschlange für spätere Anwendung
Die Möglichkeit, schlechte Akteure oder bestimmte Endpunkte auf eine schwarze Liste zu setzen
Deine Menschen haben ähnliche, aber nicht völlig überlappende Bedürfnisse. Ein häufiges Muster ist, dass Teams überreagieren, sobald sie in die Produktion einsteigen. Sie haben nicht genug Überblick, also kompensieren sie das, indem sie alles überwachen und sich zu oft selbst anpiepsen. Es ist leicht, von null Graphen auf buchstäblich Hunderttausende von Graphen zu kommen, von denen 99% völlig bedeutungslos sind. Das ist nicht besser. Es kann sogar schlimmer sein. Wenn es so viel Rauschen erzeugt, dass deine Mitarbeiter das Signal nicht mehr finden und nur noch Logdateien durchsuchen und raten können, ist das genauso schlimm oder schlimmer, als wenn es keine Graphen gibt.
Hier kannst du anfangen, deine Mitarbeiter auszubrennen, indem du sie unterbrichst, sie aufweckst und ihnen beibringst, dass sie sich nicht um Alarme kümmern oder darauf reagieren sollen. Wenn du in der Anfangsphase davon ausgehst, dass jeder auf Abruf zur Verfügung steht, musst du die Dinge dokumentieren. Wenn du in der Aufbauphase bist, die Bereitschaft geteilt wird und du die Leute aus ihrer Komfortzone drängst, gib ihnen ein wenig Hilfe. Schreibe eine möglichst effektive Dokumentation und Verfahren.
Selbstverwirklichung
So wie das bestmögliche Selbst eines jeden Menschen einzigartig ist, ist auch die selbstverwirklichte Speicherung eines jeden Unternehmens einzigartig. Das platonische Ideal eines Speichersystems für Facebook sieht nicht wie das perfekte System für Pinterest oder Github aus, geschweige denn für ein kleines Startup. Aber genauso wie es Muster für gesunde, selbstverwirklichte Menschen gibt (die im Supermarkt keine Wutanfälle bekommen, sich gesund ernähren und Sport treiben), gibt es auch Muster für das, was wir uns als gesunde, selbstverwirklichte Speicherung vorstellen können.
In diesem Zusammenhang bedeutet Selbstverwirklichung, dass deine Dateninfrastruktur dir hilft, dein Ziel zu erreichen, und dass deine Datenbank-Workflows keine Hindernisse für den Fortschritt sind. Vielmehr helfen sie deinen Entwicklern, ihre Arbeit zu erledigen, und bewahren sie vor unnötigen Fehlern. Häufige Betriebsstörungen und langweilige Ausfälle sollten sich von selbst beheben und das System in einem gesunden Zustand halten, ohne dass Menschen nachhelfen müssen. Es bedeutet, dass du eine Skalierungsgeschichte hast, die für deine Bedürfnisse funktioniert. Ob das nun bedeutet, dass du dein System alle paar Monate verzehnfachen kannst oder ob du es einfach drei Jahre lang stabil und dumm halten kannst, bevor du dir Gedanken über die Kapazität machen musst. Ehrlich gesagt, hast du eine ausgereifte Dateninfrastruktur, wenn du die meiste Zeit damit verbringen kannst, an andere Dinge zu denken. Lustige Dinge. Zum Beispiel neue Produkte zu entwickeln oder zukünftige Probleme vorauszusehen, anstatt auf aktuelle zu reagieren.
Es ist in Ordnung, im Laufe der Zeit zwischen den Stufen hin und her zu wechseln. Die Stufen sind vor allem dazu da, dir dabei zu helfen, über relative Prioritäten nachzudenken. So ist es z.B. wichtiger, sicherzustellen, dass du funktionierende Backups hast, als ein Skript zu schreiben, mit dem du dynamisch einen neuen Shard erstellen und mehr Kapazität hinzufügen kannst. Wenn du immer noch an dem Punkt bist, an dem du nur eine Kopie deiner Daten online hast oder nicht weißt, wie du fehlschlagen sollst, wenn deine Hauptkopie stirbt, solltest du deine Arbeit unterbrechen und das zuerst herausfinden.
Einpacken
Die DBRE-Rolle ist ein Paradigmenwechsel gegenüber einer bestehenden, bekannten Rolle. Vor allem gibt uns das Framework einen neuen Weg, die Funktionen der Verwaltung von Datenspeichern in einer sich ständig verändernden Welt anzugehen. Im nächsten Abschnitt werden wir diese Funktionen im Detail untersuchen, wobei wir die operativen Funktionen aufgrund ihrer Bedeutung für die tägliche Datenbankentwicklung in den Vordergrund stellen werden. In diesem Sinne, lass uns mutig vorwärts gehen, unerschrockener Ingenieur!
Get Datenbank-Zuverlässigkeitstechnik now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
