Darlysson Teles Nascimento dos Santos; Mônica Mancini

DOI: 10.22167/2675-6528-202600698

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

Microsserviços distribuíram o risco sistêmico entre dezenas de serviços independentes, tornando falhas em cascata uma ameaça a fluxos críticos de negócio, e a Engenharia de Caos consolidou-se como prática proativa de teste de resiliência, mas o ciclo completo permaneceu dependente de especialistas humanos. Avaliou-se o framework multiagente “Autonomous Resilience Engineering” [ARE] para injeção autônoma de falhas, baseado no ciclo de Engenharia de Caos em arquiteturas de microsserviços, a partir de uma única especificação “OpenAPI”. A pesquisa adotou abordagem exploratória e quantitativa, com experimento controlado em ambiente local com contêineres Docker, utilizando o “Sock Shop” como sistema sob teste. O grupo experimental executou 15 ciclos gerados autonomamente pelo [ARE], enquanto o “baseline” simétrico realizou 14 ciclos sobre os mesmos cenários, com diagnóstico por agente único. Os dados foram coletados automaticamente pelo pipeline [ARE] via logs de contêineres em arquivos CSV e analisados por estatística descritiva. Na comparação simétrica, o [ARE] confirmou vulnerabilidades em 5 dos 15 ciclos (33,3%), enquanto o “baseline” simétrico não identificou nenhuma (0,0%), uma diferença estatisticamente significativa (p = 0,025, Fisher) com 0,47 de diferença no índice de confiança médio. O Agente Observador especializado eliminou o viés de confirmação do agente único. Os resultados demonstraram a viabilidade técnica da automação da injeção de falhas de Engenharia de Caos a partir de especificações “OpenAPI” sem intervenção humana especializada, indicando potencial de adoção por equipes de engenharia de software sem dedicação exclusiva à resiliência.

Palavras-chave: Agentes de inteligência artificial; Automação de experimentos; Engenharia de Caos; Especificação OpenAPI; Microsserviços.

1. Introdução

As arquiteturas de microsserviços consolidaram-se como o paradigma predominante para o desenvolvimento de sistemas de software em larga escala na última década. Essa transição, que envolveu a decomposição de aplicações monolíticas em serviços menores e independentes (Fowler e Lewis, 2014), trouxe benefícios significativos em termos de escalabilidade e agilidade na entrega. Contudo, essa abordagem também redistribuiu o risco sistêmico de maneira complexa (Ait Said et al., 2024). Em contraste com sistemas monolíticos, onde as falhas tendem a ser isoladas, em ambientes de microsserviços a indisponibilidade de um único componente pode propagar-se por cadeias de dependência, afetando fluxos de negócio críticos, como pagamentos e processamento de pedidos (Esen et al., 2025).

Para mitigar esses riscos e garantir a resiliência de sistemas distribuídos, a Engenharia de Caos emergiu como uma prática proativa. Essa disciplina envolve a injeção proposital de falhas em sistemas em execução para identificar vulnerabilidades antes que possam causar incidentes em produção. A abordagem foi pioneira com o “Chaos Monkey” da Netflix em dois mil e dez (Basiri et al., 2016), impulsionando o desenvolvimento de diversas ferramentas amplamente adotadas. No entanto, um gargalo significativo persiste: o planejamento de experimentos de caos, a interpretação dos resultados e o diagnóstico das causas-raiz ainda dependem de especialistas humanos com conhecimento aprofundado da disciplina. Em sistemas com dezenas de serviços, o vasto espaço de falhas possíveis torna a cobertura manual sistemática impraticável, limitando a frequência e o escopo dos experimentos (Esen, Akbulut e Catal, 2025).

