Was ist ein SRE? Die entscheidende Rolle des Site Reliability Engineers

Da sich die Welt online verändert hat, ist die Zuverlässigkeit von Websites, Cloud-Anwendungen und Cloud-Infrastrukturen zu einem entscheidenden Geschäftsgebot geworden - von E-Commerce-Operationen über globale Banken bis hin zu Suchmaschinen.

Die Art und Weise, wie wir Systeme und ihre Workloads verwalten, hat sich geändert. Heutzutage denken wir selten an wertvolle, berührungsempfindliche und leistungsstarke Server, sondern an eine Reihe von Commodity-Servern, die durch Virtualisierung zusammengeführt werden. Die verteilte Softwarearchitektur verhindert, dass Serverausfälle Ausfallzeiten verursachen. Der Fokus hat sich von Hardware zu softwaredefinierter Infrastruktur und von inkonsistenten und fehleranfälligen manuellen Prozessen zu konsistenten, zuverlässigen und wiederholbaren automatisierten Aufgaben verlagert.

Beim Site Reliability Engineering wird diese programmierbare Infrastruktur beibehalten und die Verfügbarkeit der darauf ausgeführten Workloads maximiert. Die Berufsbezeichnung Site Reliability Engineer (SRE) stammt aus den Hallen von Google, die um die Jahrtausendwende die Beziehung zwischen Softwareentwicklern und Betriebspersonal neu definieren und ihnen helfen wollten, gemeinsam robuste, flexible Systeme aufzubauen ständige Verbesserung und Automatisierung als Grundprinzipien.

Was ist ein SRE?

Auf der Basisebene bringen SREs Prinzipien der Softwareentwicklung in Infrastruktur- und Betriebsprobleme ein, mit dem Ziel des Nordsterns, hoch skalierbare und zuverlässige Systeme zu schaffen.

"Grundsätzlich ist es das, was passiert, wenn Sie einen Softwareentwickler bitten, eine Betriebsfunktion zu entwerfen", wird Ben Treynor, Vice President of Engineering bei Google und Pate von SRE, oft zitiert.

Zu den Hauptaufgaben von SRE gehört die Festlegung von Service-Level-Schwellenwerten, die häufig als Service-Level-Ziele (SLOs) bezeichnet werden und Aufschluss darüber geben, ob eine Version grünes Licht erhält oder nicht. Der heilige Gral ist immer die heilige "fünf Neunen" oder 99,999% Betriebszeit. Je besser die Betriebszeit, desto mehr Seilentwickler können coole neue Sachen auf den Markt bringen und desto mehr Schlaf-SREs erhalten, was zu einer für beide Seiten vorteilhaften Beziehung zwischen den Funktionen führt, weit entfernt von den alten Zeiten des Entwickler- und Betriebsgegensatzes.

Eine SRE-Funktion wird in der Regel anhand einer Reihe wichtiger Zuverlässigkeitsmetriken gemessen, nämlich Systemleistung, Verfügbarkeit, Latenz, Effizienz, Überwachung, Kapazitätsplanung und Notfallmaßnahmen.

[Ebenfalls zu: Anwendungsüberwachung: Was Entwickler besser machen können]

Hauptaufgaben eines SRE

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

Jason Qualman, SRE beim Überwachungssoftwareanbieter New Relic, erklärt in einem Blogbeitrag: „Ein Großteil dieser Rolle besteht darin, über ineffiziente und zeitaufwändige Dinge nachzudenken, die Menschen tun, und sie so schnell wie möglich zu stoppen. Anstatt bei manueller Arbeit eine Dose auf die Straße zu werfen, sagen Sie: "Ich werde mir jetzt die Zeit nehmen, dies zu automatisieren und andere daran zu hindern, diese schmerzhafte Sache zu tun."

Ein weiteres Schlüsselelement der SRE-Rolle ist das sogenannte „Release Engineering“, bei dem Best Practices definiert werden, um sicherzustellen, dass Software-Releases konsistent und wiederholbar sind.

