Nun zum Hype-Thema DevOps. Der Förderer für die kontinuierliche Integration und Bereitstellung von CI / CD wird von jedem implementiert, der Lust dazu hat. Die meisten achten jedoch nicht immer darauf, die Zuverlässigkeit von Informationssystemen in verschiedenen Phasen der CI / CD-Pipeline sicherzustellen. In diesem Artikel möchte ich über meine Erfahrungen bei der Automatisierung von Softwarequalitätsprüfungen und der Implementierung möglicher Szenarien für deren „Selbstheilung“ sprechen.

Quelle

Ich arbeite als Ingenieur in der Abteilung IT Services Management bei LANIT-Integration . Mein Kernbereich ist die Implementierung verschiedener Systeme zur Überwachung der Leistung und Verfügbarkeit von Anwendungen. Ich kommuniziere häufig mit IT-Kunden aus verschiedenen Marktsegmenten über aktuelle Fragen der Überwachung der Qualität ihrer IT-Services. Die Hauptaufgabe besteht darin, die Freigabezykluszeit zu minimieren und die Häufigkeit ihrer Freigabe zu erhöhen. Das ist natürlich alles gut: mehr Releases - mehr neue Funktionen - zufriedenere Benutzer - mehr Gewinn. Aber in Wirklichkeit läuft nicht immer alles gut. Bei sehr hohen Bereitstellungsraten stellt sich sofort die Frage nach der Qualität unserer Releases. Selbst bei einer vollautomatisierten Pipeline ist eines der größten Probleme die Übertragung von Diensten vom Test in die Produktion, was sich nicht auf die Verfügbarkeit und die Benutzerinteraktion mit der Anwendung auswirkt.

Aufgrund der Ergebnisse zahlreicher Kundengespräche kann ich sagen, dass die Qualitätskontrolle von Releases, das Problem der Anwendungszuverlässigkeit und die Möglichkeit ihrer "Selbstheilung" (z. B. Rollback auf eine stabile Version) in verschiedenen Phasen der CI / CD-Pipeline zu den spannendsten und relevantesten Themen gehören.


Vor kurzem habe ich selbst auf Kundenseite gearbeitet - im Support-Service für Online-Banking-Anwendungen. Die Architektur unserer Anwendung verwendete eine große Anzahl selbstgeschriebener Mikrodienste. Das Traurigste ist, dass nicht alle Entwickler mit dem hohen Entwicklungstempo, der Qualität einiger Microservices, fertig wurden, was zu lächerlichen Spitznamen für sie und ihre Entwickler führte. Es gab Geschichten darüber, aus welchen Materialien diese Produkte hergestellt werden.

"Erklärung des Problems"

Die hohe Häufigkeit von Releases und eine große Anzahl von Microservices erschweren das Verständnis der gesamten Anwendung sowohl in der Testphase als auch in der Betriebsphase. Änderungen treten ständig auf und es ist sehr schwierig, sie ohne gute Überwachungswerkzeuge zu kontrollieren. Oft sitzen Entwickler nach einer nächtlichen Veröffentlichung am Morgen auf einem Pulverfass und warten darauf, dass nichts kaputt geht, obwohl in der Testphase alle Überprüfungen erfolgreich waren.

Es gibt noch einen Punkt. In der Testphase wird die Funktionsfähigkeit der Software überprüft: die Implementierung der Hauptfunktionen der Anwendung und das Fehlen von Fehlern. Qualitative Leistungsschätzungen fehlen entweder oder berücksichtigen nicht alle Aspekte der Anwendung und der Integrationsschicht. Einige Metriken werden möglicherweise überhaupt nicht überprüft. Wenn eine Störung in einer produktiven Umgebung auftritt, findet die Abteilung für technischen Support daher erst heraus, wenn echte Benutzer anfangen, sich zu beschweren. Ich möchte die Auswirkungen von Software geringer Qualität auf Endbenutzer minimieren.

