Aktuell ist das Thema DevOps in aller Munde. Die kontinuierliche Integrations- und Liefer-Pipeline wird von allen implementiert, die sich die Mühe machen. Doch die meisten schenken der Sicherstellung der Zuverlässigkeit der Informationssysteme in den 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ätsprüfungen und der Implementierung möglicher Szenarien für deren „Selbstwiederherstellung“ sprechen.
Ich arbeite als Ingenieur in der Abteilung für IT-Services im Unternehmen . Mein Fachgebiet ist die Implementierung verschiedener Systeme zur Überwachung der Anwendungsleistung und -verfügbarkeit. Ich stehe häufig im Austausch mit IT-Kunden aus unterschiedlichen Marktsegmenten zu aktuellen Fragen der Überwachung der Qualität ihrer IT-Services. Die Hauptaufgabe besteht darin, die Zyklen eines Releases zu minimieren und die Frequenz ihrer Veröffentlichungen zu erhöhen. Das klingt natürlich gut: Mehr Releases – mehr neue Funktionen – mehr zufriedene Nutzer – mehr Gewinn. Doch in der Praxis läuft nicht immer alles reibungslos. Bei rasantem Deployment taucht sofort die Frage nach der Qualität unserer Releases auf. Selbst bei vollautomatisierten Pipelines ist eines der größten Probleme der Übergang von Services aus der Testphase in die Produktion, ohne die Betriebszeit und die Interaktion der Nutzer mit der Anwendung zu beeinträchtigen.
Aus zahlreichen Gesprächen mit Kunden kann ich sagen, dass die Qualitätskontrolle der Releases, die Zuverlässigkeit der Anwendung und die Möglichkeit ihrer „Selbstwiederherstellung“ (zum Beispiel das Zurücksetzen auf eine stabile Version) in den verschiedenen Phasen der CI/CD-Pipeline zu den drängendsten und relevantesten Themen gehören.
Kürzlich arbeitete ich selbst auf der Kundenseite – im Supportdienst einer Online-Banking-Anwendung. In der Architektur unserer Anwendung wurden viele selbst entwickelte Mikrodienste eingesetzt. Das Traurige ist, dass nicht alle Entwickler mit den hohen Entwicklungsgeschwindigkeiten Schritt halten konnten, was die Qualität einiger Mikrodienste beeinträchtigte und komische Spitznamen für sie und ihre Schöpfer hervorrief. Es gab Gerüchte darüber, aus welchen Materialien diese Produkte hergestellt werden.
„Aufgabenstellung“
Die hohe Frequenz der Releases und die Vielzahl an Mikrodiensten erschweren das Verständnis der Gesamtfunktionalität der Anwendung sowohl in der Test- als auch in der Betriebsphase. Änderungen erfolgen kontinuierlich und es ist sehr schwierig, sie ohne gute Überwachungswerkzeuge zu kontrollieren. Häufig sitzen die Entwickler nach einem nächtlichen Release am Morgen wie auf einem Pulverfass und warten darauf, dass nichts kaputtgeht, obwohl alle Tests in der Testphase erfolgreich waren.
Es gibt noch einen Punkt. In der Testphase wird die Funktionsfähigkeit der Software überprüft: die Ausführung der Hauptfunktionen der Anwendung und das Fehlen von Fehlern. Qualitative Leistungsbewertungen sind entweder nicht vorhanden oder berücksichtigen nicht alle Aspekte des Betriebs der Anwendung und der Integrationsschicht. Einige Metriken werden möglicherweise überhaupt nicht überprüft. Infolgedessen erfährt der technische Support erst von Problemen in der Produktionsumgebung, wenn reale Benutzer zu reklamieren beginnen. Es ist wünschenswert, den Einfluss von minderwertiger Software auf die Endbenutzer zu minimieren.
Ein Lösungsansatz besteht darin, Prozesse zur Qualitätskontrolle der Software in verschiedenen Phasen der CI/CD-Pipeline einzuführen und verschiedene Szenarien zur Wiederherstellung des Systems im Falle von Störungen hinzuzufügen. Wir denken auch daran, dass wir DevOps haben. Das Geschäft erwartet, dass neue Produkte so schnell wie möglich bereitgestellt werden. Daher müssen all unsere Kontrollen und Szenarien automatisiert werden.
Die Aufgabe wird in zwei Komponenten unterteilt:
- Qualitätskontrolle der Builds in der Testphase (den Prozess des Auffindens minderwertiger Builds automatisieren);
- Qualitätskontrolle der Software in der Produktionsumgebung (Mechanismen zur automatischen Erkennung von Problemen und mögliche Szenarien für deren Selbstwiederherstellung).
Werkzeug zur Überwachung und Sammlung von Metriken
Um die genannten Aufgaben zu realisieren, wird ein Überwachungssystem benötigt, das in der Lage ist, Probleme zu erkennen und sie an Automatisierungssysteme in verschiedenen Phasen der CI/CD-Pipeline zu übermitteln. Positiv wäre es auch, wenn dieses System nützliche Metriken für verschiedene Teams bereitstellt: Entwicklung, Testing, Betrieb. Und es wäre großartig, wenn auch für das Geschäft.
Zur Sammlung von Metriken kann eine Kombination verschiedener Systeme (Prometheus, ELK Stack, Zabbix usw.) verwendet werden, aber meiner Meinung nach eignen sich für diese Aufgaben am besten Lösungen der APM-Klasse (), die Ihr Leben erheblich erleichtern können.
Im Rahmen meiner Arbeit im Support habe ich ein ähnliches Projekt begonnen, indem ich eine APM-Lösung von Dynatrace verwendet habe. Jetzt, da ich in einem Integrator arbeite, kenne ich den Markt für Überwachungssysteme ziemlich gut. Meine subjektive Meinung: Dynatrace eignet sich am besten zur Lösung solcher Aufgaben.
Die Dynatrace-Lösung bietet eine horizontale Darstellung jeder Benutzeraktion mit einer tiefen Detailtiefe bis zur Ausführungsebene des Codes. Es ist möglich, die gesamte Interaktionskette zwischen verschiedenen Informationsdiensten zu verfolgen: von den Frontend-Web- und mobilen Anwendungen über die Backend-Anwendungsserver und die Integrationsschicht bis hin zum spezifischen Datenbankaufruf.
. Automatische Erstellung aller Abhängigkeiten zwischen den Systemkomponenten
. Automatische Erkennung und Erstellung des Pfades der Serviceoperation
Wir denken auch daran, dass wir uns mit verschiedenen Automatisierungstools integrieren müssen. Hier bietet die Lösung eine praktische API, die es ermöglicht, verschiedene Metriken und Ereignisse zu senden und zu empfangen.
Kommen wir nun zu einer detaillierteren Betrachtung, wie die gestellten Aufgaben mit Hilfe des Systems Dynatrace gelöst werden 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 Anwendungsbereitstellungskette zu finden. Nur „gute“ Code-Bauten sollten in die Produktionsumgebung gelangen. Dazu müssen in Ihrem Pipeline während der Testphase zusätzliche Monitore zur Überprüfung der Qualität Ihrer Dienste integriert werden.
Betrachten wir Schritt für Schritt, wie dieser Prozess implementiert und automatisiert werden kann:
In der Abbildung sind die Schritte des automatisierten Softwarequalitätsprüfungsprozesses dargestellt:
- Einrichtung des Überwachungssystems (Installation von Agenten);
- Definition von Bewertungsereignissen für die Qualität Ihrer Software (Metriken und Grenzwerte) und deren Übermittlung an das Überwachungssystem;
- Last- und Leistungstests generieren;
- Sammlung von Daten über Leistung und Verfügbarkeit im Überwachungssystem;
- Übertragung von Testdaten, die auf 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 Ihre Testumgebung installiert werden. Die Dynatrace-Lösung hat dabei den Vorteil, dass sie einen universellen Agenten, den OneAgent, verwendet, der auf OS-Instanzen (Windows, Linux, AIX) installiert wird, Ihre Dienste automatisch erkennt und beginnt, Überwachungsdaten zu sammeln. Sie müssen den Agenten nicht separat für jeden Prozess konfigurieren. Das gleiche gilt für Cloud- und Containerplattformen. Auch den Installationsprozess der Agenten können Sie automatisieren. Dynatrace fügt sich hervorragend in das Konzept "Infrastructure as Code" ein (): es gibt bereits fertige Skripte und Anleitungen für alle gängigen Plattformen. Sie integrieren den Agenten in die Konfiguration Ihres Dienstes, und bei dessen Bereitstellung erhalten Sie sofort einen neuen Dienst mit bereits laufendem Agenten.
Schritt 2. Bestimmung der Qualitätsbewertungsereignisse Ihrer Software
Jetzt müssen Sie sich mit der Liste der Dienste und Geschäftsabläufe befassen. Es ist wichtig, genau die Benutzeroperationen zu berücksichtigen, die für Ihren Dienst geschäftskritisch sind. Ich empfehle, sich mit Geschäfts- und Systemanalytikern zu beraten.
Als Nächstes müssen Sie festlegen, welche Metriken Sie für die Überprüfung auf jedem Level einbeziehen möchten. Beispielsweise könnten dies die Ausführungszeit (unterteilt in Durchschnitt, Median, Perzentile usw.), Fehler (logische, servicebezogene, infrastrukturelle usw.) und verschiedene infrastrukturelle Metriken (speicherheap, Garbage Collector, Thread-Zahl usw.) sein.
Zur Automatisierung und zur Erleichterung der Nutzung für das DevOps-Team entsteht das Konzept "Monitoring as Code". Was ich damit meine ist, dass ein Entwickler/Testingenieur eine einfache JSON-Datei schreiben kann, die die Qualitätssicherungsindikatoren definiert.
Lassen Sie uns ein Beispiel für eine solche JSON-Datei betrachten. Als Schlüssel-Wert-Paar werden Objekte aus der Dynatrace-API verwendet (beschreibung der API können Sie hier einsehen ).
{
"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 einem Array von Definitionen für Zeitreihen (timeseries):
- timeseriesId – die zu überprüfende Metrik, wie zum Beispiel Response Time, Error count, Memory used usw.;
- aggregation — das Niveau der Aggregation der Metriken, in unserem Fall avg, aber Sie können jede für Sie erforderliche verwenden (avg, min, max, sum, count, percentile);
- tags – das Tag des Objekts im Überwachungssystem oder Sie können eine spezifische Objekt-ID angeben;
- severe und warning – diese Werte regulieren die Grenzwerte unserer Metriken. Wenn der Wert der Tests über den Grenzwert 'severe' hinausgeht, wird unser Build als nicht erfolgreich markiert.
In der folgenden Abbildung sehen Sie ein Beispiel für die Verwendung solcher Schwellenwerte.
Schritt 3. Lastgenerierung
Nachdem wir die Qualitätsstufen unseres Dienstes definiert haben, müssen wir eine Testlast generieren. Sie können ein beliebiges Ihnen geeignetes Testwerkzeug verwenden, z.B. Jmeter, Selenium, Neotys, Gatling usw.
Das Überwachungssystem Dynatrace ermöglicht das Erfassen verschiedener Metadaten aus Ihren Tests und erkennt, welcher Test zu welchem Release-Zyklus und zu welchem Dienst gehört. Es wird empfohlen, zusätzliche Header in die HTTP-Anfragen des Tests einzufügen.
In der folgenden Abbildung sehen Sie ein Beispiel, wie wir mit dem zusätzlichen Header X-Dynatrace-Test kennzeichnen, dass dieser Test zum Testen der Operation des Hinzufügens eines Produkts zum Warenkorb gehört.
Bei jedem Start eines Lasttests senden Sie zusätzliche Kontextinformationen an Dynatrace über die API-Ereignisse des CI/CD-Servers. Auf diese Weise kann das System unterschiedliche Tests voneinander unterscheiden.
. Ereignis im Überwachungssystem über den Start des Lasttests
Schritt 4-5. Datenerfassung zur Leistung und Übermittlung der Daten an das CI/CD-System
Zusammen mit dem generierten Test wird im Überwachungssystem ein Ereignis über die Notwendigkeit der Datensammlung zur Überprüfung der Qualitätskennzahlen übermittelt. Außerdem wird unsere JSON-Datei angegeben, in der die Schlüsselmetriken definiert sind.
Ereignis über die Notwendigkeit der Qualitätsprüfung der Software, die auf dem CI/CD-Server generiert wird, um in das Überwachungssystem gesendet zu werden
In unserem Beispiel wird das Ereignis zur Qualitätsprüfung genannt perfSigDynatraceReport (Performance_Signature) – das ist fertig für die Integration mit Jenkins, die von den Jungs von T-Systems Multimedia Solutions entwickelt wurden. Jedes Ereignis zum Start der Prüfung 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.
Ereignis im Überwachungssystem über den Start der Qualitätsprüfung des Builds.
Nach Abschluss des Tests werden alle Metriken zur Bewertung der Softwarequalität zurück in das kontinuierliche Integrationssystem, z. B. Jenkins, übertragen, das einen Bericht über die Ergebnisse erstellt.
Ergebnisstatistik zu den Builds auf dem CI/CD-Server.
Für jeden einzelnen Build sehen wir die Statistik für jede festgelegte Metrik während der gesamten Testdurchführung. Wir sehen auch, wenn es Verstöße gegen bestimmte Grenzwerte (Warnungen und schwere Schwellenwerte) gab. Basierend auf den Gesamtergebnissen wird der gesamte Build als stabil, unstabil oder fehlerhaft markiert. Darüber hinaus können Sie zur besseren Übersicht die aktuellen Builds mit vorherigen vergleichen.
Ansicht detaillierter Statistiken zu den Builds auf dem CI/CD-Server.
Detaillierter Vergleich von zwei Builds
Bei Bedarf kann man in die Dynatrace-Oberfläche wechseln und die Statistiken zu jedem Ihrer Builds detaillierter ansehen und untereinander vergleichen.
Vergleich der Statistiken zu den Builds in Dynatrace.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Am Ende erhalten wir den Service „Monitoring als Dienst“, automatisiert im kontinuierlichen Integrationsprozess. Der Entwickler oder Tester muss nur die Liste der Metriken in einer JSON-Datei festlegen, und der Rest geschieht automatisch. Wir erhalten eine transparente Qualitätskontrolle der Releases: alle Benachrichtigungen über Leistung, Ressourcennutzung oder architektonische Regressionen.
Aufgabe 2. Automatisierung der Softwarequalitätskontrolle in der Produktionsumgebung
Also haben wir die Aufgabe gelöst, wie wir den Monitoring-Prozess während der Testphase im Pipeline automatisieren können. So minimieren wir den Anteil an fehlerhaften Builds, die in die Produktionsumgebung gelangen.
Aber was ist zu tun, wenn schlechte Software doch in die Produktionsumgebung gelangt, oder einfach etwas nicht funktioniert? Für unser Utopia hätten wir es gerne, dass es Mechanismen zur automatischen Erkennung von Problemen gibt und dass das System seine Funktionsfähigkeit, wenn möglich, selbst wiederherstellt, wenigstens nachts.
Dafür müssen wir analog zum vorherigen Abschnitt automatische Qualitätsprüfungen von Software in der Produktionsumgebung vorsehen und Szenarien zur Selbstwiederherstellung des Systems einplanen.
Selbstkorrektur als Code
In den meisten Unternehmen gibt es bereits eine angesammelte Wissensdatenbank zu verschiedenen häufig auftretenden Problemen und eine Liste von Maßnahmen zu deren Behebung, wie z.B. das Neustarten von Prozessen, das Bereinigen von Ressourcen, das Zurücksetzen von Versionen, das Wiederherstellen fehlerhafter Konfigurationsänderungen, das Erhöhen oder Verringern der Anzahl von Komponenten im Cluster, das Umschalten des blauen oder grünen Pfades und andere.
Obwohl diese Anwendungsfälle vielen Teams, mit denen ich spreche, seit vielen Jahren bekannt sind, haben sich nur wenige Gedanken gemacht und investiert, um sie zu automatisieren.
Wenn man darüber nachdenkt, gibt es nichts Übermäßig Komplexes bei der Implementierung von Prozessen zur Selbstwiederherstellung der Anwendungsfunktionalität. Man muss lediglich die bereits bekannten Arbeitsabläufe Ihrer Administratoren in Form von Codeszenarien (das Konzept "Selbstkorrektur als Code") darstellen, die Sie im Voraus für jeden spezifischen Fall geschrieben haben. Die Szenarien zur automatischen Behebung sollten darauf abzielen, die Grundursache des Problems zu beseitigen. Sie legen die richtigen Reaktionen auf Vorfälle selbst fest.
Als Auslöser für das Starten eines Szenarios kann jede Kennzahl aus Ihrem Überwachungssystem dienen, wobei es wichtig ist, dass diese Kennzahlen genau definieren, dass etwas nicht stimmt, denn Sie möchten falsche Alarme in der Produktionsumgebung vermeiden.
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 (wieder als Beispiel Dynatrace) anführen, die Ihnen ebenfalls das Leben erleichtern wird.
Zunächst einmal gibt es hier alles, was die Betriebsbereitschaft aus der Perspektive der Anwendung betrifft. Die Lösung bietet Hunderte von Kennzahlen auf verschiedenen Ebenen, die Sie als Auslöser verwenden können:
- Benutzerlevel (Browser, mobile Anwendungen, IoT-Geräte, Verhalten der Benutzer, Konversion usw.);
- Service- und Betriebsniveau (Leistung, Verfügbarkeit, Fehler usw.);
- Anwendungsinfrastruktur-Level (OS-Metriken des Hosts, JMX, MQ, Web-Server usw.);
- Plattformlevel (Virtualisierung, Cloud, Container usw.).
Überwachungsstufen in Dynatrace.
Zweitens, wie ich bereits sagte, hat Dynatrace eine offene API, die eine sehr einfache Integration mit verschiedenen Drittanbietersystemen ermöglicht. Zum Beispiel das Senden einer Benachrichtigung an das Automatisierungssystem bei Überschreiten der Kontrollparameter.
Unten ist ein Beispiel für die Interaktion mit Ansible dargestellt.
Im Folgenden gebe ich einige Beispiele, welche Automatisierungen möglich sind. Dies ist nur ein Teil der Fälle; ihre Liste in Ihrer Umgebung kann allein durch Ihre Fantasie und die Möglichkeiten Ihrer Überwachungstools begrenzt werden.
1. Schlechtes Deployment – Versionsrücksetzung
Selbst wenn wir alles sehr gut in der Testumgebung überprüfen, besteht dennoch die Möglichkeit, dass ein neues Release Ihre Anwendung in der Produktionsumgebung zum Absturz bringt. Der menschliche Faktor ist nicht abzulehnen.
In der nächsten Abbildung sehen wir einen plötzlichen Anstieg der Ausführungszeiten von Operationen auf dem Dienst. Der Beginn dieses Anstiegs fällt mit dem Zeitpunkt des Deployments der Anwendung zusammen. All diese Informationen über Ereignisse senden wir in das Automatisierungssystem. Wenn die Funktionalität des Dienstes nach Ablauf der von uns festgelegten Zeit nicht normalisiert ist, wird automatisch ein Skript aufgerufen, das die Version auf die alte zurücksetzt.
Abnahme der Leistung von Operationen nach dem Deployment.
2. Ressourcenlast bei 100 % – Knoten zur Routing hinzufügen
Im folgenden Beispiel stellt das Überwachungssystem fest, dass auf einer der Komponenten eine CPU-Auslastung von 100 % vorliegt.
CPU-Auslastung 100%
Für dieses Ereignis sind mehrere verschiedene Szenarien möglich. Zum Beispiel überprüft das Überwachungssystem zusätzlich, ob der Mangel an Ressourcen mit einem Anstieg der Belastung des Dienstes zusammenhängt. Wenn ja, wird ein Skript ausgeführt, das automatisch einen Knoten zum Routing hinzufügt, wodurch die Funktionsfähigkeit des Systems insgesamt wiederhergestellt wird.
Skalierung nach einem Vorfall
3. Kein Speicherplatz auf der Festplatte – Festplattensäuberung
Ich denke, dass viele dieser Prozesse bereits automatisiert sind. Mit APM kann man ebenfalls den freien Speicherplatz im Speichersystem überwachen. Bei Platzmangel oder langsamer Datenträgergeschwindigkeit rufen wir ein Skript zur Bereinigung auf oder fügen Speicherplatz hinzu.
Festplattenspeicher 100%
4. Geringe Benutzeraktivität oder niedrige Konversion – Wechsel zwischen der blauen und grünen Branch
Ich treffe häufig auf Kunden, die zwei Umgebungen (blue-green deploy) für Anwendungen in der Produktionsumgebung verwenden. Das ermöglicht ein schnelles Umschalten zwischen den Branches bei der Bereitstellung neuer Versionen. Oft können nach dem Deployment gravierende Änderungen auftreten, die nicht sofort bemerkt werden. Die Degeneration der Leistung und Verfügbarkeit könnte dabei unbemerkt bleiben. Um schnell auf solche Änderungen zu reagieren, ist es besser, verschiedene Metriken zu verwenden, die das Verhalten der Benutzer widerspiegeln (Anzahl der Sitzungen und Aktionen der Benutzer, Konversion, Bounce-Rate). Im nächsten Bild sehen Sie ein Beispiel, bei dem der Wechsel zwischen den Software-Branches aufgrund eines Rückgangs der Konversion erfolgt.
Rückgang der Konversion nach dem Wechsel zwischen den Software-Branches.
Mechanismen zur automatischen Problemerkennung
Am Ende werde ich ein weiteres Beispiel anführen, warum ich Dynatrace am meisten schätze.
In einem Teil meiner Erzählung über die Automatisierung der Qualitätssicherung von Builds in der Testumgebung haben wir alle Schwellenwerte manuell festgelegt. Für die Testumgebung ist dies normal, der Tester bestimmt die Kennzahlen vor jeder Überprüfung in Abhängigkeit von der Last. In der Produktionsumgebung ist es wünschenswert, dass Probleme automatisch unter Berücksichtigung verschiedener Baseline-Mechanismen erkannt werden.
Dynatrace verfügt über interessante integrierte KI-Tools, die auf der Grundlage von Mechanismen zur Erkennung anomaler Metriken (Baselining) und der Erstellung einer Interaktionskarte zwischen allen Komponenten, indem sie Ereignisse untereinander zuordnen und korrelieren, Anomalien im Betrieb Ihres Dienstes erkennen und detaillierte Informationen zu jedem Problem sowie zur zugrunde liegenden Ursache bereitstellen.
Durch die automatische Analyse der Abhängigkeiten zwischen den Komponenten stellt Dynatrace nicht nur fest, ob der problematische Dienst die Hauptursache ist, sondern auch seine Abhängigkeit von anderen Diensten. Im folgenden Beispiel verfolgt und bewertet Dynatrace automatisch die Leistung jedes Dienstes während der Durchführung von Transaktionen und identifiziert den Golang-Dienst als Hauptursache.
Beispiel für die Bestimmung der Hauptursache eines Ausfalls.
Im nächsten Bild sehen Sie den Prozess der Überwachung von Problemen in Ihrer Anwendung seit Beginn des Vorfalls.
Visualisierung des aufgetretenen Problems mit der Darstellung aller Komponenten und der Ereignisse auf ihnen.
Das Überwachungssystem hat eine vollständige Chronologie der Ereignisse zu dem aufgetretenen Problem gesammelt. Im Fenster unter dem Zeitdiagramm sehen wir alle Schlüssereignisse jeder der Komponenten. Basierend auf diesen Ereignissen können Sie Verfahren für automatische Korrekturen in Form von Code-Skripten festlegen.
Zusätzlich empfehle ich, das Überwachungssystem mit dem Service Desk oder einem Bug-Tracker zu integrieren. Bei Auftreten eines Problems erhalten die Entwickler sofort vollständige Informationen zur Analyse auf Codeebene in der Produktionsumgebung.
Fazit
Am Ende haben wir eine CI/CD-Pipeline mit integrierten automatisierten Prüfungen der Softwarequalität im Pipeline. Wir minimieren die Anzahl fehlerhafter Builds, erhöhen die Zuverlässigkeit des Systems insgesamt und wenn die Betriebsfähigkeit des Systems dennoch beeinträchtigt wird, aktivieren wir die Mechanismen zu dessen Wiederherstellung.
Es lohnt sich definitiv, Anstrengungen in die Automatisierung der Überwachung der Softwarequalität zu investieren. Es ist nicht immer ein schneller Prozess, aber mit der Zeit wird es Früchte tragen. Ich empfehle, nach der Lösung eines neuen Vorfalls in der Produktionsumgebung sofort zu überlegen, welche Monitore für Tests in der Testumgebung hinzugefügt werden sollten, um zu vermeiden, dass fehlerhafte Builds in die Produktion gelangen, sowie ein Skript zur automatischen Behebung dieser Probleme zu erstellen.
Ich hoffe, meine Beispiele helfen Ihnen bei Ihren Bestrebungen. Ich wäre auch daran interessiert, Ihre Beispiele verwendeter Metriken zur Umsetzung der Selbstwiederherstellung der Betriebsfähigkeit von Systemen zu sehen.
Quelle: habr.com