A recente evolução dos Modelos de Linguagem de Grande Porte (LLMs) apresenta uma alternativa promissora para superar essa dependência humana. Essas tecnologias demonstram capacidade para analisar especificações estruturadas, formular hipóteses de teste (Schäfer et al., 2023) e raciocinar sobre comportamentos anômalos em sistemas distribuídos (Cornacchia et al., 2025). Embora trabalhos recentes tenham explorado a automação do ciclo de Engenharia de Caos com agentes LLM em ambientes específicos, como Kubernetes (Kikuta et al., 2025), essas soluções frequentemente pressupõem infraestrutura como código e não operam a partir de uma única especificação OpenAPI como artefato de entrada. Plataformas existentes, como Chaos Mesh e LitmusChaos, automatizam a execução de experimentos, mas ainda exigem que o planejamento seja realizado por um especialista. Além disso, estudos com LLMs têm coberto etapas isoladas do ciclo, como a remediação autônoma de falhas (Sarda et al., 2024), mas não o fluxo completo. Assim, a literatura carece de um framework que receba uma especificação OpenAPI e execute, de forma autônoma e sem intervenção humana, a cadeia completa de análise do sistema, planejamento de experimentos, injeção de falhas e diagnóstico.

Em resposta a essa lacuna, propõe-se o framework “Autonomous Resilience Engineering” [ARE]. Este sistema é composto por três agentes LLM operando em um pipeline sequencial, e sua funcionalidade é baseada exclusivamente em uma especificação OpenAPI. O Agente Analisador gera hipóteses de vulnerabilidade para cada endpoint documentado; o Agente Planejador converte essas hipóteses em configurações de injeção de falha via um proxy HTTP; e o Agente Observador analisa os logs coletados após a injeção, emitindo diagnósticos com um índice de confiança baseado nas evidências observadas. Essa separação estrutural entre planejamento e diagnóstico é crucial, pois diferencia o [ARE] de arquiteturas de agente único e mitiga o viés de confirmação, conforme identificado em abordagens anteriores (Cornacchia et al., 2025). A crescente adoção de microsserviços em sistemas críticos e a dependência de especialistas humanos representam um obstáculo significativo para a escalabilidade da Engenharia de Caos, justificando a relevância desta pesquisa.

A dependência de especialistas humanos na Engenharia de Caos restringe a frequência e o escopo dos testes de resiliência em microsserviços, o que pode comprometer a robustez de sistemas críticos. Diante disso, o objetivo deste trabalho é avaliar o framework multiagente “Autonomous Resilience Engineering” [ARE] com injeção de falhas baseado no ciclo de Engenharia de Caos em arquiteturas de microsserviços a partir de uma única especificação “OpenAPI”.

2. Material e Métodos

A pesquisa adotou uma abordagem exploratória e quantitativa, com o objetivo de avaliar o framework multiagente “Autonomous Resilience Engineering” [ARE] para injeção autônoma de falhas em arquiteturas de microsserviços. Os experimentos foram conduzidos em Fortaleza, Ceará, Brasil, em um ambiente computacional local controlado. O sistema sob teste foi o “Sock Shop”, uma aplicação de referência de comércio eletrônico baseada em microsserviços, desenvolvida pela Weaveworks (2016) e implantada localmente via contêineres Docker para assegurar isolamento e reprodutibilidade.

O “Sock Shop” consistia em doze serviços interdependentes, como “front-end”, “catalogue”, “cart”, “orders”, “payment”, “shipping” e “user”, cada um executado em contêiner isolado. A comunicação entre a maioria dos serviços ocorria por chamadas HTTP síncronas, com exceção do serviço de pedidos, que utilizava uma fila de mensagens RabbitMQ para processamento assíncrono. O ambiente experimental totalizou quinze contêineres monitorados, incluindo três de infraestrutura de suporte.

A especificação OpenAPI do “Sock Shop”, contendo treze endpoints distribuídos entre os serviços de negócio, serviu como o único artefato de entrada para o framework [ARE]. Esta aplicação é de código aberto e não envolveu coleta ou processamento de dados de pessoas físicas, dispensando cuidados éticos específicos relacionados a dados pessoais.

