Testen ist ein Querschnittsproblem; das gilt auch für Datenbanken

Wir sind alle mit den Prinzipien von DevOps vertraut: kleine, gut getestete Inkremente bauen, häufige Bereitstellungen und Automatisierung von Pipelines, um manuelle Schritte zu eliminieren. Wir überwachen unsere Anwendungen genau, richten Alarme ein, rollen problematische Änderungen zurück und erhalten Benachrichtigungen, wenn Probleme auftreten.

Wenn es jedoch um Datenbanken geht, fehlt uns oft das gleiche Maß an Kontrolle und Sichtbarkeit. Das Debuggen von Leistungsproblemen kann herausfordernd sein, und wir haben möglicherweise Schwierigkeiten zu verstehen, warum Datenbanken langsamer werden. Schema-Migrationen und -Änderungen können außer Kontrolle geraten, was zu erheblichen Herausforderungen führt.

Diese Hindernisse zu überwinden erfordert Strategien, die die Schema-Migration und -Anpassung optimieren und effiziente Änderungen der Datenbankstruktur mit minimalen Ausfallzeiten oder Leistungseinbußen ermöglichen. Es ist wichtig, alle Änderungen kohärent über die Pipeline hinweg zu testen. Lassen Sie uns erkunden, wie dies erreicht werden kann.

Automatisieren Sie Ihre Tests

Datenbanken sind anfällig für viele Arten von Fehlern, erhalten jedoch oft nicht die gleiche strenge Prüfung wie Anwendungen. Während Entwickler typischerweise testen, ob Anwendungen die richtigen Daten lesen und schreiben können, übersehen sie häufig, wie dies erreicht wird. Schlüsselbereiche wie die Sicherstellung der ordnungsgemäßen Verwendung von Indizes, das Vermeiden unnötigen Lazy Loadings oder die Überprüfung der Abfrageeffizienz bleiben oft unüberprüft.

Zum Beispiel konzentrieren wir uns darauf, wie viele Zeilen die Datenbank zurückgibt, vernachlässigen jedoch die Analyse, wie viele Zeilen sie lesen musste. Ebenso werden Rückrollverfahren selten getestet, was uns bei jeder Änderung anfällig für potenziellen Datenverlust macht. Um diese Lücken zu schließen, benötigen wir umfassende automatisierte Tests, die Probleme proaktiv erkennen und den Bedarf an manueller Intervention minimieren.

Wir verlassen uns oft auf Lasttests, um Leistungsprobleme zu identifizieren, und obwohl sie offenbaren können, ob unsere Abfragen schnell genug für die Produktion sind, haben sie erhebliche Nachteile. Zuerst sind Lasttests teuer in der Erstellung und Wartung und erfordern eine sorgfältige Handhabung der GDPR-Konformität, Datenanonymisierung und zustandsbehafteten Anwendungen. Darüber hinaus finden sie zu spät im Entwicklungsprozess statt. Wenn Lasttests Probleme aufdecken, sind die Änderungen bereits implementiert, überprüft und zusammengeführt, was uns zwingt, zurück zum Reißbrett zu gehen und möglicherweise von vorne zu beginnen. Schließlich sind Lasttests zeitaufwendig und erfordern oft Stunden, um Caches zu füllen und die Zuverlässigkeit der Anwendung zu validieren, was sie weniger praktisch macht, um Probleme frühzeitig zu erkennen.

Schema-Migrationen fallen oft außerhalb des Umfangs unserer Tests. Typischerweise führen wir Test-Suiten nur nach Abschluss der Migrationen aus, was bedeutet, dass wir nicht bewerten, wie lange sie gedauert haben, ob sie Tabellenschreibvorgänge ausgelöst haben oder ob sie Leistungsengpässe verursacht haben. Diese Probleme bleiben während der Tests oft unbemerkt und werden erst beim Einsatz in der Produktion offensichtlich.

Eine weitere Herausforderung besteht darin, dass wir mit Datenbanken testen, die zu klein sind, um Leistungsprobleme frühzeitig aufzudecken. Diese Abhängigkeit von unzureichenden Tests kann dazu führen, dass Zeit mit Lasttests verschwendet wird, und lässt kritische Aspekte wie Schema-Migrationen völlig ungetestet. Dieser Mangel an Abdeckung verringert unsere Entwicklungsgeschwindigkeit, führt zu anwendungsbrechenden Problemen und behindert die Agilität.

Die Lösung für diese Herausforderungen liegt in der Implementierung von Datenbank-Richtlinien. Datenbank-Richtlinien bewerten Abfragen, Schema-Migrationen, Konfigurationen und Datenbankdesigns, während wir Code schreiben. Anstatt auf Pipeline-Ausführungen oder umfangreiche Lasttests angewiesen zu sein, können diese Überprüfungen direkt in der IDE oder Entwicklungsumgebung durchgeführt werden. Durch die Nutzung von Beobachtbarkeit und Projektionen der Produktionsdatenbank bewerten die Richtlinien Ausführungspläne, Statistiken und Konfigurationen und stellen sicher, dass alles nach dem Deployment reibungslos funktioniert.

Beobachtbarkeit rund um Datenbanken aufbauen

