Momente, in denen DevOps im Trend liegt. Der Prozess der kontinuierlichen Integration und Lieferung wird von allen umgesetzt, die es sich leisten können. Doch viele widmen der Gewährleistung der Zuverlässigkeit von Informationssystemen in verschiedenen Phasen der CI/CD-Pipeline nicht immer die nötige Aufmerksamkeit. In diesem Artikel möchte ich über meine Erfahrungen mit der Automatisierung von Softwarequalitätstests und der Umsetzung möglicher Szenarien für die "Selbstheilung" sprechen.
Ich arbeite als Ingenieur in der IT-Service-Management-Abteilung bei . Mein Fachgebiet liegt in der Implementierung verschiedener Systeme zur Überwachung der Leistungsfähigkeit und Verfügbarkeit von Anwendungen. Ich stehe regelmäßig im Austausch mit IT-Kunden aus unterschiedlichen Marktsegmenten bezüglich aktueller Fragen zur Qualitätssicherung ihrer IT-Dienste. Die Hauptaufgabe besteht darin, die Release-Zyklen zu minimieren und deren Häufigkeit zu erhöhen. Das klingt natürlich gut: Mehr Releases – mehr neue Funktionen – zufriedenere Nutzer – höherer Gewinn. Doch in der Realität läuft es nicht immer so glatt. Bei sehr hohen Bereitstellungsgeschwindigkeiten stellt sich sofort die Frage nach der Qualität unserer Releases. Selbst bei einem vollständig automatisierten Prozess gehört der Übergang von Diensten aus der Testphase in die Produktion zu den größten Herausforderungen, die dabei die Betriebszeit nicht beeinträchtigen und die Interaktion der Nutzer mit der Anwendung nicht stören.
Nach zahlreichen Gesprächen mit Kunden kann ich sagen, dass die Qualitätssicherung von Releases, die Zuverlässigkeit der Anwendungen und die Möglichkeit der ‚Selbstwiederherstellung‘ (zum Beispiel durch ein Rollback auf eine stabile Version) in den verschiedenen Phasen des CI/CD-Prozesses zu den besorgniserregendsten und relevantesten Themen gehören.
Kürzlich arbeitete ich auf der Seite des Kunden – im Supportteam einer Online-Bank. In der Architektur unserer Anwendung kamen zahlreiche selbstentwickelte Mikrodienste zum Einsatz. Am bedauerlichsten war, dass nicht alle Entwickler mit dem hohen Entwicklungstempo mithalten konnten, was die Qualität einiger Mikrodienste beeinträchtigte und zu amüsanten Spitznamen für sie und ihre Schöpfer führte. Es entstanden Geschichten darüber, aus welchen Materialien diese Produkte gefertigt werden.
„Aufgabenstellung“
Die hohe Release-Frequenz und die große Anzahl an Mikrodiensten erschweren es, das Gesamtbild der Anwendung zu verstehen, sowohl in der Testphase als auch im Betrieb. Änderungen erfolgen kontinuierlich, und ohne gute Überwachungswerkzeuge ist es sehr schwierig, diese zu kontrollieren. Oft sitzen die Entwickler nach einem nächtlichen Release am nächsten Morgen wie auf einer Zeitbombe und warten darauf, dass nichts kaputtgeht, obwohl alle Tests in der Testphase erfolgreich waren.
Es gibt noch einen weiteren Punkt. Während der Testphase wird die Funktionalität der Software überprüft: die Ausführung der Hauptfunktionen der Anwendung und das Fehlen von Fehlern. Qualitätsbewertungen der Leistung sind entweder nicht vorhanden oder berücksichtigen nicht alle Aspekte der Anwendung und der Integrationsschicht. Einige Metriken werden möglicherweise überhaupt nicht überprüft. Dadurch erfährt die technische Unterstützung von einem Ausfall in der Produktionsumgebung nur, wenn echte Anwender anfangen sich zu beschweren. Es ist wichtig, den Einfluss minderwertiger Software auf die Endbenutzer zu minimieren.
Eine der Lösungen besteht darin, Qualitätsprüfungsprozesse in verschiedenen Phasen der CI/CD-Pipeline zu implementieren, verschiedene Szenarien zur Wiederherstellung des Systems bei Ausfällen hinzuzufügen. Denken wir daran, dass wir DevOps haben. Das Geschäft erwartet die schnellstmögliche Bereitstellung neuer Produkte. Daher müssen alle unsere Prüfungen und Szenarien automatisiert sein.
Die Aufgabe wird in zwei Komponenten unterteilt:
- Qualitätskontrolle von Builds in der Testphase (den Prozess der Erkennung fehlerhafter Builds automatisieren);
- Qualitätskontrolle von Software in Produktionsumgebungen (Mechanismen zur automatischen Fehlererkennung und mögliche Selbstheilungsszenarien).
Tool zur Überwachung und Sammlung von Kennzahlen
Um die gesetzten Ziele zu erreichen, ist ein Überwachungssystem erforderlich, das Probleme erkennen und an Automatisierungssysteme in verschiedenen Phasen der CI/CD-Pipeline weitergeben kann. Es wäre auch vorteilhaft, wenn dieses System nützliche Metriken für verschiedene Teams bereitstellt: Entwicklung, Test und Betrieb. Und noch besser wäre es, wenn auch für das Unternehmen.
Zur Messung von Kennzahlen kann eine Kombination verschiedener Systeme (wie Prometheus, ELK Stack, Zabbix usw.) verwendet werden, doch meiner Meinung nach sind APM-Lösungen () am besten für diese Anforderungen geeignet und können Ihnen das Leben erheblich erleichtern.
Im Rahmen meiner Arbeit im Support habe ich ein ähnliches Projekt begonnen, indem ich eine APM-Lösung von Dynatrace verwendet habe. Jetzt, als Integrator, kenne ich den Markt für Überwachungssysteme ganz gut. Mein subjektives Urteil: Dynatrace ist die beste Wahl für diese Aufgaben.
Die Dynatrace-Lösung bietet eine umfassende Übersicht über jede Benutzerinteraktion mit einem tiefen Detailgrad bis hin zur Codeausführung. Sie können die gesamte Interaktionskette zwischen verschiedenen Informationsdiensten verfolgen: von den Frontend-Web- und Mobile-Apps über die Backend-Anwendungsserver und die Integrationsmiddleware bis hin zu spezifischen Datenbankaufrufen.
. Automatische Erstellung aller Abhängigkeiten zwischen den Systemkomponenten.
. Automatische Identifizierung und Erstellung des Pfads der Serviceoperation.
Wir müssen auch beachten, dass eine Integration mit verschiedenen Automatisierungstools erforderlich ist. Dafür verfügt die Lösung über eine benutzerfreundliche API, die das Senden und Empfangen verschiedener Metriken und Ereignisse ermöglicht.
Nun werden wir detaillierter betrachten, wie wir die Aufgaben mithilfe des Dynatrace-Systems angehen können.
Aufgabe 1. Automatisierung der Qualitätskontrolle von Builds in der Testphase.
Die erste Aufgabe besteht darin, Probleme so früh wie möglich in den Phasen der Anwendungsbereitstellung zu identifizieren. Nur "gute" Code-Bauten sollten in die Produktionsumgebung gelangen. Daher sollten in Ihrem Pipeline in der Testphase zusätzliche Überwachungsdimensionen zur Qualitätssicherung Ihrer Dienste integriert werden.
Sehen wir uns Schritt für Schritt an, wie dieser Prozess implementiert und automatisiert werden kann:
Die Abbildung zeigt den Fluss automatisierter Schritte zur Qualitätssicherung von Software:
- Bereitstellung des Überwachungssystems (Installation von Agenten);
- Bestimmung der Ereignisse zur Bewertung der Qualität Ihrer Software (Metriken und Schwellenwerte) und deren Übermittlung an das Überwachungssystem;
- Lastgenerierung und Leistungstests;
- Sammlung von Leistungs- und Verfügbarkeitsdaten im Überwachungssystem;
- Übertragung der Tests, die auf den Ereignissen zur Bewertung der Softwarequalität basieren, vom Überwachungssystem in das CI/CD-System. Automatische Analyse der Builds.
Schritt 1. Bereitstellung des Überwachungssystems
Zuerst müssen die Agenten in Ihrer Testumgebung installiert werden. Eine erfreuliche Eigenschaft der Dynatrace-Lösung ist, dass sie den universellen OneAgent nutzt, der auf Ihrem Betriebssystem (Windows, Linux, AIX) installiert wird, Ihre Dienste automatisch erkennt und beginnt, Monitoring-Daten zu sammeln. Es ist nicht erforderlich, einen separaten Agenten für jeden Prozess einzurichten. Das Gleiche gilt für Cloud- und Container-Plattformen. Auch der Installationsprozess der Agenten kann automatisiert werden. Dynatrace fügt sich hervorragend in das Konzept "Infrastructure as Code" ein,: es sind bereits Skripte und Anleitungen für alle gängigen Plattformen verfügbar. Sie integrieren den Agenten in die Konfiguration Ihres Dienstes, und bei dessen Bereitstellung erhalten Sie sofort einen neuen Dienst mit bereits funktionierendem Agenten.
Schritt 2. Bestimmung der Ereignisse zur Bewertung der Qualität Ihrer Software
Nun müssen Sie eine Liste von Diensten und Geschäftsvorgängen erstellen. Dabei ist es wichtig, gerade die Benutzeroperationen zu berücksichtigen, die geschäftskritisch für Ihren Dienst sind. Hierbei empfehle ich, sich mit Geschäfts- und Systemanalytikern abzusprechen.
Zunächst müssen Sie bestimmen, welche Metriken Sie für die Überprüfung auf jedem Level einbeziehen möchten. Dazu könnten die Ausführungszeiten (unterteilt in Durchschnitt, Median, Perzentile usw.), Fehler (logische, servicebezogene, infrastrukturelle usw.) und verschiedene Infrastrukturmetriken (Speicherheap, Garbage Collector, Threadanzahl usw.) gehören.
Um die Nutzung durch das DevOps-Team zu automatisieren und zu erleichtern, entsteht das Konzept des "Monitoring as Code". Was ich damit meine, ist, dass ein Entwickler/Tester eine einfache JSON-Datei schreiben kann, die die Qualitätsmesskriterien für Software definiert.
Schauen wir uns ein Beispiel für eine solche JSON-Datei an. Als Schlüssel/Wert-Paar verwenden wir Objekte aus der Dynatrace API (die Beschreibung der API 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 stellt ein Array von Definitionen für Zeitserien (timeseries) dar:
- timeseriesId – die überwachte Kennzahl, wie z.B. Antwortzeit, Fehlermenge, genutzter Speicher usw.;
- aggregation — die Aggregationsebene der Kennzahlen, in unserem Fall avg, aber Sie können jede für Sie erforderliche Ebene verwenden (avg, min, max, sum, count, percentile);
- tags – Tag des Objekts im Überwachungssystem oder eine spezifische Objekt-ID angeben;
- severe und warning – diese Kennzahlen steuern die Schwellenwerte unserer Metriken; wenn der Wert der Tests den Schwellenwert severe überschreitet, wird unser Build als nicht erfolgreich gekennzeichnet.
Im nächsten Bild sehen Sie ein Beispiel für die Verwendung solcher Schwellenwerte.
Schritt 3. Lastgenerierung
Nachdem wir die Qualitätslevels unseres Services bestimmt haben, müssen wir eine Testlast generieren. Sie können jedes Ihnen passende Testtool verwenden, wie z.B. JMeter, Selenium, Neotys, Gatling usw.
Das Überwachungssystem Dynatrace ermöglicht es, verschiedene Metadaten aus Ihren Tests zu erfassen und zu erkennen, welcher Test zu welchem Release-Zyklus und welchem Service gehört. Es wird empfohlen, zusätzliche Header in die HTTP-Anfragen der Tests einzufügen.
Das nächste Bild zeigt ein Beispiel, bei dem wir mit dem zusätzlichen Header X-Dynatrace-Test kennzeichnen, dass dieser Test mit dem Hinzufügen eines Produkts zum Warenkorb zu tun hat.
Bei jedem Start eines Lasttests senden Sie zusätzliche Kontextinformationen an Dynatrace über die Event-API von Ihrem CI/CD-Server. Dadurch kann das System verschiedene Tests voneinander unterscheiden.
Ein Ereignis im Überwachungssystem über den Start eines Lasttests
Schritt 4-5. Datensammlung zur Leistungsbewertung und Übertragung der Daten an das CI/CD-System
Zusammen mit dem generierten Test wird ein Ereignis zur Datensammlung bezüglich der Qualitätssicherung an das Überwachungssystem übertragen. Auch unser JSON-Dokument, das die Schlüsselmessgrößen definiert, wird angegeben.
Das Ereignis zur Überprüfung der Softwarequalität, das auf dem CI/CD-Server generiert wird, um an das Überwachungssystem gesendet zu werden
In unserem Beispiel wird das Ereignis zur Qualitätsprüfung genannt perfSigDynatraceReport (Performance_Signature) – das ist bereit für die Integration mit Jenkins, das von den Entwicklern von T-Systems Multimedia Solutions erstellt wurde. Jedes Ereignis beim Start eines Qualitätstests enthält Informationen über den Dienst, die Build-Nummer und die Testzeit. Das Plugin erfasst die Leistungswerte während des Builds, bewertet sie und vergleicht die Ergebnisse mit früheren Builds und nicht-funktionalen Anforderungen.
Ein Ereignis im Monitoring-System über den Start des Qualitätstests für den Build.
Nach Abschluss des Tests werden alle Metriken zur Bewertung der Softwarequalität zurück an das Continuous Integration-System, wie Jenkins, übermittelt, das den Bericht über die Ergebnisse erstellt.
Statistik über die Builds auf dem CI/CD-Server.
Für jeden einzelnen Build sehen wir die Statistik zu jeder von uns festgelegten Metrik während des gesamten Testablaufs. Außerdem erkennen wir, ob es Verstöße gegen bestimmte Schwellenwerte gab (Warnungen und schwerwiegende Schwellenwerte). Basierend auf den kumulierten Werten wird jeder Build als stabil, instabil oder fehlerhaft gekennzeichnet. Zu Ihrer Bequemlichkeit können Sie auch Werte zum Vergleich des aktuellen Builds mit dem vorherigen in den Bericht aufnehmen.
Einsicht in detaillierte Statistiken zu den Builds auf dem CI/CD-Server.
Detaillierter Vergleich zweier Versionen
Bei Bedarf können Sie in die Dynatrace-Oberfläche wechseln und dort die Statistiken zu jeder Ihrer Versionen genauer betrachten und sie miteinander vergleichen.
Vergleich der Statistiken zu den Versionen in Dynatrace.
Fazit
Am Ende erhalten wir einen Dienst für «Monitoring als Dienstleistung», automatisiert im kontinuierlichen Integrationsprozess. Der Entwickler oder Tester muss lediglich eine Liste von Metriken in einer JSON-Datei definieren, während der Rest automatisch erfolgt. Wir erzielen eine transparente Qualitätskontrolle der Releases: alle Benachrichtigungen über Leistung, Ressourcenverbrauch oder architektonische Rückschritte.
Aufgabe 2. Automatisierung der Qualitätskontrolle von Software in der Produktionsumgebung
Wir haben also das Problem gelöst, wie wir den Überwachungsprozess in der Testphase im Pipeline automatisieren können. Dadurch minimieren wir den Prozentsatz an fehlerhaften Versionen, die in die Produktionsumgebung gelangen.
Was tun, wenn schadhafter Code dennoch in die Produktion gelangt oder einfach etwas ausfällt? Unser Ideal wäre, dass es Mechanismen zur automatischen Problemerkennung gibt und das System, wenn möglich, seine Funktionsfähigkeit selbst wiederherstellt, zumindest nachts.
Dafür müssen wir, analog zum vorherigen Abschnitt, automatische Qualitätssicherungsprüfungen für Software in der Produktionsumgebung einplanen und Szenarien für die Selbstwiederherstellung des Systems entwickeln.
Automatische Fehlerbehebung als Code
In den meisten Unternehmen existiert bereits eine Sammlung von Wissen über verschiedene gängige Probleme sowie eine Liste von Maßnahmen zu deren Behebung, wie zum Beispiel das Neustarten von Prozessen, die Bereinigung von Ressourcen, das Zurücksetzen von Versionen, die Wiederherstellung falscher Konfigurationsänderungen, die Anpassung der Anzahl der Komponenten im Cluster, das Umschalten zwischen blauen oder grünen Verläufen und mehr.
Obwohl diese Anwendungsfälle vielen Teams seit Jahren bekannt sind, haben nur wenige darüber nachgedacht und investiert, um sie zu automatisieren.
Wenn man darüber nachdenkt, gibt es bei der Implementierung von Prozessen zur Selbstwiederherstellung der Anwendungsfunktionalität nichts besonders Kompliziertes. Es ist notwendig, die bereits bekannten Arbeitsabläufe Ihrer Administratoren als Codeszenarien darzustellen (das Konzept der „Selbstkorrektur als Code“), die Sie zuvor für jeden spezifischen Fall erstellt haben. Die Automatisierungsszenarien sollten auf die Beseitigung der Ursachen des Problems abzielen. Sie legen selbst die geeigneten Maßnahmen zur Reaktion auf den Vorfall fest.
Als Auslöser für das Starten des Skripts kann jede Metrik aus Ihrem Überwachungssystem dienen. Entscheidend ist, dass diese Metriken genau bestimmen, wenn etwas schief läuft, da man in einer produktiven Umgebung falsche Auslösungen vermeiden möchte.
Sie können jedes System oder eine Kombination von Systemen verwenden: Prometheus, ELK Stack, Zabbix usw. Ich werde jedoch einige Beispiele basierend auf der APM-Lösung (in diesem Fall Dynatrace) anführen, die Ihnen ebenfalls das Leben erleichtern wird.
Zunächst einmal finden Sie hier alles, was die Anwendungsleistung betrifft. Die Lösung bietet Hunderte von Metriken auf verschiedenen Ebenen, die Sie als Trigger verwenden können:
- Benutzerebene (Browser, mobile Anwendungen, IoT-Geräte, Nutzerverhalten, Konversion usw.);
- Service- und Betriebsebene (Leistung, Verfügbarkeit, Fehler usw.);
- Anwendungsinfrastrukturebene (Host-OS-Metriken, JMX, MQ, Webserver usw.);
- Plattformebene (Virtualisierung, Cloud, Container usw.).
Überwachungslevels in Dynatrace.
Zweitens, wie ich bereits erwähnt habe, verfügt Dynatrace über eine offene API, die eine einfache Integration mit verschiedenen Drittanbietersystemen ermöglicht. Zum Beispiel können Benachrichtigungen an ein Automatisierungssystem gesendet werden, wenn festgelegte Kontrollparameter überschritten werden.
Im Folgenden finden Sie ein Beispiel für die Interaktion mit Ansible.
Ich werde nun einige Beispiele für mögliche Automatisierungen geben. Dies sind nur einige Anwendungsfälle; die Liste in Ihrer Umgebung könnte lediglich durch Ihre Vorstellungskraft und die Möglichkeiten Ihrer Monitoring-Tools begrenzt sein.
1. Schlechtes Deployment – Rollback der Version
Selbst wenn wir alles sehr gut in einer Testumgebung überprüfen, besteht immer die Möglichkeit, dass ein neues Release Ihre Anwendung in der Produktionsumgebung beeinträchtigt. Der menschliche Faktor bleibt unberücksichtigt.
Im nächsten Diagramm sehen wir, dass es einen deutlichen Anstieg der Ausführungszeiten im Service gibt. Der Beginn dieses Anstiegs fällt mit dem Zeitpunkt des Deployments der Anwendung zusammen. Wir übermitteln all diese Informationen als Ereignisse an das Automatisierungssystem. Wenn die Funktionsfähigkeit des Services nach der von uns festgelegten Zeit nicht wiederhergestellt ist, wird automatisch ein Skript ausgeführt, das die Version auf die frühere zurücksetzt.
Degradation der Leistungsfähigkeit nach dem Deployment.
2. Ressourcenlast bei 100% – Knoten zur Routing hinzugefügt.
Im nächsten Beispiel erkennt das Überwachungssystem, dass bei einer der Komponenten die CPU-Auslastung bei 100% liegt.
CPU-Auslastung 100%
Bei diesem Ereignis sind mehrere Szenarien möglich. Beispielsweise überprüft das Monitoringsystem zusätzlich, ob der Ressourcenmangel mit einer erhöhten Last auf dem Dienst zusammenhängt. Wenn ja, wird ein Skript ausgeführt, das automatisch einen Knoten in die Routing-Tabelle hinzufügt, wodurch die Gesamtfunktionalität des Systems wiederhergestellt wird.
Skalierung nach einem Vorfall
3. Kein Speicherplatz auf der Festplatte – Festplattensäuberung
Ich denke, viele dieser Prozesse sind bereits automatisiert. Auch mit APM lässt sich der verfügbare Speicherplatz im Speichersystem überwachen. Bei fehlendem Speicherplatz oder langsamen Festplattengeschwindigkeiten rufen wir ein Skript zur Bereinigung auf oder erweitern den Speicher.
Festplattenspeicher 100%
4. Geringe Benutzeraktivität oder niedrige Konversion – Wechsel zwischen dem blauen und dem grünen Branch
Ich treffe häufig auf Kunden, die zwei Umgebungen (Blue-Green Deploy) für Anwendungen in Produktionsumgebungen nutzen. Dies ermöglicht ein schnelles Wechseln zwischen den Versionen bei der Bereitstellung neuer Releases. Oft können nach dem Deployment radikale Änderungen auftreten, die nicht sofort auffallen. Dabei kann es sein, dass eine Verschlechterung der Leistung und Verfügbarkeit nicht beobachtet wird. Um schnell auf solche Änderungen zu reagieren, ist es besser, verschiedene Metriken zu verwenden, die das Nutzerverhalten widerspiegeln (Anzahl der Sitzungen und Aktionen der Nutzer, Conversion, Bounce-Rate). Im nächsten Bild sehen Sie ein Beispiel, in dem bei einem Rückgang der Conversion zwischen den Software-Versionen gewechselt wird.
Rückgang der Conversion nach dem Wechsel zwischen den Software-Versionen.
Automatische Problemerkennungsmethoden
Am Ende gebe ich noch ein weiteres Beispiel, warum ich Dynatrace so schätze.
In meinem Bericht zur Automatisierung der Qualitätsprüfung von Builds in einer Testumgebung haben wir alle Schwellenwerte manuell festgelegt. Für eine Testumgebung ist das in Ordnung; der Tester definiert die Kennzahlen vor jeder Überprüfung je nach Last. In der Produktionsumgebung ist es jedoch wünschenswert, dass Probleme automatisch erkannt werden, unter Berücksichtigung verschiedener Baseline-Mechanismen.
Dynatrace bietet interessante integrierte KI-Tools, die auf Mechanismen zur Erkennung anomaler Metriken (Baselining) basieren. Sie erstellen eine Interaktionskarte zwischen allen Komponenten, indem sie Ereignisse zuordnen und korrelieren, um Anomalien im Betrieb Ihres Dienstes zu identifizieren und detaillierte Informationen zu jedem Problem sowie zur Ursachenanalyse bereitzustellen.
Durch die automatische Analyse der Abhängigkeiten zwischen den Komponenten identifiziert Dynatrace nicht nur, ob der betroffene Dienst die Hauptursache ist, sondern auch dessen Abhängigkeit von anderen Diensten. Im folgenden Beispiel verfolgt und bewertet Dynatrace automatisch die Leistung jedes Dienstes im Rahmen von Transaktionen und identifiziert den Golang-Dienst als Hauptursache.
Beispiel für die Bestimmung der Hauptursache eines Ausfalls.
Das nächste Bild zeigt den Prozess der Überwachung von Problemen mit Ihrer Anwendung seit Beginn des Vorfalls.
Visualisierung des aufgetretenen Problems mit der Darstellung aller Komponenten und der ihnen zugeordneten Ereignisse.
Das Überwachungssystem hat eine vollständige Chronologie der Ereignisse in Bezug auf das aufgetretene Problem gesammelt. Im Fenster unter dem Zeitdiagramm sehen wir alle wichtigen Ereignisse für jede der Komponenten. Basierend auf diesen Ereignissen können Sie Automatisierungsverfahren in Form von Codeskripten definieren.
Ich empfehle außerdem, das Überwachungssystem in ein Service Desk oder ein Bug-Tracking-System zu integrieren. Im Falle eines Problems erhalten Entwickler umgehend umfassende Informationen zur Analyse auf Code-Ebene in der Produktionsumgebung.
Fazit
So haben wir eine CI/CD-Pipeline mit integrierten automatisierten Qualitätsprüfungen geschaffen. Dadurch minimieren wir die Anzahl minderwertiger Builds, erhöhen die Zuverlässigkeit des gesamten Systems und im Falle einer Störung setzen wir Wiederherstellungsmechanismen in Gang.
Es lohnt sich, in die Automatisierung der Softwarequalitätsüberwachung zu investieren. Dies ist nicht immer ein schneller Prozess, wird sich jedoch im Laufe der Zeit auszahlen. Ich empfehle, sofort nach der Lösung eines neuen Vorfalls in der Produktionsumgebung zu überlegen, welche Monitore für Tests in der Testumgebung hinzugefügt werden sollten, um zu verhindern, dass ein fehlerhafter Build in die Produktion gelangt. Außerdem sollte ein Skript zur automatischen Behebung dieser Probleme erstellt werden.
Ich hoffe, meine Beispiele helfen Ihnen bei Ihren Vorhaben. Außerdem würde mich interessieren, welche Metriken Sie für die Umsetzung der Selbstwiederherstellung von Systemen verwenden.
Quelle: habr.com
