Die immer schneller werdende Geschäftswelt ist schon seit geraumer Zeit von dem Wort „Agilität“ besessen, wenn es um die Entwicklung von IT-Produkten geht. Und es ist nicht schwer zu verstehen, warum: Die Aussicht, die lang ersehnte Lösung zur Behebung von Problemen so schnell wie möglich zu erhalten, ist und bleibt verlockend.

Die COVID-19-Pandemie hat jedoch gezeigt, dass es nicht mehr ausreicht, einfach nur agil zu sein: Aus dem Transposit-Bericht geht hervor, dass die MTTR (mittlere Reparaturzeit) gestiegen ist (93,6 %), seit die Welt gezwungen ist, ein Remote-Arbeitsmodell einzuführen, wobei die Ausfallzeiten sogar um 68,4 % gestiegen sind!

Wie kann man nun sicherstellen, dass die Agilität nicht länger die Zuverlässigkeit beeinträchtigt? Das sind DevOps und Site Reliability Engineering (SRE). Diese Konzepte gibt es schon seit geraumer Zeit, und angesichts der Herausforderungen, die sich insbesondere im Zuge der Pandemie stellen, sind sie aktueller denn je.

DevOps und SRE wurden in den frühen 2000er Jahren entwickelt, um ein Gleichgewicht zwischen Entwicklungsagilität und Systemstabilität zu finden. Die Begriffe werden jedoch oft falsch verwendet: Manche denken, es handele sich um dasselbe, andere halten sie für konkurrierende Ideen. Die meisten glauben, dass sich ein Unternehmen immer zwischen beiden entscheiden muss. Gehen wir also der Frage auf den Grund, was DevOps und SRE sind und ob eine Debatte zwischen DevOps und SRE überhaupt Sinn macht.

DevOps ist im Kern eine Methodik, die Silos zwischen Entwicklungs-, Test-, Qualitätssicherungs- und Betriebsteams abbaut, um die Anwendungsentwicklung zu beschleunigen, die Softwarequalität zu verbessern, die Verfügbarkeit der Infrastruktur zu erhöhen, die Anwendungsleistung zu maximieren und die Kosten zu senken. All das klingt großartig. Allerdings gibt es ein Problem. DevOps ist im Grunde eine Reihe von abstrakten Prinzipien, von denen viele Unternehmen Schwierigkeiten haben, sie in die Praxis umzusetzen. Um diesen Kampf zu beenden, hat Google 2016 ein Buch mit dem Titel „Site Reliability Engineering“ veröffentlicht, das die internen DevOps-Praktiken beleuchtet, aber vor allem leicht verständliche praktische Ratschläge gibt, wie DevOps funktioniert.

Kurz gesagt: DevOps ist eine Philosophie, und SRE ist eine gute Möglichkeit, diese Philosophie umzusetzen.
Wie trägt SRE zur DevOps-Methodik bei?

Wenn Sie sich das DevOps-Manifest ansehen, werden Sie wahrscheinlich feststellen, dass es 5 Schlüsselkategorien gibt, in die DevOps unterteilt ist, die Mantras der Methodik, wenn Sie so wollen:

• Beseitigung organisatorischer Silos
• Akzeptieren von Fehlern als normal
• Kleine inkrementelle Änderungen einführen
• Nutzen von Werkzeugen und Automatisierung
• Alles messen

All diese Punkte sind zweifellos für den Erfolg eines Teams bei der Suche nach einem ausgewogenen Verhältnis zwischen Agilität und Zuverlässigkeit von entscheidender Bedeutung, und wir werden gleich herausfinden, warum. Aber so schön sie auch klingen, sie sehen nicht wie konkrete Anweisungen aus („Alles messen“? Natürlich!). Gehen wir also diese Grundsätze nacheinander durch und sehen wir, wo der Unterschied zwischen DevOps und SRE wirklich liegt.
DevOps-Ideen und SRE-Implementierung
Aufhebung der organisatorischen Silos

DevOps-Idee: Die Kommunikation zwischen den Personen, die für die Programmierung zuständig sind (Entwickler), und den Personen, die die Wartungsdienste erbringen (Betreiber), muss nahtlos sein, um zu verhindern, dass schnelle Änderungen am Code die Infrastruktur beschädigen und die Stabilität des Systems ernsthaft gefährden. Ursprünglich sollte DevOps die Mauer zwischen Entwicklungs- und Betriebsteams durchbrechen, hat sich aber schnell über die Softwarebereitstellungspipeline hinaus auf Bereiche wie Sicherheit, Finanzen, HR, Marketing, Vertrieb usw. ausgebreitet, in denen eine Zusammenarbeit unerlässlich ist.