O framework [ARE] foi implementado em Python 3.12 e é composto por três agentes de Modelo de Linguagem de Grande Porte (LLM) que compartilham o motor de raciocínio Gemini 2.5 Pro, modelo de linguagem do Google. Essa escolha visou isolar a arquitetura do pipeline como variável independente, pois o mesmo modelo foi utilizado em ambos os grupos experimentais, eliminando-o como variável interveniente.

O Agente Analisador recebeu a especificação OpenAPI e gerou cenários de falha autônomos, detalhando serviço alvo, endpoint, método HTTP, tipo de falha e hipótese de impacto. O Agente Planejador traduziu cada cenário em um stub WireMock no formato JSON para injeção via proxy HTTP. O Agente Observador analisou os logs dos contêineres coletados após a injeção, com acesso restrito aos logs de interceptação do proxy, emitindo diagnósticos com confirmação de vulnerabilidade, causa raiz, serviços afetados, recomendação de mitigação e um índice de confiança de 0,0 a 1,0, ancorado em critérios objetivos.

A infraestrutura de injeção de falhas utilizou o WireMock, implantado como um contêiner Docker adicional na rede do “Sock Shop” e configurado como proxy reverso para todos os serviços de negócio via aliases DNS no Docker Compose (WireMock, 2024a). A API REST de administração do WireMock foi o mecanismo empregado pelo [ARE] para registrar, ativar e remover os stubs de falha durante os experimentos, simulando respostas de erro, atrasos ou falhas de conexão, conforme práticas de injeção de falhas via proxy (Esen et al., 2025).

Para garantir a validade interna do estudo, o tráfego de validação foi gerado por chamadas HTTP diretas ao contêiner “front-end”, e não pelos aliases WireMock. Essa abordagem assegurou que os serviços reais do “Sock Shop” iniciassem as chamadas que acionavam os stubs de falha, eliminando a circularidade que ocorreria caso o próprio sistema de injeção gerasse o tráfego destinado a si mesmo.

A amostra experimental consistiu em vinte e nove ciclos, distribuídos em dois grupos. O grupo experimental [ARE] executou quinze ciclos gerados autonomamente a partir da especificação OpenAPI. O grupo “baseline” simétrico executou quatorze ciclos sobre os mesmos cenários do grupo experimental, com o diagnóstico realizado por um agente único. O critério amostral foi o caráter exploratório da pesquisa, cobrindo todos os tipos de falha e serviços relevantes do “Sock Shop”, com tamanhos amostrais considerados suficientes para avaliar a viabilidade da abordagem.

O “baseline” simétrico operou com um único agente, baseado no modelo Gemini 2.5 Pro. Este agente recebeu simultaneamente o contexto da falha injetada (descrição do cenário, serviço alvo, endpoint, tipo de falha e hipótese de impacto) e os logs coletados, emitindo o diagnóstico em uma única chamada ao modelo. Os cenários para o “baseline” simétrico foram os mesmos quinze gerados pelo Agente Analisador [ARE], sem intervenção do pesquisador, isolando a arquitetura de diagnóstico como variável de interesse.

O protocolo experimental foi idêntico para ambos os grupos. Antes de cada ciclo, o estado do WireMock foi limpo, o stub registrado via API REST, e o tráfego HTTP gerado por sessenta segundos por um script Python personalizado, que enviava requisições a cada dois segundos ao front-end. Os logs dos quinze contêineres do “Sock Shop” e do contêiner WireMock foram coletados, persistidos em arquivos CSV, e o stub removido ao final do ciclo.

A ordem de execução dos cenários do [ARE] foi determinada pela saída do Agente Analisador, sem randomização posterior. A ausência de randomização não introduziu viés de carryover, pois o protocolo incluiu a limpeza completa do estado do WireMock antes de cada ciclo. Os cenários do grupo de controle foram executados na sequência definida a priori pelo pesquisador. Ambos os grupos operaram sobre o mesmo sistema e infraestrutura, em sessão única em oito de abril de 2026, viabilizada pelo ambiente controlado e isolado.

