Was die Architektur uns über selbstheilende Systeme lehren kann

DevOps-Teams und Site Reliability Engineers (SREs) beschäftigen sich täglich mit Code. Dabei lernen sie, ihre Welt zu hinterfragen, scharfsinnige Beobachtungen anzustellen und unerwartete Verbindungen herzustellen. Schließlich ist die Softwareentwicklung, obwohl sie von Natur aus sehr logisch und mathematisch ist, zumindest teilweise eine Kunstform. 

Nicht überzeugt von dieser Aussage? Betrachten Sie die Parallelen zwischen den bemerkenswertesten architektonischen Meisterleistungen der Geschichte und moderner Softwaretechnik. Es ist ein treffender Vergleich: Genau wie Software Engineering verwendet Architektur komplexe mathematische Berechnungen, um etwas Schönes zu schaffen. Und in beiden Disziplinen kann eine kleine Fehlkalkulation zu erheblichen Konsequenzen führen. Faszinierenderweise sind viele berühmte Architekturfehler analog zu Problemen, die wir im Code finden.

Denken Sie daran, Inspiration ist überall – solange Sie wissen, wo Sie suchen müssen. Hier sind ein paar Lektionen, die Softwareentwickler aus architektonischen Offenbarungen im Laufe der Jahrhunderte lernen können, insbesondere in Bezug auf die Zukunft von Selbstheilungssystemen.

Lektion 1: Randfälle werden immer Systemschwachstellen ausnutzen

Der Citicorp Tower – heute 601 Lexington genannt – wurde 1977 in New York City fertiggestellt und war damals das siebthöchste Gebäude der Welt. Das hochmoderne Design des Wolkenkratzers umfasste drei über 100 Fuß hohe Stelzen. Es war ein Wunder bei der Fertigstellung. Ein Student entdeckte jedoch bald etwas Erschütterndes: Starke Winde die Integrität des Gebäudes gefährden könnten. Insbesondere wenn starke Viertelwinde die Ecken des Citicorp Tower trafen, drohte die Struktur einzustürzen – ein Wortwörtlich Rand Fall.

Die Wahrscheinlichkeit, dass der Turm jedes Jahr einstürzt, liegt bei eins zu sechzehn. Diese Chancen mögen jemanden dazu verleiten, an einem Spieltisch zu sitzen, aber die Aussichten für die Architekten und Statiker hinter dem Citicorp Tower waren düster. Glücklicherweise konnten die Techniker die Schraubverbindungen des Gebäudes verstärken. Katastrophe wurde vermieden.

Die Bauingenieure wussten, dass der Citicorp Tower irgendwann einem Wind ausgesetzt sein würde, der stark genug wäre, um seine Peilung zu beeinträchtigen. Ebenso wissen erfahrene Softwareingenieure, dass robustes Application Performance Monitoring (APM) und Ereignismanagement nicht ausreichen, um ein System vor den unvermeidlichen Grenzfällen zu schützen. Das liegt daran, dass statische Systeme ohne maschinelles Lernen (ML) Fähigkeiten können unerwartete und ungeplante neue Situationen, wie z. B. querende Winde, nicht bewältigen. Wenn Sie sich ausschließlich auf Überwachungstools verlassen, muss ein menschlicher Administrator Fehler entschlüsseln und den Incident-Management-Prozess eskalieren.

Um die mittlere Zeit bis zur Wiederherstellung (MTTR)/mittlere Zeit bis zur Erkennung (MTTD) zu reduzieren, müssen DevOps-Teams die hohe Wahrscheinlichkeit von Grenzfällen akzeptieren und daran arbeiten, präventiv selbstlernende Lösungen bereitzustellen. Diese Lektion geht einen langen Weg, da Voraussicht im Ingenieurwesen von entscheidender Bedeutung ist.

Lektion 2: „Das Flugzeug bauen, während es fliegt“ erzeugt einen endlosen Kreislauf

Tragische Ereignisse haben mehrere geliefert die wichtigsten Lektionen der Luftfahrtgeschichte. Als ein Flugzeug mitten im Flug eine immense Dekompression erlitt und 1954 abstürzte, stellten die Ingenieure fest, dass quadratische Passagierfenster ein unnötiger Stresspunkt waren. Fortan, Flugzeuge waren mit abgerundeten Fenstern ausgestattet. Brände an Bord führten zu neuen Sitzordnungen, bei denen die Evakuierung erleichtert wurde. Diese Veränderungen haben unzählige Leben gerettet.

