SRE (Site Reliability Engineering)¶

O que é SRE¶

Definição: SRE (Site Reliability Engineering)

Disciplina que aplica engenharia de software a infraestrutura e operações para tornar os serviços confiáveis, escaláveis e eficientes. A frase que a resume: "e se um time de desenvolvimento ficasse responsável por automatizar um time de operações?" O primeiro time de SRE surgiu no Google em 2003, e a prática se espalhou com os livros publicados pela empresa.

Como se relaciona com os outros times. Quem desenvolve foca nas funcionalidades (requisitos funcionais); operações cuida do não funcional (disponibilidade, desempenho, capacidade, suporte). DevOps é, em origem, um paradigma (cultura de colaboração entre desenvolvimento e operações, automatização e entrega contínua), embora muitas empresas criem um "time de DevOps" focado na experiência de desenvolvimento. SRE é mais específico e abrangente em impacto: define como medir e garantir a confiabilidade (SLOs, orçamento de erro), a prática de incidentes e a automação, e costuma ter um currículo diverso (suporte, desenvolvimento, redes, testes, administração de sistemas). A frase comum: "SRE é uma forma de implementar DevOps".

Competências: (1) SLIs, SLOs e orçamento de erro; (2) gestão de incidentes; (3) observabilidade; (4) desenvolvimento de ferramentas e automação de tarefas repetitivas (reduzir o toil, o trabalho operacional manual, repetitivo e sem valor duradouro); (5) engenharia do caos; (6) revisão de arquitetura, capacidade, releases e production readiness.

Ética da confiabilidade: nenhum sistema deve operar com 100% de confiabilidade — é irreal e economicamente ruim (cada "nove" a mais custa muito). Um site que fica lento e volta ao normal ao atualizar a página é aceitável. O orçamento de erro formaliza isso: quanto tempo/quantas falhas o serviço pode ter antes de a confiabilidade virar prioridade sobre novas funcionalidades.

Pronto para produção

Muitos times de SRE usam uma lista de verificação (production readiness review) antes de assumir um serviço: SLOs e alertas definidos, runbooks, painéis, testes e cobertura mínima, plano de reversão, capacidade, backups e donos claros.

Observability: os três pilares¶

Definição: Observability

Capacidade de entender o estado interno de um sistema a partir dos dados que ele expõe externamente — especialmente importante em arquiteturas distribuídas (microsserviços), onde uma falha pode se originar em qualquer ponto de uma cadeia de chamadas entre serviços. Apoia-se em três pilares complementares: métricas, logs e traces.

Métricas¶

Definição: Métricas

Dados numéricos sobre desempenho, saúde e performance do sistema ao longo do tempo — quantidade de requisições e a saúde de cada uma, taxas de erro, tempo de resposta, consumo de memória e CPU.

Definição: Stack Prometheus + Micrometer + Grafana

Em aplicações Java, a combinação mais usada. O Micrometer instrumenta automaticamente métricas técnicas (latência HTTP, erros, uso de memória, threads ativas) numa aplicação Spring Boot, funcionando como camada de abstração que disponibiliza essas métricas num formato que o Prometheus entende (endpoint /actuator/prometheus). O Prometheus periodicamente coleta essas métricas (scraping, em intervalos configuráveis) e as armazena num banco otimizado para séries temporais, consultável via PromQL, permitindo ainda configurar alertas diretamente quando uma métrica ultrapassa um limite crítico. O Grafana se conecta ao Prometheus como fonte de dados e atua como camada de visualização — dashboards interativos, gráficos em tempo real, mapas de calor, alertas visuais e notificações (e-mail, Slack, Teams).

Logs¶

Definição: Logs

Registros textuais gerados por uma aplicação durante sua execução, contendo informações sobre eventos, operações, estados e comportamentos internos do sistema — uma das principais ferramentas para diagnóstico, depuração e auditoria. Um log é composto, normalmente, por data, horário, nível de severidade (INFO, DEBUG, WARN, ERROR), a origem (classe ou método) e uma mensagem descritiva sobre o evento ocorrido.

