class SRE implements DevOps

 

Heute möchte ich Euch von meinen neusten Erfahrungen aus dem Umfeld der agilen Transformation berichten, auch ich habe mich erfolgreich an das Wagnis einer neuen Zertifizierung gewagt….

 

Aus dem Baukasten des SRE.

 

Was oder wer ist ein SRE?

 

 

Wir beleuchten heute die Rolle des Site Reliability Engineer.

 

Die zuerst von Google aufgestellten Prinzipien des Site Reliability Engineering haben zu einer neuen, technischen Rolle im Herzen von DevOps geführt.

Haben wir jetzt 2 konkurrierende Bewegungen oder gar neue Frameworks? Und warum kommt Google auf einmal damit um die «Ecke»?

 

Da sich die Welt online verändert hat, ist die Zuverlässigkeit von Websites, Cloud-Anwendungen und Cloud-Infrastrukturen zu einer entscheidenden Geschäftsvoraussetzung geworden – vom E-Commerce-Betrieb über globale Banken bis hin zu Suchmaschinen. (ein erster Hinweis auf Google😊

 

Die Art und Weise, wie wir Systeme und ihre Arbeitsabläufe verwalten, hat sich geändert. Heute denken wir selten in Form von wertvollen, hochleistungsfähigen Servern mit hohem Bedienkomfort, sondern stattdessen denken wir in Racks von Commodity-Servern, die durch Virtualisierung zusammengelegt werden, wobei eine verteilte Software-Architektur verhindert, dass Serverausfälle zu Ausfallzeiten führen. Der Schwerpunkt hat sich von der Hardware auf eine softwaredefinierte Infrastruktur verlagert und von inkonsistenten und fehleranfälligen manuellen Prozessen auf konsistente, zuverlässige und wiederholbare automatisierte Aufgaben.

 

Site Reliability Engineering ist die Praxis, diese programmierbare Infrastruktur aufrechtzuerhalten und die Verfügbarkeit der darauf laufenden Arbeitslasten zu maximieren. Die Berufsbezeichnung Site Reliability Engineer (SRE) stammt ursprünglich aus den Hallen von Google, das zur Jahrtausendwende die Beziehung zwischen Software-Entwicklern und Operations neu definieren wollte – und ihnen dabei helfen wollte, gemeinsam robuste, flexible Systeme mit ständiger Verbesserung und Automatisierung als Kernprinzipien aufzubauen.

 

Auf der Basis-Ebene bringen SREs Software-Engineering-Prinzipien in Infrastruktur- und Betriebsstörungen ein, mit dem ehrgeizigen Ziel, hochskalierbare und zuverlässige Systeme zu schaffen.

“Im Grunde ist es das Ergebnis, was passiert, wenn man einen Software-Engineer bittet, eine Operations-Funktionalität zu entwerfen”, Ben Treynor, VP of Engineering bei Google und der Pate von SRE.

 

Das klingt jetzt alles nach Tool-Chain-Analyse und technischem Kling-Klang. Schauen wir mal, wo die Kultur sich versteckt hält.

 

Doch erstmal zu den Aufgaben eines SRE.

 

Zu den Hauptaufgaben von SRE gehört die Festlegung von Service-Level-Schwellenwerten, die sich oft als Service-Level Objectives (SLOs) manifestieren und darüber informieren, ob ein Release grünes Licht erhält. Der heilige Gral sind immer die geheiligten “fünf Neunen” oder 99,999% Betriebszeit. Je besser die Betriebszeit, desto mehr Entwickler können coole neue Software auf den Markt bringen und desto mehr schlafen die SREs 😊

 

Das wiederum führt unweigerlich für beide Seiten zu einer vorteilhaften Beziehung, weit entfernt von den alten Zeiten des Antagonismus, in denen sich Dev und Ops feindlich gegenüberstanden.

 

Eine SRE-Aufgabe wird in der Regel anhand einer Reihe wichtiger Zuverlässigkeitskennzahlen gemessen, nämlich:

Systemleistung, Verfügbarkeit, Latenz, Effizienz, Überwachung, Kapazitätsplanung und Notfallreaktion.

Jeder gute SRE wird vor allem von einer Sache besessen sein: der Automatisierung..

Wie Jason Qualman, ein SRE bei dem Monitoring Entwickler New Relic, in einem Blogbeitrag feststellt: “Ein großer Teil dieser Rolle besteht darin, über ineffiziente und zeitraubende Dinge nachzudenken, die die Menschen tun, und diesen Dingen so schnell wie möglich ein Ende zu setzen. Anstatt eine Dose mit seinem Fuss den Weg hinunter zu treten, sagen sie sich: “Ich werde mir die Zeit nehmen, dies jetzt zu automatisieren und verhindern, dass jemand anderes diesen schmerzhaften Kick ausführen muss.»

Ein weiteres Schlüsselelement der SRE-Rolle ist etwas, das als “Release Engineering” bezeichnet wird und die Definition von Best Practices beinhaltet, um sicherzustellen, dass Software-Releases konsistent und wiederholbar sind.

” Release-Engineers haben ein solides (wenn nicht sogar Experten-) Verständnis von Quellcodeverwaltung, Compilern, Build-Konfigurationssprachen, automatisierten Build-Tools, Paketmanagern und Installationsprogrammen. Zu ihren Fähigkeiten gehört ein tiefgreifendes Wissen in mehreren Bereichen: Entwicklung, Konfigurationsmanagement, Testintegration, Systemadministration und Kundensupport”, schreibt Dinah McNutt, technische Programm-Managerin bei Google, für das Buch Site Reliability Engineering (veröffentlicht von O’Reilly im Jahr 2016 und verfasst von Googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones und Betsy Beyer).

 

Dann gibt es jedoch noch den reaktiven Part der Rolle, der die Alarmierung, den Bereitschaftsdienst und die Fehlerbehebung sowie die Reaktion auf Notfälle und Zwischenfälle und die Post-Mortem Analyse umfasst.

 

Im Wesentlichen ist es wichtig, dass SREs wissen, wie sie Systeme am besten überwachen und reagieren können, wenn etwas schief läuft, indem sie ständig sogenannte “Response Playbooks” schreiben und neu schreiben, um die Zeit zu verkürzen, die für die Behebung einer eventuell auftretenden Störung benötigt wird. Bei Google bedeutet dies, einen Vorfall zu dokumentieren, alle beitragenden Ursachen zu verstehen und zukünftige Präventivmaßnahmen zu implementieren.

 

“Einen Post-Mor

tem Report zu schreiben ist keine Strafe – es ist eine Chance zum Lernen für das gesamte Unternehmen”, schreiben die Googlers John Lunney und Sue Lueder in einem Kapitel des Buches Site Reliability Engineering.

 

 

SREs vs. DevOps Engineers

 

Ich kann mir vorstellen und ahne was du denkst. Das klingt doch alles sehr nach dem uns bekannten DevOps, aber wenn es um die Terminologie geht, ist die Berufsbezeichnung SRE ungefähr fünf Jahre älter als DevOps Engineer.

 

Beide basieren auf ähnlichen Prinzipien, aber der Unterschied ist sowohl subtil als auch wichtig. Der Hauptunterschied besteht darin, dass sich DevOps-Engineers darauf konzentrieren, die kontinuierliche Bereitstellung und die Geschwindigkeit der Entwickler zu unterstützen, während SREs die Verantwortung für Zuverlässigkeit und Automatisierung während des gesamten Software-Lebenszyklus übernehmen, wobei der Schwerpunkt auf der erfolgreichen Bereitstellung und Überwachung von Releases liegt und die softwaredefinierte Infrastruktur am Laufen gehalten werden.

 

 

 

Die SRE haben eine integrale Funktion innerhalb des umfassenderen Engineer Teams: Sie sorgen dafür, dass ein Spezialist am Tisch sitzt, der sich auf den Aufbau stabiler Systeme konzentriert.

 

Wie Jayne Groll vom DevOps-Institut es ausdrückt: “DevOps konzentriert sich auf das Engineering der kontinuierlichen Lieferung bis zum Einsatzort; SRE konzentriert sich auf das Engineering des kontinuierlichen Betriebs am Ort des Kundenverbrauchs.”

 

 

Puhh, da muss ich zweimal lesen um es zu verstehen, doch darum scheint es tatsächlich zu gehen 😊 Ich bin gespannt auf Kommentare wie ihr das seht….

 

 

Die Geschichte von SRE bei Google

 

Die Rückverfolgung der SRE-Prinzipien bis zu ihren Ursprüngen bei Google in den frühen 2000er Jahren stellt eine zentrale Lektion in dieser Disziplin dar.

“Als ich zu Google kam, hatte ich das Glück, Teil eines Teams zu sein, das zum Teil aus Leuten bestand, die Software-Ingenieure waren und die dazu neigten, Software als Mittel zur Lösung von Problemen zu verwenden, die in der Vergangenheit von Hand gelöst wurden. Als es also an der Zeit war, ein formelles Team für diese operative Arbeit zu bilden, war es nur natürlich, den Ansatz ‘alles kann als Softwareproblem behandelt werden’ zu wählen und damit zu arbeiten”, erklärte Ben Treynor in einem Interview im internen Blog von Google.

“SRE führt also im Grunde genommen Arbeiten aus, die in der Vergangenheit von einem Betriebsteam ausgeführt wurden, setzt jedoch Ingenieure mit Software-Know-how ein und verlässt sich auf die Tatsache, dass diese Ingenieure von Natur aus dazu prädisponiert sind und die Fähigkeit haben, menschliche Arbeit durch Automatisierung zu ersetzen”, fügt Treynor hinzu.

 

Google denkt auch recht starr darüber nach, wie man ein SRE-Team zusammenstellt. Alle Google-SRE müssen entweder Google-Software-Ingenieure oder “Kandidaten sein, die den Qualifikationen von Google Software Engineering sehr nahe kommen”. Sie müssen auch über Fähigkeiten im Bereich Infrastrukturmanagement verfügen, am häufigsten werden hier “Kompetenz im Bereich Unix-Systemengineering und Netzwerke Spezialisten (Layer 1 bis Layer 3) gewählt.”

 

Die SRE-Qualifikationen sind nach wie vor von Unternehmen zu Unternehmen unterschiedlich, aber was die Grundprinzipien betrifft, ist der Google-Ansatz ein solider Ausgangspunkt. Die Einzelheiten hängen von den geschäftlichen Anforderungen, den etablierten Prozessen und dem Tech-Stack ab, den das Unternehmen bereits eingeführt hat.

 

SREs verbringen in der Regel etwa 50 Prozent ihrer Zeit mit der Ausführung traditioneller Operations Tätigkeiten, wie z.B. Bereitschaftsdienst und Einspringen bei der Lösung von Problemen. Die anderen 50 Prozent konzentrieren sich auf die Entwicklung von Software, um die zugrunde liegenden Systeme mit der Zeit widerstandsfähiger, automatisierter und “selbstheilender” zu machen. Deshalb erfordert diese Aufgabe eine solide Mischung aus Software-Engineering-Aufgaben und operativen Fähigkeiten. Ein SRE ist gut organisiert, unter Druck kühl und ein Problemlöser. SRE-Manager sind für Teamleistung, Strategie und Optimierung verantwortlich.

 

 

 

Netflix stellt in diesem Zusammenhang ein First Mover dar. Die von ihnen ins Leben gerufene “Simian Army” ist für mich immer noch ein Meilenstein des Chaos Engineering auf gekonnt amüsanter Weise: –> https://en.wikipedia.org/wiki/Chaos_engineering

 

 

Aber was ist mit Organisationen, in denen die SRE-Rolle nicht existiert? In dem O’Reilly-Bericht “Was ist SRE? empfehlen Kurt Andersen von LinkedIn und Craig Sebenik von Split, einen ” grassroots”-Ansatz zu wählen.

 

 

Sie empfehlen, „dort ein Entwicklungsteam zu finden, das motiviert ist, ein kleines SRE-Team (oder eine Einzelperson) zu entwickeln und zu implementieren”. Mit der Zeit kannst du diesen Erfolg als positives Beispiel für andere Teams nutzen”.

Nun gut, klingt nach einer weiteren Spielwiese mit unklarem Ausgang…

 

 

Da war doch das Thema Kultur.  Nun, ich schreibe aus dem Grund nichts dazu, da sich in diesem Punkt die Philosophien nicht wirklich unterscheiden. Bei Google arbeiten, ist vermutlich ohnehin eine „coole“ Sache, ich denke hier stellt sich die Kulturfrage eh nicht.

Andererseits werden andere Firmen die gleichen Herausforderungen haben, wenn es darum geht agile Teams einzusetzen jedoch vergessen die Welt drumherum mit einzubinden.

 

 

DevOps steht nach wie vor für mich als Bewegung klar im Vordergrund. So schliesst sich nämlich auch für mich der Kreis, wenn wir den Blog schliessen mit der Code Zeile:

<< class SRE implements DevOps >>

 

Mich würde spontan interessieren, wie DevOps als Bewegung mit den verschiedenen Frameworks umgeht.

 

Wie werden eigentlich Service Management Disziplinen in einem agilen Umfeld realisiert?

 

Wie entsteht z.B. ein Service Katalog samt Prozessualer Unterstützung im SAFe Umfeld…spannend und vielleicht auch bald einen Blog wert.

 

 

Solange Roboter uns nicht das Spielen abnehmen, kickt ruhig mal gegen eine Cola-Dose, das hat auch als Kinde Spass gemacht und tat nicht weh 😊

 

 

Alles Liebe, bleibt gesund,

 

 -Euer Sven