Viele DBAs werden heute aufgefordert, zu einer DevOps-Kultur beizutragen. Ein DBA, den ich kenne, erzählte mir die Geschichte einer kürzlich durchgeführten Umstrukturierung seines Unternehmens, und als sie das neue Organigramm verschickten, wurde sein Titel tatsächlich von DBA zu DevOps-Ingenieur geändert. Was macht er jetzt anders als früher? Nun, es stellt sich heraus ... Nicht viel. Das meiste, was er jetzt tut, ist immer noch derselbe. Aber sein Büro ist jetzt der Ground Zero für DevOps, also nimmt er diesen neuen Titel ziemlich ernst.
Hier ist die Wahrheit – DBAs waren so ziemlich schon immer Teil von DevOps. Das liegt daran, dass die meisten bereits Dev-Aufgaben erledigen. Dinge wie das Schreiben von SQL, die Leistungsoptimierung von SQL Server, die Durchführung von Objektanalysen und Berichterstellung und sie erledigen bereits Ops-Aufgaben wie das Konfigurieren von Servern, das Ausführen von Sicherungen und Wiederherstellungen und das Optimieren des Betriebssystems, des Netzwerks und des Speichers.
Die wichtigste Änderung besteht darin, dass DevOps Anwendungsentwickler häufig wegen Stabilitäts- und Leistungsproblemen gegen Infrastrukturteams antreten lässt. Dev und Ops haben unterschiedliche Prioritäten, die einen feinen Balanceakt erfordern.
Diese Geschichte hat zwei Seiten. Der Entwickler Seite des Hauses wird daran gemessen, wie schnell und zuverlässig sie Änderungen in die Produktion bringen können. Ihr Ziel ist es, Code so schnell wie möglich nach Spezifikation zu entwickeln, ihn in Produktion zu bringen und diese Änderungen am Laufen zu halten.
Op geht es darum sicherzustellen, dass die Dinge nicht kaputt gehen, wenn man sie aus den Augen verliert. Es geht um all die Grundlagen, die dafür sorgen, dass die Lichter angehen und die Daten in Bewegung bleiben.
DBAs spielen eine große Rolle bei der Zusammenführung von Dev und Ops. Tatsächlich ist es eine große Chance für DBAs, in diese aufstrebende Rolle des DevOps-Ingenieurs hineinzuwachsen, einschließlich der Überwachung und Optimierung der SQL-Serverleistung.
Ein Großteil von DevOps basiert auf dem Motto „Fail oft, fail fast“. Nehmen Sie kleine, inkrementelle Änderungen vor und übertragen Sie sie in die Produktion. Wenn sie ein Problem verursachen oder nicht ganz den Kundenwünschen entsprechen, setzen Sie sie schnell zurück, reparieren Sie sie und bringen Sie sie schnell wieder in Produktion.
Dies birgt jedoch echte Risiken…
Es ist nicht immer einfach, die Ursache eines Leistungs- oder Stabilitätsproblems zu verstehen. Es erfordert einiges an Graben, um die Punkte zwischen einer Änderung, die jemand an der Anwendung oder der Infrastruktur vorgenommen hat, und den Auswirkungen, die sie auf die Arbeitslast und Leistung der Datenbank hat, zu verbinden.
Diese Konzepte sind für den DBA etwas neu und die Aufgabe, sich in der Mitte zu treffen, um an der DevOps-Kultur teilzunehmen, mag etwas überwältigend erscheinen. Aber irgendwo muss man ja anfangen. Viele Organisationen verfolgen den Ansatz, Probleme mit der Leistung von SQL-Servern aus einer anderen Perspektive zu betrachten und eine andere Überwachungsmethode zu implementieren.
Was wäre, wenn Sie den nötigen Einblick in den Zustand Ihrer SQL Server-Umgebung hätten, um Leistungsprobleme proaktiv zu lösen … bevor sie Ihr Geschäft ernsthaft beeinträchtigen? Was wäre, wenn Sie Leistungseinbußen schnell identifizieren, die Ursache isolieren und analysieren und optimieren könnten, um ähnliche Probleme in Zukunft zu vermeiden?
Oh, und was wäre, wenn Sie all dies auf Abonnementbasis haben könnten? Ohne zusätzliche Hardware, ohne Software, ohne Wartungskosten und von überall und jederzeit auf jedem Gerät darauf zugreifen zu können?
Mit Spotlight Cloud ist das möglich! Es ist so einfach wie Anmelden. Anmelden. Lösen.
Beginnen Sie mit Spotlight Cloud für unübertroffene Überwachung und Diagnose von Cloud-gehosteten Datenbanken für SQL Server. Es ist wie eine sofortige Beförderung!