Wenn wir in die Produktion deployen, können sich die Systemdynamiken im Laufe der Zeit ändern. Die CPU-Auslastung kann ansteigen, die Speichernutzung könnte zunehmen, die Datenmengen könnten wachsen und die Datenverteilungsmuster könnten sich ändern. Diese Probleme schnell zu identifizieren ist entscheidend, aber nicht genug. Aktuelle Überwachungstools überfluten uns mit Rohdaten, so dass wir die Gründe selbst zusammenpuzzeln müssen. Zum Beispiel könnten sie einen Anstieg der CPU-Auslastung anzeigen, aber nicht erklären, warum das passiert ist. Die Last der Untersuchung und Identifizierung der Ursachen liegt vollständig bei uns. Dieser Ansatz ist veraltet und ineffizient.

Um wirklich schnell voranzukommen, müssen wir uns von der traditionellen Überwachung zur vollen Beobachtbarkeit verlagern. Anstatt mit Rohdaten überflutet zu werden, benötigen wir handlungsorientierte Erkenntnisse, die uns helfen, die Ursache von Problemen zu verstehen. Datenbank-Schutzschranken bieten diese Transformation. Sie verbinden die Punkte, zeigen, wie verschiedene Faktoren miteinander in Beziehung stehen, zeigen das Problem auf und schlagen Lösungen vor. Anstatt nur einen Anstieg der CPU-Auslastung zu beobachten, helfen uns Schutzschranken zu verstehen, dass eine kürzliche Bereitstellung eine Abfrage geändert hat, wodurch ein Index umgangen wurde, was zu der erhöhten CPU-Last führte. Mit dieser Klarheit können wir entschlossen handeln, die Abfrage oder den Index reparieren, um das Problem zu lösen. Dieser Wechsel vom „Sehen“ zum „Verstehen“ ist der Schlüssel, um Geschwindigkeit und Zuverlässigkeit aufrechtzuerhalten.

Die nächste Entwicklung in der Datenbankverwaltung besteht darin, vom automatisierten Untersuchen von Problemen zur automatisierten Lösung überzugehen. Viele Probleme können automatisch mit gut integrierten Systemen behoben werden. Beobachtbarkeitstools können Leistungs- und Zuverlässigkeitsprobleme analysieren und die erforderlichen Code- oder Konfigurationsänderungen generieren, um sie zu lösen. Diese Fixes können entweder automatisch angewendet werden oder eine explizite Genehmigung erfordern, um sicherzustellen, dass Probleme sofort mit minimalem Aufwand Ihrerseits behoben werden.

Jenseits der schnellen Problembehebung ist das ultimative Ziel, Probleme von vornherein zu verhindern. Häufige Rollbacks oder Ausfälle behindern den Fortschritt und die Agilität. Wahre Agilität wird nicht erreicht, indem Probleme schnell gelöst werden, sondern indem Systeme entworfen werden, in denen Probleme selten auftreten. Obwohl diese Vision inkrementelle Schritte erfordern kann, stellt sie die ultimative Richtung für Innovation dar.

Metis ermöglicht es Ihnen, diese Herausforderungen zu meistern. Es bewertet Ihre Änderungen, bevor sie überhaupt im Repository festgeschrieben werden, indem es Abfragen, Schema-Migrationen, Ausführungspläne, Leistung und Korrektheit während Ihrer Pipelines analysiert. Metis integriert sich nahtlos in CI/CD-Workflows und verhindert, dass fehlerhafte Änderungen in die Produktion gelangen. Aber es geht noch weiter – es bietet eine tiefgreifende Beobachtbarkeit Ihrer Produktionsdatenbank, indem es Metriken analysiert und Bereitstellungen, Erweiterungen und Konfigurationen verfolgt. Es behebt automatisch Probleme, wenn möglich, und warnt Sie, wenn eine manuelle Intervention erforderlich ist. Mit Metis können Sie schneller arbeiten und jeden Aspekt Ihrer CI/CD-Pipeline automatisieren, was ein reibungsloseres und zuverlässigeres Datenbankmanagement gewährleistet.

Jeder muss teilnehmen

Datenbankbeobachtbarkeit besteht darin, proaktiv Probleme zu verhindern, auf eine automatisierte Verständnis- und Lösungsfindung hinzuarbeiten und datenbankspezifische Prüfungen im gesamten Entwicklungsprozess zu integrieren. Sich auf veraltete Werkzeuge und Arbeitsabläufe zu verlassen, reicht nicht mehr aus; wir benötigen moderne Lösungen, die sich an die heutigen Komplexitäten anpassen. Datenbankleitplanken bieten diese Unterstützung. Sie helfen Entwicklern, ineffizienten Code zu vermeiden, Schemas und Konfigurationen zu analysieren und jeden Schritt des Softwareentwicklungszyklus innerhalb unserer Pipelines zu validieren.

Leitplanken wandeln auch rohe Überwachungsdaten in handlungsorientierte Erkenntnisse um, indem sie nicht nur erklären, was schief gelaufen ist, sondern auch, wie man es beheben kann. Diese Fähigkeit ist in allen Branchen unerlässlich, da die Komplexität der Systeme weiter zunehmen wird. Um vorauszubleiben, müssen wir innovative Tools und Prozesse nutzen, die es uns ermöglichen, schneller und effizienter voranzukommen.

Source:
https://dzone.com/articles/testing-is-a-cross-cutting-concern-so-are-databases