Definição: Centralização de logs com Grafana Loki

Em sistemas distribuídos, como microsserviços, eventos ficam espalhados entre diferentes aplicações — dificultando rastrear uma falha só olhando o log de um serviço isolado. Ferramentas como o Grafana Loki coletam, centralizam e permitem buscas rápidas nesses registros. No Spring Boot, o Logback (framework de logging padrão) pode ser configurado para enviar logs diretamente ao Loki via um appender específico (ex.: loki4j). Quando logs, métricas (Prometheus) e traces (Tempo) estão integrados, é possível cruzar todos eles por um trace ID comum, identificando rapidamente falhas, picos de latência e comportamentos anômalos.

Traces¶

Definição: Traces e Spans

Um trace é o registro do caminho completo que uma requisição percorre dentro de um sistema distribuído, passando por diferentes microsserviços, funções ou componentes. Cada trace é composto por uma sequência de spans, onde cada span representa uma operação individual — uma chamada de API, uma consulta a banco, uma publicação no Kafka. Mantendo o mesmo trace id em todas as etapas de uma jornada (ex.: criar um pedido, que passa por frontend → order-service → payment-service → inventory-service), é possível acompanhar toda a jornada ponta-a-ponta, registrando quanto tempo cada serviço levou e onde ocorreu alguma falha ou gargalo.

Definição: Grafana Tempo + Micrometer Tracing

Com o Micrometer Tracing configurado nos microsserviços e o Grafana Tempo rodando, os traces gerados pelas aplicações são enviados automaticamente para o Tempo (via endpoint compatível com Zipkin). O Grafana, conectado ao Tempo, permite visualizar esses traces graficamente — combinado com logs (Loki) e métricas (Prometheus), oferece observabilidade completa de ponta a ponta num sistema distribuído.

AoP (Aspect-Oriented Programming)¶

Definição: AoP (Programação Orientada a Aspectos)

Paradigma que complementa a Programação Orientada a Objetos (POO), lidando de forma elegante com funcionalidades que atravessam múltiplos módulos de um sistema — chamadas de cross-cutting concerns (preocupações transversais), como logging, segurança, tratamento de exceções e gerenciamento de transações. Essas funcionalidades, quando implementadas só com POO, tendem a gerar código repetitivo e disperso pela base de código. A AoP não substitui a orientação a objetos — atua como extensão: encapsula esses comportamentos transversais em aspects, aplicados automaticamente antes, depois ou ao redor de métodos específicos, sem alterar diretamente o código dessas classes.

Definição: Pointcut e Advice

Um pointcut define onde um comportamento transversal deve ser aplicado (ex.: "todo método público de uma classe anotada com @RestController"); um advice define o que deve ser executado naquele ponto (@Before, @AfterReturning, @AfterThrowing) — antes, depois com sucesso, ou quando uma exceção é lançada.

@Aspect
@Component
public class ControllerLoggingAspect {

    @Pointcut("within(org.springframework.web.bind.annotation.RestController *)")
    public void restControllerMethods() {}

    @Before("restControllerMethods()")
    public void logBefore(JoinPoint joinPoint) {
        log.info(" Entrando em método: {}.{}",
            joinPoint.getSignature().getDeclaringTypeName(),
            joinPoint.getSignature().getName());
    }

    @AfterReturning(pointcut = "restControllerMethods()", returning = "result")
    public void logAfterReturning(JoinPoint joinPoint, Object result) {
        log.info(" Retorno de {}.{} => {}",
            joinPoint.getSignature().getDeclaringTypeName(),
            joinPoint.getSignature().getName(), result);
    }