Eine der Lösungen besteht darin, Softwarequalitätskontrollprozesse in verschiedenen Phasen der CI / CD-Pipeline zu implementieren und verschiedene Skripte hinzuzufügen, um das System im Falle eines Unfalls wiederherzustellen. Denken Sie auch daran, dass wir DevOps haben. Das Unternehmen erwartet, so schnell wie möglich ein neues Produkt zu erhalten. Daher müssen alle unsere Prüfungen und Skripte automatisiert werden.

Die Aufgabe ist in zwei Komponenten unterteilt:

• Qualitätskontrolle von Baugruppen in der Testphase (um den Prozess des Auffangens minderwertiger Baugruppen zu automatisieren);
• Software-Qualitätskontrolle in der Produktionsumgebung (automatische Problemerkennungsmechanismen und mögliche Szenarien zur Selbstheilung).

Tool zum Überwachen und Sammeln von Metriken

Um die gestellten Aufgaben zu realisieren, ist ein Überwachungssystem erforderlich, das Probleme erkennen und in verschiedenen Phasen der CI / CD-Pipeline an Automatisierungssysteme übertragen kann. Ein positiver Punkt wird auch sein, wenn dieses System nützliche Metriken für verschiedene Teams bereitstellt: Entwicklung, Test, Betrieb. Und ganz wunderbar, wenn geschäftlich.

Zum Sammeln von Metriken können Sie eine Kombination verschiedener Systeme (Prometheus, ELK Stack, Zabbix usw.) verwenden. Meiner Meinung nach eignen sich APM-Lösungen ( Application Performance Monitoring ) jedoch am besten für diese Aufgaben, was Ihr Leben erheblich vereinfachen kann.

Im Rahmen meiner Arbeit im Escortservice begann ich ein ähnliches Projekt mit der APM-Klassenlösung von Dynatrace durchzuführen. Als Integrator kenne ich den Markt für Überwachungssysteme sehr gut. Meine subjektive Meinung: Dynatrace eignet sich am besten für solche Aufgaben.
Die Dynatrace-Lösung bietet eine horizontale Anzeige jeder Benutzeroperation mit einem tiefen Detaillierungsgrad bis hin zur Ebene der Codeausführung. Sie können die gesamte Interaktionskette zwischen verschiedenen Informationsdiensten verfolgen: von Front-End-Ebenen von Web- und Mobilanwendungen über Back-End-Anwendungsserver, Integrationsbus bis hin zu einem bestimmten Aufruf der Datenbank.

Quelle Automatische Erstellung aller Abhängigkeiten zwischen Systemkomponenten

Quelle Automatische Erkennung und Erstellung eines Pfades für einen Servicevorgang

Denken Sie auch daran, dass wir in verschiedene Automatisierungstools integrieren müssen. Hier verfügt die Lösung über eine praktische API, mit der Sie verschiedene Metriken und Ereignisse senden und empfangen können.

Als Nächstes werden wir uns eingehender mit der Lösung von Aufgaben mit dem Dynatrace-System befassen.

Aufgabe 1. Automatisierung der Qualitätskontrolle von Baugruppen in der Testphase

Die erste Aufgabe besteht darin, Probleme so früh wie möglich in den Phasen der Anwendungsbereitstellungspipeline zu finden. Nur "gute" Code-Builds sollten die Produktumgebung erreichen. Zu diesem Zweck sollten in der Testphase zusätzliche Monitore in Ihre Pipeline aufgenommen werden, um die Qualität Ihrer Dienste zu überprüfen.



Schauen wir uns die Schritte an, um dies zu implementieren und diesen Prozess zu automatisieren:

Quelle

Die Abbildung zeigt den Ablauf der automatisierten Schritte zur Qualitätskontrolle von Software:

