Site Reliability Engineering (SRE) ist eine Reihe von Grundsätzen und Praktiken, die Aspekte der Softwaretechnik umfassen und auf Infrastruktur- und Betriebsprobleme angewendet werden. Die Hauptziele sind die Schaffung skalierbarer und hochzuverlässiger Softwaresysteme. Site Reliability Engineering ist eng mit DevOps verwandt, einer Reihe von Praktiken, die Softwareentwicklung und IT-Betrieb kombinieren, und SRE wurde auch als eine spezifische Umsetzung von DevOps beschrieben.

Geschichte

Der Bereich Site Reliability Engineering hat seinen Ursprung bei Google mit Ben Treynor Sloss, der nach seinem Eintritt in das Unternehmen im Jahr 2003 ein Site Reliability Team gründete. Im Jahr 2016 beschäftigte Google mehr als 1000 Site Reliability Engineers. Nachdem das Konzept im Jahr 2003 bei Google entstanden war, verbreitete es sich in der gesamten Softwareentwicklungsbranche, und andere Unternehmen begannen daraufhin, Site Reliability Engineers zu beschäftigen. Die Position ist eher in größeren Webunternehmen verbreitet, da kleine Unternehmen oft nicht in einem Umfang tätig sind, der dedizierte SREs erfordern würde. Zu den Unternehmen, die das Konzept übernommen haben, gehören LinkedIn, Dropbox, Airbnb, IBM, und Netflix. Laut einem Bericht des DevOps Institute aus dem Jahr 2021 hatten 22 % der Unternehmen in einer Umfrage unter 2000 Befragten das SRE-Modell übernommen.

Definition

Die Aufgabe des Site Reliability Engineering kann sowohl von Einzelpersonen als auch von Teams wahrgenommen werden, die in der Regel für eine Kombination der folgenden Aufgaben innerhalb einer breiteren technischen Organisation verantwortlich sind: Systemverfügbarkeit, Latenz, Performance, Effizienz, Change-Management, Monitoring, Notfallreaktion und Kapazitätsplanung. Site Reliability Engineers haben oft einen Hintergrund in Softwaretechnik, Systemtechnik oder Systemadministration. Zu den Schwerpunkten des Site Reliability Engineering gehören Automatisierung, Systemdesign und Verbesserung der Systemausfallsicherheit (Resilienz).

Site Reliability Engineering als eine Reihe von Prinzipien und Praktiken kann von jedem durchgeführt werden. SRE ist dem Security Engineering insofern ähnlich, als von jedem erwartet wird, dass er zu guten Sicherheitspraktiken beiträgt, aber ein Unternehmen kann sich auch dafür entscheiden, Spezialisten für diese Aufgabe einzustellen. Umgekehrt können Unternehmen für die Sicherung von Internet-Systemen Sicherheitsingenieure einstellen und für die Definition und Gewährleistung ihrer Zuverlässigkeitsziele stattdessen SREs engagieren.

Site Reliability Engineering wurde auch als eine spezifische Umsetzung von DevOps beschrieben, aber es konzentriert sich speziell auf den Aufbau zuverlässiger Systeme, während DevOps eher auf die Infrastruktur ausgerichtet ist.

Stephen Gossett schrieb in Built In, dass einige Unternehmen ihre Betriebsteams in SRE-Teams umbenannt haben, ohne dass sich dadurch etwas geändert hat. Dies scheint auch auf Betriebsteams zuzutreffen, die in DevOps-Teams umbenannt wurden.

Prinzipien und Praktiken

Es hat mehrere Versuche gegeben, eine kanonische Liste von Prinzipien der Standortzuverlässigkeitstechnik zu definieren, aber obwohl es keinen Konsens gibt, sind die folgenden Merkmale normalerweise in den meisten dieser Definitionen enthalten:

  • Automatisierung oder Eliminierung von sich wiederholenden Tätigkeiten, die auch kosteneffektiv zu automatisieren oder zu eliminieren sind.
  • Vermeidung des Strebens nach viel mehr Zuverlässigkeit als unbedingt notwendig. Die Definition dessen, was notwendig ist, ist ein eigenes Verfahren (siehe Liste der Verfahren unten).
  • Systemdesign mit der Tendenz, die Risiken für Verfügbarkeit, Latenz und Effizienz zu reduzieren.
  • Beobachtbarkeit, d. h. die Möglichkeit, beliebige Fragen über Ihr System zu stellen, ohne vorher zu wissen, was Sie fragen wollen.

