Entgegen Betteridges Gesetz der Überschriften lautet die kurze Antwort: Ja. Doch wie bei allem, was heutzutage mit Technologie zu tun hat, ist die ausführliche Antwort etwas komplizierter.
DevOps ist meiner Meinung nach inzwischen in praktisch allen Branchen recht weit verbreitet. Zwar übernimmt nicht jedes Unternehmen jeden Aspekt dieses Ansatzes oder hält sich mit demselben Eifer an seine Prinzipien wie beispielsweise Netflix, doch DevOps ist definitiv ein Trend, der sich durchsetzt.
Auch wenn dies kein direkter Beleg ist: Als wir für unseren Bericht „State of Application Delivery 2018“ die mehr als 3.000 Befragten danach fragten, wie sich die digitale Transformation auf ihre Entscheidungen rund um Anwendungen auswirkt, lauteten zwei der drei häufigsten Antworten: „Automatisierung und Orchestrierung von IT-Systemen und -Prozessen“ sowie „Veränderung der Art und Weise, wie wir Anwendungen entwickeln (zum Beispiel durch den Umstieg auf agile Methoden)“. Für mich sind beide Antworten indirekte Reaktionen darauf, dass zumindest Teile eines DevOps-Ansatzes für die Entwicklung und Bereitstellung von Anwendungen in modernen Architekturen übernommen werden.
Wenn Unternehmen also einige der mit DevOps verbundenen Tools und Techniken einsetzen, könnte man annehmen, dass sie auch andere übernehmen. Eine davon könnte sogar sein (dramatische Musik setzt ein): Systeme so zu konzipieren, dass sie ausfallen dürfen.
Nun, diese Formulierung ist etwas ungenau, denn niemand setzt sich hin und entwickelt Systeme mit dem Ziel, dass sie ausfallen. Was man jedoch tut, ist, Systeme so zu konzipieren, dass sie resilient gegenüber Ausfällen sind. Das bedeutet beispielsweise: Wenn eine Instanz (ein Server) abstürzt, sollte das System die Situation automatisch bewältigen können, indem es die ausgefallene Instanz entfernt und eine neue startet, die ihren Platz einnimmt.
Voilà! Für Ausfälle konzipiert.
Und obwohl dies sicherlich eine wünschenswerte Reaktion ist – insbesondere, wenn ein System einer hohen Last und Nachfrage ausgesetzt ist –, birgt dieser Ansatz ein Risiko, das berücksichtigt und anschließend hoffentlich behoben werden muss.
Betrachten wir die Cloudflare-Sicherheitslücke von Anfang 2017. Cloudflare – das in seinem eigenen Bericht über das Problem erfreulich transparent war – erklärt, dass es sich im Wesentlichen um ein Speicherleck handelte, das potenziell zum Abfluss von Daten führen konnte und durch einen Fehler in einer Erweiterung eines HTTP-Parsers verursacht wurde. Kurz gesagt: Der Fehler verursachte ein Speicherleck, das wiederum Instanzen zum Absturz brachte. Diese Instanzen wurden beendet und neu gestartet, denn schließlich waren sie auf Ausfallsicherheit ausgelegt.
Nur fürs Protokoll: Dies ist kein Beitrag nach dem Motto „Cloudflare wegen eines Fehlers fertigmachen“. Als Entwickler kann ich sehr gut nachempfinden, wie es ist, wenn die eigenen Fehler derart öffentlich offengelegt werden. Weniger Verständnis habe ich für Situationen, in denen kaum Wert darauf gelegt wird, herauszufinden, warum etwas abstürzt, Speicherlecks verursacht oder schlichtweg nicht funktioniert.
Und genau darum geht es im heutigen Beitrag. Denn manchmal führt die DevOps-Philosophie bei ihren Anhängern zu einer allzu sorglosen Haltung gegenüber der Untersuchung von Fehlern im Nachhinein.
Es ist völlig legitim, auf den Ausfall eines Dienstes oder einer App zu reagieren, indem man den Dienst beendet und neu startet, um die Verfügbarkeit sicherzustellen – solange man den Absturz anschließend untersucht, um seine Ursache zu ermitteln. Apps stürzen nicht grundlos ab. Wenn eine App ausfällt, hat etwas den Absturz verursacht. In neun von zehn Fällen handelt es sich etwa um einen nicht ausnutzbaren Fehler. Nichts, worüber man einen Blogbeitrag schreiben müsste. Doch wenn es sich beim zehnten Mal um eine schwerwiegende Schwachstelle handelt, die nur darauf wartet, ausgenutzt zu werden, lohnt sich der vermeintlich vergebliche Aufwand in den anderen neun Fällen. Denn darüber sollte man einen Blogbeitrag schreiben.
Es ist nicht vertretbar, dies zu ignorieren.
Die Überwachung von Fehlern und anderen Problemen sowie entsprechende Warnmeldungen sind ebenfalls zentrale Bestandteile eines umfassenden DevOps-Programms. Dafür steht das „S“ in CAMS, den Grundpfeilern eines ganzheitlichen DevOps-Ansatzes: Culture, Automation, Measurement und Sharing. Damon und John (die das Akronym 2010 prägten) sprachen dabei nicht nur über Pizza und Bier (obwohl sich damit das „C“ für Culture in DevOps gut fördern lässt). Es geht auch um Daten und den Zustand von Systemen. Es geht darum, sicherzustellen, dass diejenigen, denen dieses Wissen nützt, auch informiert sind. Dazu gehören auch Systemausfälle.
Ein Fehler – insbesondere ein Absturz – sollte nicht unbemerkt bleiben. Wenn ein System in der Pipeline abstürzt, sollte jemand davon erfahren und der Sache nachgehen. Dies zu ignorieren, stellt ein Sicherheitsrisiko dar. Schlimmer noch: Es handelt sich um ein vermeidbares Risiko, denn es geht um Ihre Umgebung, Ihre Systeme und Ihren Code. Sie haben die vollständige Kontrolle und somit keine Entschuldigung dafür, es zu ignorieren.
Kurz gesagt: Ja, „Build to Fail“ kann Ihre Anwendungen – und Ihr Unternehmen – Sicherheitsrisiken aussetzen. Die gute Nachricht ist, dass sich diese Risiken vollständig beherrschen lassen, wenn Sie sicherstellen, dass diese Philosophie nicht nur auf dem Papier „Built to Fail“ lautet, in der Praxis aber zu „Built to Ignore a Fail“ verkommt.
Achten Sie auf Abstürze – selbst wenn Sie die betroffenen Systeme neu starten, um eine hohe Verfügbarkeit zu gewährleisten. So bewahren Sie sich (und Ihr Unternehmen) womöglich davor, aus den völlig falschen Gründen auf Twitter zum Trend zu werden.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...