O instrumento de coleta de dados foi um pipeline automatizado que registrou os logs dos contêineres ao final de cada ciclo, persistindo-os em arquivos CSV sem intervenção manual, abordagem compatível com pesquisas experimentais de natureza computacional (Marconi e Lakatos, 2022). A análise dos dados baseou-se em métricas comparadas entre os grupos por estatística descritiva (Marconi e Lakatos, 2022), mediante cálculo direto de cada indicador por grupo. Aplicou-se o teste exato de Fisher (unilateral, H₁: [ARE] > Controle) para a dimensão de eficácia, e estatística descritiva para precisão diagnóstica, eficiência, diversidade de cenários e cobertura da especificação OpenAPI.

3. Resultados e Discussão

A avaliação do framework multiagente “Autonomous Resilience Engineering” [ARE] revelou achados significativos quanto à sua capacidade de automatizar a injeção de falhas e o diagnóstico em arquiteturas de microsserviços, utilizando exclusivamente uma especificação OpenAPI. Os resultados demonstraram a viabilidade técnica da abordagem proposta, superando as limitações de dependência de especialistas humanos identificadas na Engenharia de Caos tradicional. A pesquisa comparou o desempenho do [ARE] com um “baseline” simétrico de agente único, em um experimento controlado, evidenciando a eficácia e a precisão diagnóstica do framework multiagente. Essa abordagem contribui para a escalabilidade dos testes de resiliência, um desafio persistente em ambientes de microsserviços complexos, conforme apontado por Esen, Akbulut e Catal (2025).

Os experimentos foram conduzidos em um ambiente local com contêineres Docker, utilizando o “Sock Shop” como sistema sob teste, uma aplicação de referência amplamente empregada em estudos de resiliência (Weaveworks, 2016). O grupo experimental, operando com o [ARE], executou 15 ciclos de injeção de falhas gerados autonomamente. Em contraste, o “baseline” simétrico realizou 14 ciclos sobre os mesmos cenários, com o diagnóstico efetuado por um agente único. A coleta de dados foi automatizada pelo pipeline do [ARE], registrando logs dos contêineres em arquivos CSV, o que garantiu a reprodutibilidade e a consistência dos dados para análise. A metodologia adotada permitiu uma comparação direta e controlada entre as duas abordagens de diagnóstico.

Visão geral comparativa

Na comparação entre o [ARE] e o “baseline” simétrico, o framework multiagente confirmou vulnerabilidades em 5 dos 15 ciclos executados, o que representa uma taxa de eficácia de 33,3%. Em contrapartida, o “baseline” simétrico não identificou nenhuma vulnerabilidade nos 14 ciclos que conseguiu completar, resultando em uma taxa de 0,0%. Essa diferença na capacidade de identificação de falhas é estatisticamente significativa, com um valor de p = 0,025 (teste exato de Fisher), indicando que o desempenho superior do [ARE] não é atribuível ao acaso. A disparidade nos resultados sublinha a importância da arquitetura multiagente para a detecção proativa de problemas de resiliência.

O índice de confiança médio dos diagnósticos também revelou uma distinção marcante entre os grupos. Para o [ARE], o índice de confiança médio foi de 0,61 em todos os ciclos, e de 0,90 nos ciclos em que a vulnerabilidade foi confirmada. Já o “baseline” simétrico apresentou um índice de confiança médio substancialmente menor, de 0,14. Essa diferença de 0,47 no índice de confiança médio em favor do [ARE] é consistente com o viés de confirmação documentado em agentes de chamada única, conforme observado por Cornacchia et al. (2025). A separação de papéis entre os agentes do [ARE] demonstrou ser crucial para mitigar esse viés, resultando em diagnósticos mais confiáveis e embasados em evidências.