1. Bereitstellung eines Überwachungssystems (Installation von Agenten);
2. Definition von Ereignissen zur Qualitätsbewertung Ihrer Software (Metriken und Schwellenwerte) und deren Übertragung an das Überwachungssystem;
3. Lastgenerierung und Leistungstests;
4. Sammeln von Leistungs- und Verfügbarkeitsdaten in einem Überwachungssystem;
5. Übertragen von Testdaten basierend auf Ereignissen zur Bewertung der Softwarequalität vom Überwachungssystem zum CI / CD-System. Automatische Montageanalyse.

Schritt 1. Stellen Sie ein Überwachungssystem bereit

Sie müssen zuerst die Agenten in Ihrer Testumgebung installieren. Gleichzeitig verfügt die Dynatrace-Lösung über eine nette Funktion: Sie verwendet den OneAgent Universal Agent, der auf der Betriebssysteminstanz (Windows, Linux, AIX) installiert ist, erkennt Ihre Dienste automatisch und beginnt mit der Erfassung von Überwachungsdaten. Sie müssen nicht für jeden Prozess einen Agenten separat konfigurieren. Ähnliches gilt für Cloud- und Containerplattformen. Gleichzeitig können Sie auch die Installation von Agenten automatisieren. Dynatrace passt perfekt zum Konzept der „Infrastruktur als Code“ ( Infrastruktur als Code oder IaC ): Es gibt vorgefertigte Skripte und Anweisungen für alle gängigen Plattformen. Betten Sie den Agenten in die Konfiguration Ihres Dienstes ein. Wenn Sie ihn bereitstellen, erhalten Sie sofort einen neuen Dienst mit einem bereits ausgeführten Agenten.

Schritt 2. Identifizieren Sie Ihre Ereignisse zur Bewertung der Softwarequalität

Jetzt müssen Sie die Liste der Services und Geschäftsvorgänge festlegen. Es ist wichtig, genau die Benutzervorgänge zu berücksichtigen, die für Ihren Service geschäftskritisch sind. Hier empfehle ich die Beratung von Geschäfts- und Systemanalysten.

Als Nächstes müssen Sie festlegen, welche Metriken für jede der Ebenen in die Überprüfung einbezogen werden sollen. Dies können beispielsweise Laufzeit (mit Trennung nach Durchschnitt, Median, Perzentil usw.), Fehler (logisch, Dienst, Infrastruktur usw.) und verschiedene Infrastrukturmetriken (Speicherheap, Garbage Collector, Thread-Anzahl usw.) sein.

Zur Automatisierung und Benutzerfreundlichkeit führt das DevOps-Team das Konzept der „Überwachung als Code“ ein. Damit meine ich, dass ein Entwickler / Tester eine einfache JSON-Datei schreiben kann, die die Indikatoren für die Softwarequalitätskontrolle definiert.

Schauen wir uns ein Beispiel für eine solche JSON-Datei an. Objekte aus der Dynatrace-API werden als Schlüssel / Wert-Paar verwendet ( eine Beschreibung der API finden Sie in der Dynatrace-API ).

{    "timeseries": [    {      "timeseriesId": "service.ResponseTime",      "aggregation": "avg",      "tags": "Frontend",      "severe": 250000,      "warning": 1000000    },    {      "timeseriesId": "service.ResponseTime ",      "aggregation": "avg",      "tags": "Backend",      "severe": 4000000,      "warning": 8000000    },    {      "timeseriesId": "docker.Container.Cpu",      "aggregation": "avg",      "severe": 50,      "warning": 70    }  ] } 

Die Datei besteht aus einer Reihe von Zeitreihendefinitionen:

• timeseriesId - Metrik überprüft, z. B. Antwortzeit, Fehleranzahl, verwendeter Speicher usw.;
• Aggregation - Die Ebene der Aggregation von Metriken, in unserem Fall Durchschnitt, aber Sie können alles verwenden, was Sie benötigen (Durchschnitt, Min, Max, Summe, Anzahl, Perzentil).
• Tags - Ein Objekt-Tag im Überwachungssystem, oder Sie können eine bestimmte Objektkennung angeben.
• schwerwiegend und warnend - Diese Indikatoren steuern die Schwellenwerte unserer Metriken. Wenn der Wert der Tests den schwerwiegenden Schwellenwert überschreitet, wird unsere Baugruppe als nicht erfolgreich markiert.