SRE-Implementierung: Sie müssen ein engmaschiges, funktionsübergreifendes Team aufbauen, indem Sie nicht nur Entwickler und Operatoren zusammenbringen, sondern auch synergiefördernde Praktiken auf die Bereiche Finanzen, Personalwesen, Führungsteams usw. ausweiten. Die Kultur der besseren Kommunikation und des Wissensaustauschs, die DevOps und SRE von Natur aus erfordern, kann durch häufige Stand-ups geschaffen werden, während Integration und Automatisierung mit speziellen Toolsets umgesetzt werden sollten.
Scheitern als normal akzeptieren

DevOps-Gedanke: Kein von Menschen geschaffenes System kann zu 100 % zuverlässig sein, daher sollte ein Ausfall des besagten Systems von keinem Unternehmen als Katastrophe empfunden werden, sondern als Normalität behandelt werden… solange daraus eine Lehre gezogen wird.

SRE-Implementierung: Sie müssen sich intern darauf einigen, wie viel Ausfallzeit unter den gegebenen Umständen akzeptabel ist, und darauf vorbereitet sein, Systemausfälle schnell zu bewältigen (da sie unvermeidlich sind und nicht überraschend kommen sollten); eine Möglichkeit, dies zu tun, ist die Durchführung so genannter „schuldloser Post-Mortems“, bei denen keine Zeit damit verschwendet wird, die Schuldigen für den Ausfall zu suchen. Stattdessen sucht das Team routinemäßig nach Möglichkeiten zur Verbesserung des Systems und konzentriert sich dabei auf die Zukunft, nicht auf die Vergangenheit.

DevOps-Idee: Häufige, aber kleine Änderungen am Code helfen, schneller auf Probleme zu reagieren und Fehler einfacher zu beheben. Und warum? Das ist ganz einfach. Die Suche nach einem Fehler in 100 Codezeilen ist viel einfacher als in 100.000 Codezeilen. Außerdem ist der Entwicklungsprozess dadurch generell viel flexibler und kann auf plötzliche Änderungen reagieren.

SRE-Implementierung: Sie müssen beachten, dass es nicht auf die tatsächliche Anzahl der Deployments pro Tag ankommt. Das Streben nach einer übermäßigen Anzahl von Deployments nur um der Deployments willen ist vergebliche Mühe. Sie sollten in der Tat häufig deployen, aber auch dafür sorgen, dass diese Deployments sinnvoll sind – je sinnvoller die Art des Deployments ist, desto einfacher ist es, einen potenziellen Fehler zu beheben, und desto geringer sind die Kosten für Fehlschläge.
Von Tools und Automatisierung profitieren

Die DevOps-Idee: Es liegt in der menschlichen Natur, dass wir monotone Aufgaben nicht effizient ausführen können. Genauso wie es viel Zeit und Energie kostet, wichtige Arbeitsabläufe manuell zu erledigen, können Unternehmen, die Tools und Automatisierung nutzen, diese Prozesse exponentiell verbessern.

SRE-Implementierung: Sie sollten sich überlegen, welche langfristigen Verbesserungen am System vorgenommen werden müssen, und die Aufgaben automatisieren, die in einem Jahr oder in ein paar Jahren regelmäßig anfallen werden (SRE nennt dies „die Arbeit von diesem Jahr weg automatisieren“). Auf diese Weise vermeiden Sie Investitionen in kurzfristige Gewinne und konzentrieren sich auf die langfristige Automatisierung.

DevOps-Idee: Konkrete Metriken, die verschiedene Aspekte Ihres Entwicklungsprozesses messen, helfen nicht nur dabei, festzustellen, ob das Unternehmen erfolgreich an einem bestimmten Projekt arbeitet, sondern liefern auch eine Rechtfertigung für diese oder jene Geschäftsentscheidung.

SRE-Implementierung: Sie sollten Service-Level-Agreements (SLA), Service-Level-Ziele (SLO) und Service-Level-Indikatoren (SLI) verwenden, die mittlere Zeit zwischen zwei Ausfällen (MTBF) und die mittlere Wiederherstellungszeit (MTTR) des Systems verfolgen und ein Fehlerbudget festlegen. So können Sie Ihr Projekt wesentlich effizienter gestalten.

Wir werden in Kürze näher darauf eingehen, was einige der Begriffe im obigen Absatz tatsächlich bedeuten, aber der Rest des Bildes sollte inzwischen mehr als deutlich sein. DevOps wurde geschaffen, um die IT-Entwicklung besser zu machen. In der Zwischenzeit sollte SRE zeigen, WIE genau wir das tun sollten. Wie viele SRE-Spezialisten zu sagen pflegen, „SRE implementiert DevOps“.

SRE als Konzept ist ohne Service-Level Agreement (SLA), Service-Level Objective (SLO), Service-Level Indicator (SLI) kaum vorstellbar. Wie bereits erwähnt, handelt es sich hierbei um die zentralen Begriffe, die sich in vielerlei Hinsicht auf die Messung des Erfolgs Ihrer SRE-Implementierung beziehen. Und genau wie die Namen dieser Konzepte sind auch ihre Eigenschaften einander sehr ähnlich, allerdings mit einigen entscheidenden Unterschieden:

