Tipps für Site Reliability Engineers

So managen Sie SLOs und Fehlerbudgets

02.06.2023
Von 


Isaac Sacolick ist Autor des Amazon-Bestsellers "Diving Digital: The Leader's Guide to Business Transformation thourh Technology". Er schreibt als freier Autor unter anderem für unsere US-Schwesterpublikation CIO.com.

 
Diese Tipps unterstützen Site Reliability Engineers dabei, die Performance zu halten, während sie im Devops-Lifecycle operieren.
Diese Tipps unterstützen Site Reliability Engineers dabei, Service-Level-Ziele zu erfüllen und Fehlerbudgets zu schonen.
Diese Tipps unterstützen Site Reliability Engineers dabei, Service-Level-Ziele zu erfüllen und Fehlerbudgets zu schonen.
Foto: Mameraman - shutterstock.com

Site Reliability Engineers (SREs) ergreifen proaktive Maßnahmen, um die App Performance zu optimieren, die Anzahl der Fehler in der Produktion zu verringern und Folgen von Produktionsstörungen zu reduzieren. Dabei müssen sie häufig Kompromisse eingehen, denn eine Steigerung der Betriebsleistung ist oft mit exponentiell steigenden Kosten verbunden.

Um Entscheidungen zu treffen, kommen bei Devops-Organisationen mit SREs zwei Messinstrumente zum Einsatz:

  • Service Level Objectives (SLOs) und

  • Fehlerbudgets.

SLOs dienen als Benchmark für die Performance und Zuverlässigkeit von Applikationen und Business Services. Werden diese Ziele verfehlt, belastet das die Fehlerbudgets und signalisiert Devops-Teams, dass sie ihren Fokus von Features darauf verlagern sollten, Betriebsprobleme zu beheben.

Es gibt verschiedene Arten von Service-Level-Zielen. Allen ist gemein, dass Error Events erfasst und anhand eines akzeptablen Schwellenwertes einem Benchmarking unterzogen werden. Eine mobile Anwendung kann beispielsweise Anwendungsfehler und Interaktionen mit schlechten Reaktionszeiten erfassen und ein SLO definieren, das 99,9 Prozent fehlerfreie Benutzerereignisse pro rollierendem 24-Stunden-Zeitraum anstrebt. Wenn Ereignisse diesen SLO überschreiten, werden sie mit dem Fehlerbudget verrechnet. SLOs und Fehlerbudgets sind simple Konzepte, aber sie zu messen und zu managen erfordert Technologieplattformen und definierte Verfahren. Die Site Reliability Engineers benötigen:

  • einerseits Tools, um SLOs zu erfassen und zu reporten sowie Fehlerbudgets zu managen.

  • Andererseits auch Tools, die innerhalb der Dev- und Ops-Lebenszyklen eingesetzt werden können, um Performance und Zuverlässigkeit zu verbessern.

So gehen Sie vor.

1. Feature Flags einsetzen

"Houston, wir haben ein Problem" - wenn dieser Satz fällt, kommt SREs die Herausforderung zu, die Wurzel des Übels zu finden. In einigen Fällen können sie das Problem einfach beheben. Sind aber Codeänderungen erforderlich, brauchen sie Tools, um dieses Problem zu umgehen. Die bessere Option: den Rollout von Features mit Hilfe von Feature Flags kontrollieren, damit Probleme schneller identifiziert und behoben werden können.

"Ich bin ein großer Fan von Feature-Flagging-Tools wie LaunchDarkly und Optimizely", outet sich Marcus Merrell, Vice President of Technology Strategy bei SauceLabs. "Diese Tools erlaubt es einer begrenzten Gruppe von Nutzern, Änderungen zu sehen, während das Team auf Probleme achten kann. Sobald das Feature in Produktion ist und sich für eine gewisse Zeit gut verhält, kann man die Änderungen für alle User freigeben."

Feature Flagging ist ein Tool, um Fehler in der Produktion zu minimieren und stellt einen entscheidenden Fortschritt dar, wie Merrell unterstreicht: "Früher musste man riskieren, den gesamten Software Development Lifecycle zu unterbrechen, wenn ein Problem auftrat. Mit Feature Flagging verwebt man quasi das Sicherheitsnetz mit dem Feature."

2. Strategien entwickeln

Das Network Operations Center (NOC) steht in der Verantwortung, Applikationsausfälle und schlechte User Experiences zu identifizieren. Zu diesem Zweck braucht das NOC Monitoring-Systeme und Tools sowie das notwendige Knowhow, um diese richtig einzusetzen.