In vielen Branchen – einschließlich der Luftfahrt – gibt es keine Möglichkeit, ein Produkt umfassend einem Stresstest zu unterziehen. Wie bereits erwähnt, sind Grenzfälle unvermeidlich. Die wichtigste Erkenntnis hier ist, dass Softwareingenieure die Schwachstellen ihres Systems beachten müssen, wenn sie sich zeigen. Von dort aus müssen sie diese zielführend ansprechen. Dazu sind zwei Dinge erforderlich: (1) die Identifizierung und Verfolgung der richtigen Key Performance Indicators (KPIs) und (2) die Investition von Zeit und Ressourcen in die Verbesserung von Systemen auf der Grundlage relevanter Metriken.

Das durchschnittliche Engineering-Team investiert in 16 bis 40 Überwachungstools, verfehlt jedoch oft die Marke, an der Metriken Erfolg zeigen. Weniger als 15 % der Teams verfolgen die MTTD, sodass sie 66 % des Incident-Lebenszyklus verpassen. Und ein Viertel der Teams berichten ihre Service Level Agreements (SLAs) nicht erfüllen trotz erheblicher Investitionen in die Verfügbarkeitsverfolgung. Dies zeigt uns, dass die Datenerfassung eine gründliche, systematische Analyse erfordert, um sie zu schneiden – Punktlösungen reichen nicht mehr aus.

Softwareingenieure, DevOps-Teams und SREs müssen Prozesse und Tools priorisieren, die aus überwältigenden Mengen an Informationen zur Verfügbarkeit Wert ziehen. Anstatt nur einen kritischen Fehler zu beobachten, müssen sie sich eine Seite aus dem Buch eines Luftfahrtingenieurs nehmen und schnell wichtige Entscheidungen treffen. Das Geheimnis dafür liegt in der KI.

Lektion 3: KI ist ein grundlegender Baustein für selbstheilende Systeme

Ein vollständig autonomes, perfekt funktionierendes, selbstheilendes System ist ideal für jeden Softwareentwickler. Systeme, die sich selbst patchen, sind gut für die Kundenzufriedenheit, da sie kostspielige Ausfallzeiten für Verbraucher vermeiden. Darüber hinaus sind sie für IT-Service-Management-Funktionen (ITSM) von großem Nutzen, da sie den Bedarf an mühsamer Ticketverwaltung erheblich reduzieren. Der Aufbau eines solchen Systems erfordert mehrere Komponenten, von denen viele derzeit unerreichbar sind. Aber wir sind einer Selbstheilungsrealität näher, als manche vielleicht glauben.

Der Mangel an weit verbreiteter KI-Akzeptanz bleibt die größte Hürde, vor der selbstheilende Systeme heute stehen. Obwohl viele Unternehmen rudimentäre KI- oder ML-basierte Tools eingeführt haben, ist die Integrität dieser Tools fraglich. Das heißt, viele Ingenieure beschäftigen sich damit Künstliche Intelligenz für den IT-Betrieb (AIOps)-Technologien, die einer regelbasierten Automatisierungslogik statt autonomen KI-Algorithmen folgen. Der Unterschied mag winzig erscheinen, aber in der Praxis ist es der Unterschied zwischen Stunden verlorener Produktivität und Millionen möglicher Verluste.

Die Sache ist die, dass regelbasierte AIOps-Tools die Interaktionen zwischen unterschiedlichen Punktlösungen analysieren und wahrscheinlich häufige Datenfehler identifizieren können. Automatisierungsbasierte Systeme können jedoch weder die Entwicklung völlig neuer Fehler im Laufe der Zeit verarbeiten, noch können sie neuartige Fehlfunktionen in Daten vorhersagen. Das liegt daran, dass die menschlichen Administratoren, die diese Funktionen codieren, das System auffordern, einem zu folgen wenn dies, dann das logisches Muster. Wirklich effiziente AIOps-Tools mindern Fehler, die an allen vier klassischen Telemetriepunkten auftreten – von der Erkennung bis zur Auflösung –, indem sie neue und problematische Muster klassifizieren, bevor menschliche Techniker sich ihrer Existenz überhaupt bewusst sind. 

Während wir auf die warten bevorstehende dritte KI-Welle, kommt diese Version von AIOps selbstheilenden Systemen am nächsten. Es wird interessant sein zu verfolgen, wie aktuelle AIOps-Anwendungen in die Zukunft der KI einfließen, die eine vollständig realisierte Automatisierung und unabhängige Denkmöglichkeiten umfassen wird. Vielleicht ernten dann auch Bauingenieure die Früchte eines KI-basierten, selbstheilenden Systems.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/