Die folgende Abbildung zeigt ein Beispiel für die Verwendung solcher Mülleimer.

Quelle

Schritt 3. Lastgenerierung

Nachdem wir die Qualitätsstufen unseres Service ermittelt haben, muss eine Testlast generiert werden. Sie können jedes der für Sie geeigneten Testwerkzeuge verwenden, z. B. Jmeter, Selen, Neotys, Gatling usw.

Mit dem Dynatrace-Überwachungssystem können Sie verschiedene Metadaten aus Ihren Tests erfassen und erkennen, welcher Test sich auf welchen Release-Zyklus und welchen Service bezieht. Es wird empfohlen, den Test-HTTP-Anforderungen zusätzliche Header hinzuzufügen.

Die folgende Abbildung zeigt ein Beispiel, in dem unter Verwendung des optionalen X-Dynatrace-Test-Headers markiert wird, dass sich dieser Test auf das Testen des Vorgangs zum Hinzufügen eines Artikels zum Warenkorb bezieht.

Quelle

Wenn Sie jeden Auslastungstest ausführen, senden Sie zusätzliche Kontextinformationen mithilfe der Ereignis-API vom CI / CD-Server an Dynatrace. Somit kann das System untereinander zwischen verschiedenen Tests unterscheiden.

Quelle Ereignis im Überwachungssystem über den Start von Lasttests

Schritt 4-5. Sammeln Sie Leistungsdaten und übertragen Sie Daten an ein CI / CD-System

Zusammen mit dem generierten Test wird dem Überwachungssystem ein Ereignis über die Notwendigkeit übertragen, Daten zur Überprüfung der Servicequalitätsindikatoren zu sammeln. Unsere JSON-Datei wird ebenfalls angezeigt, in der Schlüsselmetriken definiert sind.

Ein Ereignis über die Notwendigkeit, die Qualität der auf dem CI / CD-Server generierten Software für das Senden an das Überwachungssystem zu überprüfen

In unserem Beispiel heißt das Qualitätskontrollereignis perfSigDynatraceReport (Performance_Signature ) - dies ist ein fertiges Plug-In für die Integration mit Jenkins, das von den Mitarbeitern von T-Systems Multimedia Solutions entwickelt wurde. Jedes Ereignis zum Start des Tests enthält Informationen zu Service, Build-Nummer und Testzeit. Das Plugin sammelt Leistungswerte während der Montage, wertet sie aus und vergleicht das Ergebnis mit früheren Baugruppen und nicht funktionalen Anforderungen.

Ereignis im Überwachungssystem über den Beginn der Qualitätskontrolle der Montage. Quelle

Nach Abschluss des Tests werden alle Metriken zur Bewertung der Softwarequalität zurück an das kontinuierliche Integrationssystem übertragen, z. B. Jenkins, das einen Bericht über die Ergebnisse erstellt.

Das Ergebnis der Baugruppenstatistik auf dem CI / CD-Server. Quelle

Für jede einzelne Baugruppe werden Statistiken für jede Metrik angezeigt, die wir während des gesamten Tests festgelegt haben. Wir sehen auch, ob es bei bestimmten Schwellenwerten Verstöße gab (Warnung und schwere Thrasholds). Basierend auf den aggregierten Metriken wird die gesamte Baugruppe als stabil, instabil oder fehlgeschlagen markiert. Der Einfachheit halber können Sie auch Indikatoren hinzufügen, um die aktuelle Baugruppe mit der vorherigen im Bericht zu vergleichen.

Zeigen Sie detaillierte Baugruppenstatistiken auf dem CI / CD-Server an. Quelle

Detaillierter Vergleich zweier Baugruppen

Bei Bedarf können Sie zur Dynatrace-Oberfläche gehen und dort die Statistiken für jede Ihrer Baugruppen genauer betrachten und miteinander vergleichen.

