15 minutos de leitura
Na Invillia, toda quarta-feira, ao meio-dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiências vital para quem revolucionar a forma de inovar. E essencial para que ela nunca pare. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais.
Introdução
O Microsoft Innovation Hub, antigo Microsoft Technological Center (MTC) é uma área que atua somente com projetos de inovação para clientes, buscando solucionar os desafios de negócios em determinados serviços. Dessa forma, a área busca compreensão sobre o negócio e as métricas, desenhando a arquitetura da aplicação.
Com experiência acumulada em consultoria, gerência de produtos, comunidades developers, arquitetura, engenharia, Cloud Solution, infraestrutura e aplicações de segurança e marketing, o especialista da Microsoft, Fabio Hara, abordou duas tecnologias recentes que evoluem a arquitetura de produtos e novas aplicações em nuvem:
- A evolução do AIOPs para uso em operações com aplicações de negócio, Copilot etc., que atua a partir de novos serviços de Inteligência Artificial, como processamento de linguagem natural e modelos de aprendizado de máquina, para automatizar e simplificar o gerenciamento de serviços de TI e fluxos de trabalho operacionais;
- E o Chaos Engineering, ou Engenharia do Caos, disciplina que estuda como podem ocorrer falhas, fornecendo metodologias para ajudar a evitá-las. Isso porque ao compreender sua causa raiz, pode-se utilizar experimentos controlados para identificar pontos de falhas antes que eles causem problemas em um sistema, evitando proativamente interrupções. Por exemplo, ao disponibilizar online e para acesso, é feito um desenho básico desta arquitetura, pensando posteriormente no suporte da aplicação. Antes de disponibilizá-la online e para acesso de todos, no entanto, a tecnologia torna possível injetar uma série de falhas na aplicação visando detectar quais podem acontecer, seus sintomas e como modificar a arquitetura para que ela seja mais resiliente antes de ser implementada. Depois de implementada, também é possível aplicar o Chaos Engineering neste ambiente para verificar como reestruturar a arquitetura e tornar a aplicação mais resiliente.
As duas tecnologias mostram como é possível atingir níveis de SLA mais alto, isso significa que, para ter melhor aplicação, é necessário implementar falhas aleatórias e não falhas previstas no ambiente.
Preparando ambientes para AIOPs – Para manter as cargas de trabalho críticas confiáveis e preparar-se para inevitável interrupção
Ao implementar uma aplicação, o objetivo principal é ter o maior número de nove possíveis em um SLA, 99.99806% Azure single-instance VM uptime (média móvel de 12 meses até julho de 2023). Afinal, se questionarmos um cliente sobre a quantidade de tempo que sua aplicação pode ficar indisponível, ele vai responder “nunca”, ou seja, zero de indisponibilidade. Entretanto, quanto mais próximo de 100% disponível, obviamente mais cara e complexa é a solução.
Quando se fala, por exemplo, de uma aplicação que terá 99.99806% de uptime – quantidade de tempo em que estará indisponível no ano –, verificando em porcentagem, o tempo indisponível equivalerá a cerca de 10 minutos no total. Neste caso, o cliente imagina 10 minutos de “downtime” (com a solução parada) e não 1 minuto por mês, que totalizam 10 minutos no ano. Por isso, este não é um cálculo fácil de atingir, mesmo que todo cliente busque o número mais alto possível.
Por que coisas ruins acontecem?
Todas as aplicações e sistemas são vulneráveis, desde uma falha de hardware, driver, software até, também, falhas de pessoas em produtos e processos. Por isso, quando se faz analogia do que pode acontecer de errado num ambiente, não se trata, necessariamente, de um incidente, mas uma série de falhas e/ou componentes em processos que não acontecem inesperadamente, mas que podem ser comuns com raízes e gaps.
Problemas de confiabilidade: o risco aos clientes
Os times de TI reclamam que perdem tempo resolvendo problemas e deixam de executar novos projetos ou realizar melhorias no sistema, daí a necessidade de quantificar e buscar solucionar na prática este “gap’. Afinal, construir soluções confiáveis é uma responsabilidade compartilhada.
Passo 1 – Visão geral: Identificar e documentar cargas de trabalho
Quando se utiliza nuvem, parte da responsabilidade é do cliente e parte do provedor de nuvem (Microsoft, AWS, Google etc.). Entretanto, na responsabilidade da Microsoft ou do provedor, há uma série de técnicas e arquiteturas necessárias para manter o serviço mais disponível possível.
Assim, na camada de responsabilidade do cliente, quanto mais se utiliza infraestrutura como serviço, maior é a quantidade de probabilidades, porque se passa a gerenciar uma parte do sistema operacional que poderia ser serviço ou plataforma (deve-se lembrar o cliente que rodar na nuvem não é sinal de 100% de estabilidade, pois um sistema que dava problema local e foi migrado, apenas mudou o problema de lugar, esperando uma resolução que pode não acontecer).
Entretanto, se numa arquitetura se deseja resolver o problema de indisponibilidade de aplicações e serviços, é necessário identificar primeiro o que está gerando o problema, e como ele pode ser documentado.
Mesmo que não seja agradável documentar ambientes, esta ação é recomendada e, hoje, há ferramentas utilizadas no mercado para realizar esta tarefa, como o Azure Resource Inventury (ARI) – ferramenta gratuita criada por dois engenheiros da Microsoft do Brasil que conecta numa subscription do Azure, e gera um documento (planilha Excel e diagrama no Vision) contendo toda a topologia, subscrição e serviços conectados.
Já como opção de ferramenta paga, há o ClouDocs, que conecta em qualquer provedor de nuvem ou ambiente “on-premise” (como o AWS, Google Cloud, Azure etc.), gerando um documento (Word) que contém a documentação do ambiente com diagramas e tabelas, mostrando como a aplicação funciona com web service configurado, o que possibilita sua reconstrução. O ClouDocs oferece a opção de rodar semanalmente para mostrar o que foi alterado de uma semana para a outra e quem alterou o quê – também é popularmente conhecido como “dedo-duro”.
Há empresas que dedicam um colaborador para realizar esta documentação do ambiente da nuvem, levando horas ou dias e tornando o tempo improdutivo, dado que se trata de um trabalho incessante e que pode não ter sido realizado anteriormente. Por isso, o custo com essas ferramentas pode trazer economia de tempo e ajuda com “troubleshooting”, além de desenhar melhor a solução.
Workloads – Um exemplo de cliente do mundo
O próximo passo é identificar um workload, ou seja, uma coleção de recursos de aplicativos, dados e infraestrutura de suporte que funcionam juntos em direção a uma meta de negócios definida. Quando se trabalha com resiliência de nuvem, não se faz desenhos para melhorar o todo, mas normalmente atua-se por workload, documentando cada cenário de aplicação para entender como ele funciona.
Considerando a carga de trabalho do mundo real, busca-se encontrar aplicações que utilizam mais de uma subscrição, afinal, há times de dados que têm uma subscrição, e a segurança está em outra subscrição, sendo que muitas vezes a aplicação é composta por acesso de várias subscrições, o que acaba tornando um pouco mais complexo o cenário. Daí a importância de rastrear, identificar e desenhar, visando a melhoria da disponibilidade daquela aplicação.
Características de uma carga de trabalho de missão crítica
Os clientes possuem uma tendência de acreditar que toda carga de trabalho é crítica. Mas existem alguns critérios que classificam uma missão ou aplicação de missão crítica.
Tecnicamente, as características de uma carga de trabalho de missão crítica podem ser de impacto social (por exemplo, quando um web site simples está fora do ar ou foi invadido, o que pode gerar reputação negativa para a empresa) e de impacto no negócio (quando uma aplicação interrompe a emissão de nota fiscal, por exemplo).
Assim, as siglas de nível de serviço buscam entender seus requisitos de tempo de atividade e informar suas prioridades para monitoramento e resiliência, ressaltando o que se quer atingir:
- Service Level Indicator (SLI) – a porcentagem de solicitações de usuários de um sistema que demonstra quanto este é capaz de processar em tanto tempo, além da quantidade de quests que a aplicação suporta a cada tantos minutos;
- Service Level Objective (SLO) – o target existente para determinada aplicação que deve ser definido pelo cliente;
- Service Level Agreement (SLA) – para garantir 99 ou até 95% de disponibilidade, entretanto, quanto mais alto o cliente deseja o SLA como objetivo final, maior e mais complexo fica o custo da aplicação (o preço de uma máquina virtual com replicação de dados custa o triplo considerando o custo de target e tráfego de rede).
Necessidades de disponibilidade da aplicação
Há atualmente uma disciplina que demonstra como realizar a análise de disponibilidade, melhorando o tempo de monitoração de aplicação e tornando ela mais resiliente.
O SRE, por exemplo, mostra como se preparar para melhorar a monitoração de aplicações do serviço, porque uma das coisas que mais se discute hoje é o tempo de resolução do problema – desde o tempo de detecção até o recebimento da reclamação pelo usuário, engajamento na atuação do chamado e o tempo para correção do problema (“troubleshooting” de aplicações).
Resiliência de aplicações
Antes de colocar uma aplicação no ar, seria adequado realizar testes, mas o problema é que o teste já se executa prevendo o que se deseja que dê erro. No entanto, os times de produção não querem realizar testes aleatórios para “matar” serviço ou executar processos complexos numa aplicação em produção.
Para tanto, são pensadas as seguintes práticas:
- Chaos engineering – a prática de submeter aplicativos e serviços em nuvem a falhas e interrupções de dependência do mundo real para construir e validar a resiliência;
- Fault injection – A introdução deliberada de uma falha em um sistema para validar a robustez e o tratamento de erros.
Por exemplo, a Netflix implementou um mecanismo interessante – o Chaos Monkey ou “Macaquinho do Caos”, que funciona como se soltasse um macaco no datacenter, que sairia puxando cabos e fazendo coisas erradas nos servidores, o que poderia provocar falhas e caos no ambiente de forma aleatória. A partir da implementação, para cada falha aleatória, eles já pensavam na arquitetura que tinham que enviar.
Ao injetar falhas numa máquina virtual que exige duas máquinas, no entanto, ao “cair” aquela região serão necessárias máquinas replicadas em outra região com balanceamento de carga. Por isso, depois que o time de TI da Netflix criou a disciplina de “engenharia do caos”, surgiu a disciplina de arquitetura utilizada para submeter falhas em ambientes. Antes, essas falhas eram focadas em máquinas virtuais, mas em um ambiente de nuvem há falhas de serviços PaaS difíceis de simular, como uma falha de latência de rede em nuvem.
No caso da Microsoft, a implementação desse mecanismo de gestão de falhas levou à criação do Chaos Studio que gira em torno da ideia de fazer validação de projeto, pensando em alta disponibilidade, injetando e simulando falhas aleatórias (seja em máquina virtual, rede, serviços PaaS etc.) para entender quais são e como é possível mitigá-las na arquitetura para que a aplicação seja mais resiliente.
É legal perceber que muitas dessas falhas são possíveis de se resolver utilizando mais PaaS ou SaaS na arquitetura porque diminui a quantidade de falhas eliminando esta camada.
No caso de já ter um ambiente pronto e precisar testar falhas aleatórias para verificar como o ambiente se comporta num cenário de falhas é comum alguns clientes tirarem uma cópia do ambiente, mantendo subscrição de teste para injetar essas falhas, e testando o que deve ser mudado na arquitetura atual em produção.
Azure Chaos Studio – Para medir, entender, melhorar e manter a resiliência do produto
A ferramenta disponível no Azure realiza testes não apenas em ambientes e máquinas virtuais, mas, também, em serviços PAAS. Por exemplo, testando falhas num cosmos DB ou ajustando uma falha num serviço PAAS, webservice e assim por diante.
Interessante que, para gerar falhas, quando há máquina virtual, é necessário instalar um agente dentro da máquina, já que não é possível simular algumas falhas sem um agente causador. Neste caso, como ejetar uma falha de memory leak numa VM? É necessário ter um agente que simule isso dentro da VM e tenha este comportamento.
Por isso quando se fala em Chaos Studio com máquinas virtuais, é necessário um agente para criar falhas e melhorar a arquitetura. Assim, é possível perceber que o projeto iniciado, ao ser implementado, tenha que alterar toda a arquitetura, mas é importante saber que esse tipo de ferramenta pode ser aliado para o arquiteto, para se pensar em resiliência de maneira muito mais séria.
Experimento do caos
Cenários orquestrados de várias etapas com falhas aplicadas a destinos de recursos de assinatura durante a carga consideram as seguintes etapas: hipótese, experimento, análise, aperfeiçoamento e estado estacionário.
Hoje, a ferramenta disponível no portal do Azure conta com treinamentos da Microsoft Learning cuja ideia é simular e promover falhas, em paralelo, sequenciais etc., tendo suporte para vários serviços, e testando apenas máquinas virtuais e serviços PaaS, inclusive redes.
Assim, o ideal é que se tenha um ambiente de homologação similar ao que se tem em produção para a realização de testes que verifiquem o que vai acontecer em possível falha de rede, como aplicações que não possuem mecanismo de retry, onde não é possível prever como elas vão se comportar com falhas.
Monitoramento focado e assertivo da aplicação
A monitoração pode ser feita da infraestrutura geral da aplicação, máquina virtual, memória, processador, dentro do código da aplicação (APM) etc.
No entanto, se a monitoração for feita errada, o custo de logs é muito maior do que o custo do ambiente da aplicação. Quando o cliente quer monitorar tudo e a cada 5 segundos manda logs, pode estourar o account, e gastar dinheiro sem necessidade. Por isso, a monitoração é um ponto de atenção em custos, cujo objetivo é melhorar o atendimento e suporte.
Visão para monitoramento no Azure
Quando se fala de monitoração numa visão geral, hoje a principal ferramenta é o Azure Monitor, que monitora o que está no Azure e fora dele – no datacenter, local etc. – utilizando o serviço Azure Arc, que monitora e faz deploy de uma aplicação.
Applications Insight Code Optimizations
O Applications Insight Code Optimizations é o APM de monitoração de aplicação, dado que, para entrar num código, aplicação em .NET, JAVA etc., muitas vezes é necessário instrumentar o código e alterar trechos para que reportar logs para outro serviço – função do Applications Insights.
Atualmente ele está em private preview em códigos .NET, monitorando o código de uma aplicação e explicando dentro dele qual linha pode estar gerando problemas. Para isso, ele utiliza serviços de IA, faz análise do log para entender o erro e sugerir alteração de código, afinal, apontar melhorias e corrigir códigos só é possível graças ao uso da Inteligência Artificial.
Estes serviços estarão disponíveis em breve, mas atualmente é necessário solicitar acesso.
As recomendações de desempenho acionáveis em nível de código conectam equipes de operações com desenvolvedores e aceleram o tempo de correção, considerando suas principais características:
- Codifica os aprendizados da Microsoft ao executar aplicativos de nuvem de alta escala (Azure, Teams, M365, Xbox) em um modelo baseado em IA;
- Cenário Cloud to Code: a extensão de otimização de código para VS Code integra-se diretamente ao IDE do desenvolvedor para sugerir correções de código .NET relacionadas ao desempenho;
- Incorporado no Copilots para Azure e HigHub.
Microsoft AIOPs – Definições e mercado
Este conceito já existia antes da IA porque era baseado em Machine Learning e os times de infraestrutura e suporte utilizavam AIOps, porque dependiam de um cientista de dados para analisar logs de aplicações não estruturados e fazer análise preditiva de problemas. Entretanto, o AIOps é um conceito que está crescendo ainda mais com o uso da Inteligência Artificial, e começando a ser implementado em serviços.
Entre os principais desafios do DevOps estão: entender o que aconteceu de problema, quais sistemas foram afetados, porquê, o que pode ser feito para corrigi-lo e como. Nesse sentido, o AIOPs ajuda porque já é um serviço que traz a IA embutida.
Azure Monitor AIOps – Construindo a nuvem inteligente
Quando há um incidente e vários erros acontecendo dentro de uma aplicação, o padrão de monitoração é disparar logs e alertas a todo momento. Entretanto, quando há muitos alertas, pode ser mais difícil entender qual faz sentido e está correlacionado com o outro. Por isso, ter um mecanismo que interprete um alerta para diferentes aplicações torna mais fácil entender como aconteceram 50 incidentes smart alerts.
Já o Dynamic thresholds – outro mecanismo de monitoração dentro do Azure Monitor – trabalha baseado no comportamento da aplicação e incidentes. Ou seja, fazendo análise preditiva do que pode acontecer (probabilidades e tendências) com determinada aplicação ou ambiente (o que é um comportamento esperado e não esperado de uma aplicação).
No projeto Smart Detection, por sua vez, se há uma aplicação monitorada pelo Azure Monitor, é possível olhar o código da aplicação através do Application Insights dentro do Azure Monitor. Esta ação envolve alguns fatores como, por exemplo, as regras, que se fossem feitas na mão, serias morosas, porque quanto maior é o seu ambiente, menor o tempo para fazer monitorações em escala, separando esses ambientes e tornando-os mais inteligentes.
Estas e outras funções ficam dentro do Azure Monitor como mecanismos separados e não como ferramenta única. Entretanto, muitos desses mecanismos estão evoluindo pois precisam de tempo para analisar um histórico a fim de entender o comportamento do ambiente, e fazer sugestões e análises, já que não existe o módulo Azure Crystal Ball, que diz o que vai acontecer dentro do Azure.
Microsoft Azure Monitor AIOPs Investigation
O Azure Monitor Investigation é um mecanismo em private preview considerado um dos mais fantásticos para se trabalhar com o Azure, e que atualmente aguarda o lançamento.
A ferramenta é voltada para o time SRE e operações que cuida do ambiente de nuvem, investigando o problema, correlacionando as suas possíveis causas e sugerindo sua correção. Considerando que muitos clientes perdem tempo com “troubleshooting”, a ferramenta se torna imprescindível para auxiliar este processo de análise rapidamente.
A solução de problemas de aplicativos e plataformas reduz o tempo de mitigação (TTM), com tecnologia de IA comprovada em campo, resumo alimentado por IA, integração com Copilot, Configuração fácil “Out of the Box”, Integração com o Azure Monitor, Entre serviços e aplicativos, Várias fontes de dados.
Demo
Ao receber um alerta, anteriormente configurado para envio por e-mail, ao clicar, é mostrado o incidente no portal do Azure. No botão de investigação, o cenário é aberto para apresentar o histórico atual sobre o que pode ter causado o problema, sua explicação, o que fazer pra solucionar e mitigar, além dos recursos afetados, facilitando este processo de análise e investigação, e reduzindo o tempo de solução.
Este recurso tende a ser inserido dentro do Azure Monitor futuramente, visando facilitar o trabalho do “troubleshooting” e investigação. Além disso, há ferramentas similares no mercado com módulo pago da Dynatrace para este processo de análise.
Métrica de diversidade de lotes
- Medir a capacidade do LLM de produzir respostas distintas a entradas distintas;
- Não há necessidade de dados rotulados.
Quando há o recebimento de logs de eventos, são recebidos vários textos para análise e é necessário conferir se estão de acordo com os logs recebidos e se o Azure Monitor está funcionando. Então são recebidos os nomes de várias aplicações que reportam o erro, sendo necessário separar o que é “ruído” e quais têm maior probabilidade de ser a “causa”.
Uma vez separadas as possíveis causas, é necessário buscar em bases indexadas de conhecimento dentro de IA daquele domínio. Então separa-se onde executar a pesquisa em bases de conhecimento para que não seja necessário fazer tudo no Azure, extraindo as informações e comparando o resultado (fazendo a correlação entre eles pra verificar o problema que foi inicialmente levantado) antes de enviar para o usuário.
Ao longo de todo este processo, se fosse possível calcular a quantidade de chamadas feitas para resolver este problema, seriam mais de seis chamadas. Por isso, o objetivo é evitar o que em Inteligência Artificial chama de “alucinação”, ou seja, utilizar ferramentas de IA para perguntas e receber respostas aleatórias, afinal, em suporte, isso nunca pode acontecer.
Por fim, este é um mecanismo inteligente para extrair mensagens relevantes, fazendo pesquisas específicas no domínio dos problemas, gerando prompt de resultado, correlacionando e comparando com o que foi pedido inicialmente, e, finalmente, trazendo resultados para o usuário. Isso ajuda a entender melhor todo o fluxo de resolução.
Copilot – componente do AIOps
O AIOps não é uma ferramenta, mas uma disciplina dentro do portal do Azure, onde já existe o Copilot for Azure – atualmente em preview. Assim como o Investigate – que é mais avançado –, ele opera em código e faz correlação, podendo também pedir sugestão e questionar por quê tal máquina está lenta ou por quê o cluster derruba os nodes. Esta é mais uma ferramenta que ajuda o conceito de AIOps facilitar a vida dos usuários de Azure a fazer “troubleshooting” e operar e administrar seu ambiente.
Existem também outras ferramentas, mas não tantas de AIOps, pois quando se fala de monitoração, envolve praticamente todo o back-end, mas algumas vezes não se têm a percepção do usuário. É comum, por exemplo, um cliente relatar que sabe de um problema por um usuário que liga reclamando, sendo que, neste caso, uma das formas de resolver é utilizando o RPA.
Robot Process Automation (RPA)
Por fim, a Automação Robótica de Processos é uma tecnologia que utiliza robôs de software para fazer a automação de mecanismos em tela simulando um comportamento de usuário.
Há ferramentas específicas – como o Power Automate da Microsoft – capazes de simular a tela de aplicação como um usuário, medindo o tempo de resposta de cada clique com o botão sobre cada tarefa, para verificar como ele está respondendo durante a navegação. No caso da apresentação de falhas ou lentidão em um dos processos, isso gera um alerta de problema que visa melhorar os tempos de resposta das aplicações.
Com isso, o AIOps traz a Inteligência Artificial aos times de operações, aplicações e todos que mexem com o Azure, dado que sua ideia é facilitar o desenvolvimento, já que sabemos que se perde muito tempo fazendo troubleshooting de aplicações e as ferramentas ajudam no diagnóstico e resposta.
Portanto, além de simular problemas, pensar e melhorar aplicações, essas tendências atuais mudam o cenário da arquitetura tornando os ambientes de nuvem mais resilientes, melhores e facilitando as nossas vidas.
