AIOps e Observabilidade: automação da resposta a incidentes

Apresentando a instrutora e o curso

Olá! Eu sou Camilla Martins, mais conhecida como Panky de DevOps, e estou na Alura para oferecer um curso sobre AIOps (operações de TI com IA) e automação de incidentes.

Este é o segundo curso da carreira de AIOps, no qual trataremos os fundamentos de AIOps e de observabilidade.

Definindo os objetivos do curso

Nosso objetivo neste curso é:

• mitigar o excesso de alertas em ambientes modernos por meio de correlação automatizada de eventos;
• aplicar linhas de base dinâmicas para detecção inteligente de anomalias com redução de falsos positivos;
• integrar inteligência artificial ao processo de resolução de problemas; e
• estruturar fluxos seguros de remediação automatizada, a famosa self-healing (autocura), com guardrails (diretrizes de segurança) e human-in-the-loop (aprovação humana).

Indicando o público-alvo e a programação

Se você é uma pessoa SRE (engenheira de confiabilidade de site), uma pessoa DevOps Engineer (engenheira de DevOps), uma pessoa Platform Engineer (engenheira de Plataforma), uma pessoa Cloud Engineer (engenheira de Nuvem), uma pessoa gestora de TI, atua com DevSecOps (segurança em DevOps), ou é uma pessoa desenvolvedora curiosa para saber mais sobre como automatizar processos em DevOps, me acompanhe nesta jornada.

Vamos falar sobre o volume de sinais: como operar com um volume maior de sinais e alertas e como limpar esse volume. Na Aula 2, veremos detecção de anomalias em operações; na Aula 4, falaremos sobre pesquisa operacional assistida por IA, automação operacional e respostas a incidentes; e, na Aula 5, abordaremos operações resilientes em ambientes distribuídos.

Explicando os pré-requisitos e a abordagem prática

É importante que você tenha alguma familiaridade com Python e Docker e conhecimentos básicos de Kubernetes, apenas para que entenda algumas coisas de que falamos aqui. Você não precisa de uma conta no Datadog ou no Grafana, porque uma das vantagens deste curso é que não vamos usar nada em produção; tudo aqui será apenas de teste, ideias fictícias.

Essas ideias se baseiam em conceitos que eu aplico e uso no meu dia a dia como DevOps Engineer Senior (Pessoa Engenheira DevOps Sênior) e também trabalhando todos os dias com a ajuda da IA, não apenas para a automação de bugs (erros) e correções de problemas, mas para tudo: escrita de código, construção de projetos, escalonamento de infraestrutura, entre outros. Eu uso IA para muitas coisas aqui.

Você não precisa depender de nenhuma LLM (Modelo de Linguagem de Grande Porte) exclusiva nem de nenhuma nuvem exclusiva; tudo será executado em Python, simulando várias situações do dia a dia em produção, e nós passaremos por várias etapas de gestão de incidentes. Espero que você goste, e vou ver você ao longo destas cinco aulas.

[♪]

Apresentando a aula e objetivos

Aula 1

Nesta primeira aula, vamos tratar de observabilidade, priorização, correlação de incidentes e do conceito de alert storm (tempestade de alertas), que ocorre quando um único alerta começa a disparar várias vezes.

Explorando cenários e conceito de alert storm

Vamos discutir cenários em que isso costuma acontecer. Por exemplo, quando a causa é uma API da nossa aplicação que caiu. Se essa API está indisponível e nossa aplicação não consegue se conectar nem executar determinadas tarefas, outras alertas começam a ocorrer: surgem problemas de latência, aparecem erros 500. No entanto, não é apenas um problema de latência ou apenas de erro 500 devido a algo pontual, e sim porque existe uma causa subjacente, a causa raiz, que pode ser uma falha em uma API, uma lentidão nessa API ou uma queda total. Às vezes utilizamos um serviço de terceiros e, ao consultar a página de status, vemos que ele está fora do ar. Há inúmeras situações que levam a múltiplos alertas de lentidão, erro 400 e erro 500 quando, no fim das contas, o problema é uma questão menor que, como um dominó, provoca outros problemas.

O conceito de alert storm (tempestade de alertas) descreve exatamente quando um único ponto de falha dispara dezenas ou centenas de alertas secundários. Esses alertas não estão diretamente relacionados como causa raiz, mas acabam explodindo porque a causa raiz os afeta.

Diferenciando ruído e sinal

Também precisamos diferenciar ruído e sinal, ou seja, distinguir entre alertas que requerem atenção e alertas informativos. Em nosso trabalho, lidamos com falsos positivos e falsos negativos. Às vezes, há um alerta que dispara o tempo todo por latência, por erro 400 ou informando que a aplicação caiu, mas, ao acessarmos o site ou o health check (verificação de integridade) da aplicação, ela está online. Por que o alerta dispara? Em muitos casos, por uma falha no ajuste do limiar (threshold) de alerta ou na configuração desse limiar. Pode acontecer, por exemplo, de verificarmos o site apenas uma vez e, justamente naquele instante, ocorrer uma lentidão ou um breve timeout (tempo limite); com isso, concluímos que o site caiu. Não repetimos a verificação para confirmar se realmente caiu ou se foi apenas uma intermitência momentânea, caracterizando um falso positivo.

Há também o cenário oposto: tudo parece tranquilo, mas descobrimos que a aplicação caiu e demoramos para perceber. Pior ainda, quem nos avisa é a equipe de suporte ou a pessoa cliente. Isso nos coloca em má posição, pois quem deveria monitorar e ser alertado primeiro somos nós, a área de DevOps, e não receber a notícia de terceiros, especialmente considerando que dispomos de diversas ferramentas para reduzir o nosso MTTR, o Mean Time to React (tempo médio para reagir). Quanto menor for esse tempo, melhor, pois significa que possivelmente fomos a única equipe que conseguiu visualizar o erro com antecedência.

Mitigando fadiga e calibrando alertas

Quando há alertas em excesso, confundimos o que é alerta realmente crítico com o que é apenas informativo. Por exemplo, receber um aviso de que estamos com 80% da capacidade de disco é informativo e, ao mesmo tempo, útil, porque ajuda a evitar um problema em produção: a aplicação pode parar, o deploy (implantação) pode falhar por falta de espaço em disco, a memória pode estar no limite, a CPU pode ficar saturada e assim por diante. O ideal é manter alertas preditivos que evitem incidentes, mas sem exagero. Existe aquela máxima: alertas demais equivalem a alerta nenhum, porque passamos a ignorá-los e, quando percebemos, deixamos passar o alerta realmente importante — e então vêm o post-mortem (análise pós-incidente), a sala de guerra e o restante da história.

Também precisamos considerar a fadiga operacional, isto é, o impacto psicológico e técnico causado por uma equipe sobrecarregada de alertas. Já comentamos sobre esse cenário. Imaginemos estar de on-call (plantão) e receber alertas o tempo todo. Recentemente passamos por uma situação assim: percebemos que, na realidade, não eram alertas verdadeiros, eram falsos negativos; parecia que o serviço estava fora do ar, mas não estava. Fomos ao time responsável por essas alertas e por esses recursos — a equipe de bancos de dados — e dissemos que era necessário corrigir, porque estávamos acordando a madrugada inteira. Acordar repetidas vezes e, às nove da manhã, precisar registrar o ponto e iniciar o trabalho é inviável; o cansaço compromete a produtividade.

Alertas não são algo imutável; calibramos constantemente. Às vezes, uma API da aplicação muda, ou muda a região em que trabalhamos, o que altera a latência. Se passamos a atuar, por exemplo, na região da China, a latência é maior. Não podemos configurar um timeout (tempo limite) de 5 ou 10 segundos para verificar a aplicação, pois pode ser curto demais. As alertas precisam ser ajustadas de acordo com as mudanças na infraestrutura. Se o site está mais performático, um timeout grande demais pode mascarar falhas reais na aplicação. Portanto, é essencial calibrar periodicamente e refatorar as alertas. Quando tudo está em infraestrutura como código — em Terraform, em Pulumi —, melhor ainda: fica muito mais fácil refatorar via código, com rastreabilidade do que foi alterado e possibilidade de debug (depuração). As IAs, hoje, ajudam muito nesse processo, tornando-o mais simples do que fazê-lo manualmente e com menor probabilidade de erro.

Simulando alerta em cascata e analisando causa raiz

O que faremos hoje, de forma objetiva: vamos simular uma alerta em cascata. Vamos acessar o vídeo da Aula 1, Volume de Sinais, 1.1, e executar um comando correspondente — é apenas um código simples de simulação. O que veremos é uma simulação de uma alert storm (tempestade de alertas) em uma arquitetura de microsserviços. A causa raiz é um problema de timeout (tempo limite) no banco de dados e, a partir dele, surgem outros problemas: outras alertas disparam por conta desse timeout. Passamos a observar problemas de cache (cache), falhas de autenticação nesse banco e erros 500. Isso é comum: algo começa a falhar e erros 500 se multiplicam. Não aparece apenas o connection timeout (tempo limite de conexão); surgem diversos 500 — em alguns casos, server timeout (tempo limite no servidor) —, por exemplo, vindos de um índice.

Nesse cenário, o catálogo de produtos do site fica indisponível. Por quê? Porque a base de dados está fora do ar; como o e-commerce (comércio eletrônico) vai acessar as informações? O API Gateway começa a lançar erros, a etapa de compra do e-commerce apresenta falhas no serviço de carrinho, a parte de pagamentos também falha. Tudo isso decorre da causa raiz: o banco de dados caiu. O frontend (camada de apresentação) retorna 503 porque o backend (camada de serviço) tem problemas, os quais existem porque o banco de dados está indisponível.

Observamos 9 alertas no total, mais 1 que é a causa raiz, responsável por gerar outras 8 alertas. Ou seja, quase 90% é ruído; apenas 1 é a alerta real, a causa raiz. Qual é a causa identificável? Se resolvermos o banco de dados — colocando o serviço em linha novamente (RDS, MongoDB etc.) —, os demais alertas se resolverão: carrinho, API Gateway, serviço de usuárias(os), autenticação, erros 500 relacionados a produto e à interação entre usuárias(os) e produto. Muitas vezes será assim: existe ruído, e o mais importante é reconhecer que isso acontecerá. É válido ter alertas relacionadas à alerta raiz, mas precisamos entender que a causa raiz é a que resolve todas as demais.

Antecipando correlação de incidentes e encerrando a aula

Sem correlação automatizada, a equipe recebe todas essas alertas simultaneamente e não consegue identificar qual é a causa raiz. Quando tivermos, na próxima aula, a correlação de sinais, poderemos perceber o que é ruído e o que é causa raiz. É isso que veremos na próxima aula, que trata de correlação de incidentes.

Nos vemos lá. Agradecemos! [♪]

Apresentando a correlação de incidentes

Olá.

Depois de analisarmos a questão das alertas e mostrarmos que há ruído entre alertas e que algumas alertas derivam de uma alerta raiz, vamos tratar de correlação de incidentes. Vamos aprofundar essas correlações e apresentar a teoria, mostrando como as plataformas operacionais agregam logs (registros), traces (rastros) e métricas correlacionadas.

Definindo conceitos essenciais e pilares da observabilidade

Alguns conceitos essenciais:

• Correlação de eventos: agrupar eventos distintos que compartilham uma causa raiz. Por exemplo, na situação em que nossa base de dados caiu, conseguimos entender que nossa alerta de cache (cache), a alerta de autenticação e as alertas de erro no nosso e-commerce (comércio eletrônico), tanto no carrinho quanto no pagamento, estão relacionadas a essa causa raiz: a indisponibilidade da base de dados. Precisamos, então, saber como agrupar tudo isso.

Tipos de sinais, os três pilares da observabilidade:

• Logs (registros)
• Métricas
• Traces (rastros)

Detalhando logs e níveis de severidade

Sobre logs:

• Em geral, um log contém um timestamp (carimbo de data e hora) e um log level (nível de log), que indica a criticidade: pode ser crítico, alto (high), médio (medium), informativo (info) ou de depuração (debug). Também pode haver nível de rastreamento (trace), que é ainda mais detalhado.
• Exemplo prático com Terraform: níveis como trace ou debug aumentam a quantidade de informações no log. Isso é importante para entendermos, por exemplo: “não conseguimos criar um load balancer (balanceador de carga); por quê? É um problema na AWS? É um problema no nosso código? É algo no provider (provedor) do Terraform?” Dependerá do que o log traz.
• Info (informativo) é apenas informativo.
• Warning (aviso) não chega a ser um problema, é um alerta. Exemplo: “80% do seu disco já está usado, atenção.”
• Ainda no Terraform como exemplo: um log de warning pode indicar “isto está gerando um plano inválido, entre outras informações”, mas não necessariamente afeta a utilidade ao executar um plan (plano) ou um apply (aplicação).
• Sobre detalhamento: o nível trace engloba o debug; é ainda mais específico. Já o debug não mostrará algumas coisas que o trace exibirá. Em debug, podemos ver mensagens como “estamos executando, usando o provider (provedor) da HashiCorp para Go” e “estamos ignorando um item específico”. Esse detalhamento pode revelar informações que não apareciam em níveis menores.
• Isso é muito importante quando lidamos com problemas. Não se limita ao Terraform; em outras aplicações, um nível de log mais específico ajuda a chegar ao resultado do nosso troubleshooting (diagnóstico de problemas). Por exemplo, descobrimos que algo não funciona porque o provider (provedor) da HashiCorp está indisponível.

Explicando métricas e calibração de limiares

Sobre métricas:

• As métricas nos permitem rastrear o que está funcionando ou falhando na aplicação. Fazemos uma calibração por meio de um threshold (limiar).
• Exemplo: queremos saber quantos erros 500 estamos tendo. Às vezes, é normal haver erros 500, pois podem ser provocados por quem usa o sistema. Porém, se após um deploy observamos 10 erros 500 por segundo, provavelmente não é normal. A métrica nos ajuda a calibrar o que esperamos da aplicação versus o que está acontecendo de fato, distinguindo comportamento esperado de comportamento problemático.

Explorando traces e práticas de postmortem

Sobre traces (rastros):

• Usamos traces para rastrear onde e como algo ocorreu. Após identificarmos um problema pelas métricas e pelos logs, os traces ajudam a entender o “por quê”.
• Eles são úteis para um postmortem (análise pós-incidente). Para quem não tem familiaridade, um postmortem busca responder: “por que o problema aconteceu?”.
• Nesse contexto, usamos o conceito de 5 whys (5 porquês), que auxilia a chegar à causa raiz. Fazemos perguntas como “o quê?”, “por quê?”, “como chegou a isso?” e “onde foi?”. Também podemos utilizar uma estrutura ou template (modelo) para construir o postmortem.

Aplicando o método cinco porquês

Exemplo simples de 5 whys (5 porquês):

1. Problema: não chegamos a tempo a uma reunião; precisávamos executar uma rotina às 9h e não chegamos a tempo.
2. Por quê? Porque chegamos tarde ao trabalho.
3. Por quê? Porque acordamos tarde.
4. Por quê? Porque o alarme não tocou.
5. Por quê? Porque a bateria acabou.
6. Por quê? Porque esquecemos de verificar.

Sabemos que, para que o alarme toque e possamos chegar cedo ao trabalho, precisamos carregar o celular. Por que um projeto não foi entregue a tempo? Porque a equipe estava de férias. Por que estava de férias? Porque as férias foram aprovadas. Por que aprovaram as férias sem saber que um grupo estaria ausente e que o documento e o projeto precisariam ser entregues? Porque não revisaram o calendário do time. Por que não existe um processo para revisar isso? O que precisamos fazer agora? Ao revisar o calendário de aprovação de férias, devemos verificar se haverá pessoas disponíveis nesse período para cobrir todas as necessidades do time. O método Five Whys (cinco porquês) é interessante por essa razão; vamos retomar esse ponto por conta de Trace (rastreamento), que mencionamos aqui.

Correlacionando por tempo e topologia

Correlação por janela de tempo: usar janelas de tempo para agrupar eventos correlacionados. Às vezes temos um log (registro) que parece não ter muito a ver com a situação, mas existe relação. É útil observar esse log (registro) próximo do momento do incidente para investigar. Por exemplo, com o banco de dados: por que o banco caiu? Cinco minutos antes, há um log (registro) de uma atualização no banco. Será que essa atualização não provocou um problema no banco de dados? O banco foi atualizado, caiu e não conseguiu voltar?

Agrupamento baseado em topologia: usar as dependências entre serviços para inferir causalidade. Por exemplo, questões de segurança. Log4j ficou muito famoso como problema de segurança. Será que uma vulnerabilidade que tivemos no time ocorreu porque não atualizamos o Log4j? Ou porque não atualizamos outra dependência? Porque não estamos revisando nossos CVEs, isto é, os registros de vulnerabilidades que indicam o que está desatualizado e vulnerável na nossa base de código?

Demonstrando um incidente e seus sinais

O que vamos ver agora? Vamos realizar uma correlação de eventos de forma rápida nesta aula. Executamos aqui a Aula 1.2. O que temos? Agora estamos correlacionando eventos do banco de dados. Por que o banco de dados caiu? Porque havia muitas conexões. Ele caiu, e ocorreu toda a cascata depois: a cache (cache) ficou indisponível, a autenticação por token (token) também falhou, começaram a surgir erros 503 no front-end (camada de apresentação) porque o back-end (camada de serviços) estava fora.

Esses são os logs (registros). O que temos de métricas? Alguns exemplos: métricas para verificar se a aplicação, como o banco de dados, está on (ligado) ou off (desligado); conexões ativas — quantas conexões existem. Se há muitas, podemos definir um threshold (limite) a partir de X conexões para acionar alerta, pois indica possível sobrecarga no banco. No serviço de autenticação, observar o error rate (taxa de erro): quantas solicitações de autenticação são bem-sucedidas e quantas falham. No API Gateway (gateway de API), latência muito alta provavelmente também indica problema.

Em Trace (rastreamento), podemos ver aspectos relacionados ao serviço de autenticação e ao API Gateway (gateway de API). Falhou a parte de validação da autenticação. A rota até o problema raiz nos leva ao token (token) e ao API Gateway (gateway de API), onde está falhando. Algo está ocorrendo. O quê, onde e como? Onde está ocorrendo? No serviço de autenticação e no API Gateway (gateway de API). O que está acontecendo? Precisamos olhar o log (registro) e a métrica.

Identificando a causa raiz e reduzindo alertas

Quais foram os sinais ingeridos? 11 sinais. Incidentes únicos. O que ocorreu? Causa raiz: o banco de dados. Agrupamos 10 sinais, que foram esses: um problema que afetou o serviço de autenticação, o API Gateway (gateway de API), o front-end (camada de apresentação), o próprio banco de dados, a cache (cache) do banco de dados, etc. O que conseguimos ver? Métrica, log (registro) e trace (rastreamento). Tudo isso ajudou a verificar qual foi, de fato, a causa raiz.

Com isso, podemos reduzir o número de alertas. Ou podemos manter esses alertas, mas entender que, dentre todos, a causa raiz — que, ao ser resolvida, resolve o restante — está no serviço de banco de dados. Também identificamos um problema específico no Payment Service (serviço de pagamento), que ficou isolado: um assunto relacionado à Invoice Generation (geração de faturas) que estava falhando.

Ao correlacionar temporal e topologicamente as sinais, reduzimos de 11 alertas individuais para dois incidentes distintos: um incidente real e um evento isolado sem impacto, que foi a questão das faturas.

Indicando ferramentas e próximos passos

Existem plataformas como Datadog, Datatrace, New Relic e outras. Plataformas de observabilidade são inúmeras, e a escolha depende muito do contexto de trabalho, avaliando prós e contras. Há questões financeiras envolvidas; portanto, é preciso analisar o que faz mais sentido. Também podemos verificar tudo isso de forma automática usando Machine Learning (aprendizado de máquina) e a topologia do nosso próprio ambiente.

No próximo vídeo, veremos como calcular o impacto de uma falha, priorizar o impacto e demais aspectos relacionados. Nos vemos na próxima aula. Até mais!