SRE rückt moderne Unternehmensarchitekturen in den Fokus

„An“ zu sein ist nicht das Maß der Leistung. Nur weil eine Lampe mit Strom versorgt wird, heißt das nicht, dass sie dem Benutzer ausreichend Licht gibt, um zuverlässig zu sehen, was er tut. Neben der Sehstärke haben noch viele andere Faktoren Einfluss darauf, ob der Benutzer sehen kann oder nicht. Die Glühbirne könnte schwach sein – entweder weil sie kaputt geht oder weil sie zwar Strom hat, aber nicht genug. Wenn die Leistung der Glühbirne nicht ausreicht, um hell zu leuchten, liegt möglicherweise ein Problem mit der Verkabelung vor oder es liegt eine Einschränkung des Stromflusses durch einen Dimmer vor. Und wenn die Glühbirne hell ist, kann es sein, dass der Lampenschirm zu dunkel oder der Platz zu groß für nur eine Lampe ist. Kurz gesagt: Es gibt viele Faktoren, die die Leistung der Lampe und damit das Benutzererlebnis beeinflussen. Zur Beurteilung der Leistung und Zuverlässigkeit von Systemen und Anwendungen gehört mehr als die herkömmliche Messung der Betriebszeit. Die Zuverlässigkeit hängt auch vom Serviceniveau ab.

Systeme und Anwendungen bestehen aus vielen Komponenten (Infrastruktur, APIs, Sicherheit, Arbeitsabläufe, Logik, Daten usw.), die zu einem bestimmten Zweck zusammengeführt werden. Die bloße Verfügbarkeit garantiert jedoch keine Zuverlässigkeit. Wie bei der Lampenanalogie müssen Sie in der Lage sein, alle Komponenten zu bewerten und einzuschätzen, um optimale Leistung und Erfahrung bestätigen zu können. Während es in einem stationären Geschäft ganz einfach sein kann, Mängel im Serviceniveau festzustellen, indem man einfach den „Kundenweg“ abläuft und so das Gesamterlebnis beurteilt, kann dies in einem digitalen Geschäft eine erhebliche Herausforderung darstellen. Angesichts der Geschäfts- und IT-Silos, die durch traditionelle Unternehmensarchitekturen entstehen, ist die Identifizierung eines Problems und die Ermittlung seiner Grundursache nicht immer einfach oder effizient. Unternehmensleiter denken vielleicht, dass ein Problem vorliegt, die IT-Teams, die ihre Komponenten verwalten, sind sich dessen vielleicht aber nicht bewusst, wenn alles „eingeschaltet“ ist. Site Reliability Engineering (SRE) ist die Brücke zwischen dem Business und der IT, um die Erfüllung geschäftlicher Verpflichtungen durch Service Level Objectives (SLOs) sicherzustellen.

Site Reliability Engineering entstand bei Google in den frühen 2000er Jahren und ist laut dem Unternehmen „das Ergebnis, wenn man den Betrieb so behandelt, als handele es sich um ein Softwareproblem.“ In unseren Begriffen handelt es sich dabei um eine Reihe von Prozessen, Praktiken und Werkzeugen sowie um eine Kultur und Denkweise, die darauf abzielen, zuverlässige, effiziente und skalierbare Systeme zu schaffen, die die Geschäftsziele unterstützen.

SRE konzentriert sich auf zuverlässige – nicht nur verfügbare – und skalierbare Systeme. Wir fügen hinzu, dass es eine Geisteshaltung und eine Kultur ist, weil, wie bei der Sicherheit, von jedem erwartet werden sollte, unabhängig von seiner Rolle einen positiven Beitrag zu hochwertigen und zuverlässigen Systemen zu leisten. Obwohl es sich bei SRE auch um eine Kultur und Denkweise handelt, ist es häufig in die Praxis eines Serviceteams eingebettet, das den gesamten Service von Anfang bis Ende bereitstellt. Diese Teams sind im Allgemeinen dafür verantwortlich, das Kernsystem zu verbessern und Innovationen durch die Überwachung von Verfügbarkeit, Latenz, Leistung und Wiederherstellung zu ermöglichen, während sie gleichzeitig durch Automatisierung und Effizienz eine kontinuierliche Verbesserung vorantreiben. Im Wesentlichen blicken sie auf den ganzen Raum und prüfen nicht nur, ob die Lampe an ist.

Site Reliability Engineering definiert die Maßnahmen der SLOs und SLIs (Service Level Indicators), um Geschäftsergebnisse zu erreichen. Einfacher ausgedrückt vereint SRE die Anforderungen und Ziele der Entwicklungs-, Sicherheits- und Betriebsteams, um die Versprechen des Unternehmens gegenüber seinen Kunden zuverlässig zu erfüllen.

Wenn die geschäftliche Verpflichtung darin besteht, dass die Benutzer zuverlässig über genügend Licht verfügen, damit sie sehen können, was sie tun (Servicelevel), könnte ein SLO darin bestehen, dass pro 10 Quadratfuß Fläche eine hell leuchtende Lampe (Verfügbarkeit) bereitgestellt wird. Ein weiteres SLO könnte eine definierte MTTR (mittlere Wiederherstellungszeit) sein. In diesem Beispiel ist dies die Zeitspanne, in der defekte oder durchbrennende Glühbirnen ersetzt werden. SLIs sind dann die von Site-Reliability-Ingenieuren und der IT definierten Schwellenwerte, um sicherzustellen, dass SLOs erreicht werden. Dazu gehört beispielsweise die Überwachung des Lichtstroms, des Stromflusses zu jeder Lampe oder der geringfügigen Änderungen der Lampenposition, die dadurch verursacht werden, dass Benutzer die Lampen anstoßen oder verschieben. In Anwendungsbereitstellungssystemen können dies beispielsweise CPU-Auslastung, API-Aufruf- und Datenbankabfragezeit usw. sein. Es liegt an den Site Reliability Engineers, die SLI-Maßnahmen zu definieren, die sich auf die geschäftlichen SLOs auswirken, und durch die Anpassung der Betriebsrichtlinien und -konfiguration festzulegen, welche Reaktionen ergriffen werden, wenn die SLI-Maßnahmen unter bestimmte Schwellenwerte fallen.