guidance for self healing code on aws
1.0.0
Jeder Kunde, der Software erstellt, weist zwangsläufig Fehler auf, muss aber gleichzeitig häufig mit dem Druck bei der Produkt- und Funktionsentwicklung konkurrieren, der ihn häufig dazu zwingt, der Behebung von Fehlern eine geringere Priorität einzuräumen. Diese Fehler können den Fokus der Entwickler ablenken, das Benutzererlebnis verschlechtern und zu irreführenden Messwerten über das Benutzererlebnis führen. Selbst wenn Kunden der Behebung von Fehlern Priorität einräumen, erfordert dies häufig geschäftliche Investitionen in Form von Erfahrung/qualifizierten Ingenieuren, die viel Zeit und Konzentration auf das Verständnis und die Behebung von Fehlern verwenden.
Dieses Repo enthält ein End-to-End-System, das Amazon CloudWatch, AWS Lambda und Amazon Bedrock kombiniert, um ein End-to-End-System zu schaffen, das Fehler automatisch erkennt und behebt, um die Anwendungszuverlässigkeit und das gesamte Kundenerlebnis zu verbessern. Der Log Driven Bug Fixer verbindet sich über ein AWS Lambda-Abonnement mit der Amazon CloudWatch Logs-Protokollgruppe einer Anwendung. Alle Protokolle, die Anwendungsfehler enthalten, werden zur Verarbeitung gesendet; Dabei erstellt eine Lambda-Funktion eine Eingabeaufforderung, einschließlich der Stapelverfolgung und relevanter Codedateien, und sendet sie dann an Amazon Bedrock (Claude v1), um Codekorrekturen zu generieren. Der geänderte Code wird dann in die Quellcodeverwaltung (Git) übertragen und erstellt eine Pull-Anfrage zur Überprüfung und Bereitstellung.
Die folgende Tabelle enthält eine Beispielaufschlüsselung der Kosten für die Bereitstellung dieses Leitfadens mit den Standardparametern in der Region USA Ost (Nord-Virginia) für einen Monat.
| AWS-Dienst | Abmessungen | Monatliche Kosten [USD] |
|---|---|---|
| Amazon DynamoDB | Durchschnittliche Elementgröße 0,5 KB, 0,5 RCU und 1 WCU pro Nachricht | 17,08 $ |
| Amazon CloudWatch | Pro Nachricht werden 33 KB Protokolle geschrieben und gespeichert | 8,77 $ |
| AWS Lambda | 45 Sekunden Ausführungszeit pro eindeutiger Fehlermeldung | 2,43 $ |
| Amazon SQS | 3 Anfragen pro Nachricht, 1.000 Nachrichtengröße | 0,01 $ |
| Amazonas-Grundgestein | 1.000 Eingabe-Tokens, 1.000 Ausgabe-Tokens | 32,00 $ |
| Gesamt | 60,29 $ |
Diese Lösung unterstützt Build-Umgebungen in Mac oder Linux.
Für diese Bereitstellung ist es erforderlich, dass Sie Zugriff auf die folgenden AWS-Dienste haben:
Diese Bereitstellungsanweisungen sind so optimiert, dass sie optimal auf Mac oder Amazon Linux 2023 funktionieren. Für die Bereitstellung in einem anderen Betriebssystem sind möglicherweise zusätzliche Schritte erforderlich.
Sammeln Sie die folgenden Informationen zu Ihrer vorhandenen Anwendung, da diese Eingaben zur Konfiguration der Lösung erforderlich sind
Klonen Sie das Repo mit dem Befehl git clone https://github.com/aws-solutions-library-samples/guidance-for-self-healing-code-on-aws.git
cd in den Repo-Ordner cd guidance-for-self-healing-code-on-aws
Installieren Sie Pakete in Anforderungen mit dem Befehl pip install -r requirement.txt
Exportieren Sie die erforderlichen Umgebungsvariablen:
# CloudFormation stack name.
export STACK_NAME=self-healing-code
# S3 bucket to store zipped Lambda function code for deployments.
# Note: the S3 bucket must be in the same region as the CloudFormation stack deployment region.
export DEPLOYMENT_S3_BUCKET=<NAME OF YOUR S3 BUCKET>
# All variables and secrets for this project will be stored under this prefix.
# You can define a different value if it's already in use.
export PARAMETER_STORE_PREFIX=/${STACK_NAME}/
pip3 install -r requirements.txt
# Follow the resulting series of prompts to store configuration details in SSM Parameter Store. This steps will use information gathered during Step 1
python3 bin/configure.py
Führen Sie das obige Skript erneut aus, wenn Sie Änderungen vornehmen müssen. Alternativ können Sie die SSM-Parameterspeicherwerte, die unter dem Präfix ${PARAMETER_STORE_PREFIX} gespeichert sind, direkt ändern.
# Create a deployment package (Lambda function source code)
cloudformation/package.sh
# Deploy the CloudFormation template
cloudformation/deploy.sh
Öffnen Sie die CloudFormation-Konsole und überprüfen Sie den Status der Vorlage mit dem Namen des Stacks, der in Schritt 4 der Bereitstellungsschritte angegeben wurde.
Nach dem Empfang eines Python-Stack-Trace in der in Schritt 6 konfigurierten Amazon CloudWatch-Protokollgruppe Ihrer Anwendung wird im Quellcodeverwaltungssystem eine Pull-Anfrage erstellt. Beachten Sie, dass die Verarbeitung mehrere Minuten dauern kann. Wenn Sie eine schnelle Validierung der Lösung wünschen, können Sie einen Fehler in Ihre vorhandene Anwendung einschleusen, der zu einem Python-Stack-Trace in den Protokollen Ihrer Anwendung führen kann
Beispiel für eine Ausgabe-Pull-Anfrage in Github:
Bei dieser Anleitung handelt es sich um ein Beispielprojekt, das auf Python 3.9+-Codebasen abzielt. Es bestehen weitere Möglichkeiten, dieses System zu erweitern und zu verbessern. Einige vorgeschlagene nächste Schritte:
src/handlers/providers um die Antworten von LLMs zu verfeinernsrc/handlers/source_code.py )src/providers/source_code.py ). aws cloudformation delete-stack --stack-name ${STACK_NAME}
aws ssm delete-parameters-by-path --path ${PARAMETER_STORE_PREFIX}
Kunden sind dafür verantwortlich, ihre eigene unabhängige Bewertung der Informationen in dieser Anleitung vorzunehmen. Diese Anleitung: (a) dient nur zu Informationszwecken, (b) stellt die aktuellen Produktangebote und -praktiken von AWS dar, die ohne Vorankündigung geändert werden können, und (c) stellt keine Verpflichtungen oder Zusicherungen von AWS und seinen verbundenen Unternehmen, Lieferanten usw. dar Lizenzgeber. AWS-Produkte oder -Dienste werden „wie besehen“ ohne ausdrückliche oder stillschweigende Garantien, Zusicherungen oder Bedingungen jeglicher Art bereitgestellt. Die Verantwortlichkeiten und Verbindlichkeiten von AWS gegenüber seinen Kunden werden durch AWS-Vereinbarungen geregelt, und dieser Leitfaden ist weder Teil einer Vereinbarung zwischen AWS und seinen Kunden noch ändert er diese.