    @AfterThrowing(pointcut = "restControllerMethods()", throwing = "ex")
    public void logException(JoinPoint joinPoint, Throwable ex) {
        log.error(" Exceção em {}.{}: {}",
            joinPoint.getSignature().getDeclaringTypeName(),
            joinPoint.getSignature().getName(), ex.getMessage(), ex);
    }
}

Essa configuração gera logs padronizados para todo REST controller da aplicação — entrada no endpoint, retorno da execução, e exceções — sem que nenhum controller precise conter código de logging próprio. A AoP é especialmente útil para fornecer padronização de logging e contribuir com uma stack de Observability mais assertiva, permitindo que desenvolvedoras foquem na lógica de negócio enquanto aspectos como segurança, monitoramento ou logging são tratados de forma transparente e automática.

SLI, SLO, SLA e error budget¶

Definição: SLI, SLO e SLA

SLI (Service Level Indicator): a métrica medida (ex.: % de requisições com sucesso, latência p99). SLO (Objective): a meta interna para o SLI (ex.: 99,9% de sucesso em 30 dias). SLA (Agreement): o contrato com o cliente, com consequências (multas, créditos) se for descumprido; costuma ser menos rígido que o SLO.

Error budget (orçamento de erro): 100% − SLO. Um SLO de 99,9% permite ~43 minutos de indisponibilidade por mês. Enquanto há orçamento, a equipe pode lançar novidades; quando acaba, o foco muda para confiabilidade (congelar releases, corrigir causas).
Escolha SLIs que reflitam a experiência do usuário (disponibilidade, latência, correção, frescor dos dados) e não apenas CPU ou memória.

SLO	Indisponibilidade permitida/mês
99%	~7 h 18 min
99,9%	~43 min
99,99%	~4 min 23 s

Observabilidade na prática¶

Complementa Observability: os três pilares.

OpenTelemetry (OTel): padrão aberto (APIs, SDKs e collector) para gerar métricas, logs e traces de forma independente de fornecedor; o collector envia os dados a Prometheus, Grafana, Jaeger, Datadog etc.
Métricas RED (para serviços): Rate (requisições/s), Errors (taxa de erro), Duration (latência). USE (para recursos): Utilization, Saturation, Errors. Os quatro sinais de ouro: latência, tráfego, erros e saturação.
Correlação: propague o traceId entre serviços e inclua-o em cada linha de log — é o que permite ir de um alerta ao trace e aos logs da mesma requisição.
Alertas: alerte sobre sintomas que afetam o usuário (consumo do error budget), não sobre toda causa possível; cada alerta deve ser acionável e ter um runbook.

Gestão de incidentes¶

Detectar (alerta, monitoramento, relato) e classificar a severidade (SEV1 a SEV4).
Responder: acionar quem está de plantão (on-call), definir um comandante do incidente e um canal único de comunicação.
Mitigar primeiro, investigar depois: rollback, desligar uma feature flag, escalar instâncias — restaurar o serviço antes de achar a causa raiz.
Comunicar o status a interessados e clientes.
Pós-morte (postmortem) sem culpados (blameless): linha do tempo, causa raiz (ex.: "5 porquês"), o que funcionou, o que não funcionou e ações corretivas com dono e prazo.
Runbook: guia passo a passo para diagnosticar e resolver um problema conhecido (comandos, painéis, quem acionar).
Métricas de resposta: MTTD (tempo para detectar), MTTR (tempo para recuperar).
Escala de plantão saudável: rodízio, limites de acionamentos fora do horário e melhoria contínua para reduzir o ruído.

Engenharia do caos¶

Definição: Chaos Engineering

Prática de injetar falhas controladas (derrubar instância, aumentar latência, cortar uma dependência) em produção ou em ambientes parecidos para descobrir fraquezas antes dos clientes. Ferramentas: Chaos Monkey, Gremlin, LitmusChaos, Chaos Mesh.

