INTRODUÇÃO
Este é o episódio 1 da temporada 2 da série “Estudo de
Caso”, com foco na solução de problema em serviço de infraestrutura na nuvem,
utilizando Inteligência Artificial (IA) e o Método de Análise e Solução de
Problemas (MASP).
Estudo de Caso
Objetivo
Solucionar um problema de Tecnologia da Informação (TI), usando
o Método de Análise e Solução de Problema (MASP), no contexto abaixo.
Contexto
O contexto é a publicação de uma versão de um aplicativo no
ambiente de homologação, no serviço de infraestrutura na nuvem AWS, no servidor
S2.
Durante a publicação, o desenvolvedor observou a ocorrência
de uma mensagem de erro e constatou que a versão do aplicativo não foi
atualizada.
O desenvolvedor está ciente de que houve mudanças na
infraestrutura de serviço na nuvem, para desacoplar o Frontend (React) do
Backend (Django), e que estas mudanças podem ter causado o erro.
As mudanças para o desacoplamento foram feitas pelo profissional
que é especialista no serviço de infraestrutura na nuvem.
As mudanças no aplicativo foram feitas pelo desenvolvedor.
1 PERSONAGEM
1.1 Qual o papel do Chatbot de IA? Profissional da área de
TI especialista no serviço de infraestrutura na nuvem AWS e que tem experiência
de desacoplamento do Frontend do Backend neste ambiente.
2 IDENTIFICAÇÃO DO PROBLEMA
Definir claramente o problema
(diferença entre o que é e o que deveria ser). Utilizar 5W1H.
2.1 [What?] - O que aconteceu diferente do
esperado?
Apareceu esta mensagem de erro, no log do comando ssh, no
qual é executado o comando “git pull” da Branch do aplicativo para o servidor AWS
S2:
ERROR: Service 'devweb' failed to build: COPY failed: stat
/var/lib/docker/tmp/docker-builder477234485/crontab.txt: no such file or
directory
2.2 [Who?] - Quem iniciou a execução? O
desenvolvedor
2.3 [When?] - Evento que iniciou a execução? Foi
a execução do comando ssh no terminal Power Shell.
2.4 [Where?] - Onde a execução parou? Parou no Step 10/12 : COPY crontab.txt
/etc/cron.d/redecount-cron
2.5 [Why?] - Por que a execução parou? Não
sei, mas existe uma informação importante. O especialista na infraestrutura
implementou uma grande mudança, que foi o desacoplamento do Front End (React
JS) do Back End (Python/Django). A execução estava sendo feita corretamente,
até que ocorreu esse problema. Provavelmente, foi realizada alguma pequena mudança
ou ajuste, no desacoplamento.
2.6 [How?] - Como é o procedimento, passo a
passo, para reproduzir o erro? Seguem abaixo os steps.
Após executar o comando ssh no terminal, apareceram várias
mensagens informativas, entre as quais, estas abaixo, que informam os passos executados.
Step 1/12 : FROM python:3.11.3 ---> 0a6cd0db41a4
Step 2/12 : MAINTAINER NondasJr
<nondasjuniorsk8@gmail.com> ---> Using cache ---> f5bafb8b8b50
Step 3/12 : ENV PYTHONUNBUFFERED 1 ---> Running in
71f1da189662 ---> 0c64783e3c05
Removing intermediate container 71f1da189662
Step 4/12 : RUN apt-get update && apt-get install -y
cron ---> Running in 712bf9cca95d
Step 5/12 : RUN mkdir /code ---> Running in 95f33a9dedce
---> 1837679cb392
Removing intermediate container 95f33a9dedce
Step 6/12 : WORKDIR /code ---> add1a291eeb5
Removing intermediate container 7b268465d5a9
Step 7/12 : ADD requirements.txt /code/ ---> a6f9ef980307
Step 8/12 : RUN pip install -r requirements.txt --->
Running in 4b789b5f6635
Step 9/12 : ADD . /code/ ---> 7d06c2e59d9b
Step 10/12 : COPY crontab.txt /etc/cron.d/redecount-cron
3 OBSERVAÇÃO
Investigar as características específicas do
problema com uma visão ampla e sob vários pontos de vista. Utilizar Diagrama de
Ishikawa ou Causa e Efeito.
3.1 [Pessoas?] Como este item influencia no problema?
3.1.1 Falta de treinamento adequado da equipe? Não. A pessoa
responsável pela infraestrutura é treinada e especializada. Mas o desenvolvedor
não conhece a infraestrutura e precisa entender o erro que aconteceu, para colaborar
com o especialista na solução do problema.
3.1.2 Problemas de comunicação entre membros da equipe? Não.
3.1.3 Ausência de revisões? Não
3.2 [Recurso?] Como este item influencia no problema?
3.2.1 Computador desatualizado? Não
3.2.2 Aplicativo desatualizado ou instável? Não
3.2.3 Configurações do ambiente incorretas ou
inconsistentes? Não sei
3.2.4 Configuração incorreta das variáveis de ambiente? Não
sei
3.2.5 Incompatibilidades no ambiente, ou seja, diferenças
entre os ambientes onde o processo é executado? Não sei
3.2.6 Condições de rede, ou seja, problemas de conectividade
que afetam a execução do processo? Não sei.
3.3 [Método?] Como este item influencia no problema?
3.3.1 Práticas de execução inadequadas? Não sei
3.3.2 Falta de documentação do Procedimento Operacional
Padrão? Não. Mas, talvez a documentação esteja desatualizada.
3.3.3 Processo de verificação deficiente, com testes
insuficientes ou mal planejados? Não
3.4 [Entrada?] Como este item influencia no problema?
3.4.1 Informações de terceiros com falhas ou incompatíveis?
Não
3.4.2 Informações de terceiros instáveis ou desatualizadas?
Não
3.4.3 Dependências de Informações de terceiros inadequadas
ou desatualizadas? Não sei.
3.5 [Saída?] Como este item influencia no problema?
3.5.1 Resultado incompleto, impreciso ou inválido? Não
3.5.2 Resultado indisponível no local esperado? Sim
3.5.3 Resultado rejeitado por quem vai utilizá-lo? Não
3.6 [Medição?] Como este item influencia no problema?
3.6.1 Falta de monitoramento adequado do desempenho? Não
3.6.2 Falta de métricas claras e consistentes para avaliar a
qualidade do processo? Não
3.6.3 Ausência de ferramentas de análise para detectar
problemas no processo? Não
4 ANÁLISE
Descobrir as causas fundamentais. Utilizar
"5 Porquês".
4.1 Para cada problema encontrado no item 3 OBSERVAÇÃO,
perguntar 5 vezes o porquê do problema ou defeito ter ocorrido, a fim de
descobrir a sua real causa, ou seja, a causa raiz.
4.1.1 Pessoas: Por que a forma de executar o trabalho
influencia no problema? Porque o roteiro desatualizado para fazer o upload para
o S2 pode ter causado o erro.
4.1.2 Recurso: Por que os recursos utilizados podem ter
influência no problema? Porque houve mudança na infraestrutura para desacoplar
o Front End do Back End.
4.1.3 Método: Por que o método de configuração da
infraestrutura do S2 influencia no problema? Porque a documentação pode estar
desatualizada.
4.1.4 Entrada: Por que a qualidade da informação de entrada
influencia no problema? Não influencia
4.1.5 Saída: Por que a qualidade da informação de saída
influencia no problema? Não influencia
4.1.6 Medição: Por que o modo de medir o desenvolvimento de
atividades influencia no problema? Não influencia
COMANDO PARA O CHATBOT DE IA
Crie um Plano de Ação para resolver o problema
especificado acima e, se possível, ensine como executar as ações.
O Plano de Ação deve ter 5 etapas: Iniciação, Planejamento,
Execução, Monitoramento e Controle e Encerramento.
Cada etapa do Plano de Ação deve ter 3 grupos de tarefas
executáveis: Entrada, Passos, Saída.
Cada Entrada deve especificar, além de dados e recursos
disponíveis, as pré-condições, que são os requisitos para iniciar a execução
dos passos.
Cada Saída deve especificar, além de dados e recursos
disponibilizados, as pós-condições, que são os requisitos para considerar a
execução encerrada com sucesso.
Resposta do Chatbot de IA Google Gemini
Olá! Que bom que você está utilizando o MASP para solucionar
esse problema na publicação do seu aplicativo. Com certeza, seguindo as etapas
do método, vamos encontrar a causa raiz e implementar uma solução eficaz.
1 PERSONAGEM
1.1 Meu papel aqui é o de um profissional de TI
especialista no serviço de infraestrutura na nuvem AWS, com experiência em desacoplamento
de Frontend e Backend nesse ambiente. Posso te ajudar a entender as
possíveis causas do erro sob a perspectiva da infraestrutura e orientar nas
ações para a solução.
2 IDENTIFICAÇÃO DO PROBLEMA
O problema central é a falha na atualização da versão do
aplicativo no ambiente de homologação (servidor S2 na AWS), evidenciada
pela mensagem de erro durante a execução do comando git pull.
- [What?]
A publicação da nova versão do aplicativo falhou, e a versão antiga
permanece no servidor S2. A mensagem de erro específica é: ERROR: Service
'devweb' failed to build: COPY failed: stat
/var/lib/docker/tmp/docker-builder477234485/crontab.txt: no such file or
directory.
- [Who?]
O desenvolvedor iniciou a execução.
- [When?]
O evento que iniciou a execução foi a tentativa de deploy da nova versão
através do comando ssh no terminal Power Shell.
- [Where?]
A execução parou no Step 10/12 do processo de build do Docker, durante a
instrução COPY crontab.txt /etc/cron.d/redecount-cron.
- [Why?]
A causa exata é desconhecida, mas a recente mudança na infraestrutura para
desacoplar Frontend e Backend é uma forte suspeita. Uma pequena
configuração ou ajuste nessa mudança pode ter introduzido o problema. A
ausência do arquivo crontab.txt no local esperado durante o build do
Docker é a falha imediata.
- [How?]
O erro é reproduzido ao executar os seguintes passos via ssh:
- Conectar
ao servidor AWS S2 via ssh.
- Navegar
até o diretório do projeto.
- Executar
o comando git pull para obter a versão mais recente do código.
- O
processo de build do Docker é iniciado automaticamente ou manualmente.
- O
erro ocorre no Step 10/12: COPY crontab.txt /etc/cron.d/redecount-cron.
3 OBSERVAÇÃO
Analisando as possíveis causas sob diferentes perspectivas:
- [Pessoas?]
- 3.1.1
Falta de treinamento adequado da equipe? Não diretamente. Embora o
desenvolvedor não conheça a fundo a nova infraestrutura, a falha parece
ser específica na configuração do ambiente. O conhecimento do
especialista em AWS é crucial.
- 3.1.2
Problemas de comunicação entre membros da equipe? Não identificado
como causa direta, mas uma comunicação clara será vital para a solução.
- 3.1.3
Ausência de revisões? Não identificado como causa direta, mas
revisões nas configurações de infraestrutura e no processo de deploy
poderiam prevenir problemas futuros.
- [Recurso?]
- 3.2.3
Configurações do ambiente incorretas ou inconsistentes? Possível
causa. A mudança na infraestrutura pode ter introduzido alguma
configuração incorreta no Dockerfile ou nos arquivos relacionados ao
deploy. A falta do crontab.txt sugere um problema nessa área.
- 3.2.4
Configuração incorreta das variáveis de ambiente? Menos provável,
pois o erro ocorre na cópia de um arquivo específico.
- 3.2.5
Incompatibilidades no ambiente? Possível causa. Pode haver
alguma diferença na forma como os arquivos são acessados ou estruturados
após o desacoplamento.
- [Método?]
- 3.3.2
Falta de documentação do Procedimento Operacional Padrão? Possível
causa. Se a documentação do processo de deploy não foi atualizada
após a mudança na infraestrutura, o desenvolvedor pode estar seguindo um
fluxo desatualizado.
- [Entrada?]
Não parece ser a causa principal.
- [Saída?]
- 3.5.2
Resultado indisponível no local esperado? Sim, a nova versão do
aplicativo não está disponível no ambiente de homologação.
- [Medição?]
Não parece ser a causa principal.
4 ANÁLISE (5 Porquês)
Vamos focar nas possíveis causas identificadas na
observação:
4.1.1 Pessoas (Roteiro desatualizado):
- Por
que a forma de executar o trabalho influencia no problema? Porque o
roteiro desatualizado para fazer o upload para o S2 pode ter causado o
erro.
- Por
que o roteiro pode estar desatualizado? Porque houve uma mudança
significativa na infraestrutura (desacoplamento Frontend/Backend) e o
roteiro de deploy talvez não tenha sido atualizado para refletir essa
mudança.
- Por
que a mudança na infraestrutura afetaria o roteiro? Porque o processo
de build e deploy pode ter sido alterado devido à nova arquitetura. Por
exemplo, a forma como os arquivos são transferidos ou construídos pode ter
mudado.
- Por
que o arquivo crontab.txt não foi encontrado? Talvez o novo processo
de build não inclua mais a etapa de copiar esse arquivo do mesmo local, ou
o local de origem do arquivo mudou e o Dockerfile não foi atualizado.
- Por
que o Dockerfile não foi atualizado? Possivelmente porque a
necessidade de alterar essa parte específica do Dockerfile não foi
identificada ou comunicada durante a implementação do desacoplamento.
4.1.2 Recurso (Mudança na infraestrutura):
- Por
que os recursos utilizados podem ter influência no problema? Porque
houve mudança na infraestrutura para desacoplar o Front End do Back End.
- Por
que essa mudança causaria o erro? Porque o processo de build do Docker
pode depender de uma estrutura de arquivos ou de um contexto que foi
alterado com o desacoplamento.
- Por
que o COPY crontab.txt falharia? Porque o arquivo crontab.txt pode não
existir mais no local especificado dentro do contexto do build do Docker
após as mudanças na infraestrutura.
- Por
que o arquivo não estaria lá? Talvez ele tenha sido movido para outro
local, renomeado, ou não é mais gerado/incluído no processo de build da
mesma forma.
- Por
que isso não foi previsto? Talvez a análise de impacto da mudança na
infraestrutura não cobriu todos os detalhes do processo de deploy do
aplicativo.
4.1.3 Método (Documentação desatualizada):
- Por
que o método de configuração da infraestrutura do S2 influencia no
problema? Porque a documentação pode estar desatualizada.
- Por
que a documentação estaria desatualizada? Porque a infraestrutura foi
recentemente modificada, e a documentação não acompanhou essas alterações.
- Por
que a falta de documentação atualizada causa o erro? Porque o
desenvolvedor pode estar seguindo passos incorretos ou o processo de
deploy pode depender de configurações que não são mais válidas.
- Por
que o arquivo crontab.txt não é encontrado? Se a documentação antiga
indicava que esse arquivo estaria presente em um determinado local durante
o build, e isso mudou, o Dockerfile baseado nessa documentação falharia.
- Por
que a documentação não foi atualizada? Falta de comunicação sobre a
necessidade de atualização ou um processo inadequado para manter a
documentação sincronizada com as mudanças na infraestrutura.
Causa Raiz Provável (Combinando as análises): A causa
raiz mais provável é uma falha na atualização do processo de build e deploy
do aplicativo (especificamente o Dockerfile) para refletir as mudanças na
estrutura de arquivos ou no contexto do build introduzidas pelo desacoplamento
do Frontend e Backend. Isso pode ser resultado de falta de comunicação
detalhada sobre as mudanças ou de uma documentação desatualizada do processo de
deploy.
5 PLANO DE AÇÃO
Aqui está um Plano de Ação para resolver o problema, com
foco na investigação da causa raiz e na correção do processo de deploy:
Etapa 1: Iniciação
- Entrada:
- Dados/Recursos
Disponíveis:
- Mensagem
de erro detalhada (ERROR: Service 'devweb' failed to build: COPY failed:
stat /var/lib/docker/tmp/docker-builder477234485/crontab.txt: no such
file or directory).
- Log
completo do processo de deploy (comando ssh e saída).
- Dockerfile
do aplicativo.
- Conhecimento
do desenvolvedor sobre as mudanças no aplicativo.
- Meu
conhecimento como especialista em AWS e desacoplamento.
- Pré-condições:
- Acesso
ao servidor AWS S2 via ssh.
- Acesso
ao código-fonte do aplicativo (repositório Git).
- Disponibilidade
do especialista em infraestrutura na nuvem (eu, no papel do Chatbot).
- Passos:
1.
Reunião inicial (virtual): Desenvolvedor
e eu (Chatbot) alinhamos o entendimento do problema e o contexto das mudanças
na infraestrutura.
2.
Definição do escopo da investigação:
Focamos em entender como a mudança de desacoplamento pode ter afetado o
processo de build do Docker e a localização de arquivos como o crontab.txt.
3.
Comunicação clara dos papéis: O
desenvolvedor fornecerá detalhes sobre o aplicativo e o processo de deploy,
enquanto eu fornecerei insights sobre a infraestrutura AWS e o impacto do
desacoplamento.
- Saída:
- Dados/Recursos
Disponibilizados:
- Entendimento
compartilhado do problema e seu contexto.
- Escopo
claro da investigação definido.
- Plano
inicial de comunicação estabelecido.
- Pós-condições:
- Equipe
alinhada para iniciar a fase de planejamento.
Etapa 2: Planejamento
- Entrada:
- Dados/Recursos
Disponíveis:
- Entendimento
compartilhado do problema.
- Dockerfile
do aplicativo.
- Informações
sobre as mudanças realizadas na infraestrutura de desacoplamento.
- Possível
documentação existente sobre o processo de deploy (antigo e novo).
- Pré-condições:
- Conclusão
da etapa de Iniciação.
- Disponibilidade
para analisar os arquivos de configuração e logs.
- Passos:
1.
Análise detalhada do Dockerfile:
Verificar onde o arquivo crontab.txt era esperado e como ele era copiado.
2.
Investigação das mudanças na infraestrutura:
Entender como o desacoplamento alterou a estrutura de arquivos e o contexto do
build no servidor S2.
3.
Verificação da existência do crontab.txt:
Localizar o arquivo no repositório do projeto e verificar se ele ainda está no
local esperado pelo Dockerfile.
4.
Comparação com a documentação (se existente):
Verificar se o processo de build atual corresponde à documentação.
5.
Formulação de hipóteses: Levantar
possíveis causas para a ausência do arquivo no momento do COPY.
6.
Definição das ações corretivas: Planejar
as alterações necessárias no Dockerfile ou no processo de build para incluir
corretamente o crontab.txt.
7.
Planejamento dos testes: Definir como a
correção será testada no ambiente de homologação.
- Saída:
- Dados/Recursos
Disponibilizados:
- Lista
de possíveis causas do problema.
- Plano
detalhado das ações corretivas a serem implementadas.
- Plano
de testes para verificar a solução.
- Pós-condições:
- Plano
de ação aprovado para execução.
Etapa 3: Execução
- Entrada:
- Dados/Recursos
Disponíveis:
- Plano
de ação detalhado.
- Acesso
ao código-fonte do aplicativo (para modificar o Dockerfile, se
necessário).
- Acesso
ao servidor AWS S2 (para executar comandos de build e deploy).
- Pré-condições:
- Conclusão
da etapa de Planejamento.
- Aprovação
das ações corretivas.
- Passos:
1.
Implementação das ações corretivas:
- Possível
Ação 1 (Arquivo movido): Se o crontab.txt foi movido, alterar o
caminho no comando COPY do Dockerfile para o novo local.
- Possível
Ação 2 (Arquivo não incluído): Se o arquivo não está sendo incluído
no contexto do build do Docker, garantir que ele esteja presente no
diretório correto durante o processo de build (por exemplo, através de
um ADD anterior).
- Possível
Ação 3 (Processo de build alterado): Se o processo de build foi
completamente alterado, adaptar o Dockerfile para a nova forma de
incluir arquivos de configuração.
2.
Build da nova imagem Docker: Executar o
comando de build do Docker no servidor S2 com as alterações realizadas.
3.
Deploy da nova imagem: Publicar a nova
imagem do Docker no ambiente de homologação (servidor S2).
4.
Verificação do deploy: Acessar o
aplicativo no ambiente de homologação para garantir que a nova versão foi
publicada corretamente e não há erros aparentes.
- Saída:
- Dados/Recursos
Disponibilizados:
- Nova
imagem Docker do aplicativo construída.
- Nova
versão do aplicativo implantada no ambiente de homologação.
- Logs
do processo de build e deploy.
- Pós-condições:
- Nova
versão do aplicativo em execução no ambiente de homologação.
Etapa 4: Monitoramento e Controle
- Entrada:
- Dados/Recursos
Disponíveis:
- Nova
versão do aplicativo em execução no ambiente de homologação.
- Acesso
aos logs do aplicativo e do servidor.
- Plano
de testes definido na etapa de Planejamento.
- Pré-condições:
- Conclusão
da etapa de Execução.
- Passos:
1.
Execução dos testes planejados: O
desenvolvedor executa os testes para garantir que a nova versão do aplicativo
está funcionando corretamente e que o erro original não ocorre.
2.
Monitoramento dos logs: Acompanhar os
logs do aplicativo e do servidor para identificar quaisquer novos erros ou
comportamentos inesperados.
3.
Validação do ambiente: Verificar se o
ambiente de homologação está estável com a nova versão.
4.
Comparação com a versão anterior (se
aplicável): Garantir que as funcionalidades da versão anterior foram
mantidas e que as novas funcionalidades estão funcionando como esperado.
- Saída:
- Dados/Recursos
Disponibilizados:
- Resultados
dos testes.
- Logs
de monitoramento.
- Relatório
de status da nova versão no ambiente de homologação.
- Pós-condições:
- Confirmação
de que o problema foi resolvido e a nova versão está estável no ambiente
de homologação.
Etapa 5: Encerramento
- Entrada:
- Dados/Recursos
Disponíveis:
- Resultados
positivos dos testes e do monitoramento.
- Confirmação
da estabilidade da nova versão.
- Pré-condições:
- Conclusão
da etapa de Monitoramento e Controle com resultados satisfatórios.
- Passos:
1.
Documentação da solução: Registrar as
alterações realizadas no Dockerfile, no processo de build ou em qualquer outra
configuração para resolver o problema. Atualizar a documentação do processo de
deploy, se necessário.
2.
Lições aprendidas: Analisar o processo
para identificar o que funcionou bem, o que poderia ter sido feito de forma
diferente e como evitar problemas semelhantes no futuro (por exemplo, melhorar
a comunicação sobre mudanças na infraestrutura e garantir a atualização da documentação).
3.
Comunicação do encerramento: Informar a
equipe sobre a resolução do problema e a publicação bem-sucedida da nova versão
no ambiente de homologação.
- Saída:
- Dados/Recursos
Disponibilizados:
- Documentação
atualizada do processo de deploy (se aplicável).
- Registro
das lições aprendidas.
- Comunicação
de encerramento do problema.
- Pós-condições:
- Problema
formalmente encerrado.
Lembre-se que este é um plano genérico baseado nas
informações fornecidas. A causa raiz exata pode exigir uma investigação mais
aprofundada durante a etapa de Planejamento e Execução. Estou aqui para ajudar
em cada etapa, fornecendo insights sobre a infraestrutura AWS e auxiliando na
análise dos logs e configurações.
Qual o próximo passo que você gostaria de dar? Podemos
começar analisando o seu Dockerfile?
CONCLUSÃO
O serviço de infraestrutura na nuvem é uma “caixa preta”
para o desenvolvedor, que trabalha com um roteiro para fazer publicação de
versões do aplicativo, mas não tem conhecimento suficiente para corrigir falhas
ocorridas dentro da infraestrutura durante a publicação.
A assistência do Chatbot de IA Gemini foi importante para o desenvolvedor aprender um pouco mais, facilitando a comunicação com o especialista na infraestrutura, durante a solução do problema.
A utilização do MASP, com suas 42 perguntas, foi importante para o desenvolvedor solicitar ajuda ao Chatbot de IA, por meio de um Prompt objetivo, com um contexto bem definido e com clareza nas informações.
Com relação às 42 perguntas do MASP, é importante ressaltar que o esforço do desenvolvedor na coleta e no registro dos dados para criar o Prompt, foi muito importante a análise do problema.
Solução do problema
- Série Estudo de Caso:
- Temporada T2 Solução de Problema com IA e MASP:
- Episódio E2 Aplicativo Web
- Episódio E3 Instalação de Aplicativo
- Episódio E4 Aplicativo Web
- Episódio E5 Correção T2E4
- Episódio E6 Correção T2E2
Nenhum comentário:
Postar um comentário