Vergleich der Baugruppenstatistik in Dynatrace. Quelle

Schlussfolgerungen

Als Ergebnis erhalten wir den Service „Monitoring as a Service“, der in der Pipeline der kontinuierlichen Integration automatisiert wird. Der Entwickler oder Tester muss nur die Liste der Metriken in der JSON-Datei ermitteln, und alles andere geschieht automatisch. Wir erhalten eine transparente Qualitätskontrolle von Releases: alle Benachrichtigungen über Leistung, Ressourcenverbrauch oder Architekturregressionen.

Aufgabe 2. Automatisierung der Softwarequalitätskontrolle in einer Produktionsumgebung

Daher haben wir das Problem gelöst, wie der Überwachungsprozess in der Testphase in Pipeline automatisiert werden kann. Auf diese Weise minimieren wir den Prozentsatz minderwertiger Baugruppen, die die Lebensmittelumgebung erreichen.

Aber was tun, wenn schlechte Software immer noch an den Point of Sale kommt oder einfach etwas kaputt geht? Für die Utopie wollten wir Mechanismen zur automatischen Erkennung von Problemen, und wenn möglich, würde das System selbst zumindest nachts seine Arbeitsfähigkeit wiederherstellen.

Zu diesem Zweck bieten wir in Analogie zum vorherigen Abschnitt automatische Softwarequalitätsprüfungen in der Produktionsumgebung an und legen Skripte zur Selbstheilung des Systems darunter.


Automatische Korrektur als Code

Die meisten Unternehmen verfügen bereits über eine gesammelte Wissensbasis zu verschiedenen Arten von häufig auftretenden Problemen und eine Liste von Maßnahmen, um diese zu beheben, z. B. Neustarten von Prozessen, Bereinigen von Ressourcen, Zurücksetzen von Versionen, Wiederherstellen falscher Konfigurationsänderungen, Erhöhen oder Verringern der Anzahl von Komponenten in einem Cluster, Wechseln eines blauen oder grünen Umrisses und andere

Trotz der Tatsache, dass viele der Teams, mit denen ich kommuniziere, diese Anwendungsfälle seit vielen Jahren kennen, haben nur wenige über ihre Automatisierung nachgedacht und in sie investiert.

Wenn Sie darüber nachdenken, dann ist bei der Implementierung von Prozessen zur Selbstheilung des Anwendungszustands nichts besonders Kompliziertes. Sie müssen die bekannten Arbeitsszenarien Ihrer Administratoren in Form von Codeskripten (das Konzept der „Autokorrektur als Code“) darstellen, die Sie im Voraus für jeden einzelnen Fall geschrieben haben. Automatische Reparaturszenarien sollten die Hauptursache des Problems beheben. Sie legen selbst die richtigen Maßnahmen zur Reaktion auf Vorfälle fest.

Jede Metrik Ihres Überwachungssystems kann als Auslöser für die Ausführung eines Skripts dienen. Hauptsache, diese Metriken bestimmen genau, dass alles schlecht ist, da ich in einer produktiven Umgebung keine Fehlalarme erhalten möchte.

Sie können jedes System oder jede Reihe von Systemen verwenden: Prometheus, ELK Stack, Zabbix usw. Aber ich werde einige Beispiele geben, die auf der APM-Lösung basieren (Dynatrace wird wieder ein Beispiel sein), die Ihnen auch das Leben erleichtern werden.

Erstens gibt es alles, was die Bedienbarkeit in Bezug auf die Anwendung betrifft. Die Lösung bietet Hunderte von Metriken auf verschiedenen Ebenen, die Sie als Auslöser verwenden können:

• Benutzerebene (Browser, mobile Anwendungen, IoT-Geräte, Benutzerverhalten, Konvertierung usw.);
• Servicelevel und Betrieb (Leistung, Verfügbarkeit, Fehler usw.);
• Ebene der Anwendungsinfrastruktur (Host-Betriebssystemmetriken, JMX, MQ, Webserver usw.);
• Plattformebene (Virtualisierung, Cloud, Container usw.).

Überwachungsebenen in Dynatrace. Quelle

Zweitens verfügt Dynatrace, wie bereits erwähnt, über eine offene API, die die Integration in verschiedene Systeme von Drittanbietern sehr bequem macht. Senden Sie beispielsweise eine Benachrichtigung an das Automatisierungssystem, wenn die Steuerparameter überschritten werden.

Unten finden Sie ein Beispiel für die Interaktion mit Ansible.

Quelle

Im Folgenden werde ich einige Beispiele dafür geben, welche Automatisierung genau durchgeführt werden kann. Dies ist nur ein Teil der Fälle. Die Auflistung in Ihrer Umgebung kann nur durch Ihre Vorstellungskraft und die Funktionen Ihrer Überwachungstools eingeschränkt werden.

1. Fehlerhafte Bereitstellung - Rollback der Version

Selbst wenn wir alle in einer Testumgebung sehr gut testen, besteht immer noch die Möglichkeit, dass eine neue Version Ihre Anwendung in der Produktumgebung zerstört. Der gleiche menschliche Faktor wurde nicht aufgehoben.

In der nächsten Abbildung sehen wir, dass die Ausführungszeit von Operationen auf dem Dienst stark ansteigt. Der Beginn dieses Sprungs fällt mit der Bereitstellungszeit für die Anwendung zusammen. Wir übertragen alle diese Informationen als Ereignisse an das Automatisierungssystem. Wenn sich die Servicefreundlichkeit des Dienstes nach Ablauf der von uns angegebenen Zeit nicht normalisiert, wird automatisch ein Skript aufgerufen, das die Version auf die alte zurücksetzt.

Leistungsminderung nach der Bereitstellung. Quelle

2. Ressourcenbelastung zu 100% - Fügen Sie dem Routing einen Knoten hinzu

Im folgenden Beispiel stellt das Überwachungssystem fest, dass eine der Komponenten eine 100% ige CPU-Auslastung aufweist.

CPU-Auslastung 100%

Für dieses Ereignis sind verschiedene Szenarien möglich. Beispielsweise prüft das Überwachungssystem zusätzlich, ob der Mangel an Ressourcen mit einer Erhöhung der Belastung des Dienstes verbunden ist. Wenn ja, wird ein Skript ausgeführt, das den Knoten automatisch zum Routing hinzufügt und dadurch das gesamte System wiederherstellt.

Skalieren von Knoten nach einem Vorfall

3. Mangel an Festplattenspeicher - Datenträgerbereinigung

Ich denke, dass viele dieser Prozesse bereits automatisiert sind. Mit APM können Sie auch den freien Speicherplatz auf dem Festplattensubsystem überwachen. In Ermangelung von Speicherplatz oder langsamer Festplattenoperation rufen wir das Skript auf, um Speicherplatz zu bereinigen oder hinzuzufügen.


Festplattenladen 100%

4. Geringe Benutzeraktivität oder geringe Conversion - Wechseln Sie zwischen dem blauen und dem grünen Zweig

Ich treffe Kunden häufig mit zwei Schaltkreisen (blau-grün bereitstellen) für Anwendungen in der Produktionsumgebung. Auf diese Weise können Sie bei der Bereitstellung neuer Versionen schnell zwischen Zweigen wechseln. Oft können nach der Bereitstellung grundlegende Änderungen auftreten, die nicht sofort erkennbar sind. Eine Verschlechterung der Leistung und Verfügbarkeit kann jedoch nicht beobachtet werden. Um schnell auf solche Änderungen zu reagieren, ist es besser, verschiedene Metriken zu verwenden, die das Benutzerverhalten widerspiegeln (Anzahl der Sitzungen und Benutzeraktionen, Conversion, Absprungrate). Die folgende Abbildung zeigt ein Beispiel, in dem bei einem Rückgang der Konvertierung zwischen Softwarezweigen gewechselt wird.

Conversion-Drop nach dem Wechsel zwischen Software-Zweigen. Quelle

Automatische Problembestimmungsmechanismen

Am Ende werde ich noch ein Beispiel geben, für das ich Dynatrace am meisten mag.

In einem Teil meiner Geschichte über die Automatisierung der Qualitätskontrolle von Baugruppen in einer Testumgebung haben wir alle Schwellenwerte im manuellen Modus ermittelt. Dies ist in einer Testumgebung normal. Der Tester bestimmt die Indikatoren vor jedem Test abhängig von der Belastung. In der Produktionsumgebung ist es wünschenswert, dass Probleme unter Berücksichtigung der verschiedenen Basismechanismen automatisch erkannt werden.

Dynatrace verfügt über interessante integrierte Tools für künstliche Intelligenz, die auf den Mechanismen zur Ermittlung anomaler Metriken (Baselining) und zur Erstellung einer Interaktionskarte zwischen allen Komponenten, zum Vergleich und zur Korrelation von Ereignissen untereinander, zur Ermittlung von Anomalien in der Arbeit Ihres Dienstes und zur Bereitstellung detaillierter Informationen zu jedem Problem und jeder Grundursache basieren.

Durch die automatische Analyse der Abhängigkeiten zwischen Komponenten ermittelt Dynatrace nicht nur, ob der problematische Dienst die Hauptursache ist, sondern auch seine Abhängigkeit von anderen Diensten. Im folgenden Beispiel überwacht und bewertet Dynatrace automatisch den Zustand jedes Dienstes als Teil einer Transaktion und identifiziert den Golang-Dienst als Hauptgrund.

Ein Beispiel für die Ermittlung der Grundursache eines Fehlers. Quelle

Die folgende Abbildung zeigt den Prozess der Überwachung von Problemen mit Ihrer Anwendung vom Beginn des Vorfalls an.

Visualisierung eines auftretenden Problems mit der Anzeige aller Komponenten und Ereignisse darauf

Das Überwachungssystem hat eine vollständige Chronologie der Ereignisse zu dem Problem zusammengestellt. Im Fenster unter der Zeitleiste sehen wir alle wichtigen Ereignisse für jede der Komponenten. Basierend auf diesen Ereignissen können Sie Verfahren zur automatischen Korrektur in Form von Codeskripten festlegen.

Darüber hinaus empfehle ich Ihnen, das Überwachungssystem in Service Desk oder einen Bug-Tracker zu integrieren. Wenn ein Problem auftritt, erhalten Entwickler schnell vollständige Informationen für die Analyse auf Codeebene in der Produktionsumgebung.

Fazit

Als Ergebnis haben wir eine CI / CD-Pipeline mit integrierten automatisierten Softwarequalitätsprüfungen in Pipeline erhalten. Wir minimieren die Anzahl von Baugruppen mit schlechter Qualität, erhöhen die Zuverlässigkeit des Gesamtsystems und starten Mechanismen zur Wiederherstellung des Systems, wenn wir die Leistung des Systems weiterhin beeinträchtigen.


Es lohnt sich auf jeden Fall, die Überwachung der Softwarequalität zu automatisieren. Es ist nicht immer ein schneller Prozess, aber im Laufe der Zeit wird er Früchte tragen. Ich empfehle, nach dem Lösen eines neuen Vorfalls in der Produktumgebung sofort zu überlegen, welche Monitore für Überprüfungen in der Testumgebung hinzugefügt werden sollen, um zu vermeiden, dass das Produkt fehlerhaft erstellt wird, und ein Skript zu erstellen, um diese Probleme automatisch zu beheben.

Ich hoffe, meine Beispiele helfen Ihnen bei Ihren Bemühungen. Es wird mich auch interessieren, Ihre Beispiele für verwendete Metriken für die Implementierung von Selbstheilungssystemen zu sehen.

Quelle