Eu sou Danilo Regis, arquiteto de soluções e especialista em segurança da informação, perícia forense computacional e direito digital com compliance. Também tenho um MBA em Gestão de Empresas pela Fundação Getúlio Vargas.
Audiodescrição: Sou uma pessoa negra com barba, uso óculos, visto uma camisa polo azul-marinho e estou nos estúdios da Alura.
Em um passado não muito distante, nós falávamos muito sobre monitoramento das nossas aplicações. Precisávamos saber se a saúde do nosso ambiente estava adequada às nossas necessidades. Observávamos CPU, memória e a quantidade de espaço disponível em disco. Chamávamos isso de monitoramento, que se concentrava principalmente no passado. Disparávamos alertas quando um determinado disco estava cheio ou quando havia um pico de CPU e, em seguida, iniciávamos o trabalho de encontrar as causas-raiz.
No caso da observabilidade, falamos de algo que já nasce com os correlacionamentos adequados e nos informa não apenas o que aconteceu, mas também estabelece uma relação causal, um nexo causal entre as partes. Isso é parte do que veremos no nosso curso de observabilidade, confiabilidade e SLOs (Service Level Objectives, Objetivos de Nível de Serviço), em diálogo com SLAs e SLIs. Vamos aprender bastante sobre isso ao longo do curso.
Nosso curso passará por sete aulas ou blocos, começando pelo entendimento de três pilares fundamentais da observabilidade: logs (registros), métricas e traces (rastros). Nós vamos discutir o valor que esses pilares possuem dentro do nosso contexto de observabilidade.
Falaremos sobre SLIs, SLOs e Error Budgets (orçamentos de erro): quanto podemos consumir, quando devemos ser conservadores no restante do mês e como agir quando estivermos próximos de violar nosso SLA com clientes e parceiros.
Vamos abordar monitoramento orientado a sintomas e IOPS (Input/Output Operations Per Second, operações de entrada/saída por segundo). Também discutiremos arquitetura para confiabilidade.
Confiabilidade é a ideia de que todo sistema passará por problemas. Nosso objetivo é garantir que, mesmo em situações críticas, o sistema permaneça o mais funcional possível.
Nesse ponto entra, por exemplo, o conceito de graceful degradation (degradação gradual), que é a degradação parcial da aplicação quando possível. Aplicamos a observabilidade como feedback (retorno).
Discutimos como podemos trabalhar para melhorar a arquitetura, prevendo cenários mais críticos, como uma Black Friday (Black Friday) ou um ambiente multicloud (multinuvem) no qual uma das nuvens fique indisponível. Exploramos como a experiência de observação pode fornecer grandes insights (percepções) sobre o que devemos fazer.
Entraremos em prevenção de incidentes, finalizando com o impacto organizacional da confiabilidade.
O curso é voltado para profissionais de diversas áreas. Consideramos as áreas de SRE e de engenharia de confiabilidade: um time que não apenas monitora, mas apoia e colabora com outras áreas para alcançar as metas de negócio da forma mais segura possível. Também é voltado para pessoas desenvolvedoras de software e pessoas arquitetas — todas aquelas que precisam entender a lógica por trás de um ambiente estável o suficiente para alcançarmos os nossos objetivos, sempre de forma equilibrada.
Cada ‘9’ acrescentado aos objetivos de disponibilidade eleva significativamente o custo. Com frequência ouvimos que o sistema precisa ser infalível, com 99,9999% de disponibilidade. Entretanto, cada ‘9’ adicional pode sair muito caro. Faz parte do trabalho de arquitetura e de engenharia entender até que ponto devemos buscar esse número e até que ponto devemos assumir risco. É o número desses ‘9’ que nos orienta: quantas horas estamos dispostos a ficar fora do ar?
Este curso é voltado justamente para quem precisa entender que a confiabilidade é percentual. Ela tem um número e nunca chega a 100%. Pode se aproximar mais ou menos, e isso dialoga com tudo: com o negócio, com o produto, com a relação com fornecedores, com a observabilidade nos ambientes e também com o nosso planejamento.
Um error budget (orçamento de erro), por exemplo, direciona o nosso apetite de risco. Seremos mais ousados se tivermos um orçamento maior e menos ousados se tivermos um orçamento menor.
Espero que vocês gostem do nosso conteúdo e nos vemos a seguir na nossa primeira aula.
Vamos abordar os três pilares básicos da observabilidade: os logs (registros), as métricas e o tracing (rastreamento). Nossos objetivos aqui são entender quais são esses pilares da telemetria, resolver pontos cegos em sistemas e compreender como é feita a correlação de dados para valorizar esses pilares.
Vamos observar um cenário hipotético em um ambiente multicloud (multinuvem), complexo e comum em muitas empresas, muitas vezes com uma dezena ou mais de aplicações necessárias para um determinado sistema funcionar. Nosso sistema simulado descreve um fluxo de pagamentos que nasce de forma externa (por exemplo, na Visa), passa por um API Gateway e faz uma chamada em um cluster do Kubernetes. Esse cluster do Kubernetes publica em um contexto do Azure Service Bus, e essa mensagem é consumida por um núcleo (core, núcleo) de pagamentos.
Esse fluxo percorre um longo caminho: há notificações; temos tópicos e gráficos; e há comunicação com um serviço de benefícios, programas de fidelidade (loyalties, programas de fidelidade) e benefícios externos. Em muitos ambientes bancários, especialmente, há também um contexto em mainframe.
Para que todo esse mapeamento seja correlacionado, utilizamos técnicas de tracing (rastreamento). O tracing (rastreamento) é o acompanhamento de uma chamada entre serviços. Contudo, há um desafio: como garantir que um determinado rastreamento percorra todos os caminhos sem se perder? Por exemplo, quando a chamada entra em um tópico, quando entra em uma fila, quando é colocada em outra nuvem ou quando vai para um ambiente de mainframe que não leva consigo os cabeçalhos do W3C, como o TraceID (ID de rastreamento), e todo o contexto de rastreamento que existe em uma chamada clássica vinda de um ambiente modernizado na web. Chamamos esse desafio de “abismo telemétrico”, que é quando corremos o risco de perder a rastreabilidade daquela chamada. É para mitigar esse risco que as soluções de telemetria e observabilidade trabalham.
Os logs (registros) são gerados pelas aplicações ou por aplicações em sidecar (aplicação paralela), que rodam em paralelo aos códigos. Por exemplo, quando temos uma API em Java para processar pagamentos, ela pode gerar seu log do que está acontecendo dentro da aplicação. Esses registros também podem ser gerados por um sidecar (aplicação paralela). Por exemplo, o Istio operando no modelo sidecar (aplicação paralela) também pode gerar seus próprios logs, assim como outro tipo de aplicação que não necessariamente desenvolvemos.
As métricas representam valores quantitativos, como número de pagamentos, número de requisições, número de erros. E os traces (rastros) são os cabeçalhos (headers, cabeçalhos) e referências que acompanham as chamadas para entendermos que a chamada começou em um ponto A e foi até um ponto X, passando por diversos outros serviços.
A ideia central é que os pilares são importantes e necessários, mas o principal valor está nas correlações entre eles. Um dos padrões de observabilidade prevê que possamos obter informações para análises futuras sem exigir um novo deployment (implantação). Para quem é mais jovem dentro da RHTI isso pode parecer natural, mas, em um passado não muito distante, era necessário alterarmos a aplicação para gerar logs (registros). Um chamado era recebido, analisávamos e, muitas vezes, não conseguíamos reproduzir o erro. Então alterávamos pontos do código para que, caso novamente ocorresse exatamente o mesmo cenário, um log fosse gerado e, só então, fosse possível realizar uma análise mais aprofundada. Com o advento de modelos como o OpenTelemetry, isso deixou de ser necessário. A ideia é que tudo seja instrumentado e que os logs (registros) sejam gerados, muitas vezes, sem que precisemos efetivamente usá-los; mas, em casos de incidente ou de necessidade de uma análise mais aprofundada (uma perícia técnica), esses registros estarão disponíveis.
Quanto a modelos de logs (registros) utilizados hoje, preferimos JSON em vez de TXT. No passado, era comum as aplicações gerarem arquivos .log com textos corridos. Até hoje, é o que temos, por exemplo, no Microsoft IIS: ao acessarmos seu log, ele será um log em TXT, com cada ocorrência em uma linha. Atualmente, adotamos JSON, que oferece muito mais flexibilidade.
A propagação via TraceID (ID de rastreamento), que segue o padrão do W3C, é muitas vezes complementada por um CorrelationID (ID de correlação). Esse CorrelationID (ID de correlação) é um identificador gerado artificialmente no primeiro ponto de contato de uma determinada requisição (request, requisição) ou, em alguns cenários, até antes — podendo inclusive ser gerado no chamador. É possível utilizar o TraceID (ID de rastreamento) como CorrelationID (ID de correlação)? Sim. Ainda assim, é comum empresas grandes, como a Microsoft, trabalharem com ambos. Assim, ao apresentarem algum erro, podemos ver um RequestID (ID de requisição) e um TraceID (ID de rastreamento), ou um RequestID (ID de requisição) e um CorrelationID (ID de correlação). Esses dois identificadores podem ser iguais? Sim, mas, em alguns cenários, geramos números diferentes: por exemplo, o CorrelationID (ID de correlação) sendo gerado na borda (edge, borda), ao lado do TraceID (ID de rastreamento), ou sendo gerado em outro ponto, cada um em um momento diferente. Por ser um padrão W3C, o TraceID (ID de rastreamento) é amplamente utilizado. Toda requisição que não acompanha um TraceID (ID de rastreamento) recebe um novo.
Podemos ter problemas quando algumas bibliotecas não propagam o TraceID (ID de rastreamento) de forma nativa. É comum, para quem trabalha com Java ou .NET, nem pensar em como o TraceID (ID de rastreamento) está sendo propagado, pois bibliotecas como WebClient, REST Client e outros clientes que trabalham com os protocolos TCP e HTTP/HTTPS frequentemente o propagam de forma transparente.
A classificação adequada dos logs (registros) é muito importante. Temos níveis de severidade como: Information (informação), Debug (depuração), Trace (rastreamento), Warning (aviso) e Error (erro). O nível Information (informação) gera registros mais operacionais e, às vezes, não traz detalhes técnicos suficientes. Por outro lado, manter a aplicação o tempo todo em níveis mais verbosos sobrecarrega os sistemas de logs (registros) e as ferramentas de observabilidade. Assim, no dia a dia, operamos em um nível mais alto (menos verboso) em cenário normal e, quando surge a necessidade de analisar melhor uma aplicação, ajustamos via variáveis de ambiente (Environment Variables, variáveis de ambiente), seja no Kubernetes, seja em outro contexto, para gerar mais logs (registros) nos níveis Debug (depuração) e Trace (rastreamento). Feita a análise e passado o período de acompanhamento, elevamos novamente para o nível Information (informação).
Devemos dar atenção especial aos códigos HTTP, amplamente utilizados em observabilidade e com grande peso nas análises. Jamais devemos retornar um HTTP 200 com um corpo sinalizando erro, pois isso prejudica a observabilidade. Precisamos que o código HTTP corresponda, de fato, ao que está acontecendo. Há uma ampla gama de códigos HTTP a recorrer: a família 200 indica sucesso; a família 400 indica problemas relacionados ao pacote da requisição (por exemplo, Bad Request (requisição inválida)); e a família 500 indica problemas internos do servidor.
Por fim, métricas importantes incluem: rate (taxa), isto é, quantas vezes algo acontece por intervalo; erros; e duração.
Nós também trabalhamos com o método USE (Utilization, Saturation, Errors — utilização, saturação e erros). Ele indica quanto determinada operação pesa dentro de um determinado workload (carga de trabalho) e qual é a quantidade de erros.
Este é um exemplo de log. O que temos aqui? Um trecho de log, não um log completo. É um exemplo baseado no OpenTelemetry. Para ilustrar, veja um trecho de log no formato JSON:
"Timestamp": "2026-08-09T13:24:51.102000000Z",
"ObservedTimestamp": "2026-08-09T13:24:51.105000000Z",
"SeverityNumber": 9,
"SeverityText": "INFO",
"TraceId": "4bf92f3577b34da6a3ce929d0e0e4736",
"SpanId": "00f067aa0ba902b7",
"Body": "Payment processed successfully",
"Resource": {
"attributes": [
{ "key": "service.name", "value": { "stringValue": "payment-api" } },
{ "key": "deployment.environment", "value": { "stringValue": "prod" } }
]
}
A seguir, detalhamos seus principais campos. Temos o Timestamp (carimbo de tempo) e o ObservedTimestamp (carimbo de tempo observado), que pode ter uma diferença de milissegundos entre o evento e a captura pela ferramenta de observabilidade. Há também a severidade e o texto, o que é interessante para atribuir controles de observação no ambiente.
Temos o nosso TraceId. O TraceId acompanha toda a cadeia: se a chamada passar por 10 microserviços, todos levarão o mesmo TraceId. O SpanId representa as ramificações: se um microserviço chamar três outros, cada um desses terá um SpanId diferente. Há ainda o Body e alguns exemplos de Resource, como ServiceName e Ambiente.
Esta é a arquitetura do OpenTelemetry. Há uma parte relacionada a rastreamento de chamadas (trace), métricas, Baggage (bagagem, ou seja, dados que incorporam o log) e Propagação de Contexto, que buscamos preservar ao máximo no ambiente. A propagação é uma das capacidades que podemos perder ao entrar, por exemplo, em um ambiente de mainframe (mainframe). Quando falamos em aspectos transversais, referimo-nos a preocupações de cross-cutting (transversal), isto é, algo que roda paralelamente ao que implementamos no negócio.
Os frameworks frequentemente já trabalham nativamente com essa propagação. Ao utilizarmos linguagens como Java e .NET, isso costuma ser natural e embutido nas bibliotecas (libs). É padrão para todas as linguagens? Não necessariamente. Dependendo da forma como implementamos em uma linguagem como Go, podemos perder todos os cabeçalhos (headers) da chamada quando ela passa do serviço A para o serviço B. Os clientes (clients) também costumam ter, nativamente, a funcionalidade de propagar o rastreamento (trace).
Exemplos de atributos que enriquecem as chamadas e os logs: método HTTP (HTTP method — método HTTP), URL (URL) e código de status (status code — código de status). Cada uma dessas informações pode ser utilizada para rastreamento.
Para exemplificar, eis um conjunto típico de atributos registrados junto ao trace/log:
"Attributes": [
{ "key": "http.request.method", "value": { "stringValue": "POST" } },
{ "key": "url.path", "value": { "stringValue": "/api/v1/payments" } },
{ "key": "http.response.status_code", "value": { "intValue": 200 } },
{ "key": "client.address", "value": { "stringValue": "187.56.22.1" } },
{ "key": "client.port", "value": { "intValue": 54120 } },
{ "key": "user.id", "value": { "stringValue": "usr_98a2f1c0" } },
{ "key": "duration_ms", "value": { "doubleValue": 42.5 } }
]
A cardinalidade trata da variação de entradas dentro do log. Imagine incluir, em cada log, uma informação impossível de graficar, como o nome da pessoa usuária. Supondo que desejamos montar um gráfico em uma plataforma para mostrar o que cada pessoa usuária está fazendo: se houver um milhão de pessoas usuárias, não faz sentido alcançarmos esse nível de granularidade de observabilidade. Dizemos, então, que se trata de cardinalidade alta. Jamais vamos implementar controles em cima de pessoa usuária, TraceId, endereço de IP, porta, entre outros. Por quê? Porque é muito difícil; o volume cresce, usamos mais disco e mais memória, as consultas ficam lentas e o custo se eleva muito.
Falamos que um controle tem cardinalidade baixa quando olhamos, por exemplo, para agrupamento por serviços, operações e códigos de status, pois são atributos mais leves, padronizados e com maior valor agregado. Veremos como podemos partir de uma informação e chegar ao nível mais baixo — por exemplo, até uma pessoa usuária específica —, quando necessário.
Com tantas informações sendo registradas em vários logs, a correlação ganha muito valor — e é nisso que a IA brilha. Utilizar a correlação pelo TraceId é um caminho simples e direto de seguir; porém, em ambientes muito complexos, os logs podem se desalinhar e perder correlações. A IA consegue observar outros padrões nesses dados, inclusive pontos que não estamos acompanhando nos painéis de telemetria, e, como lida bem com grandes volumes de dados, tem mais facilidade para estabelecer encadeamentos em toda a massa de logs.
Vamos agora para uma demonstração de como isso funciona por baixo dos panos. Veremos um pouco de métricas, de service mesh (malha de serviços) e de dashboards (painéis). No navegador, vamos rodar uma aplicação de demonstração com operações criadas para simular um ambiente produtivo e entender como isso se comporta na observação.
Estamos em uma instância do Kiali, uma ferramenta de observabilidade que roda sobre o Istio. O Istio é uma aplicação de service mesh que intercepta chamadas por meio do Envoy. O Envoy é um sistema de rede que atua como intermediador, um sidecar (contêiner auxiliar) pelo qual toda chamada entre o ponto A e o ponto B é monitorada. Quando um serviço chama outro, o Kiali mostra cada serviço e o tráfego que circula entre eles. Quando tudo está bem, a indicação aparece em verde; quando há problemas, ele também sinaliza. E como sabemos qual chamada parte do ponto A para o ponto B? Por meio do TraceId.
Vamos agora ao Grafana, muito utilizado como ferramenta que consome logs diversos — inclusive os gerados pelo Istio com o Envoy — e também os gerados pelas nossas aplicações. Cada um desses logs é computado dentro da lógica de taxa (rate — taxa). Assim, temos a quantificação das chamadas, o número de erros ocorridos e a duração média das chamadas. Cada chamada fica registrada e pode ser analisada.
Ao analisar um TraceId específico, encontramos o encadeamento das chamadas. Por exemplo, vemos que algo entrou por um recurso de entrada do Kubernetes, o Ingress (recurso de entrada), percorreu o nosso hub, chegou ao nosso cluster (cluster Kubernetes) e, então, ao serviço de pagamentos. Se abrirmos o log, podemos clicar na opção “Logs for this span” (Logs for this span — logs para este span). Ao clicar, somos encaminhados ao log gerado dentro da aplicação. Assim, partimos da recepção de dados HTTP, seguimos o rastreamento (tracing — rastreamento) da chamada e abrimos o que ocorreu dentro da aplicação. Lá podemos ver mensagens como “checagem de fraude concluída” e “histórico de chargeback (estorno)”, entre outros logs gerados dentro do microserviço.
Como isso é feito? Pelo TraceId. Quanto mais longe conseguimos chegar com o TraceId, melhor. Se for feita uma chamada para um mainframe, talvez percamos o rastro: sabemos que foi até um determinado serviço e, a partir daquele ponto, passamos a chamar de “abismo telemétrico”.
Vimos o Kiali, que é um front-end (camada de interface) para o Istio e o Envoy, e vimos o Grafana. Tudo isso serve para dar transparência e mostrar, na observação, o que está acontecendo dentro dos nossos pods (pods do Kubernetes) e dos nossos workloads (cargas de trabalho).
Concluímos nossa primeira aula entendendo a importância das métricas, desde que devidamente correlacionadas. Não adianta apenas sabermos que existe um erro: queremos que esse erro, partindo daquele TraceId, nos leve até o log gerado dentro da aplicação para que possamos identificar o que ocorreu e por que a chamada falhou. Entendemos as principais métricas, o motivo de buscarmos cardinalidade mais reduzida e a importância de observarmos o que é incomum: códigos HTTP, serviços e pontos específicos que nos permitem traçar métricas relevantes. Voltaremos ao Grafana nas aulas seguintes para entender melhor como essas informações podem ser plotadas e demonstradas. O valor das métricas está justamente nas correlações.
Espero que vocês tenham gostado da nossa primeira aula, e nos vemos a seguir na Aula 2.
Vamos abordar os conceitos de SLI, SLO e Error Budget (orçamento de erros). Nosso objetivo é reforçar que os números que importam são principalmente aqueles observados do ponto de vista do cliente, da pessoa usuária e do(a) parceiro(a). Isso é importante porque viemos de uma época em que o monitoramento era centrado em CPU, memória e disco, e hoje extrapolamos esse foco. Essas métricas continuam relevantes, mas a percepção do cliente final se sobrepõe à saúde do ambiente por si só. Também vamos tratar de SLA (Service Level Agreement, Acordo de Nível de Serviço) e da forma de lidarmos adequadamente com o Error Budget (orçamento de erros).
Começamos diferenciando observabilidade reativa de observabilidade ativa. A reativa é o modelo clássico em que máquinas são monitoradas para verificar CPU, memória e disco, e normalmente geramos alertas quando ocorre uma queda: um serviço caiu, uma carga de trabalho (workload) falhou, um site saiu do ar, e alguém entra em ação para resolver o problema. Em outras palavras, “apagamos incêndios”. A ideia da observabilidade ativa é evitar que o “incêndio” comece ou, ao menos, detectá-lo no início. O que isso significa? Monitoramos o ambiente e verificamos números que indicam que algo ruim está por vir. Assim, tomamos decisões orientadas por Error Budget (orçamento de erros).
O que é isso na prática? É a possibilidade de errarmos dentro de um limite. Temos um pacote de erros possíveis dentro do mês. Podemos, por exemplo, definir que até 1% das vendas pode falhar porque o servidor não respondeu adequadamente. Esse é um exemplo de Budget que usamos como referência. Esse limite também orienta nosso apetite por risco: se temos Budget disponível, podemos nos arriscar mais; o contrário também é verdadeiro.
Começando com SLI (Service Level Indicator, Indicador de Nível de Serviço): são os indicadores que estabelecemos para o negócio. Quais indicadores? Podem ser número de vendas, volume de clientes atendidos, TMA (tempo médio de atendimento), transações efetuadas, pagamentos; enfim, indicadores que fazem sentido para o negócio. A proporção entre o que teve sucesso e o que foi solicitado é nosso SLI. Um exemplo clássico é a quantidade de requisições em um microserviço que retornaram 200 versus o total de requisições enviadas para esse microserviço.
Falamos muito sobre disponibilidade e latência, e acrescentamos a qualidade. Por que qualidade? Não basta a resposta adequada com 200, por exemplo. Às vezes, a informação não está correta. Pensemos em um cálculo de rota entre dois pontos: se a resposta retornada ao cliente está inadequada, isso é um problema de qualidade dos dados. Outro exemplo: janelas de agendamento para exames. A API responde, mas retorna apenas duas janelas de agendamento quando deveria retornar dez. Isso é um problema de qualidade. A ideia é que essa percepção esteja o mais próxima possível do ponto de vista do cliente ou parceiro.
O SLA (Service Level Agreement, Acordo de Nível de Serviço) é nosso acordo sobre qual nível de qualidade e disponibilidade vamos alcançar. Já temos um SLI (o indicador). Com base nele, definimos o SLA: o que vamos buscar e garantir contratualmente. Por exemplo, podemos contratar um serviço “24 horas por dia, 7 dias por semana”, mas tecnicamente isso é expresso por um SLA, como 99,9%. Considerando um mês de 30 dias (43.200 minutos), isso representa aproximadamente 43 minutos de indisponibilidade possíveis no mês. Sempre existe essa margem; ninguém entrega 100% garantidos.
Em ambientes modernizados, é comum utilizarmos SaaS (Software as a Service, Software como Serviço), PaaS (Platform as a Service, Plataforma como Serviço) e IaaS (Infrastructure as a Service, Infraestrutura como Serviço). Podemos usar, por exemplo, Kubernetes e um Blob Storage (armazenamento de blobs), além de um bucket (bucket) e um banco de dados. Se cada um desses serviços tiver disponibilidade de 99,9%, ao combinarmos para formar nosso produto, a resultante é o produto dessas disponibilidades. Nesse caso, 99,7%, o que representa cerca de 2 horas por mês potencialmente fora do ar e aproximadamente 26 horas por ano. São números de referência; não significa que a indisponibilidade necessariamente ocorrerá, mas, conceitualmente, precisamos considerar esse cenário.
O SLO (Service Level Objective, Objetivo de Nível de Serviço) é o objetivo interno. Podemos trabalhar com o que o provedor oferece (aquela regra do produto das disponibilidades). Porém, ao repassarmos isso adiante, não devemos assumir sempre o melhor caso. Se calculamos que, com base no que usamos, temos 99,7%, podemos ofertar ao cliente 99,5%. A diferença é a margem de segurança, que funciona como um amortecedor. Trabalhamos internamente para ter um nível melhor do que o SLA que acordamos com o cliente. Essa margem de segurança é recomendada ao definirmos o SLA contratual.
E onde entra o Error Budget (orçamento de erros)? Ele é a diferença entre 100% e nosso SLO. Se afirmamos que podemos ficar, por exemplo, 43 minutos fora do ar por mês, esse é nosso Budget: 43 minutos “utilizáveis” de indisponibilidade. Como usamos isso de forma positiva? Suponhamos que no início do mês estamos com 0% consumido e ocorram incidentes de SQL que nos deixem fora do ar por 45 minutos. Isso consome nosso Budget, e, ao somarmos mais dois incidentes, podemos esgotá-lo. Esse é o pior cenário: Budget consumido por incidentes.
Existe a visão oposta. Se o Budget foi zerado porque consumimos 100% dele, devemos focar totalmente em confiabilidade. Devemos ser conservadores: é o momento de cancelar as GMUDs, avisar que não haverá mudanças, não lançar novas versões e não aplicar nenhum patch (correção). Por outro lado, se temos Budget de sobra (ou seja, pouco consumido), devemos usá-lo. Vamos publicar versões, testar novas funcionalidades e aplicar patches de segurança.
Com frequência, abrimos o painel da cloud (nuvem) e vemos diversos alertas: “Seu cluster está desatualizado”, “Seu SQL está desatualizado”, “Há muitos patches não aplicados”. Ao perguntarmos por que está assim, a resposta costuma ser “falta de janela” — não houve espaço para realizar uma GMUD. O Budget pode e deve ser utilizado para isso também. Se temos Budget e não há uma versão nova aguardando, vamos usá-lo para atualizar o ambiente. É importante utilizar esse Budget, não desperdiçá-lo, pois é com ele que melhoramos o produto e o ambiente como um todo.
Esse modelo também despolitiza a conversa. Por quê? Quando colocamos números na mesa, temos um argumento forte para dialogar com as áreas de infraestrutura, segurança e produto, tomar decisões e reduzir o risco de comprometer o SLA. A área de produto quer entregar versões novas? Sim, sempre. Mas existe um acordo com o cliente que precisa ser mantido: há um SLA a ser alcançado.
Nenhuma área de produto deseja publicar uma versão e assumir o risco de comprometer o SLA, pois isso pode gerar multa, necessidade de devolver crédito para clientes, abertura de processo judicial e até repasse de perda de faturamento de clientes. Essa situação tende a se tornar uma bola de neve. O conceito de error budget (orçamento de erro) é adequado justamente para considerarmos esse fator na tomada de decisão.
Como costumamos demonstrar o error budget (orçamento de erro)? Utilizamos ferramentas como o Grafana ou alertas enviados para celular e outras plataformas monitoradas.
Vamos retomar o Grafana, no qual destacamos um exemplo de gráfico que mostra uma taxa de sucesso e um orçamento de erro restante. Observamos dois gráficos: um de taxa de sucesso, que caiu para 98,2%, e outro de orçamento de erro restante para o período. Constatamos que 50% do error budget (orçamento de erro) já foi consumido. Ainda estamos na faixa verde, mas quase entrando em uma zona amarela, uma zona de risco. Esse cenário pode ser monitorado por ferramentas como o Grafana, que também disparam alertas para que as pessoas responsáveis tomem decisões.
Voltando à apresentação, precisamos ter muito cuidado com a forma como lidamos com alertas. Quais são os alertas que podem ocorrer normalmente? Em monitoramento, principalmente em ambientes modernizados, com cluster (agrupamento) Kubernetes, não devemos nos precipitar com qualquer alerta. Um serviço pode cair? Pode. Contudo, a própria plataforma muitas vezes consegue restaurá-lo automaticamente, e não precisamos nos preocupar tanto com isso.
No entanto, há casos de consumo muito lento do error budget (orçamento de erro), que avança de forma gradual e passa despercebido. É como uma torneira pingando: por menor que seja o vazamento, ao final do período ele pode, sim, esgotar o orçamento.
Utilizamos como referência o conceito de burn rate (taxa de queima). A referência básica é o valor 1. O que esse 1 significa? Se tudo ocorrer dentro do esperado, o error budget (orçamento de erro) será consumido ao longo de todo o período, sem comprometer o SLA. Com base no rate (taxa), tomamos decisões. Na tabela de referência, o 1 aparece na última linha:
Também trabalhamos com o conceito de percentis. Exemplos comuns: P50, P95, P99 e P100. Evitamos olhar médias para latência, pois a média é uma métrica arriscada nesse contexto. Vejamos um cenário fictício que ilustra a lógica de percentis.
Imagine uma pizzaria com 100 pedidos:
Em termos de interpretação:
O trabalho com a cauda de latência é uma prática dos times de SRE, focada nos extremos. Em sistemas distribuídos, um serviço na cauda pode derrubar todo o restante. Pequenas diferenças, se não forem observadas, podem se desdobrar em um evento que derruba tudo. Para serviços mais críticos, buscamos SLAs mais rigorosos e monitoramos a cauda com ainda mais cuidado, dentro de um processo de melhoria contínua. Não queremos pontos fora da curva: queremos que todas as solicitações sejam bem atendidas e que todos os serviços respondam de forma adequada.
A ideia de percentil é muito utilizada para latência e é o mais comum no Grafana. Contudo, ela pode ser aplicada a outros contextos, pois é um cálculo estatístico:
Finalizamos esta aula entendendo os conceitos de SLI, SLO e error budget (orçamento de erro), e como utilizar o error budget (orçamento de erro) para melhorar processos, fluxos de entrega e de atualização, sendo conservadores quando necessário e inovadores quando possível. Com error budget (orçamento de erro) disponível, podemos inovar e testar. Com restrição, devemos conter mudanças e aguardar a virada do período.
Encerramos por aqui e nos vemos a seguir na terceira aula, a Aula 3.
O curso Observabilidade e confiabilidade: estratégias com SLOs e resiliência possui 175 minutos de vídeos, em um total de 45 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:
Todos os cursos, trilhas e certificados para evoluir.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
Modo entrevista técnica e comportamental
Aprenda mais rápido com IA, idiomas e imersões.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Acesso ao maior portal de vagas tech do Brasil
Desafios de código
System design
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Aceleração de carreira: mentoria, vagas e prática guiada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
2 mentorias individuais com foco na sua carreira