O Agente Analisador do [ARE] demonstrou sua capacidade de gerar cenários de falha de forma autônoma, a partir da especificação OpenAPI do “Sock Shop”. Foram gerados 15 cenários, cobrindo 6 serviços (cart, catalogue, orders, payment, shipping e user), 6 tipos de falha e 11 dos 13 endpoints documentados, o que corresponde a 84,6% da especificação. Esse resultado está alinhado com a literatura que aponta a capacidade de modelos de linguagem de analisar especificações estruturadas para formular hipóteses de teste de alta qualidade (Schäfer et al., 2023; Li et al., 2025). A autonomia na geração de cenários é um avanço fundamental para a escalabilidade da Engenharia de Caos, reduzindo a dependência de intervenção humana especializada.

Os 15 ciclos executados pelo [ARE] foram categorizados em três grupos distintos. O primeiro grupo, composto por 5 ciclos (ARE-001, ARE-003, ARE-004, ARE-008 e ARE-009), correspondeu a situações em que o “stub” de falha não foi acionado devido à ausência de tráfego no endpoint alvo. O segundo grupo, também com 5 ciclos (ARE-007, ARE-010, ARE-011, ARE-012 e ARE-013), resultou em diagnósticos inconclusivos, indicando insuficiência de evidências para uma confirmação robusta. O terceiro grupo, que incluiu 5 ciclos (ARE-002, ARE-005, ARE-006, ARE-014 e ARE-015), teve vulnerabilidades confirmadas com um índice de confiança médio de 0,90, demonstrando a eficácia do framework em identificar problemas reais de resiliência.

Um caso notável foi o ciclo ARE-009, que apresentou uma duração atípica de 593 segundos. Essa anomalia foi atribuída a múltiplas tentativas de geração de “stub” decorrentes de uma limitação de taxa da API do modelo de linguagem, o que sugere um ponto de otimização para futuras implementações. Apesar dessa ocorrência, o Agente Analisador conseguiu formular hipóteses para endpoints parametrizados, como /catalogue/{id}, /carts/{customerId}/items e /customers/{id}. Essa capacidade de lidar com rotas complexas reforça a aplicabilidade do [ARE] em sistemas de microsserviços com APIs bem definidas, confirmando a superioridade dos LLMs com instruções específicas ao domínio na geração de hipóteses de teste, em comparação com abordagens baseadas em “templates” fixos (Li et al., 2025).

O “baseline” simétrico executou 14 dos 15 cenários gerados pelo Agente Analisador do [ARE], sendo que o ciclo ARE-005 não foi executado devido a um limite de requisições da API do modelo de linguagem durante a sessão experimental. Cada ciclo no “baseline” utilizou o mesmo “stub” registrado pelo Agente Planejador do [ARE] e o mesmo gerador de tráfego do grupo experimental. A principal variável isolada para comparação foi a arquitetura de diagnóstico: um único agente recebeu simultaneamente o contexto do cenário e os logs coletados, em contraste com a separação de papéis do Agente Observador especializado do [ARE].

Nenhum dos 14 ciclos executados pelo “baseline” simétrico resultou na confirmação de vulnerabilidade, com o índice de confiança médio de 0,14 e zero ciclos atingindo o limiar de confiança de 0,7. Em particular, para os 4 ciclos (ARE-002, ARE-006, ARE-014 e ARE-015) que foram confirmados pelo [ARE] com alta confiança (entre 0,85 e 0,95), o “baseline” simétrico atribuiu confianças significativamente mais baixas, variando de 0,10 a 0,20. Essa discrepância evidencia que o Agente Observador especializado, ao analisar os logs sem acesso prévio ao contexto do cenário planejado, produziu diagnósticos mais precisos e menos enviesados do que o agente único com acesso completo ao contexto, corroborando os achados de Cornacchia et al. (2025) sobre o viés de confirmação em agentes de chamada única.

Análise comparativa das métricas