In der Realität kommen Ausfälle leider im Regelfall Flächenbränden gleich, weil Abhängigkeiten zwischen Microservices, SaaS-Lösungen von Drittanbietern und Applikationen eine Flut von Alarmmeldungen auslösen können. Das kennt auch Roni Avidov, R&D Lead bei Monday.com: "Wie viele schnell wachsende Unternehmen hatten wir mit 'Alert Fatigue' und einer wachsenden Zahl von Fehlalarmen zu kämpfen. Das hat das Vertrauen in unsere bestehende Tool-Landschaft beeinträchtigt."

Um Alarmmeldungen und relevante Observability-Daten korrelieren und zu behebbaren Incidents verbinden, brauchen Devops-Teams eine Strategie. Für Unternehmen, die Microservices entwickeln, auf Multi-Cloud-Infrastrukturen setzen und die Deployment-Frequenz von geschäftskritischen Applikationen erhöhen wollen, kann das eine Herausforderung darstellen. In solchen Fällen können AIOps-Plattformen dazu beitragen, den Zeitrahmen für die Auflösung von Vorfällen und die Identifizierung von Abhilfemaßnahmen zu verringern.

Avidov verrät, welcher Ansatz Monday.com zum Erfolg geführt hat: "Wir verwenden Sentry, um alle Plattformen in unserem Stack zu supporten. Das ermöglicht uns eine einfache Korrelation zwischen den Alarmmeldungen. So konnten wir die Zeit bis zur Problemlösung um über 70 Prozent, die Anzahl der clientseitigen Fehler um 60 Prozent und die Anzahl der Fehlalarme um 50 Prozent reduzieren."

Laut Emily Arnott, Community Manager bei Blameless, besteht ein weiteres Erfolgskriterium darin, Echtzeitdaten zu erfassen: "SLOs und Fehlerbudgets müssen aktuelle Vorfallsdaten akkurat widerspiegeln. Ist das nicht der Fall, könnte es zu einem Breach kommen, der auch die Kunden betrifft - bevor die Techniker es merken. Automatisierte Tools sind der beste Weg, um ihre SLOs stets auf dem neuesten Stand zu halten."

3. SLO-Templates und -Dashboards erstellen

Um Maßnahmen zur Verbesserung der Service-Zuverlässigkeit und -Performance voranzutreiben, können Site Reliability Engineers Richtlinien als SLOs, Fehlerbudgets sowie Monitoring- und AIOps-Plattformen definieren.

Zac Nickens, Global Reliability and Observability Engineering Manager bei OutSystems, empfiehlt in diesem Zusammenhang ein Review von "The SLO Development Lifecycle" (SLODLC) - einer Open-Source-Methode, die ein Handbuch, Worksheets, Templates und Anwendungsbeispiele für die Anwendung von SLOs beinhaltet: "Wir verwenden SLODLC im Rahmen interner SLO-Discovery- und Design-Sessions und nutzen dabei Templates der Webseite."

Das ist jedoch nur der erste Schritt auf dem Weg zur Kollaboration von Business, Devops und Site Reliability Engineers. "Wir veröffentlichen diese SLOs in unserem internen Wiki und verlinken sie in unserem SLO-Dashboard auf Nobl9. Die SLO-Design-Dokumente von SLODLC machen es einfach, den geschäftlichen Kontext über das Warum hinter jeder Metrik und jedem Fehlerbudget zu teilen", ergänzt Nickens.

4. SLOs als Code implementieren

Wenn Sie nach einem besseren Weg suchen, um umsetzbare SLOs zu erfassen und zu nutzen, empfiehlt Bruno Kurtic, Chief Strategy Officer bei Sumo Logic, sich mit OpenSLO auseinanderzusetzen. Das Open-Source-Projekt definiert SLOs als Code, wie der Manager erklärt: "OpenSLO besteht aus einer API-Definition und einem Befehlszeilen-Tool, um SLO-Definitionen zu validieren und zu konvertieren."

Zum Projekt tragen unter anderem folgende Unternehmen bei:

  • GitLab,

  • Lightstep,

  • Nobl9,

  • Red Hat,

  • Sumo Logic und

  • Tapico.io.

Das zeigt, dass immer mehr Unternehmen offene und interoperable Tools entwickeln, um Site Reliability Engineers dabei zu unterstützen, die Performance und Zuverlässigkeit von Business Services zu optimieren. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.