Passos: definir o estado estável (SLIs) → formular a hipótese ("se uma réplica cair, o SLO se mantém") → executar o experimento com raio de impacto pequeno e plano de interrupção → observar → corrigir. Combina com circuit breaker, retry, timeouts e bulkhead.

SLOs, métricas e alertas na prática¶

SLO: janela, noves e minutos ruins¶

SLA é um acordo externo e formal (com consequências financeiras, como créditos em caso de descumprimento); SLO é o objetivo interno que orienta a engenharia, sem multa. O SLO deve ser mais rígido que o SLA, para dar margem.
O SLO se expressa por uma janela (diária, semanal, 28/30 dias) e uma meta. 99% equivale a 14 min e 24 s de eventos ruins por dia ou 1 h 40 min 48 s por semana. Janelas semanais ou móveis costumam ser um bom equilíbrio: curtas demais amplificam ruído, longas demais escondem problemas.
Cuidado com noves demais: cada nove aumenta custo e complexidade, e o serviço depende de dependências (nenhum serviço é mais confiável que o conjunto de suas dependências críticas). Comece com um valor razoável (por exemplo 99,9%), meça e ajuste junto com produto e engenharia, mapeando as jornadas de usuário críticas. O MTBF (tempo médio entre falhas) e o MTTR ajudam a pensar no número realista.
Um SLI é a condição mensurável de "bom": por exemplo, taxa de sucesso das requisições ≥ 99,9% e latência da página inicial ≤ 400 ms. É comum contar em minutos bons e minutos ruins (um minuto é ruim se violar o SLI) em vez de requisições individuais, e há SLIs para outros tipos de serviço (pipelines de dados: atraso e completude; filas: tempo de espera; batch: sucesso e prazo).
Orçamento de erro = 100% − SLO. Ex.: com 99,9% e janela semanal, "permitir apenas ~10 minutos ruins na semana". Se o orçamento acaba, congele funcionalidades e priorize confiabilidade; se sobra, é espaço para risco e inovação.

Quatro sinais de ouro e boas práticas de métricas¶

Entre milhares de métricas possíveis, SRE foca em quatro sinais que refletem a experiência do usuário:

Sinal	Pergunta
Latência	Quanto tempo leva para responder? (separe sucessos e erros)
Tráfego	Quanta demanda o serviço recebe? (requisições/s)
Erros	Qual a taxa de falhas (explícitas e implícitas)?
Saturação	Quão "cheio" está o recurso mais limitado? (CPU, memória, disco, fila)

Cuidados:

Tipos de métrica: contador (só cresce: requisições, erros), gauge (sobe e desce: memória, itens na fila), histograma/sumário (distribuição em faixas, para percentis: p50, p95, p99). Prefira percentis a médias para latência (a média esconde a cauda).
Cardinalidade: cada combinação única de labels cria uma série. Rótulos com valores ilimitados (ID de usuário, URL completa, e-mail) explodem o custo do banco de séries temporais. Use rótulos de baixa cardinalidade (rota, método, status) e coloque os detalhes em logs e traces.
Bancos de séries temporais (Prometheus, Graphite, InfluxDB): armazenam (nome, valor, instante) e permitem agregar com funções (avg, rate, histogram_quantile).
OpenTelemetry (OTel): padrão aberto de APIs e SDKs para emitir métricas, logs e traces de forma independente de fornecedor; os dados passam por um collector e seguem para vários destinos.
Logs estruturados (JSON, com ID de correlação) e amostragem de traces (guardar uma fração, priorizando erros e requisições lentas) controlam custo (Observability).

Alertas que valem a pena¶