A análise comparativa das métricas de eficácia, precisão diagnóstica, eficiência, diversidade e cobertura reforça a superioridade do [ARE]. Em termos de eficácia, o [ARE] confirmou 5 vulnerabilidades (33,3%) enquanto o “baseline” simétrico não confirmou nenhuma (0,0%). A diferença no índice de confiança médio de 0,47 em favor do [ARE] (0,61 versus 0,14) é um indicador robusto da maior precisão diagnóstica do framework multiagente. Essa diferença na taxa de eficácia foi estatisticamente significativa (p = 0,025, α = 0,05) para o tamanho amostral utilizado, validando a capacidade do [ARE] de identificar vulnerabilidades de forma autônoma.

Em relação à diversidade de cenários, ambos os grupos avaliaram os mesmos 15 cenários, cobrindo 6 serviços e 6 tipos de falha. A diferença crucial reside no fato de que o [ARE] gerou esses cenários autonomamente a partir da especificação OpenAPI, enquanto o “baseline” simétrico os recebeu como entrada pré-definida. Essa autonomia na geração de cenários é um diferencial competitivo do [ARE], pois elimina a necessidade de intervenção humana na fase de planejamento, um dos gargalos da Engenharia de Caos tradicional (Esen, Akbulut e Catal, 2025). A capacidade de explorar um vasto espaço de falhas sem supervisão especializada é fundamental para a escalabilidade da prática.

A cobertura da especificação OpenAPI também foi idêntica para ambos os grupos, abrangendo 84,6% dos endpoints documentados (11 de 13). Isso incluiu rotas parametrizadas que não foram contempladas em experimentos anteriores, demonstrando a abrangência do Agente Analisador em explorar a superfície da API. A capacidade de cobrir uma proporção tão alta de endpoints de forma autônoma, a partir de uma única especificação, ressalta o potencial do [ARE] para ser adotado em equipes de engenharia de software que buscam integrar a Engenharia de Caos sem a necessidade de dedicação exclusiva de especialistas em resiliência.

No que tange à eficiência, o [ARE] completou cada ciclo em uma média de 135,0 segundos, enquanto o “baseline” simétrico levou 112,3 segundos. A diferença de 20% no tempo médio por ciclo reflete o processamento sequencial das três chamadas ao modelo de linguagem no pipeline do [ARE], em contraste com a chamada única do agente do “baseline”. Contudo, é importante notar que esse custo adicional de tempo no [ARE] inclui o planejamento automatizado dos cenários, uma etapa que seria manual e demorada em um cenário real para o “baseline”. Portanto, a eficiência do [ARE] deve ser contextualizada pela automação completa do ciclo, que compensa o tempo adicional de processamento dos agentes.

A separação estrutural entre o Agente Planejador e o Agente Observador no [ARE] foi um fator determinante para a eliminação do viés de confirmação, um problema identificado em abordagens de agente único (Cornacchia et al., 2025). O Agente Observador, ao analisar os logs sem acesso ao contexto do cenário planejado, garantiu que os diagnósticos fossem baseados exclusivamente nas evidências empíricas, resultando em maior precisão e confiabilidade. Essa arquitetura multiagente, com papéis bem definidos, demonstrou ser superior para produzir diagnósticos mais confiáveis em comparação com soluções de agente único, confirmando a hipótese central de que a mitigação do viés de confirmação é essencial para a automação eficaz da Engenharia de Caos.

Os resultados obtidos com o [ARE] confirmam a viabilidade técnica da automação da injeção de falhas de Engenharia de Caos a partir de especificações OpenAPI, sem a necessidade de intervenção humana especializada. O framework demonstrou ser capaz de gerar cenários, injetar falhas e diagnosticar vulnerabilidades de forma autônoma, com uma eficácia e precisão diagnóstica superiores às do “baseline” de agente único. A separação de papéis entre os agentes foi crucial para mitigar o viés de confirmação, resultando em diagnósticos mais confiáveis. Embora o experimento tenha sido conduzido em um ambiente controlado, os achados indicam um potencial significativo para a adoção do [ARE] por equipes de engenharia de software, democratizando o acesso à Engenharia de Caos e fortalecendo a resiliência de sistemas de microsserviços.