• SLA wird als Vereinbarung zwischen dem Service Provider und dem Kunden über Kennzahlen wie Betriebszeit, Ausfallzeit, Reaktionsfähigkeit, Verantwortlichkeiten usw. bezeichnet. Mit anderen Worten, es handelt sich um eine Reihe von Versprechen an den Kunden, die durch verschiedene Messgrößen dargestellt werden, sowie um eine Reihe von Konsequenzen, wenn diese Versprechen nicht eingehalten werden;
• SLO wird wiederum als Vereinbarung innerhalb eines SLA über eine bestimmte Kennzahl bezeichnet, z. B. Betriebszeit oder Antwortzeit. Im Grunde ist ein SLO ein individuelles Versprechen an den Kunden. In dieser Hinsicht kann man ein SLA also als eine bestimmte Gruppe von SLOs betrachten;
• Der SLI schließlich ist ein Indikator, der anzeigt, ob das System in Übereinstimmung mit diesem oder jenem SLO funktioniert.

Ein typisches Beispiel für das Zusammenspiel dieser drei Begriffe wäre etwas in dieser Art: Ein SLA, das Sie mit Ihrem Kunden abgeschlossen haben, besagt, dass das System 99,9 % der Zeit verfügbar sein wird (die so genannten „drei Neunen der Verfügbarkeit“), es würde also die SLO enthalten, die 99,9 % Betriebszeit bedeuten würde, und die SLI wäre die tatsächliche Messung der Betriebszeit des Systems.
Welche Arten von Unternehmen brauchen SRE und DevOps?

In Anbetracht der Tatsache, dass DevOps und SRE dazu da sind, Entwicklungsteams bei der Sicherstellung einer hohen Systemstabilität zu unterstützen und gleichzeitig sehr agil zu sein, kann man relativ sicher sagen, dass jedes Entwicklungsunternehmen bis zu einem gewissen Grad wissen sollte, was DevOps/SRE-Techniken sind und wie man sie implementiert. Sie sind das A und O der modernen Softwareentwicklung.

In unseren früheren Beiträgen haben wir uns bereits mit den Vorteilen von DevOps für große Produktionsunternehmen und den massiven Auswirkungen auf die Finanzdienstleistungsriesen befasst, aber die Genialität von DevOps und SRE liegt in ihrer universellen Anwendbarkeit – Ihr Unternehmen muss KEIN Softwareentwicklungsunternehmen sein, um von diesen Praktiken zu profitieren; solange Sie mit Update-Rollouts, Infrastrukturänderungen, Wachstum und Upscaling zu tun haben, können Sie sich mit dieser Philosophie beschäftigen.

Und tatsächlich ist kein Team zu klein für DevOps/SRE. Wenn Sie ein kleines Unternehmen sind, brauchen Sie nicht einmal einen speziellen SRE-Spezialisten. In diesem Fall kann es sich lohnen, eines Ihrer Teammitglieder in der Anwendung der SRE-Methode zu schulen, da die Lernkurve nicht so hoch ist.

Wenn man all dies berücksichtigt, kann man leicht zu dem Schluss kommen, dass die Ideen und Konzepte hinter DevOps und SRE für jedes Unternehmen interessant sind – ob Großunternehmen oder kleines StartUp, ob IT oder Nicht-IT, sie sind für jeden geeignet.

Bei dem Versuch, die Debatte zwischen Site Reliability Engineering und DevOps zu klären, können wir nun mit Sicherheit sagen, dass es keinen Sinn hat, entweder oder zu sagen. Wie können wir hier überhaupt von einer Debatte sprechen, wenn die beiden Dinge, die wir verzweifelt versuchen, einander gegenüberzustellen, praktisch dasselbe sind, wobei das eine ein wesentlicher Bestandteil des anderen ist?

Wenn Sie sagen, dass Sie DevOps gut machen können, ist es wahrscheinlich, dass Sie das mit Hilfe von SRE-Prinzipien tun.

Wenn Sie sagen, dass Sie SRE gut machen können, sollten Sie wissen, dass wir technisch gesehen über DevOps sprechen.

Es handelt sich also keineswegs um ein „rote Pille-blaue Pille“-Szenario. Sowohl DevOps als auch SRE sind zu begrüßen, und wir sind sehr gespannt, wie sich beide in den kommenden Jahren entwickeln werden.

Interessieren Sie sich für SRE und DevOps? Sprechen Sie mit unseren DevOps–Experten, um herauszufinden, wie DevOps und SRE Ihnen helfen können, neue Geschäftsmöglichkeiten zu erschließen.