Jetzt ist das Thema DevOps in aller Munde. Kontinuierliche Integration und Bereitstellungspipeline Jeder setzt es um. Doch die meisten schenken der Gewährleistung der Zuverlässigkeit der Informationssysteme in den verschiedenen Phasen der CI/CD-Pipeline nicht immer die gebührende Aufmerksamkeit. In diesem Artikel möchte ich über meine Erfahrungen bei der Automatisierung von Software-Qualitätsprüfungen und der Umsetzung möglicher Szenarien für deren „Selbstheilung“ sprechen.
Ich arbeite als Ingenieur in der IT-Service-Management-Abteilung eines Unternehmens . Mein Kernkompetenzgebiet ist die Implementierung verschiedener Systeme zur Überwachung der Anwendungsleistung und -verfügbarkeit. Ich kommuniziere oft mit IT-Kunden aus unterschiedlichen Marktsegmenten über aktuelle Fragen zur Überwachung der Qualität ihrer IT-Services. Das Hauptziel besteht darin, die Release-Zykluszeit zu minimieren und die Release-Frequenz zu erhöhen. Das ist natürlich alles gut: mehr Veröffentlichungen – mehr neue Funktionen – mehr zufriedene Benutzer – mehr Gewinn. Aber in Wirklichkeit läuft es nicht immer gut. Bei sehr hohen Bereitstellungsraten stellt sich sofort die Frage nach der Qualität unserer Releases. Selbst bei einer vollständig automatisierten Pipeline besteht eine der größten Herausforderungen darin, Dienste vom Test in die Produktion zu verlagern, ohne die Anwendungsverfügbarkeit und das Benutzererlebnis zu beeinträchtigen.
Basierend auf den Ergebnissen zahlreicher Gespräche mit Kunden kann ich sagen, dass die Release-Qualitätskontrolle, das Problem der Anwendungszuverlässigkeit und die Möglichkeit ihrer „Selbstheilung“ (z. B. Rollback auf eine stabile Version) in verschiedenen Phasen des CI bestehen /CD-Pipeline gehören zu den spannendsten und relevantesten Themen.
Zuletzt war ich selbst auf Kundenseite tätig – im Support für Online-Banking-Anwendungssoftware. Die Architektur unserer Anwendung nutzte eine große Anzahl selbst geschriebener Microservices. Das Traurigste ist, dass nicht alle Entwickler mit dem hohen Entwicklungstempo zurechtkamen; die Qualität einiger Microservices litt darunter, was zu lustigen Spitznamen für sie und ihre Entwickler führte. Es gab Geschichten darüber, aus welchen Materialien diese Produkte hergestellt wurden.
"Formulierung des Problems"
Die hohe Häufigkeit von Veröffentlichungen und eine große Anzahl von Microservices machen es schwierig, die Funktionsweise der Anwendung als Ganzes zu verstehen, sowohl in der Testphase als auch in der Betriebsphase. Veränderungen treten ständig auf und es ist sehr schwierig, sie ohne gute Überwachungstools zu kontrollieren. Oft sitzen Entwickler nach einem Nacht-Release am Morgen wie auf einem Pulverfass und warten darauf, dass nichts kaputt geht, obwohl in der Testphase alle Kontrollen erfolgreich waren.
Es gibt noch einen weiteren Punkt. In der Testphase wird die Funktionalität der Software überprüft: die Umsetzung der Hauptfunktionen der Anwendung und die Fehlerfreiheit. Qualitative Leistungsbewertungen fehlen entweder oder berücksichtigen nicht alle Aspekte der Anwendung und der Integrationsschicht. Einige Messwerte werden möglicherweise überhaupt nicht überprüft. Wenn in einer Produktionsumgebung ein Ausfall auftritt, erfährt die technische Supportabteilung daher erst dann davon, wenn sich echte Benutzer beschweren. Ich möchte die Auswirkungen minderwertiger Software auf Endbenutzer minimieren.
Eine der Lösungen besteht darin, Prozesse zur Überprüfung der Softwarequalität in verschiedenen Phasen der CI/CD-Pipeline zu implementieren und verschiedene Szenarien zur Wiederherstellung des Systems im Notfall hinzuzufügen. Wir erinnern uns auch daran, dass wir DevOps haben. Unternehmen erwarten, so schnell wie möglich ein neues Produkt zu erhalten. Daher müssen alle unsere Prüfungen und Skripte automatisiert werden.
Die Aufgabe gliedert sich in zwei Komponenten:
- Qualitätskontrolle von Baugruppen in der Testphase (um den Prozess der Erkennung minderwertiger Baugruppen zu automatisieren);
- Software-Qualitätskontrolle in der Produktionsumgebung (Mechanismen zur automatischen Erkennung von Problemen und mögliche Szenarien für deren Selbstheilung).
Tool zum Überwachen und Sammeln von Metriken
Um die gesetzten Ziele zu erreichen, ist ein Überwachungssystem erforderlich, das Probleme erkennen und an Automatisierungssysteme in verschiedenen Phasen der CI/CD-Pipeline übertragen kann. Es wird auch positiv sein, wenn dieses System nützliche Metriken für verschiedene Teams bereitstellt: Entwicklung, Test, Betrieb. Und es ist absolut wunderbar, wenn es auch geschäftlich ist.
Um Metriken zu sammeln, können Sie eine Reihe verschiedener Systeme verwenden (Prometheus, ELK Stack, Zabbix usw.), aber meiner Meinung nach sind Lösungen der APM-Klasse für diese Aufgaben am besten geeignet (), was Ihr Leben erheblich vereinfachen kann.
Im Rahmen meiner Arbeit im Support-Service habe ich mit der Durchführung eines ähnlichen Projekts mit einer APM-Klassenlösung von Dynatrace begonnen. Da ich nun für einen Integrator arbeite, kenne ich den Markt für Überwachungssysteme recht gut. Meine subjektive Meinung: Für die Lösung solcher Probleme ist Dynatrace am besten geeignet.
Dynatrace bietet eine horizontale Ansicht jedes Benutzervorgangs auf einer granularen Ebene bis hin zur Codeausführungsebene. Sie können die gesamte Interaktionskette zwischen verschiedenen Informationsdiensten verfolgen: von der Front-End-Ebene von Web- und Mobilanwendungen über Back-End-Anwendungsserver und Integrationsbus bis hin zu einem bestimmten Aufruf der Datenbank.
. Automatischer Aufbau aller Abhängigkeiten zwischen Systemkomponenten
. Automatische Erkennung und Konstruktion des Service-Betriebspfads
Wir denken auch daran, dass wir verschiedene Automatisierungstools integrieren müssen. Hier verfügt die Lösung über eine komfortable API, die es Ihnen ermöglicht, verschiedene Metriken und Ereignisse zu senden und zu empfangen.
Lassen Sie uns als Nächstes einen detaillierteren Blick darauf werfen, wie diese Probleme mithilfe des Dynatrace-Systems gelöst werden können.
Aufgabe 1. Automatisierung der Qualitätskontrolle von Baugruppen in der Testphase
Die erste Herausforderung besteht darin, Probleme so früh wie möglich in der Anwendungsbereitstellungspipeline zu finden. Nur „gute“ Code-Builds sollten die Produktion erreichen. Zu diesem Zweck sollte Ihre Pipeline in der Testphase zusätzliche Monitore umfassen, um die Qualität Ihrer Dienste zu überprüfen.
Sehen wir uns Schritt für Schritt an, wie Sie dies implementieren und diesen Prozess automatisieren können:
Die Abbildung zeigt den Ablauf automatisierter Softwarequalitätstestschritte:
- Bereitstellung eines Überwachungssystems (Installation von Agenten);
- Identifizieren von Ereignissen zur Beurteilung der Qualität Ihrer Software (Metriken und Schwellenwerte) und deren Übergabe an das Überwachungssystem;
- Erstellung von Last- und Leistungstests;
- Sammeln von Leistungs- und Verfügbarkeitsdaten im Überwachungssystem;
- Übertragung von Testdaten basierend auf Software-Qualitätsbewertungsereignissen vom Überwachungssystem zum CI/CD-System. Automatische Analyse von Baugruppen.
Schritt 1. Bereitstellung des Überwachungssystems
Zuerst müssen Sie die Agenten in Ihrer Testumgebung installieren. Gleichzeitig verfügt die Dynatrace-Lösung über eine nette Funktion: Sie verwendet den Universalagenten OneAgent, der auf einer Betriebssysteminstanz (Windows, Linux, AIX) installiert ist, Ihre Dienste automatisch erkennt und mit der Erfassung von Überwachungsdaten über diese beginnt. Sie müssen nicht für jeden Prozess einen separaten Agenten konfigurieren. Bei Cloud- und Container-Plattformen wird die Situation ähnlich sein. Gleichzeitig können Sie auch den Agent-Installationsprozess automatisieren. Dynatrace passt perfekt in das „Infrastructure as Code“-Konzept (): Für alle gängigen Plattformen gibt es vorgefertigte Skripte und Anleitungen. Sie betten den Agenten in die Konfiguration Ihres Dienstes ein, und wenn Sie ihn bereitstellen, erhalten Sie sofort einen neuen Dienst mit einem bereits funktionierenden Agenten.
Schritt 2: Definieren Sie Ihre Softwarequalitätsereignisse
Jetzt müssen Sie sich für die Liste der Dienstleistungen und Geschäftstätigkeiten entscheiden. Es ist wichtig, genau die Benutzervorgänge zu berücksichtigen, die für Ihren Service geschäftskritisch sind. Hier empfehle ich die Beratung durch Business- und Systemanalysten.
Als Nächstes müssen Sie festlegen, welche Kennzahlen Sie für jede Ebene in die Überprüfung einbeziehen möchten. Dies können beispielsweise die Ausführungszeit (unterteilt in Durchschnitt, Median, Perzentile usw.), Fehler (logisch, Dienst, Infrastruktur usw.) und verschiedene Infrastrukturmetriken (Speicherheap, Garbage Collector, Thread-Anzahl usw.) sein.
Zur Automatisierung und Benutzerfreundlichkeit durch das DevOps-Team erscheint das Konzept „Monitoring as Code“. Damit meine ich, dass ein Entwickler/Tester eine einfache JSON-Datei schreiben kann, die Metriken zur Software-Qualitätssicherung definiert.
Schauen wir uns ein Beispiel einer solchen JSON-Datei an. Als Schlüssel/Wert-Paare werden Objekte aus der Dynatrace-API verwendet (API-Beschreibung finden Sie hier). ).
{
"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 ist ein Array von Zeitreihendefinitionen:
- timeseriesId – die überprüfte Metrik, zum Beispiel Antwortzeit, Fehleranzahl, verwendeter Speicher usw.;
- Aggregation – Ebene der Metrikaggregation, in unserem Fall Durchschnitt, Sie können jedoch jede beliebige verwenden (Durchschnitt, Min., Max., Summe, Anzahl, Perzentil);
- Tags – Objekt-Tag im Überwachungssystem, oder Sie können eine bestimmte Objekt-ID angeben;
- schwerwiegend und Warnung – diese Indikatoren regeln die Schwellenwerte unserer Metriken; wenn der Testwert den schwerwiegenden Schwellenwert überschreitet, wird unser Build als nicht erfolgreich markiert.
Die folgende Abbildung zeigt ein Beispiel für die Verwendung solcher Schwellenwerte.
Schritt 3: Lastgenerierung
Sobald wir das Qualitätsniveau unseres Dienstes ermittelt haben, müssen wir eine Testlast generieren. Sie können jedes der Testtools verwenden, mit denen Sie vertraut sind, z. B. Jmeter, Selenium, Neotys, Gatling usw.
Mit dem Überwachungssystem von Dynatrace können Sie verschiedene Metadaten Ihrer Tests erfassen und erkennen, welche Tests zu welchem Release-Zyklus und welchem Service gehören. Es wird empfohlen, HTTP-Testanfragen zusätzliche Header hinzuzufügen.
Die folgende Abbildung zeigt ein Beispiel, in dem wir mithilfe des zusätzlichen Headers „X-Dynatrace-Test“ angeben, dass es sich bei diesem Test um das Testen des Vorgangs des Hinzufügens eines Artikels zum Warenkorb handelt.
Wenn Sie jeden Auslastungstest ausführen, senden Sie mithilfe der Event-API vom CI/CD-Server zusätzliche Kontextinformationen an Dynatrace. Auf diese Weise kann das System zwischen verschiedenen Tests unterscheiden.
. Ereignis im Überwachungssystem über den Beginn des Lasttests
Schritt 4-5. Erfassen Sie Leistungsdaten und übertragen Sie Daten an das CI/CD-System
Zusammen mit dem generierten Test wird ein Ereignis über die Notwendigkeit, Daten zur Überprüfung von Servicequalitätsindikatoren zu sammeln, an das Überwachungssystem übermittelt. Außerdem wird unsere JSON-Datei angegeben, die die Schlüsselmetriken definiert.
Veranstaltung über die Notwendigkeit, die Qualität der auf dem CI/CD-Server generierten Software zum Senden an das Überwachungssystem zu überprüfen
In unserem Beispiel wird das Ereignis Qualitätsprüfung aufgerufen perfSigDynatraceReport (Performance_Signature) - das ist fertig zur Integration mit Jenkins, das von den Jungs von T-Systems Multimedia Solutions entwickelt wurde. Jedes Teststartereignis enthält Informationen zum Dienst, zur Build-Nummer und zur Testzeit. Das Plugin sammelt Leistungswerte zur Build-Zeit, wertet diese aus und vergleicht das Ergebnis mit früheren Builds und nicht-funktionalen Anforderungen.
Ereignis im Überwachungssystem über den Beginn einer Bauqualitätsprüfung.
Nach Abschluss des Tests werden alle Metriken zur Bewertung der Softwarequalität zurück an ein kontinuierliches Integrationssystem, beispielsweise Jenkins, übertragen, das einen Bericht über die Ergebnisse erstellt.
Das Ergebnis der Statistiken zu Assemblys auf dem CI/CD-Server.
Für jeden einzelnen Build sehen wir Statistiken für jede Metrik, die wir während des gesamten Tests festgelegt haben. Wir sehen auch, ob es Verstöße gegen bestimmte Schwellenwerte (Warnung und schwerwiegende Schwellenwerte) gab. Basierend auf aggregierten Metriken wird der gesamte Build als stabil, instabil oder fehlgeschlagen markiert. Der Einfachheit halber können Sie dem Bericht auch Indikatoren hinzufügen, die den aktuellen Build mit dem vorherigen vergleichen.
Zeigen Sie detaillierte Statistiken zu Assemblys auf dem CI/CD-Server an.
Detaillierter Vergleich zweier Baugruppen
Bei Bedarf kannst du auf die Dynatrace-Oberfläche gehen und dort die Statistiken für jeden deiner Builds detaillierter einsehen und miteinander vergleichen.
Vergleich der Build-Statistiken in Dynatrace.
Befund
Als Ergebnis erhalten wir einen „Monitoring as a Service“-Service, automatisiert in der Continuous Integration Pipeline. Der Entwickler oder Tester muss lediglich eine Liste von Metriken in einer JSON-Datei definieren, alles andere geschieht automatisch. Wir erhalten eine transparente Qualitätskontrolle der Releases: alle Benachrichtigungen über Performance, Ressourcenverbrauch oder Architekturregressionen.
Aufgabe 2. Automatisierung der Software-Qualitätskontrolle in einer Produktionsumgebung
Damit haben wir das Problem gelöst, den Überwachungsprozess in der Testphase in Pipeline zu automatisieren. Dadurch minimieren wir den Anteil minderwertiger Baugruppen, die in die Produktionsumgebung gelangen.
Aber was tun, wenn schlechte Software verkauft wird oder einfach etwas kaputt geht? Für eine Utopie wollten wir Mechanismen, die Probleme automatisch erkennen und das System selbst nach Möglichkeit zumindest nachts wieder funktionsfähig machen.
Dazu müssen wir analog zum vorherigen Abschnitt automatische Software-Qualitätsprüfungen in der Produktionsumgebung vorsehen und diese auf Szenarien zur Selbstheilung des Systems basieren.
Autokorrektur als Code
Die meisten Unternehmen verfügen bereits über eine akkumulierte Wissensdatenbank zu verschiedenen Arten häufiger Probleme und eine Liste von Maßnahmen zu deren Behebung, z. B. Neustarten von Prozessen, Bereinigen von Ressourcen, Zurücksetzen von Versionen, Wiederherstellen ungültiger Konfigurationsänderungen, Erhöhen oder Verringern der Anzahl der Komponenten des Clusters, Wechseln des blauen oder grünen Umrisses usw.
Obwohl diese Anwendungsfälle vielen der Teams, mit denen ich spreche, schon seit Jahren bekannt sind, haben nur wenige darüber nachgedacht oder in eine Automatisierung investiert.
Wenn Sie darüber nachdenken, ist die Implementierung von Prozessen zur Selbstheilung der Anwendungsleistung nicht allzu kompliziert; Sie müssen die bereits bekannten Arbeitsszenarien Ihrer Administratoren in Form von Code-Skripten darstellen (das „Auto-Fix-as-Code“-Konzept). , die Sie im Voraus für jeden einzelnen Fall geschrieben haben. Automatische Reparaturskripte sollten darauf abzielen, die Grundursache des Problems zu beseitigen. Sie bestimmen selbst die richtigen Maßnahmen, um auf einen Vorfall zu reagieren.
Jede Metrik Ihres Überwachungssystems kann als Auslöser für den Start des Skripts dienen. Die Hauptsache ist, dass diese Metriken genau bestimmen, dass alles schlecht ist, da Sie in einer produktiven Umgebung keine Fehlalarme erhalten möchten.
Sie können jedes System oder jede Systemgruppe verwenden: Prometheus, ELK Stack, Zabbix usw. Aber ich werde einige Beispiele geben, die auf einer APM-Lösung basieren (Dynatrace wird wieder ein Beispiel sein), die Ihnen auch das Leben erleichtern werden.
Erstens gibt es alles, was mit der Leistung im Hinblick auf den Anwendungsbetrieb zu tun hat. 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.);
- Service- und Betriebsniveau (Leistung, Verfügbarkeit, Fehler usw.);
- Ebene der Anwendungsinfrastruktur (Metriken des Host-Betriebssystems, JMX, MQ, Webserver usw.);
- Plattformebene (Virtualisierung, Cloud, Container usw.).
Überwachungsniveaus in Dynatrace.
Zweitens verfügt Dynatrace, wie ich bereits sagte, über eine offene API, die die Integration in verschiedene Drittsysteme sehr einfach macht. Zum Beispiel das Versenden einer Benachrichtigung an das Automatisierungssystem, wenn Regelparameter überschritten werden.
Nachfolgend finden Sie ein Beispiel für die Interaktion mit Ansible.
Im Folgenden gebe ich einige Beispiele dafür, welche Art von Automatisierung möglich ist. Dies ist nur ein Teil der Fälle; ihre Liste in Ihrer Umgebung kann nur durch Ihre Vorstellungskraft und die Fähigkeiten Ihrer Überwachungstools begrenzt werden.
1. Fehlerhafte Bereitstellung – Versions-Rollback
Selbst wenn wir alles in einer Testumgebung sehr gut testen, besteht immer noch die Möglichkeit, dass eine neue Version Ihre Anwendung in einer Produktionsumgebung zum Erliegen bringt. Der gleiche menschliche Faktor wurde nicht aufgehoben.
In der folgenden Abbildung sehen wir, dass es einen starken Sprung in der Ausführungszeit von Vorgängen für den Dienst gibt. Der Beginn dieses Sprungs fällt mit dem Zeitpunkt der Bereitstellung in der Anwendung zusammen. All diese Informationen übermitteln wir als Ereignisse an das Automatisierungssystem. Wenn sich die Leistung des Dienstes nach der von uns festgelegten Zeit nicht wieder normalisiert, wird automatisch ein Skript aufgerufen, das die Version auf die alte zurücksetzt.
Verschlechterung der Betriebsleistung nach der Bereitstellung.
2. Ressourcenauslastung bei 100 % – Fügen Sie dem Routing einen Knoten hinzu
Im folgenden Beispiel stellt das Überwachungssystem fest, dass eine der Komponenten eine CPU-Auslastung von 100 % 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öhten Auslastung des Dienstes einhergeht. Ist dies der Fall, wird ein Skript ausgeführt, das automatisch einen Knoten zum Routing hinzufügt und so die Funktionalität des Gesamtsystems wiederherstellt.
Skalierung nach einem Vorfall
3. Platzmangel auf der Festplatte – Festplattenreinigung
Ich denke, dass viele Menschen diese Prozesse bereits automatisiert haben. Mit APM können Sie auch den freien Speicherplatz auf dem Festplattensubsystem überwachen. Wenn kein Speicherplatz vorhanden ist oder die Festplatte langsam läuft, rufen wir ein Skript auf, um sie zu bereinigen oder Speicherplatz hinzuzufügen.
Scheibenbelastung 100 %
4. Geringe Benutzeraktivität oder geringe Konvertierung – Wechsel zwischen blauen und grünen Zweigen
Ich sehe oft, dass Kunden zwei Schleifen (blau-grüne Bereitstellung) für Anwendungen in einer Produktionsumgebung verwenden. Dadurch können Sie bei der Bereitstellung neuer Releases schnell zwischen den Zweigen wechseln. Oftmals kann es nach der Bereitstellung zu dramatischen Veränderungen kommen, die nicht sofort erkennbar sind. In diesem Fall ist möglicherweise keine Verschlechterung der Leistung und Verfügbarkeit zu beobachten. Um schnell auf solche Veränderungen zu reagieren, ist es besser, verschiedene Metriken zu verwenden, die das Nutzerverhalten widerspiegeln (Anzahl der Sitzungen und Nutzeraktionen, Conversion, Absprungrate). Die folgende Abbildung zeigt ein Beispiel, bei dem bei sinkenden Conversion-Raten ein Wechsel zwischen Softwarezweigen erfolgt.
Die Conversion-Rate sinkt nach dem Wechsel zwischen Softwarezweigen.
Mechanismen zur automatischen Problemerkennung
Abschließend gebe ich Ihnen noch ein Beispiel dafür, warum mir Dynatrace am besten gefällt.
Im Teil meiner Geschichte über die Automatisierung von Qualitätsprüfungen von Baugruppen in einer Testumgebung haben wir alle Schwellenwerte manuell ermittelt. Dies ist in einer Testumgebung normal, der Tester legt die Indikatoren vor jedem Test je nach Belastung selbst fest. In einer Produktionsumgebung ist es wünschenswert, dass Probleme automatisch erkannt werden und dabei verschiedene Basismechanismen berücksichtigt werden.
Dynatrace verfügt über interessante integrierte Tools für künstliche Intelligenz, die auf der Grundlage von Mechanismen zur Bestimmung anomaler Metriken (Baselining) und zum Erstellen einer Karte der Interaktion zwischen allen Komponenten, zum Vergleichen und Korrelieren von Ereignissen untereinander Anomalien im Betrieb Ihres Dienstes ermitteln und detaillierte Informationen bereitstellen Informationen zu jedem Problem und seiner Grundursache.
Durch die automatische Analyse von Abhängigkeiten zwischen Komponenten ermittelt Dynatrace nicht nur, ob der problematische Dienst die Ursache ist, sondern auch seine Abhängigkeit von anderen Diensten. Im folgenden Beispiel überwacht und bewertet Dynatrace automatisch den Zustand jedes Dienstes innerhalb der Transaktionsausführung und identifiziert den Golang-Dienst als Hauptursache.
Ein Beispiel für die Ermittlung der Grundursache eines Fehlers.
Die folgende Abbildung zeigt den Prozess der Überwachung von Problemen mit Ihrer Anwendung ab Beginn eines Vorfalls.
Visualisierung eines auftretenden Problems mit Anzeige aller Komponenten und Ereignisse darauf
Das Überwachungssystem erfasste eine vollständige Chronologie der Ereignisse im Zusammenhang mit dem aufgetretenen Problem. Im Fenster unterhalb der Zeitleiste sehen wir alle wichtigen Ereignisse zu jeder der Komponenten. Basierend auf diesen Ereignissen können Sie Verfahren zur automatischen Korrektur in Form von Code-Skripten festlegen.
Darüber hinaus empfehle ich Ihnen, ein Überwachungssystem mit Service Desk oder einen Bugtracker zu integrieren. Wenn ein Problem auftritt, erhalten Entwickler schnell vollständige Informationen, um es auf Codeebene in der Produktionsumgebung zu analysieren.
Abschluss
Als Ergebnis hatten wir eine CI/CD-Pipeline mit integrierten automatisierten Software-Qualitätsprüfungen in Pipeline. Wir minimieren die Anzahl minderwertiger Baugruppen, erhöhen die Zuverlässigkeit des Gesamtsystems und wenn unser System dennoch ausfällt, starten wir Mechanismen zur Wiederherstellung.
Es lohnt sich auf jeden Fall, Aufwand in die Automatisierung der Software-Qualitätsüberwachung zu investieren; es ist nicht immer ein schneller Prozess, aber mit der Zeit wird er Früchte tragen. Ich empfehle Ihnen, nach der Lösung eines neuen Vorfalls in der Produktionsumgebung sofort darüber nachzudenken, welche Monitore Sie für Überprüfungen in der Testumgebung hinzufügen sollten, um zu verhindern, dass ein fehlerhafter Build in die Produktion gelangt, und außerdem ein Skript zu erstellen, um diese Probleme automatisch zu beheben.
Ich hoffe, dass meine Beispiele Ihnen bei Ihren Bemühungen helfen werden. Ich bin auch daran interessiert, Ihre Beispiele für Metriken zu sehen, die zur Implementierung von Selbstheilungssystemen verwendet werden.
Source: habr.com