Fadiga de alarmes: muitos alertas levam a ignorá-los. Cada alerta deve ser acionável, urgente e indicar impacto real. Evite falsos positivos e blips (oscilações transitórias sem impacto relevante).
Alerte sobre sintomas, não causas: em vez de "CPU > 90%" (que pode não afetar ninguém), alerte quando o SLI degrada (taxa de sucesso ou p99). CPU, memória e disco são SLI proxies (indicadores intermediários) — bons para painéis e diagnóstico, ruins como fonte principal de page.
Alertas baseados em orçamento de erro e taxa de consumo (burn rate): dispara quando o orçamento é consumido rápido demais (por exemplo, 2% do orçamento mensal em 1 hora ⇒ page; consumo lento ⇒ ticket). Usar várias janelas (curta e longa) reduz falsos positivos.
Prioridades: page (acorda alguém, resposta imediata) x ticket (resolver no horário comercial) x notificação informativa. Todo alerta de baixa prioridade que chega no plantão deve virar correção da causa-raiz ou ser removido.
Passos acionáveis: cada alerta aponta para um runbook (documento com verificações e ações de mitigação) e um painel. Silêncio prolongado também pode ser sinal de problema (o monitoramento quebrou).
Plantão (on-call): escala justa e sustentável, escalonamento claro, handoff documentado, compensação e limite de alertas por turno.

Ciclo de vida de um incidente¶

Definição: incidente e comandante de incidente

Incidente é um evento não planejado que afeta a funcionalidade de um serviço e exige resposta coordenada. Nem todo problema reportado é um incidente: o SRE decide por triagem. O comandante de incidente coordena a resposta: avalia o impacto, abre um canal de comunicação, aciona especialistas, delega funções e decide, enquanto outras pessoas investigam e executam.

Etapa	O que acontece
1. Problema reportado	Por alerta (ideal), por usuários (tickets, redes sociais) ou por pessoas internas; detecção humana tende a ser tardia
2. Triagem	Há impacto real? Quantos usuários? Define a severidade
3. Diagnóstico	Perguntas: já funcionou antes? O que mudou (deploy, configuração, tráfego, dependência)? Há alteração em métricas, traces ou logs? Invoque especialistas
4. Tratamento	Mitigar primeiro (reverter a mudança, desviar tráfego, aumentar capacidade, reiniciar), corrigir a causa-raiz depois; o comandante sequencia as ações para que não entrem em conflito
5. Revisão	Post mortem sem culpa, itens de ação com responsáveis e prazos
6. Conclusão	Verifica as tarefas pós-incidente e marca como concluído

Severidade (exemplo): Sev0 (indisponibilidade total ou da infraestrutura/observabilidade), Sev1 (funcionalidade crítica com grande impacto), Sev2 (impacto parcial ou degradação), Sev3 (baixo impacto). Severidades podem escalar se a mitigação demora ou o problema se espalha; Sev0/1 são comunicados a toda a organização (transparência).

Post mortem: sem atribuição de culpa (blameless): a falha é do sistema e do processo, não da pessoa; transparente (aberto à organização) e colaborativo. Responde: o que deu certo (replicar), o que deu errado, onde tivemos sorte e o que fazer (ações concretas em ferramentas, telemetria, processo). Se a causa-raiz não aparece, melhore a detectabilidade para a próxima. Agende post mortem para todo incidente Sev1 ou superior.

Métricas de incidentes (revisadas periodicamente, por serviço, time e severidade): MTBF (entre falhas), MTTD (para detectar), MTTR (para recuperar) — e reúna "histórias de guerra" para compartilhar aprendizado.

Monitoramento sintético e simulações¶

Monitoramento sintético: sondas automatizadas executam transações artificiais (login, busca, checkout) continuamente de fora do sistema, medindo disponibilidade e latência mesmo sem tráfego real (por exemplo, de madrugada) e antes dos usuários. Cuidados: funções de escrita não devem poluir produção (use dados de teste e limpeza); a ausência do item-alvo da consulta quebra a sonda; APIs de terceiros fora do seu controle (avalie o SLA e a página de status). Complementa, não substitui, a observabilidade com tráfego real.
Simulações de incidentes (game days, "roda da desgraça"): ensaios controlados ligados à engenharia do caos: formule uma hipótese de estado estável, injete falhas (matar instâncias, atrasar rede, derrubar dependência), observe e aprenda. Ajudam a construir "memória muscular" no incidente, melhorar runbooks, validar alertas, painéis e backups, e testar o escalonamento e o page — como um teste de integração do processo de incidentes (Engenharia do caos).

