Die 3 wichtigsten Erkenntnisse aus dem Site Reliability Engineering Panel mit LinkedIn, Dell und Gremlin auf der NGINX Conf 2019
Auf unserer NGINX Conf 2019 haben wir über 50 aufgezeichnete Sitzungen zu verschiedenen Themen durchgeführt. In diesem Blog möchte ich jedoch Erkenntnisse zu einem der heißesten Themen der Branche weitergeben: Site Reliability Engineering (und auch das verwandte Thema Chaos Engineering). Ich werde mich nur auf die drei wichtigsten Erkenntnisse konzentrieren, wir empfehlen Ihnen jedoch, sich die gesamte Sitzung hier anzusehen.
1. SRE-Definition
Das Gespräch begann mit der Frage, wie die Diskussionsteilnehmer den Begriff Site Reliability Engineering definierten, mit der übereinstimmenden Bemerkung, dass es sich dabei im Wesentlichen um Folgendes handelt: „Alles, um sicherzustellen, dass eine Site betriebsbereit ist.“ Darüber hinaus legten sie aber auch Wert darauf, „wirklich in die Tiefe zu gehen und das Problem so schnell wie möglich zu beheben, wenn ein Problem auftritt“ und „Entwicklungsteams mit einer kundenorientierten Denkweise auszustatten“. Konnten Sie in den Beschreibungen außerdem einige Ähnlichkeiten mit herkömmlichen Networking Operations-Teams erkennen? Ja, ich auch, aber ein Diskussionsteilnehmer hat mir wirklich aus der Seele gesprochen, als er betonte: „Einige Organisationen richten ein SRE-Team ein, indem sie lediglich ihr Network Ops-Team umbenennen, aber das ist nicht die beste Methode.“ Es gab einige Diskussionen darüber, aber mein Fazit ist, dass der größte Unterschied zwischen SRE und NetOps darin liegt, dass das SRE-Personal „in einem Entwicklungsteam oder einem kundenorientierten Team sitzt und sich wirklich auf die Geschäftsziele konzentriert.“
2. Chaos Engineering und Fehlerinjektion
Eines der Schlüsselthemen für eine SRE-Funktion ist das Konzept des Chaos Engineering. Die detaillierte Erläuterung des Chaos Engineering verschiebe ich auf diesen Artikel , in dieser Sitzung geht es jedoch wirklich um „einen Ansatz zur Identifizierung kritischer Fehler und deren schnelle Behebung“ – so etwas wie Feuerübungen. Und obwohl es Ähnlichkeiten mit Feuerübungen gibt, ist das Ziel des Chaos Engineering umfassender, da es sich auf die quantitative Analyse von Wiederherstellungs-, Haltbarkeits- und Verfügbarkeitsmetriken konzentriert.
Failure Injection ist eine recht gängige Methode, die 2014 von Netflix eingeführt wurde . Es handelt sich dabei um einen Testansatz, bei dem Metadaten einer Fehlersimulation zu Testzwecken, jedoch kontrolliert, in die Produktionsumgebung übertragen werden. Diese Bemühungen werden normalerweise von SRE-Teams geleitet, um eine höhere Verfügbarkeit und Zuverlässigkeit des Dienstes (oder der Site) sicherzustellen.
3. KPI und Fähigkeiten von SRE
Es gab eine interessante Diskussion darüber, wie SRE gemessen werden sollte. Obwohl mehrfach darauf hingewiesen wurde, dass MTTD (Mean-time-to-Detect) und MTTR (Mean-time-to-Respond) wichtige Messgrößen sind, waren sich alle Diskussionsteilnehmer einig, dass die Messgrößen je nach Branche und den von einem betriebenen Systemen oder Standorten unterschiedlich ausfallen. Ein guter Vorschlag aus der Diskussion war: „Sie können beginnen, indem Sie diese Frage stellen: ‚Welche sind Ihre fünf wichtigsten Systeme?‘ und das wird Ihnen helfen, Prioritäten zu setzen.“
Ein weiteres Thema war der bevorzugte Kompetenzbereich für eine SRE-Position. Laut Aussage der Diskussionsteilnehmer hängt dies auch davon ab, welches System Sie verwenden. (Wenn Sie beispielsweise NGINX ausführen, ist NGINX-Erfahrung für die Einstellung eines SRE von entscheidender Bedeutung.) Ein toller Vorschlag der Gruppe bestand darin, nach Möglichkeiten zu suchen, SRE-Personal zwischen verschiedenen Unternehmensbereichen und Systemen rotieren zu lassen, um die SRE-Ressourcen zu skalieren und besser auszustatten. Stellen Sie außerdem sicher, dass Ihre SRE-Teams an SRE-Community-Events und -Aktivitäten teilnehmen, beispielsweise an Schulungen, Offsites, dedizierten Slack-Kanälen und „Spieltagen“, neben anderen hilfreichen Vorschlägen.
Fazit – Ist 2020 der richtige Zeitpunkt, Ihre eigene SRE-Strategie zu definieren?
Kurz gesagt ergab die Diskussion, dass viele Organisationen immer noch lernen, wie sie das Konzept und die Rolle von SRE definieren und nutzen können. Und wie die Diskussionsteilnehmer wiederholten, variieren diese oft je nach Branche und System (und sogar je nach einzelnem Unternehmen). Insgesamt werden wir uns auch im nächsten Jahr weiterhin mit Chaos Engineering befassen – vielleicht ist dies der perfekte Zeitpunkt, um darüber nachzudenken, was dies für Sie und Ihr Unternehmen bedeutet?