Die Praktiken des Site Reliability Engineering sind ebenfalls sehr unterschiedlich, aber die folgende Liste wird relativ häufig zumindest teilweise umgesetzt:

  • Arbeitsmanagement als Umsetzung des ersten oben genannten Grundsatzes.
  • Definition und Messung von Zuverlässigkeitszielen - SLIs, SLOs und Fehlerbudgets.
  • Nicht-abstrakter Entwurf von Großsystemen (NALSD) mit Schwerpunkt auf der Zuverlässigkeit.
  • Entwurf und Implementierung von Beobachtbarkeit.
  • Definieren, Testen und Ausführen eines Störungsmanagementprozesses.
  • Kapazitätsplanung.
  • Änderungs- und Versionsmanagement, einschließlich CI/CD.
  • Chaos-Engineering.

Implementierungen

Site-Reliability-Engineering-Teams arbeiten mit den anderen Teams in ihren Unternehmen und den SRE-Prinzipien und -Praktiken in verschiedenen Formen zusammen. Im Folgenden finden Sie einen Überblick über gängige SRE-Team-Implementierungen:

Kitchen Sink, auch bekannt als „Everything SRE“

Der Umfang der abgedeckten Dienste oder Arbeitsabläufe ist in der Regel unbegrenzt.

Infrastruktur

Konzentriert sich auf die Zuverlässigkeit der Systeme hinter den Kulissen, die die Arbeit anderer Teams effizienter machen. Diese Teams werden oft mit „Plattform“-Teams oder „Platform Operations“-Teams verwechselt. Infrastruktur-SRE-Teams können sich mit einem oder mehreren Plattform-Engineering-Teams zusammentun, aber sie unterscheiden sich darin, dass sich Infrastruktur-SRE-Teams auf die Durchführung der meisten, wenn nicht aller in der obigen Liste der Grundsätze und Praktiken beschriebenen Arbeiten konzentrieren. Plattformteams konzentrieren sich in der Regel auf die Entwicklung der Plattform, und obwohl Zuverlässigkeit wünschenswert ist, ist dies nicht ihre einzige Priorität.

Werkzeuge

Konzentriert sich auf Tools zur Messung, Wartung und Verbesserung der Systemzuverlässigkeit.

Produkt oder Anwendung

SRE-Team für Produkt und/oder Anwendung. Einige große Unternehmen beschäftigen mehrere dieser Teams.

Eingebettet

In der Regel SRE-Einzelkämpfer oder Paare, die innerhalb eines Software-Engineering-Teams arbeiten und die meisten der oben beschriebenen Prinzipien und Praktiken anwenden.

Beratung

Beratung bei der Umsetzung von SRE-Prinzipien und -Praktiken. Dabei handelt es sich in der Regel um erfahrene SREs, die in Teams mit einer oder mehreren der oben genannten Implementierungen gearbeitet haben. SREs in externen SRE-Beratungsteams werden oft als „Customer Reliability Engineers“ bezeichnet. Sie ändern selten, wenn überhaupt, die Konfiguration oder den Code des Kunden.

Große Unternehmen, die SRE eingeführt haben, verfügen in der Regel über eine Kombination der oben beschriebenen Implementierungen, einschließlich mehrerer Teams derselben Implementierung, z. B. mehrere Produkt-/Anwendungs-SRE-Teams, um die spezifischen Anforderungen verschiedener Produkte zu erfüllen, und ein Infrastruktur-SRE-Team, das sich mit einer Plattform-Engineering-Gruppe zusammenschließt, um die Zuverlässigkeitsziele einer gemeinsamen Plattform für beide Produkte/Anwendungen zu erfüllen.

