guidance for self healing code on aws
1.0.0
Qualquer cliente que cria software inevitavelmente tem bugs, mas, ao mesmo tempo, muitas vezes deve competir com a pressão de desenvolvimento de produtos e recursos, o que muitas vezes os leva a despriorizar a resolução de bugs. Esses bugs podem distrair o foco dos desenvolvedores, degradar a experiência do usuário e causar métricas enganosas sobre a experiência do usuário. Mesmo que os clientes priorizem a correção de bugs, isso geralmente requer investimento empresarial na forma de experiência/engenheiros qualificados para dedicar uma grande quantidade de tempo e foco na compreensão e correção de bugs.
Este repositório contém um sistema ponta a ponta que combina Amazon CloudWatch, AWS Lambda e Amazon Bedrock para criar um sistema ponta a ponta que detecta e corrige bugs automaticamente para melhorar a confiabilidade do aplicativo e a experiência geral do cliente. O Log Driven Bug Fixer se conecta ao grupo de logs do Amazon CloudWatch Logs de um aplicativo por meio de uma assinatura do AWS Lambda. Quaisquer logs contendo erros de aplicação são enviados para processamento; onde uma função Lambda cria um prompt, incluindo o rastreamento de pilha e arquivos de código relevantes, e o envia ao Amazon Bedrock (Claude v1) para gerar correções de código. O código modificado é então enviado para o controle de origem (git) e cria uma solicitação pull para revisão e implantação.
A tabela a seguir fornece um exemplo de detalhamento de custos para implantação desta orientação com os parâmetros padrão na região Leste dos EUA (Norte da Virgínia) por um mês.
| Serviço AWS | Dimensões | Custo mensal [USD] |
|---|---|---|
| Amazon DynamoDB | Tamanho médio do item 0,5kb, 0,5 RCU e 1 WCU por mensagem | US$ 17,08 |
| Amazon CloudWatch | 33kb de logs gravados e armazenados por mensagem | US$ 8,77 |
| AWS Lambda | Tempo de execução de 45 segundos por mensagem de erro exclusiva | US$ 2,43 |
| Amazon SQS | 3 solicitações por mensagem, tamanho de mensagem de 1k | US$ 0,01 |
| Base Amazônica | 1.000 tokens de entrada, 1.000 tokens de saída | US$ 32,00 |
| Total | US$ 60,29 |
Esta solução oferece suporte a ambientes de construção em Mac ou Linux.
Esta implantação requer que você tenha acesso aos seguintes serviços da AWS:
Estas instruções de implantação são otimizadas para funcionar melhor no Mac ou no Amazon Linux 2023. A implantação em outro sistema operacional pode exigir etapas adicionais.
Reúna as informações a seguir sobre seu aplicativo existente, pois são informações necessárias para configurar a solução
Clone o repositório usando o comando git clone https://github.com/aws-solutions-library-samples/guidance-for-self-healing-code-on-aws.git
cd para a pasta repo cd guidance-for-self-healing-code-on-aws
Instale pacotes em requisitos usando o comando pip install -r requirement.txt
Exporte as variáveis de ambiente necessárias:
# 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
Execute novamente o script acima se precisar fazer alguma alteração. Alternativamente, você pode modificar diretamente os valores do SSM Parameter Store que são armazenados sob o prefixo ${PARAMETER_STORE_PREFIX}.
# Create a deployment package (Lambda function source code)
cloudformation/package.sh
# Deploy the CloudFormation template
cloudformation/deploy.sh
Abra o console do CloudFormation e verifique o status do modelo com o nome da pilha especificada na etapa 4 das etapas de implantação.
Ao receber um rastreamento de pilha do Python no grupo de logs do Amazon CloudWatch do seu aplicativo configurado na Etapa 6, uma solicitação pull será criada no sistema de controle de origem. Observe que o processamento pode levar vários minutos para ser concluído. Se quiser uma validação rápida da solução, você pode injetar um erro em seu aplicativo existente, o que pode resultar em um rastreamento de pilha python nos logs do seu aplicativo
Exemplo de solicitação pull de saída no Github:
Esta orientação é um projeto de amostra voltado para bases de código Python 3.9+. Existem outras oportunidades para ampliar e aprimorar este sistema. Algumas sugestões de próximos passos:
src/handlers/providers para refinar as respostas do LLMsrc/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}
Os clientes são responsáveis por fazer a sua própria avaliação independente das informações contidas nesta Orientação. Esta Orientação: (a) é apenas para fins informativos, (b) representa as ofertas e práticas atuais de produtos da AWS, que estão sujeitas a alterações sem aviso prévio, e (c) não cria quaisquer compromissos ou garantias da AWS e suas afiliadas, fornecedores ou licenciantes. Os produtos ou serviços da AWS são fornecidos “no estado em que se encontram”, sem garantias, representações ou condições de qualquer tipo, expressas ou implícitas. As responsabilidades e obrigações da AWS para com seus clientes são controladas pelos contratos da AWS, e esta Orientação não faz parte nem modifica qualquer acordo entre a AWS e seus clientes.