„Release-Ingenieure verfügen über ein solides (wenn nicht Experten-) Verständnis für Quellcodeverwaltung, Compiler, Build-Konfigurationssprachen, automatisierte Build-Tools, Paketmanager und Installationsprogramme. Zu ihren Fähigkeiten gehört ein umfassendes Wissen über mehrere Bereiche: Entwicklung, Konfigurationsmanagement, Testintegration, Systemadministration und Kundensupport “, schrieb Dinah McNutt, technischer Programmmanager bei Google, für das wegweisende Buch Site Reliability Engineering (veröffentlicht von O'Reilly in) 2016 und verfasst von den Googlern Jennifer Petoff, Niall Richard Murphy, Chris Jones und Betsy Beyer).

Dann gibt es den Reaktionsteil der Rolle, der Alarmierung, Bereitschaftsdienst und Fehlerbehebung sowie Notfall- und Vorfallreaktionen und Postmortems umfasst.

Im Wesentlichen ist es wichtig, dass SREs wissen, wie sie Systeme am besten überwachen und reagieren können, wenn etwas schief geht. Sie schreiben ständig Antwort-Playbooks und schreiben sie neu, um die Zeit für die Behebung eventuell auftretender Ausfälle zu verkürzen. Bei Google geht es darum, einen Vorfall zu dokumentieren, alle Ursachen zu verstehen und zukünftige vorbeugende Maßnahmen zu implementieren.

„Das Schreiben eines Postmortems ist keine Bestrafung - es ist eine Lernmöglichkeit für das gesamte Unternehmen“, schreiben die Googler John Lunney und Sue Lueder in einem Kapitel des Site Reliability Engineering- Buches.

[Ebenfalls zu: 3 Schritte zur Anwendung agiler Methoden im IT-Betrieb]

SREs vs. Entwickler Ingenieure

Ich weiß was du denkst. Das klingt alles sehr nach Devops, aber wenn es um Terminologie geht, datiert die SRE-Berufsbezeichnung den Devops-Ingenieur tatsächlich um etwa fünf Jahre vor.

Beide basieren auf ähnlichen Prinzipien, aber der Unterschied ist subtil und wichtig. Beide Arbeitsmethoden beinhalten den Abbau der Barrieren zwischen Entwicklern und Betriebspersonal. Beide zielen darauf ab, die Geschwindigkeit der Entwicklerteams zu erhöhen und gleichzeitig die zentrale Ausfallsicherheit dieser Dienste zu gewährleisten.

Der Hauptunterschied besteht darin, dass sich die Entwickler von Entwicklern in der Regel auf die Unterstützung der kontinuierlichen Bereitstellung und der Entwicklergeschwindigkeit konzentrieren, 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 und der Aufrechterhaltung des Brummens der softwaredefinierten Infrastruktur liegt. Das SRE hat eine integrale Funktion innerhalb des breiteren Engineering-Teams: Es stellt sicher, dass ein Spezialist am Tisch sitzt, der sich auf den Aufbau stabiler Systeme konzentriert.

Jayne Groll vom Devops Institute sagt dazu: „Devops konzentriert sich auf die Entwicklung einer kontinuierlichen Lieferung bis zum Einsatzort. SRE konzentriert sich auf die Entwicklung kontinuierlicher Betriebsabläufe zum Zeitpunkt des Kundenverbrauchs. “

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 ist eine wichtige Lektion in der Disziplin.

„Als ich zu Google kam, hatte ich das Glück, Teil eines Teams zu sein, das sich teilweise aus Leuten zusammensetzte, die Software-Ingenieure waren und dazu neigten, Software zu verwenden, um Probleme zu lösen, die in der Vergangenheit von Hand gelöst wurden. Als es an der Zeit war, ein formelles Team für diese operative Arbeit zu bilden, war es selbstverständlich, den Ansatz „Alles kann als Softwareproblem behandelt werden“ zu verfolgen und damit zu arbeiten “, erklärte Ben Treynor in einem Interview im internen Blog von Google.

„SRE erledigt also im Wesentlichen Arbeiten, die in der Vergangenheit von einem Betriebsteam ausgeführt wurden, setzt jedoch Ingenieure mit Software-Know-how ein und setzt auf die Tatsache, dass diese Ingenieure von Natur aus sowohl für die Automatisierung menschlicher Arbeit prädisponiert sind als auch diese ersetzen können. Fügt Treynor hinzu.

Google denkt auch ziemlich streng darüber nach, wie man ein SRE-Team zusammenstellt. Alle Google SREs müssen entweder Google Software Engineers oder "Kandidaten sein, die den Qualifikationen von Google Software Engineering sehr nahe kommen". Sie müssen außerdem über Kenntnisse im Bereich Infrastrukturmanagement verfügen, am häufigsten über „Unix-Systeminternale und Netzwerkkenntnisse (Layer 1 bis Layer 3)“.

Die SRE-Qualifikationen variieren immer noch von Unternehmen zu Unternehmen, aber was die Grundprinzipien betrifft, ist der Google-Ansatz ein solider Ausgangspunkt. Die Details hängen von den Geschäftsanforderungen, den etablierten Prozessen und dem Tech-Stack ab, die bereits von der Organisation übernommen wurden.

SRE Stellenbeschreibung und Gehalt

SREs verbringen in der Regel etwa 50 Prozent ihrer Zeit mit der Ausführung traditioneller Betriebsfunktionen, z. B. Bereitschaftsdienst und Einspringen, um Probleme zu lösen. Die anderen 50 Prozent konzentrieren sich auf die Entwicklung von Software, um zugrunde liegende Systeme im Laufe der Zeit widerstandsfähiger, automatisierter und selbstheilender zu machen. Aus diesem Grund erfordert die Rolle eine solide Mischung aus Software-Engineering-Fähigkeiten und Betriebsfähigkeiten. Ein guter SRE wird organisiert, unter Druck kühl und ein Problemlöser. SRE-Manager sind für die Teamleistung, Strategie und Optimierung verantwortlich.

Aber was ist mit Organisationen, in denen die SRE-Rolle nicht existiert? Im O'Reilly-Bericht "Was ist SRE?" Kurt Andersen von LinkedIn und Craig Sebenik von Split (ein Anbieter von Release-Management-Software) empfehlen einen „Graswurzel“ -Ansatz. Sie empfehlen, „ein Entwicklungsteam zu finden, das motiviert ist, ein kleines SRE-Team (oder eine Einzelperson) dort zu ändern und zu implementieren. Mit der Zeit können Sie diesen Erfolg als positives Beispiel für andere Teams verwenden. “

Das durchschnittliche Jahresgehalt für eine SRE beträgt in den USA ungefähr 130.000 USD und in Großbritannien 76.000 GBP.

SRE-Ressourcen

Es gibt zahlreiche Ressourcen, um SRE-Kenntnisse aufzubauen, von Zertifizierungen des DevOps Institute bis hin zu Büchern und Online-Ressourcen von O'Reilly, Microsoft und Google. Das bereits erwähnte 550-seitige Gigant  Site Reliability Engineering  von Jennifer Petoff, Niall Richard Murphy, Chris Jones und Betsy Beyer ist die erste Adresse zu diesem Thema, das 2016 veröffentlicht wurde. Das Buch ist auch kostenlos online bei Google erhältlich. 

Weitere neuere Bücher zu diesem Thema sind  Training Site Reliability Engineers  von Jennifer Petoff, JC van Winkel und Preston Yoshioka; Was ist SRE?  von Kurt Andersen und Craig Sebenik; Ich suche SRE  von David N. Blank-Edelman und  das Site Reliability Workbook  von Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara und Stephen Thorne.

O'Reilly verfügt außerdem über eine umfassende Bibliothek mit Online-Assets, Videos und E-Books zu diesem Thema, die in dieser SRE Essentials-Wiedergabeliste von der ehemaligen Zuverlässigkeitsingenieurin der Google-Website, Liz Fong-Jones, zusammengestellt wurde.

Online-Lernjuggernaut Coursera bietet verschiedene Kurse an, darunter das beliebte Site Reliability Engineering: Messen und Verwalten der Zuverlässigkeit von Google Cloud Training. Dieser Kurs ist auch bei Pluralsight erhältlich, ebenso wie der Anfängerkurs Site Reliability Engineering (SRE): Das große Ganze von Elton Stoneman. Die Linux Foundation bietet einen selbstgeführten Kurs mit dem Titel DevOps und SRE Fundamentals: Implementing Continuous Delivery an.

Das in Großbritannien ansässige Jellyfish Training bietet verschiedene zweitägige private Schulungsoptionen für die SRE Foundation (SREF) an.

Lesen Sie mehr über Devops

  • Was ist Devops? Transformation der Softwareentwicklung
  • 3 Möglichkeiten, ein Devops-Programm zu starten
  • Best Practices für Entwickler: Die 5 Methoden, die Sie anwenden sollten
  • 15 KPIs zur Verfolgung der Devops-Transformation
  • Anwendungsüberwachung: Was Entwickler besser können
  • Wo Site Reliability Engineering auf Entwickler trifft
  • 5 Prinzipien, um ein kollaboratives agiles Entwicklerteam zu werden
  • 3 Schritte zur Anwendung agiler Methoden im IT-Betrieb
  • Wie agile Teams das Incident Management unterstützen können
  • Wie Dataops Daten, Analysen und maschinelles Lernen verbessert
  • Anwenden von Entwicklern in den Bereichen Datenwissenschaft und maschinelles Lernen
  • 7 Fragen zur Priorisierung Ihres Devops-Backlogs