„Eingeschaltet“ zu sein ist kein Maß für Leistung. Nur weil eine Lampe mit Strom versorgt wird, bedeutet das nicht, dass sie dem Nutzer genügend Licht bietet, um zuverlässig sehen zu können, was er tut. Neben der Stromversorgung beeinflussen viele weitere Faktoren, ob der Nutzer etwas sehen kann. Die Glühbirne könnte nur schwach leuchten – entweder weil sie bald ausfällt oder weil sie zwar Strom erhält, aber nicht genug. Wenn die Glühbirne nicht ausreichend mit Strom versorgt wird, um hell zu leuchten, könnte ein Problem mit der Verkabelung vorliegen oder ein Dimmer den Stromfluss begrenzen. Und selbst wenn die Glühbirne hell leuchtet, könnte der Lampenschirm zu dunkel oder der Raum für eine einzige Lichtquelle zu groß sein. Kurz gesagt: Viele Faktoren beeinflussen die Leistung der Lampe und damit das Nutzererlebnis. Ebenso reicht die herkömmliche Messgröße der Verfügbarkeit allein nicht aus, um die Leistung und Zuverlässigkeit von Systemen und Anwendungen zu beurteilen. Die Zuverlässigkeit hängt auch vom Serviceniveau ab.
Systeme und Anwendungen bestehen aus vielen Komponenten – Infrastruktur, APIs, Sicherheit, Workflows, Logik, Daten usw. –, die zu einem bestimmten Zweck zusammengeführt werden. Doch nur weil sie eingeschaltet sind, ist ihre Zuverlässigkeit noch lange nicht gewährleistet. Wie bei der Analogie mit der Lampe müssen Sie alle Komponenten bewerten und beurteilen können, um eine optimale Leistung und Nutzererfahrung sicherzustellen. Während sich in einem stationären Unternehmen ein unzureichendes Serviceniveau mitunter ganz einfach feststellen lässt, indem man den „Kundenweg“ selbst durchläuft und so das Gesamterlebnis beurteilt, kann dies in einem digitalen Unternehmen eine erhebliche Herausforderung darstellen. Aufgrund der durch traditionelle Unternehmensarchitekturen entstandenen Silos zwischen Fachbereichen und IT ist es nicht immer einfach oder effizient, ein Problem zu erkennen und dessen Ursache zu ermitteln. Führungskräfte vermuten möglicherweise ein Problem, während die für die jeweiligen Komponenten zuständigen IT-Teams keines sehen, solange alles „eingeschaltet“ ist. Site Reliability Engineering (SRE) bildet die Brücke zwischen Fachbereichen und IT, um die Erfüllung geschäftlicher Zusagen mithilfe von Service Level Objectives (SLOs) sicherzustellen.
Was ist SRE?
Site Reliability Engineering entstand Anfang der 2000er-Jahre bei Google und ist laut Google „das, was man erhält, wenn man den IT-Betrieb wie ein Softwareproblem behandelt“. Für uns umfasst es eine Reihe von Prozessen, Praktiken und Tools sowie eine Kultur und Denkweise, mit denen zuverlässige, effiziente und skalierbare Systeme geschaffen werden, die die Geschäftsziele unterstützen.
SRE konzentriert sich auf zuverlässige – nicht nur verfügbare – und skalierbare Systeme. Wir sprechen dabei auch von einer Denkweise und Kultur, weil ähnlich wie bei der Sicherheit von allen erwartet werden sollte, unabhängig von ihrer Rolle einen positiven Beitrag zu hochwertigen, zuverlässigen Systemen zu leisten. Obwohl SRE ebenfalls eine Kultur und Denkweise ist, wird die praktische Umsetzung häufig in ein Serviceteam integriert, das den gesamten Service von Anfang bis Ende bereitstellt. Diese Teams sind in der Regel dafür verantwortlich, das Kernsystem zu verbessern und Innovationen zu ermöglichen, indem sie Verfügbarkeit, Latenz, Leistung und Wiederherstellung überwachen und zugleich durch Automatisierung und Effizienz kontinuierliche Verbesserungen vorantreiben. Im Wesentlichen betrachten sie den gesamten Raum, anstatt nur zu prüfen, ob die Lampe eingeschaltet ist.
Wie SRE mithilfe von SLIs SLOs erfüllt
Site Reliability Engineering definiert die Messgrößen für SLOs und SLIs (Service Level Indicators), um die Geschäftsziele zu erreichen. Einfacher ausgedrückt: SRE vereint die Anforderungen und Ziele der Entwicklungs-, Sicherheits- und Betriebsteams, damit die den Kunden gegebenen Geschäftsversprechen zuverlässig eingehalten werden.
Wenn die geschäftliche Zusage darin besteht, dass den Benutzern zuverlässig genügend Licht zur Verfügung steht, damit sie sehen können, was sie tun (Service-Level), könnte ein SLO vorsehen, dass pro 10 Quadratfuß Fläche eine hell leuchtende Lampe (Verfügbarkeit) aufrechterhalten wird. Ein weiteres SLO könnte eine festgelegte MTTR (Mean Time to Recover, mittlere Wiederherstellungszeit) sein, in diesem Beispiel also die Zeitspanne, innerhalb derer ausgefallene oder nachlassende Glühbirnen ersetzt werden. SLIs sind dann die von Site Reliability Engineers und der IT festgelegten Schwellenwerte, mit denen die Einhaltung der SLOs sichergestellt wird. Dazu können etwa die Überwachung des Lichtstroms, des Stromflusses zu jeder Lampe oder geringfügiger Änderungen der Lampenposition gehören, die dadurch entstehen, dass Benutzer gegen die Lampen stoßen oder sie verschieben. In Systemen zur Anwendungsbereitstellung könnten dies beispielsweise CPU-Auslastung, Dauer von API-Aufrufen und Datenbankabfragen usw. sein. Es liegt an den Site Reliability Engineers, die SLI-Messgrößen zu definieren, die sich auf die geschäftlichen SLOs auswirken, und festzulegen, welche Maßnahmen durch Anpassung von Betriebsrichtlinien und Konfiguration ergriffen werden, wenn bestimmte Schwellenwerte unterschritten werden.
Der Nutzen von SRE in modernen Unternehmensarchitekturen
Die Messgrößen, Schwellenwerte und Reaktionen bilden die Schnittstelle zwischen SRE und den anderen Bereichen einer modernen Unternehmensarchitektur, die für die Anwendungsbereitstellung eines digitalen Unternehmens konzipiert ist. Betriebsdaten – Telemetriedaten – bilden die Grundlage für die Beobachtbarkeit der von SRE definierten Messgrößen und Schwellenwerte. Automatisierung ist der kombinierte Einsatz von Tools, Technologien und Verfahren, der es Site Reliability Engineers ermöglicht, definierte Reaktionen mit weniger manuellem Aufwand zu skalieren und so die SLOs eines digitalen Dienstes effizient zu erfüllen. Die Systemzuverlässigkeit digitaler Dienste wiederum erhöht die Wahrscheinlichkeit einer positiven Benutzererfahrung mit Ihrem digitalen Unternehmen.
Noch einmal zusammengefasst: SRE fungiert als Brücke, die die Anstrengungen von IT und Geschäftsbereichen bündelt. Dabei werden alle verfügbaren Tools, Technologien und Prozesse eingesetzt, um nicht nur sicherzustellen, dass Systeme „in Betrieb“ sind, sondern auch, dass sie zuverlässig funktionieren. Durch die Integration von SRE in die Unternehmensarchitektur können Unternehmen ihre Systemanwendungen proaktiv betreuen und Leistungseinbrüche oder Unregelmäßigkeiten früher erkennen. Site Reliability Engineers können diese dann untersuchen und beheben, bevor die Benutzererfahrung beeinträchtigt wird.
Wenn Sie erfahren möchten, wie Sie SRE in Ihr Unternehmen integrieren und den Transformationsprozess hin zu einem effizienten und skalierbaren digitalen Unternehmen unterstützen können, lesen Sie „The Need for Speed“, ein Kapitel von Julia Renouard in unserem bei O’Reilly erschienenen Buch „Enterprise Architecture for Digital Business“.
Ähnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.