Branchenumfeld

Die USENIX-Organisation veranstaltet seit 2014 eine jährliche SREcon-Konferenz für Site Reliability Engineers in der Industrie und hält auch regionale Konferenzen mit ähnlichen Themen ab.

Literatur

  • Tom Limoncelli, Strata R. Chalup, Christina J. Hogan: The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services. Band 2, Addison-Wesley, Upper Saddle River 2014, ISBN 978-0-13-347854-9.
  • Petoff Beyer, Jones Murphy, Jennifer Betsy, Chris Niall: Site Reliability Engineering: How Google Runs Production Systems. O’Reilly, 2016, ISBN 978-1-4919-2912-4.
  • David N. Blank-Edelman (Hrsg.): Seeking SRE: Conversations About Running Production Systems at Scale. 1. Auflage. O’Reilly, Sebastopol 2018, ISBN 978-1-4919-7886-3.
  • Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne: The Site Reliability Workbook: Practical Ways to Implement SRE. O’Reilly, 2018, ISBN 978-1-4920-2950-2.
  • Nat Welch: Real-World SRE: The Survival Guide for Responding to a System Outage and Maximizing Uptime. Packt, 2018, ISBN 978-1-78862-888-4.
  • Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield: Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. O’Reilly, 2020, ISBN 978-1-4920-8312-2.
  • Jones Rosenthal, Nora Casey: Chaos Engineering: System Resiliency in Practice. O’Reilly, 2020, ISBN 978-1-4920-4386-7.

Einzelnachweise

  1. ↑ Evaluating where your team lies on the SRE spectrum. Abgerufen am 1. Oktober 2021 (englisch).
  2. 1 2 3 4 5 Google - Site Reliability Engineering. Abgerufen am 1. Oktober 2021.
  3. 1 2 What's the Difference Between DevOps and SRE? (class SRE implements DevOps). Abgerufen am 1. Oktober 2021 (deutsch).
  4. ↑ Atlassian: Love DevOps? Wait until you meet SRE. Abgerufen am 1. Oktober 2021 (englisch).
  5. ↑ What is SRE? Abgerufen am 1. Oktober 2021 (englisch).
  6. ↑ Ben Treynor: Keys to {SRE}. 2014 (usenix.org [abgerufen am 1. Oktober 2021]).
  7. 1 2 Are site reliability engineers the next data scientists? In: TechCrunch. Abgerufen am 2. Oktober 2021 (amerikanisches Englisch).
  8. 1 2 3 Site Reliability Engineer: Day In The Life | Built In. Abgerufen am 2. Oktober 2021 (englisch).
  9. ↑ What is Site Reliability Engineering (SRE). Abgerufen am 2. Oktober 2021 (amerikanisches Englisch).
  10. ↑ Eveline Oehrlich, Jayne Groll, Jean-Pierre Garbani: Upskilling 2021 Enterprise DevOps SkillsReport (PDF; 43 MB) (Report). DevOps Institute.
  11. ↑ Eveline Oehrlich: What it takes to be a site reliability engineer. Abgerufen am 2. Oktober 2021 (englisch).
  12. ↑ Google - Site Reliability Engineering. Abgerufen am 2. Oktober 2021.
  13. 1 2 Chris Jones, Todd Underwood, Shylaja Nukala: Hiring Site Reliability Engineers. (PDF; 307 kB). Vol. 40, Nr. 3, Juni 2015, S. 35–39.
  14. ↑ The 7 SRE Principles [And How to Put Them Into Practice] | Blameless. Abgerufen am 2. Oktober 2021 (englisch).
  15. ↑ Evaluating where your team lies on the SRE spectrum. Abgerufen am 2. Oktober 2021 (englisch).
  16. ↑ Learn about observability | Honeycomb. Abgerufen am 2. Oktober 2021.
  17. ↑ SRE at Google: How to structure your SRE team. Abgerufen am 2. Oktober 2021 (englisch).
  18. ↑ SREcon. 25. August 2017, abgerufen am 2. Oktober 2021 (englisch).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.