Ferramentas de SRE e boas práticas¶

Metaengenharia: SREs constroem ferramentas que gerenciam o próprio trabalho: um catálogo de serviços (dono, tier, dependências, repositório, painéis, runbooks), um registro de incidentes e alertas, automação de escalonamento e de post mortems. Exemplo clássico: o Outalator do Google, que cataloga interrupções. Comece mapeando as entidades da organização (serviços, times, incidentes, alertas, SLOs).
Construir ou comprar: não reinvente o que existe, mas lembre das limitações de terceiros (personalização, integração, custo, dependência do fornecedor). Pesam: pontos de extensão, código aberto, esforço de manutenção, tamanho do time.
Orientações básicas de produção: elimine pontos únicos de falha; não faça um deploy e vire as costas (observe a telemetria); tenha plano de reversão; revisão por pares das mudanças; runbooks atualizados; comunique eventos suspeitos; aprenda com sucessos e falhas. Detalhes de implantação segura (canary, blue/green, rolling) em CI/CD e de arquitetura confiável em System Design.

Recuperação de desastres e alta disponibilidade¶

Termo	Significado
RTO (Recovery Time Objective)	Tempo máximo aceitável para voltar a operar
RPO (Recovery Point Objective)	Quantidade máxima de dados que se aceita perder, medida em tempo (ex.: 5 min)
*Failover*	Troca automática ou manual para o ambiente reserva
Multi-AZ / multi-região	Replicar em zonas/regiões diferentes para sobreviver a falhas de datacenter

Backup: completo, incremental ou diferencial, com retenção definida, armazenamento em local separado, verificação de integridade e automação (ex.: pg_dump). Restore: um backup só vale se a restauração foi testada e cronometrada contra o RTO.
Replicação: síncrona (RPO ≈ 0, mais lenta) ou assíncrona (mais rápida, pode perder as últimas gravações); réplicas de leitura aliviam a carga e servem de failover.
Failover: detectar a falha (health checks), promover a réplica, redirecionar o tráfego (DNS, balanceador, service discovery) e comunicar. Evite split-brain (dois nós achando que são o primário).
Estratégias (do mais barato ao mais rápido): backup & restore → pilot light (núcleo mínimo sempre ligado) → warm standby (cópia reduzida funcionando) → active-active (duas regiões atendendo ao mesmo tempo).
Backups só valem se forem testados: restaure periodicamente e treine o plano (game days). Documente o procedimento e automatize com infraestrutura como código.

Platform engineering¶

Times de plataforma criam uma plataforma interna para desenvolvedores (Internal Developer Platform) que oferece caminhos dourados (golden paths): modelos de projeto (templates), pipelines de CI/CD prontas, observabilidade e segurança já configuradas e autoatendimento (portal como o Backstage). O objetivo é reduzir a carga cognitiva e o tempo para colocar um serviço em produção, mantendo padrões e conformidade.

Custo e escalabilidade (FinOps)¶

Dimensione recursos pela demanda real (right-sizing), use autoscaling (horizontal por CPU/requisições; vertical quando necessário) e cache para reduzir carga.
Acompanhe custo por serviço (tags, painéis), desligue ambientes ociosos e avalie instâncias reservadas/spot. Relacione o custo com os SLOs: confiabilidade extra tem preço.

Monitoração e métricas: da sondagem ao APM¶

Métricas são o caminho para entender como a aplicação se comporta entre deploys e mudanças de arquitetura. Há duas formas de obtê-las: instrumentar o código e coletar dados do ambiente*; no meio delas está o profiling, que examina métricas *por camada para achar caminhos de código lentos e problemas de capacidade. O ideal é combinar monitoração, métricas, profiling e eventos (mudanças, problemas de infraestrutura).