4. Conclusão

Este trabalho avaliou o framework multiagente “Autonomous Resilience Engineering” [ARE] para injeção autônoma de falhas, baseado no ciclo de Engenharia de Caos em arquiteturas de microsserviços, a partir de uma única especificação “OpenAPI”. Verificou-se que o [ARE] demonstrou viabilidade técnica na automação completa do ciclo de Engenharia de Caos, desde a geração de cenários até o diagnóstico, sem a necessidade de intervenção humana especializada. Em um experimento controlado, o [ARE] confirmou vulnerabilidades em 5 dos 15 ciclos executados (33,3%), enquanto o “baseline” simétrico, com diagnóstico por agente único, não identificou nenhuma vulnerabilidade nos 14 ciclos que conseguiu completar (0,0%). Essa diferença foi estatisticamente significativa (p = 0,025, Fisher), com o [ARE] apresentando um índice de confiança médio 0,47 superior. A arquitetura multiagente, com a separação de papéis entre o Agente Planejador e o Agente Observador especializado, eliminou o viés de confirmação inerente a abordagens de agente único, resultando em diagnósticos mais precisos e confiáveis. A principal contribuição do estudo reside na demonstração de que a automação da injeção de falhas de Engenharia de Caos, a partir de especificações OpenAPI, é tecnicamente factível, o que potencializa sua adoção por equipes de engenharia de software sem dedicação exclusiva à resiliência, democratizando o acesso a essa prática essencial para a robustez de sistemas distribuídos.

Contudo, o estudo apresentou limitações. Os resultados obtidos com o “Sock Shop” não são diretamente generalizáveis para sistemas de produção com tráfego real, uma vez que o experimento foi conduzido em ambiente local controlado com contêineres Docker, o que restringiu a aplicabilidade a cenários com variabilidade de infraestrutura e carga dinâmica. O comportamento não determinístico do modelo de linguagem e os limites de requisições da API condicionaram a reprodutibilidade exata dos resultados, e o tamanho amostral mostrou-se insuficiente para inferências estatísticas formais. Além disso, o gerador de tráfego utilizado não cobriu todos os “endpoints” parametrizados, o que pode ter condicionado a taxa bruta de confirmação. Para estudos futuros, sugere-se incorporar um gerador de tráfego orientado pela própria especificação “OpenAPI” para ampliar a cobertura de “endpoints” parametrizados, avaliar o [ARE] em sistemas de produção com carga real e infraestrutura distribuída, comparar o desempenho do framework entre diferentes modelos de linguagem de grande porte e investigar sua integração em pipelines de entrega contínua como etapa automatizada de validação de resiliência.

Referências Bibliográficas

Ait Said, M.; Ezzati, A.; Mihi, S.; Belouaddane, L. 2024. Microservices adoption: an industrial inquiry into factors influencing decisions and implementation strategies. International Journal of Computing and Digital Systems 15(1): 1417-1432. Disponível em: <https://www.researchgate.net/publication/378970648>. Acesso em: 10 mar. 2026.

Basiri, A.; Ioannidis, N.; Hochstein, L.; Rosenthal, C. 201

Esen, E.; Akbulut, A.; Catal, C. 2025. Chaos experiments in microservice architectures: a systematic literature review. Computer Standards & Interfaces 97: 103945. DOI: 10.1016/j.csi.2025.103945. Disponível em: <https://www.sciencedirect.com/science/article/pii/S092054892500145X>. Acesso em: 10 mar. 2026.

Fowler, M.; Lewis, J. 2014. Microservices. [S. I.]. Disponível em: <https://martinfowler.com/articles/microservices.html>. Acesso em: 29 mar. 2026.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy