Gestão de incidentes: arquitetura em cenários de crise

Gestão de incidentes para arquitetos - Arquitetura e incidentes

Apresentando o curso

Olá! Sejam bem-vindes ao nosso curso de Gestão de Incidentes para Pessoas Arquitetas.

Sabemos que a pessoa arquiteta desempenha diferentes papéis em diversas empresas, com frequência atuando próxima do desenvolvimento de software, da infraestrutura e até do negócio. Neste curso, mostraremos como é possível que a pessoa arquiteta atue de forma ativa durante crises, em nossas famosas war rooms (salas de incidentes), contribuindo com conhecimento de arquitetura, do próprio ambiente afetado e com conceitos fundamentais de arquitetura que podem impactar o incidente ou aumentar a resiliência desse ambiente diante de uma situação crítica.

Apresentando o instrutor

Meu nome é Danilo Regis e sou arquiteto de soluções há mais de 15 anos, tendo atuado em empresas de pequeno, médio e grande porte, em logística e comércio exterior, na área da saúde e, atualmente, no setor bancário.

Audiodescrição: Sou uma pessoa negra, com pouco cabelo, uso barba, uso óculos e visto uma camiseta vermelha com gola azul. Estou no estúdio da Alura.

Sou especialista em segurança da informação e perícia forense computacional. Também tenho pós-graduação em direito digital e compliance (conformidade) e um MBA (Master of Business Administration) em gestão de empresas pela Fundação Getulio Vargas.

Detalhando a estrutura do curso e o papel na crise

Ao longo do curso, teremos sete blocos ou aulas, começando pelo papel da pessoa arquiteta durante crises, passando por detecção e resposta automatizada — que sempre buscamos projetar para proteger nosso ambiente — e por coordenação e tomada de decisões técnicas na war room (sala de incidentes).

É importante que, durante crises, haja alguém à frente conduzindo os trabalhos, e a pessoa arquiteta é muito adequada para isso, pois conhece tanto o possível impacto no negócio quanto a infraestrutura.

Abordando governança e obrigações regulatórias

Aplicamos governança multinível: a forma como tratamos as informações e autorizamos sua saída de uma sala de crise importa; importa inclusive para o aspecto reputacional da companhia e pode impactar as ações na bolsa de valores.

O post-mortem (análise pós-incidente) é o processo que realizamos após a ocorrência de uma crise para consolidar evidências e elaborar comunicados, por exemplo, a agências reguladoras como a ANPD (Autoridade Nacional de Proteção de Dados). Se a empresa for do setor bancário, podemos precisar prestar esclarecimentos ao Bacen; no setor de seguros, à SUSEP; dependendo da natureza da companhia, à Anvisa ou ao Exército.

Explorando engenharia pós-incidente e engenharia do caos

A engenharia pós-incidente é o momento em que verificamos o que poderia ter sido feito e o que podemos fazer para que o mesmo tipo de incidente não volte a ocorrer ou, se ocorrer, cause menos danos.

Por fim, falaremos sobre redução do risco sistêmico e engenharia do caos, uma mentalidade orientada a lidar com cenários críticos, por exemplo, avaliando a resiliência de parcerias para o ambiente.

Indicando o público-alvo e encerrando a introdução

Este curso é dirigido a pessoas profissionais sênior das áreas de desenvolvimento de software, infraestrutura e arquitetura.

Eu espero que vocês gostem do curso e nos vemos a seguir com nossa primeira aula. [♪]

Gestão de incidentes para arquitetos - Papel do arquiteto em crises

Justificando o papel da arquitetura e analisando o desenho

O objetivo desta primeira aula (Aula 1) é justificar por que o papel de quem atua em arquitetura pode ser central durante uma crise ou um incidente. Para isso, vamos começar analisando um desenho de arquitetura.

Em um cenário fictício, simulamos um fluxo de pagamentos bancários. Por exemplo, a WisaPay realizando um pagamento por meio de uma API (interface de programação de aplicações). O padrão implementado é o Async Request-Reply (requisição-resposta assíncrona), no qual recebemos uma solicitação por um comando e devolvemos a resposta por outra fila ou tópico. Nesse contexto, temos um API Gateway (gateway de API) e um cluster de Kubernetes que recebe a informação e coloca um comando em uma determinada fila. Uma workload (carga de trabalho) processa efetivamente em uma base de dados, aciona um trigger (gatilho) que disparará a avaliação de risco e devolverá a resposta por meio de um tópico Kafka. É somente nesse momento que a Wisa receberá a confirmação da transação.

Identificando pontos de falha e promovendo observabilidade

Observamos que existem inúmeros pontos de falha e pontos em que o processo pode ficar paralisado. Isso significa que a mensagem publicada na fila talvez nunca seja processada, ou que a resposta em um dos tópicos nunca seja publicada. Nesse cenário, podemos ter diversas zonas obscuras, pontos que chamamos de fragmentação telemétrica. Telemetria é o conceito de monitorar uma transação por todos os pontos pelos quais ela passa. Um protocolo padrão para isso é o OpenTelemetry. Esse padrão, utilizado em diferentes cargas de trabalho, toma um TraceID e um SpanID e replica essas informações em todos os componentes para que a telemetria seja exibida adequadamente em ferramentas como Line3, Datadog, New Relic e diversos outros APMs.

Podemos ter falhas críticas, dependências opacas e pontos cegos. Sabendo que isso acontece, nós, pessoas arquitetas, conseguimos direcionar trabalhos efetivos para cada profissional. Por exemplo, podemos solicitar a verificação dos certificados do ambiente para entender se algum expirou. Mesmo sem evidências claras, em um ambiente altamente complexo, nossa experiência permite orientar essa checagem, sabendo que esse é um erro comum que costuma afetar ambientes críticos. A pessoa desenvolvedora consultará os logs da aplicação. A equipe de SRE verificará se existem filas com excesso de mensagens, um volume inadequado para aquele momento. E quem atua em arquitetura, conhecendo o ambiente, ajuda a orientar os trabalhos.

De acordo com a mensagem que apareceu em um log identificado pela pessoa desenvolvedora, nós, pessoas arquitetas, podemos direcionar uma verificação adicional, por exemplo, para as equipes de infraestrutura e SRE. Consideramos todos os incidentes como eventos arquitetônicos, pois existe uma arquitetura sustentando o processo. Assim, podemos ter limitações de infraestrutura ou um dimensionamento inadequado para determinado contexto, além de pontos únicos de falha — por exemplo, alta dependência do nosso sistema de IAM (onde ocorre a autenticação de pessoas usuárias) — e falhas em cascata. Tudo isso se relaciona com a arquitetura.

Avaliando trade-offs e fases da resposta a incidentes

Toda arquitetura apresenta seus trade-offs. Escolhemos determinados níveis de desempenho em detrimento de riscos aumentados. Por exemplo, quando colocamos uma base Redis para acelerar o tempo de resposta, introduzimos um novo ponto de falha. Se esse Redis ficar indisponível, o que acontecerá? Temos um timeout (tempo limite) adequado para consultá-lo e desistir? Existe um fallback (alternativa)? Isso está implementado corretamente? Tudo isso é considerado elemento arquitetural.

Existem frameworks (estruturas) para nos ajudar durante a crise: primeiro o momento de detecção, depois o de isolamento, seguido de mitigação na borda, recuperação segura e sincronização de estado. Todos esses momentos são críticos. Por exemplo, a sincronização de estado ocorre quando retemos informações para não sobrecarregar um ambiente que está se recuperando de um incidente. Isolamos parte do ambiente e, quando essa parte volta, a informação precisa fluir e o estado deve ser replicado.

Aplicando padrões de resiliência: bulkhead e circuit breaker

Vamos tratar de isolamento com o padrão Bulkhead (antepara), a maneira de isolar determinados contextos para que funcionem da forma mais independente possível. O Bulkhead Pattern é um exemplo, e veremos outros ao longo do curso. Aqui, introduzimos o conceito de isolar partes da solução, projetando arquiteturas para que sejam o mais independentes possível. Se parte da solução está em on-premises (local), outra parte está na nuvem, ou ainda em um arranjo multi-cloud (multinuvem), como podemos garantir um Bulkhead? Uma possibilidade é reduzir a dependência entre esses ambientes.

Outro padrão é o Circuit Breaker (disjuntor de circuito), a ideia de termos um circuito que deve se abrir caso parte do ambiente esteja comprometida. Por quê? Às vezes, um determinado ambiente precisa de tempo para se recuperar — por exemplo, o reinício de um servidor ou a incorporação de um novo nó em um cluster. Precisamos dar tempo para a solução se restabelecer, e o Circuit Breaker é justamente uma abordagem arquitetural para isso. Deixamos o circuito aberto e, para tanto, devemos ter algo que funcione com o circuito aberto. Não adianta ter Circuit Breaker se não houver fallback. Por exemplo, em um serviço de consulta de CEP: se identificarmos que o serviço principal está indisponível e abrirmos seu circuito (ou seja, o removemos do fluxo), o que faremos? A solução vai parar completamente? Ou temos um segundo serviço, um segundo servidor ou algum recurso alternativo que possamos usar? A ideia do Circuit Breaker é sempre complementá-lo de forma que o restante do ambiente continue funcionando mesmo com o circuito aberto.

Complexificando a arquitetura com mainframe e multinuvem

Agora, vamos fazer um novo acréscimo à arquitetura apresentada. Adicionamos uma camada on-premises com mainframe. Observamos que, nesse ponto, o tópico Kafka alimenta uma fila IBM MQ que vai abastecer um core. Ao fazer isso, torna-se muito mais difícil monitorar o que está acontecendo dentro desse mainframe. Assim, aumentamos nossa complexidade e incluímos um cenário que provavelmente ficará ofuscado na telemetria.

Tornando o contexto ainda mais complexo, podemos ter, por exemplo, uma base de gestão de benefícios que está em outra nuvem.

Ferramentas modernas de telemetria podem, por meio de um Trace ID (identificador de rastreamento), monitorar duas nuvens. No entanto, não teremos 100% das informações que circulam no ambiente primário, o que pode dificultar a análise.

Correlacionando telemetria com ia e aiops

Observamos aqui um cenário de multi-cloud (multinuvem) associado a um mainframe (computador central), isto é, uma arquitetura híbrida. O padrão Bulkhead (compartimentação) busca isolar, em um único contexto, tudo o que é indispensável para o funcionamento do processo primário. Em cenários complexos como esse, a inteligência artificial pode nos ajudar a realizar correlações, entendendo o que acontece no ambiente multinuvem e no contexto de mainframe no local (on-premises), que pode gerar registros (logs) em formatos distintos, e correlacionando esses dados.

Entra aí o conceito da Gartner de AIOps (operações de TI orientadas por IA), isto é, a aplicação de inteligência artificial à correlação telemétrica. Ferramentas de mercado como Dynatrace, Davis, Datadog e New Relic já oferecem recursos nativos de correlação para chegar às informações mais precisas do que está sendo monitorado. Em cenários de crise, isso nos ajuda de maneira mais assertiva, indicando com precisão onde devemos concentrar a atenção e atuar.

Liderando tecnicamente e alinhando níveis organizacionais

Na liderança técnica, contamos com uma pessoa arquiteta que direciona o aspecto técnico e também observa os dados de negócio. Se falamos de uma linha de vendas, por exemplo, a prioridade é manter as vendas em operação. Assim, se para restabelecer o ambiente for necessário degradá-lo temporariamente — como reiniciar um servidor ou reconfigurar um contexto de rede —, ao analisar o impacto no negócio, a pessoa arquiteta pode orientar uma decisão alternativa.

O alinhamento multinível ajuda a organizar o ambiente, pois podem existir opiniões divergentes entre as áreas de infraestrutura e de desenvolvimento sobre o necessário e sobre a causa do incidente. A pessoa arquiteta precisa olhar de um nível mais executivo, para que a informação que circule durante a crise seja a mais assertiva possível.

Assegurando governança, compliance e gerindo dívida técnica

Governança e riscos regulatórios também devem ser considerados. Em crises, muitas vezes a intenção é restabelecer o ambiente a qualquer custo, o mais rápido possível. Contudo, temos outras obrigações e precisamos garantir, por exemplo, a coleta das informações necessárias para o relatório pós-incidente (post-mortem). Perguntas como “qual é o endereço IP e a porta de origem que estão sobrecarregando o servidor?” e “qual é a pessoa usuária que está causando um bloqueio (lock) na base de dados, extraindo muitos dados?” precisam ser respondidas. Em determinado momento, a pessoa arquiteta pode solicitar uma pausa para observar com calma o que está acontecendo, garantindo a preservação adequada das evidências, pois também zela pelo risco regulatório. Enquanto a área de infraestrutura prioriza a infraestrutura e a área de desenvolvimento foca a estabilidade dos sistemas, a pessoa arquiteta precisa ver o conjunto, conhecer de compliance (conformidade) e as obrigações legais da companhia com os respectivos órgãos. LGPD e GDPR são exemplos clássicos, e também podem existir obrigações perante Anvisa, Bacen, entre outros órgãos.

Crises também podem decorrer do que chamamos de inércia arquitetural. Durante a crise, a pessoa arquiteta avalia a dívida técnica do ambiente. Em empresas muito grandes, é comum sistemas legados com pouco ou nenhum manutenção ficarem fora das modernizações. Suponhamos que estejamos implementando uma nova ferramenta de telemetria e exista um sistema legado executado no computador de uma pessoa gerente (um executável). Isso vira uma zona cinzenta. Imagine ainda um mainframe programado para descontinuação, no qual se decide não incluir monitoramento. Há um custo arquitetural nessa opção.

Quando a pessoa arquiteta orienta uma solução, a recomendação é incluir premissas explícitas: “considerando que existe um ambiente legado”, “considerando que determinado sistema não recebe manutenção”, “assumindo que continuaremos tendo uma zona cinzenta no ambiente”. O papel da pessoa arquiteta é tornar claro para todas as pessoas o risco assumido. Em momentos de crise, quando esse risco se materializa, é fundamental evidenciar que ele havia sido mapeado e não estava priorizado. Isso reforça conceitos clássicos como o registro de riscos, o termo de assunção de risco e a gestão de dívida técnica. Exemplos típicos incluem rastreamento ausente (trace), dependências não mapeadas e acúmulo de dívidas técnicas.

Recapitulando a aula e concluindo

Sintetizando a Aula 1, entendemos que a arquitetura tem relação direta com a gestão de crises, desde o conhecimento da topologia — o entendimento das correlações entre dependências — até a importância de utilizar ferramentas modernas com inteligência artificial para contribuir com correlações telemétricas. Também compreendemos que sempre existem trade-offs (compensações), inclusive envolvendo dados de negócio. Assim, as decisões da pessoa arquiteta nem sempre buscam restabelecer o ambiente no menor tempo possível; às vezes, nós intencionalmente priorizamos ações para nos resguardar, como a coleta de evidências para elaboração do relatório post-mortem e a prestação de contas a stakeholders (partes interessadas) e órgãos reguladores.

Com isso, fica claro por que faz sentido que a pessoa arquiteta esteja à frente da gestão de incidentes, naturalmente ao lado das equipes de SRE, de infraestrutura e de TI como um todo, atuando como mais um braço forte nos processos de gestão de incidentes.

Encerramos a Aula 1 e nos vemos na Aula 2.

Detecção semântica e gestão de crises - Detecção e resposta inteligente

Apresentando a detecção semântica e descrevendo a fadiga de alertas

Na nossa segunda aula, abordaremos a importância da detecção semântica. Vamos entender o que significa semântica nesse contexto e como funciona a resposta automatizada.

Para quem atuou nos anos 1990 e 2000, eram muito comuns os monitoramentos em que uma determinada tela exibia alertas e indicações de status (se estavam ativados ou não), com sinalizações de erro, de warning (aviso) e pouca informação adicional. Hoje consideramos esse modelo ineficiente, pois frequentemente apresenta muitos falsos positivos e métricas totalmente isoladas ou descontextualizadas.

Existe o que chamamos de fadiga de alertas. A fadiga de alertas é um cenário que persiste até hoje: monitoramentos com alertas na tela em que determinadas pessoas dizem para não nos preocuparmos, que é normal, que aquela sinalização “sempre aparece” e não merece atenção, “é um alerta da casa”. Isso é fadiga. Quando temos uma tela com alertas que não exigem atenção, isso cansa, desvia nosso foco para destaques do monitoramento que não trazem significado. Não podemos permitir que isso ocorra; um alerta nunca pode ficar “fatigado”. Ele precisa ser tratado ou, se de fato deixou de ser importante, o monitoramento correspondente deve ser removido e aquela instância de serviço ou workload deve ser descontinuada, já que não é mais relevante.

Correlacionando monitoramento de infraestrutura ao negócio

Também existe o tipo de monitoramento que observa recursos: recursos de rede, de infraestrutura, links. São monitoramentos que continuam importantes. É essencial conhecermos a saúde da nossa infraestrutura e dos nossos servidores; isso segue sendo relevante. No entanto, hoje esse tipo de monitoramento perde força quando deixamos de correlacioná-lo com o nosso negócio. Este exemplo de monitoramento é de uma ferramenta muito interessante, o Zabbix, ainda amplamente utilizado. Veremos, ao longo desta aula, que ele é importante, mas ganha muito mais força quando conseguimos correlacioná-lo com nosso negócio.

O problema central é acreditar que uma saturação de CPU, um erro de rede ou algum tipo de recurso de infraestrutura se sobrepõe ao que realmente importa: o que aquilo representa para o nosso negócio. Quando temos esse tipo de monitoramento sem deixar claro o que está ocorrendo do ponto de vista do negócio, ele perde força. Por isso, hoje os monitoramentos de infraestrutura são realizados de outras formas.

Modelando telemetria orientada ao negócio com logs semânticos

Quando falamos de SRE, falamos do papel da avaliação de logs (registros) semânticos com contexto. São serviços que dizem o que fazem, de fato, não apenas tecnicamente. O fator técnico, isoladamente, não é o mais importante. Precisamos correlacionar com algo relacionado ao negócio. O SRE é quem vai monitorar a operação por meio das ferramentas, e a pessoa arquiteta auxilia a modelar o ecossistema telemétrico.

O que isso significa? Que começamos pelas métricas de negócio, identificamos os caminhos críticos e tudo aquilo que representa o tráfego e as operações monitoradas. As ferramentas que monitoram nosso ambiente precisam saber o que esses eventos significam para o negócio. Só então entram os aspectos que conhecemos de desempenho e disponibilidade.

Isso fica mais claro quando analisamos o diagrama do The Open Group, do TOGAF. No TOGAF, a arquitetura corporativa nasce em uma camada de negócio e se desdobra por nossas aplicações e tecnologia. Sempre que criamos uma solução, existe uma motivação estratégica para o negócio. Por exemplo, atender uma pessoa cliente ou disponibilizar um meio de pagamento. A camada de negócio engloba nossos serviços e ofertas. Por exemplo, efetuar um PIX. Queremos possibilitar um pagamento via PIX. Teremos uma camada de aplicações que sustenta esse interesse de negócio e um suporte via tecnologia. Aqui falamos de um cluster (agrupamento), de uma fila, de um tópico.

Quando ocorre um incidente, percorremos o caminho inverso. Se um determinado cluster (agrupamento) estiver fora de serviço, já precisamos ter mapeada na telemetria a correlação: o que isso significa? O que deixamos de prover ou comercializar por causa dessa falha tecnológica? O elo entre essas duas dimensões está na camada de aplicação. A camada de aplicação começa a fornecer logs (registros) semânticos, que indicam o que está sendo feito. Por exemplo: compra realizada, pagamento efetuado, cartão emitido, relatório médico concluído, reserva confirmada. A camada de aplicação gera logs (registros) que criam um elo e informam à telemetria o que de fato está ocorrendo.

Implementando ciclo de resposta inteligente e autocura

Temos, então, um ciclo de resposta inteligente, baseado nas informações fornecidas pelas aplicações. A primeira etapa é a ingestão de logs (registros) e métricas. Em seguida, realizamos uma análise que pode ser preditiva. Consumo de CPU e memória é importante? Sim. Mas o que nos diz mais sobre o estado do ambiente? Por exemplo, uma fila com muitos comandos a executar. Quando essa fila cresce, é sinal de que o ambiente precisa se adaptar. Isso se torna uma análise preditiva. Hoje temos ferramentas que conseguem ler esse tipo de indicador. Por exemplo, o KEDA, uma ferramenta que conectamos ao Kubernetes e que pode monitorar uma fila, um tópico ou algum tipo de gargalo, para aumentar a quantidade de pods (instâncias de execução no Kubernetes), escalar para cima e para baixo.

O isolamento semântico pode ser assistido por IA. Em ambientes muito complexos, com diferentes ferramentas ou etapas que geram zonas ofuscadas, a inteligência artificial pode auxiliar nessa correlação. O self-healing (auto-recuperação) é o que configuramos dentro do nosso SOAR (Security Orchestration, Automation, and Response — Orquestração, Automação e Resposta de Segurança), nosso sistema de respostas automatizadas a incidentes, para, por exemplo, reiniciar um workload (carga de trabalho), levantar um novo nó, aumentar a quantidade de pods (instâncias no Kubernetes) da aplicação ou reiniciar algum tipo de serviço.

Temos, inclusive em sistemas legados, um Windows Service (Serviço do Windows) que processa determinada fila. Se observamos que essa fila está gerando gargalo, aumentando e não sendo processada, o que podemos fazer? Configurar um reinício automático desse serviço ou até do servidor. O self-healing (auto-recuperação) reúne mecanismos e estratégias para que o ambiente se restabeleça por si só. Às vezes, já vamos arquitetar com o conceito de self-healing (auto-recuperação) desde o início; às vezes isso será nativo quando usamos um cluster (agrupamento) Kubernetes. Falamos muitas vezes de recursos nativos, como rollout (implantação gradual) e readiness (prontidão), que funcionam automaticamente dentro de um cluster (agrupamento), mas também podemos criar self-healing (auto-recuperação) derivado de algum tipo de incidente: sempre que ocorrer o problema X, tomamos a ação Y. Isso pode ser automatizado.

Enriquecendo o monitoramento com métricas de negócio

Esse já é um exemplo de monitoramento rico. O monitoramento rico adiciona às métricas da ferramenta — neste caso, o Dynatrace — números de pedidos ou ordens processados, estado de um determinado estoque e de entregas. Esse monitoramento deixa de tratar apenas de CPU, memória ou da saúde de um pod (instância no Kubernetes). Passa a observar, de fato, indicadores de negócio. Podemos estabelecer uma baseline (linha de base), que indica o volume esperado para aquele dia e faixa horária, muitas vezes comparando com o mesmo período do dia anterior, da semana anterior ou do mês anterior, nas mesmas datas. Isso é uma correlação de informações de negócio.

Quem gera essa informação? As aplicações. Vamos até a aplicação e inserimos um log information (registro informativo), um log debug (registro de depuração) ou outro tipo de log (registro) para gerar dados como “ordem processada” e “volume movimentado”, entre outros.

Quando temos essas correlações estabelecidas, podemos definir nossos SLIs e SLOs, isto é, nossos indicadores e objetivos de nível de serviço: em termos formais, um Service Level Indicator (indicador de nível de serviço) e um Service Level Objective (objetivo de nível de serviço). Com a correlação, deixamos de acompanhar apenas a contagem de códigos de erro HTTP 400 ocorrendo e passamos a observar, por exemplo, o número de vendas não concretizadas ou com falha em um período determinado.

Podemos estabelecer o Error Budget (orçamento de erro), que é o número aceitável de falhas para uma operação dentro de um período. Digamos que, no contexto bancário, definimos o número de confirmações de pagamento e não toleramos que mais de mil transações falhem durante toda a semana. Quando estamos gastando muito desse orçamento, o que podemos fazer? Podemos tomar decisões para reduzir risco, como não realizar um deploy (implantação) nesse período, porque uma nova versão pode desestabilizar o ambiente. Se começamos a gastar muito, podemos tomar decisões estratégicas no negócio para favorecer algum tipo de ação. Em termos práticos, isso se traduz em metas: estabelecemos uma meta de conversão e uma meta de erros toleráveis. Com isso, traçamos uma estratégia para mitigar e evitar exceder o nosso Error Budget.

Considerando estacionalidade, modelagem estocástica e análise probabilística

Estacionalidade operacional e telemetria são conceitos fundamentais. Estacionalidade é o nome que damos a períodos em que determinados comportamentos ocorrem, como no contexto de Black Friday ou Dia das Mães. São fenômenos que acontecem de tempos em tempos. O que é modelagem estocástica? É um cenário em que temos certo grau de previsibilidade comprometida. O estocástico, não determinístico, prevê flutuações. Existem algoritmos aos quais podemos recorrer e que muitas ferramentas já trazem, às vezes de forma nativa, para nos ajudar.

Entram aqui a modelagem temporal e as flutuações baseadas em padrões históricos: mesmos movimentos, em dias diferentes ou horários diferentes. Podemos ter uma expectativa e gerar alertas se houver algum tipo de ruptura nessa expectativa. Um baseline (referência) real reflete o comportamento histórico com uma referência dinâmica e contextual. Um baseline é nossa meta para uma determinada métrica, que podemos estabelecer em colaboração com a equipe de negócio ou por meio de análise histórica.

Quanto à análise probabilística, ela se baseia em algo totalmente variável. Quando usamos muito? Por exemplo, em assistências baseadas em inteligência artificial, como análise de crédito por IA. Às vezes observamos um comportamento chamado drift (desvio), quando a inteligência artificial deixa de responder como se esperava. Isso pode gerar um tipo de anomalia, que as ferramentas podem detectar e, assim, disparar alertas.

Portanto, estatística, probabilidade e estacionalidade são fatores que devemos ter em mente. Nem sempre a métrica do dia a dia é a mesma métrica que deve ser aplicada em datas ou momentos específicos. Se a área de marketing lança uma promoção que vai sobrecarregar o ambiente, a comparação com o mesmo período do dia anterior, às vezes, não serve. A estacionalidade entra justamente para entendermos que existem variações de acordo com determinados contextos de negócio.

Aplicando inteligência artificial para correlação e anomalias

Como já comentamos no primeiro bloco, a inteligência artificial, ou AIOps, nos ajuda a fazer correlação em escala, isolamento de dependências e triagem automatizada. Ela nos auxilia a olhar no lugar certo. Quando temos uma ferramenta de IA consumindo nossos logs e nossa telemetria, contamos com a ajuda de um “superespecialista” capaz de observar, considerando estacionalidade, probabilidade e até contextos não determinísticos e estocásticos, qual deveria ser o comportamento esperado naquele momento. Devemos, portanto, utilizar e conhecer esses recursos de IA integrados às nossas ferramentas e, se não os tivermos, é o momento de avaliar novas ferramentas que tragam esse tipo de capacidade.

Falamos ainda sobre descoberta contínua, grafos e redes neurais — três elementos que a IA usa para chegar a determinadas conclusões. Lembramos que sempre podemos ter falsos positivos e falsos negativos; por isso, além da análise dinâmica, mantemos em paralelo nossos guardrails (regras de proteção) e monitorações mais efetivas, como conversão de vendas, conversões de entrega e efetivações de pagamento. Assim, deixamos que a IA trabalhe principalmente para tratar anomalias estocásticas e variações sazonais de um determinado processo.

Exemplo: relação entre volume de vendas, número de pods e quantidade de mensagens aceitáveis dentro de uma determinada fila. A IA pode fazer essa correlação que, às vezes, deixamos passar por se tratar de um cenário atípico, como no padrão apresentado na primeira aula: o padrão Request-Reply (solicitação-resposta), em que temos comando via fila e resposta via tópico. Para estabelecer o equilíbrio do ambiente, a IA pode ajudar, indicando: “Há algo errado, o volume deste ponto específico não está proporcional ao que deveria sair pelo tópico.”

Orquestrando playbooks e mecanismos de resiliência em múltiplas camadas

Entramos também em detecção de incidentes e execução de playbooks (roteiros de ação), o que significa já termos preparados nossos scripts para tomada de decisão conforme o tipo de incidente. O conceito de self-healing (autocura) é justamente a ideia de que já conhecemos o problema, já passamos por um incidente desse tipo e, toda vez que ocorre, tomamos determinada ação — o que chamamos de playbook.

Exemplos clássicos incluem o circuit breaker (interrupção de circuito) com graceful degradation (degradação gradual). Podemos desativar parte do processo, desviar um fluxo para um servidor de fallback (alternativa), levantar outro servidor ou usar outra cloud (nuvem). Podemos ter um serviço primário que responde com latência muito baixa dentro do nosso ambiente, dentro do nosso padrão de Bulkhead (compartimentação) e, em um caso mais crítico, desviar esse fluxo para um serviço primário em outra rede. Aplicamos o circuit breaker, desviamos para um fallback e podemos optar por graceful degradation, desativando funcionalidades do sistema enquanto o ambiente não está totalmente estável.

A autocura e os mecanismos de resiliência se aplicam tanto à camada de rede quanto à camada de aplicação e à camada de infraestrutura. Na camada de rede, normalmente usamos ferramentas de borda, como Akamai, Cloudflare, Azion e outras, que por si só têm recursos para nos ajudar e também aliviar nosso backend (servidor de aplicação), tratando muitas coisas já na primeira camada. A camada de aplicação é o ponto mais crítico; muitas vezes não recebe o devido cuidado. Devemos adotar cuidados como usar um service mesh (malha de serviços), por exemplo, Istio com o Envoy, para dar tempo às aplicações responderem adequadamente, aplicando uma retry policy (política de repetição) e uma timeout policy (política de tempo limite). Na camada de infraestrutura, falamos de autoescalonamento, como o que o KEDA nos proporciona dentro do nosso cluster (conjunto de nós).

Sintetizando aprendizados e encerrando o bloco

Sintetizando na nossa Aula 2, discutimos a importância de alertas dinâmicos e contextuais e a relação entre a camada de negócio, a camada de aplicação e a camada de tecnologia. Essa correlação é o que confere semântica e lógica de negócio ao que observamos tecnicamente. Abordamos o uso da inteligência artificial para estabelecer uma correlação mais efetiva, especialmente em cenários de estacionalidade e contextos atípicos, e a automação nas bordas, por exemplo, utilizando circuit breaker, playbooks e autocura em diferentes camadas, cada uma com sua lógica e sua estratégia.

Com isso, finalizamos nosso segundo bloco e nos encontramos a seguir no próximo.

Sobre o curso Gestão de incidentes: arquitetura em cenários de crise

O curso Gestão de incidentes: arquitetura em cenários de crise possui 145 minutos de vídeos, em um total de 29 atividades. Gostou? Conheça nossos outros cursos de Arquitetura de Software em Back-end, ou leia nossos artigos de Back-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Gestão de incidentes para arquitetos
• Detecção semântica e gestão de crises
• Comunicação em incidentes
• Postmortem e preservação de evidências
• Engenharia pós-incidente e resiliência