Monitoração tradicional (sondas)¶

A monitoração funcional nasceu do ping. Cada teste é uma probe (sonda): ping, porta TCP aberta, resposta HTTP, texto em um log. Sistemas descendentes do Nagios têm um servidor central que executa as sondas em intervalos fixos, envia alertas (e-mail, SMS) e guarda os valores em bancos de séries (RRD; MRTG/Cacti). Há também serviços SaaS de uptime (checagem periódica de sites, com API para pausar a monitoração durante um deploy e evitar falsos alertas). É valioso, mas reativo: diz que a porta 80 está aberta, não que a resposta ficou lenta.

Coleta de métricas: séries temporais¶

flowchart LR
    A["Agentes (CollectD, exporters)"] -->|push| I["Indexador / coletor (Logstash, StatsD)"]
    I --> D[("Banco de séries temporais (Elasticsearch, InfluxDB, Graphite, Prometheus)")]
    D --> V["Dashboards (Kibana, Grafana)"]
    D --> N["Alertas e notificações"]
    P["Aplicação (/metrics)"] -. "pull / polling" .-> I

As métricas são armazenadas como time series (séries temporais): quase toda análise tem o tempo como variável (requisições/s, KB/s, visitas/hora, consultas/s). Os bancos de métricas oferecem operações primitivas para séries.
Push x pull: no push, um agente envia as métricas ao repositório (CollectD → Logstash); no pull (ou polling), o coletor consulta periodicamente uma rota HTTP exposta pela aplicação (modelo do Prometheus).
Pilha "ELK": Elasticsearch (busca e indexação), Logstash (processamento de logs e métricas) e Kibana (dashboards). Alternativas: Splunk (comercial), Grafana + InfluxDB/Graphite/StatsD, Graylog.
Os mesmos princípios valem para métricas de aplicação (tempo de consulta ao banco, tempo de resposta HTTP, usuários autenticados), exibidas no mesmo painel das do sistema operacional (ex.: CPU x usuários logados), além do rastreamento de latência.
Quase nenhuma máquina deve entrar em produção sem a monitoração mínima: automatize o agente e as métricas básicas na própria criação da máquina (CI/CD).
Métricas de negócio ("novos clientes/dia, páginas vistas, cartões aprovados, vendas") se derivam de métricas técnicas e mostram o impacto de mudanças e incidentes no resultado e na satisfação.

Profiling e APM¶

Profiling em produção é coletar métricas do ambiente de execução e da aplicação: mostra caminhos de código otimizáveis, o efeito da latência de rede ou banco no cliente e erros que não aparecem em testes de integração. Os agentes se conectam ao interpretador/VM (JMX na plataforma Java; hooks em Ruby/Python/PHP) ou ao navegador.

Tipo	O que mostra
APM (Application Performance Monitoring)	Tempo de aplicação, rede e banco, separados e acumulados; métodos/funções que mais consomem CPU
RUM (Real User Monitoring)	Dados coletados dos navegadores dos usuários reais: tempo de carga, erros que o usuário vê
Rastreamento de exceções	Captura e indexa exceções de runtime que ficariam perdidas em logs
Fluxos de rede	Quanto e quais dados trafegam entre os componentes do sistema

Desempenho em nuvem: noisy neighbor¶

Cada máquina virtual divide CPU e I/O com as vizinhas, de modo que instâncias do mesmo tamanho podem ter desempenho diferente (noisy neighbor, "vizinho barulhento"). Se a aplicação é simples de provisionar, vale monitorar o desempenho e recriar a máquina para cair em outro host. Instrumentar a aplicação também ajuda a ser proativo, a alimentar novas versões e a controlar custos e perfil de uso (Teste de carga e percentis).