SRE im Kontext
Bevor wir einen Teil der SRE-Methoden untersuchen, sollten wir einige der Konzepte, die wir in der vorherigen Lerneinheit kennengelernt haben, im Kontext betrachten. In dieser kurzen Lektion erfahren Sie etwas über die Geschichte von SRE und darüber, wie SRE mit anderen Betriebsmethoden in Zusammenhang steht, die Ihnen vertraut sind. Dank dieses Wissens können wir später größere Erfolge erzielen, da diese Methoden im Kontext mehr Sinn ergeben. Darüber hinaus haben Sie direkt eine Antwort parat, wenn Ihre Freunde fragen: „Wie unterscheidet sich SRE von...?“
Verlauf
Die stark verkürzte Geschichte von SRE beginnt bei dessen Ursprüngen: bei Google im Jahr 2003. Ben Sloss Treynor, übernahm die Leitung des „Produktionsteams“ von Google (damals nur sieben Softwareentwickler). Treynor hatte die Idee dazu und beschrieb sie als das, „was passiert, wenn ein Softwareentwickler gebeten wird, eine Betriebsfunktion zu entwickeln“. Es ist hilfreich für das Verständnis, mehr über die Geschichte erfahren, da erläutert wird, weshalb SRE sich für Mitarbeiter, die für den Betrieb zuständig sind, sehr nach „Softwareentwicklung“ anfühlt, wenn ihnen SRE zum ersten Mal begegnet. Aus diesem Bereich wurden Werte und grundlegende Tools übernommen, wie z.B. die Priorität der Codierung und Quellcodeverwaltungssysteme. Die erste und die aktuelle Implementierung von Google SRE sind in den zugehörigen zwei Büchern, die von O'Reilly veröffentlicht wurden, umfassend dokumentiert (siehe Lerneinheit „Erste Schritte“).
Als Mitarbeiter von Google das Unternehmen verließen (und Mitarbeiter des Unternehmens häufiger in der Öffentlichkeit über ihre Methoden sprachen), begann die Verbreitung von SRE auf weitere Unternehmen in der Branche. Als sich SRE auf neue Unternehmen verbreitete, übernahmen diese Unternehmen die SRE-Prinzipien und -Methoden und passten sie so an, dass sie ihrer lokalen Kultur entsprachen. Durch diesen Erweiterungsprozess entstanden in dem Bereich viele unterschiedliche Implementierungen von SRE.
DevOps und SRE
Die gesamte Branche musste sich den gleichen Herausforderungen rund um Skalierung, Entwicklungsgeschwindigkeit im Vergleich zu Betriebsstabilität und anderen Problemen bei der Softwarebereitstellung stellen, die die Site Reliability Engineering-Bewegung hervorbrachte. Durch parallele Anstrengungen zur Behebung dieser Probleme außerhalb von Google (und einigen größeren Unternehmen zu diesem Zeitpunkt) entstand DevOps.
Viele Informationen zu DevOps finden Sie im DevOps-Ressourcencenter.
Hinweis
Bitte beachten Sie, dass DevOps und SRE zwei unterschiedliche parallele Ansätze zur Begegnung der gleichen Herausforderungen sind. SRE ist nicht der nächste Evolutionsschritt nach DevOps. SRE wurde nicht mit dem Ziel geschaffen, „die Zukunft von DevOps“ zu sein.
Die Frage nach den Unterschieden zwischen SRE und DevOps sorgt in dem Bereich nach wie vor für beträchtliche Diskussionen. Es gibt einige Unterschiede, über die ein breiter Konsens herrscht, z.B. folgende:
- SRE ist eine IT-Disziplin, die auf Zuverlässigkeit ausgerichtet ist. DevOps ist eine kulturelle Bewegung, die sich aus der Idee heraus entwickelt hat, die typischen Silos aufgrund der Trennung von Entwicklungs- und Betriebsorganisationen aufzubrechen.
- SRE kann der Name einer Rolle sein, wie z.B. in der Aussage „Ich bin ein Site Reliability Engineer (SRE)“, DevOps nicht. Genau genommen verdient niemand als „DevOps“sein Geld.
- SRE ist tendenziell verbindlicher, DevOps ist ganz bewusst nicht so. Am ehesten geht es diesbezüglich um die nahezu weltweite Anwendung von Continuous Integration/Continuous Delivery- und Agile-Prinzipien.
Die beiden Betriebsmethoden, DevOps und SRE, teilen eine gemeinsame Leidenschaft für die Überwachung/Beobachtbarkeit und die Automatisierung. Daher ist es häufig einfacher, SRE-Prinzipien und -Methoden in ein Unternehmen zu importieren, das bereits eine DevOps-Methode befolgt. Dieser Prozess muss sorgfältig und bewusst durchgeführt werden. Zudem kann und sollte SRE schrittweise implementiert werden. Eine plötzliche Umstellung ist nicht erforderlich.
Warnung
Die Implementierungsstrategie, bei der einfach die Titel von Mitarbeitern eines Unternehmens ausgetauscht werden, ist fast nie erfolgreich. Dies führt nicht zu den Vorteilen, die SRE zu bieten hat. Einige bessere Vorschläge können Sie dem Abschnitt „Erste Schritte“ dieser Lerneinheit entnehmen.
Zusammenfassung
Ziel dieser kurzen Lerneinheit war es, Ihnen etwas Kontext zu SRE und DevOps zu vermitteln. SRE und DevOps sind am besten als benachbarte Denkschulen für Betriebspraktiken zu betrachten.
Nachdem wir einen kurzen Blick auf den Hintergrund von SRE geworfen haben, können wir mit einigen seiner wichtigsten Prinzipien fortfahren.