Plataforma · Observabilidade

Cada sinal é um aviso antecipado.

Operamos plataformas de missão crítica como uma torre de controle: cada serviço, cada região e cada job aparece em tempo real no radar. Quatro sinais — métricas, traces, logs e eventos — em uma só stack OpenTelemetry, com SLAs de detecção e resolução acordados em contrato.

LIVE · Mission Control SWEEP · 6.0s
RANGE · 1200ms 99.992% UPTIME 30d
01 · Quatro sinais

Métricas, traces,
logs e eventos.

Logging sozinho é narrativa sem mapa. Adotamos os quatro sinais canônicos da observabilidade — instrumentados via OpenTelemetry e correlacionados por request-id de ponta a ponta — porque cada um responde a uma pergunta diferente sobre o sistema.

Métricas

Quanto · com que frequência

RED (Rate · Errors · Duration) por endpoint e USE (Utilization · Saturation · Errors) por recurso. Agregadas, baratas, alertáveis em segundos.

  • Prometheus · OTLP
  • Histogramas p50/p95/p99
  • Alta cardinalidade controlada
Traces

Onde a latência mora

Span único acompanha a request do cliente até o último callback de banco. W3C trace-context propagado, sampling adaptativo na head, 100% retido em erro.

  • OpenTelemetry SDK
  • Tempo · Jaeger · Honeycomb
  • Tail-based sampling em incidentes
Logs

Por que aconteceu

Estruturados em JSON desde o nascimento, enriquecidos com correlation-id, tenant e versão de build. Sem PII em texto livre, retenção alinhada a LGPD/GDPR.

  • Serilog · structured logging
  • Loki · OpenSearch · ELK
  • Redação automática de PII
Eventos

O que mudou no mundo

Deploys, feature flags, migrations e ações operacionais publicadas como eventos. Toda alteração tem timestamp e ator — quando o gráfico vira, sabemos o que mexeu.

  • Audit log imutável
  • Annotations em dashboards
  • Change-correlation automática
02 · Stack de instrumentação

Uma linguagem
do edge ao banco.

OpenTelemetry como padrão único — backend, web e mobile falam o mesmo protocolo. Trocamos backend de armazenamento sem reescrever instrumentação; o vendor é commodity, o sinal é nosso.

Camada
Componente
Responsabilidade
Ferramentas
Cliente
Web · Mobile
RUM em browser e mobile, Core Web Vitals em produção, crash + ANR, sessão correlacionada ao backend.
OTel WebSentryCrashlytics
Edge
Gateway · CDN
Traces no API gateway, métricas WAF, latência de borda por região, log estruturado de cada hit.
EnvoyYARPCloudflare
Aplicação
.NET · Node · workers
System.Diagnostics + ActivitySource em hot paths, baggage propagado, exceptions capturadas com causa raiz.
OTel .NETSerilogBenchmarkDotNet
Plataforma
Kubernetes · runtime
Métricas USE de cada pod, kube-state, eventos de scheduler, custos por namespace correlacionados.
OTel Collectorkube-state-metricsOpenCost
Dados
DB · cache · bus
pg_stat_statements, slow-query log, lag de réplica, lag de consumer, dead-letter monitorado.
pgbadgerRedisInsightBurrow
Backbone
Armazenamento · visualização
Métricas, traces e logs em uma stack unificada, dashboards versionados em git, alertas como código.
GrafanaPrometheusTempoLoki
03 · Orçamento de latência

Cada hop tem
seu teto.

Latência ponta-a-ponta é soma de hops. Definimos o orçamento por etapa antes da feature existir — quando uma camada estoura, o alerta sai antes do usuário notar.

Cliente · TLS
12 ms
CDN · Edge
9 ms
API Gateway
7 ms
Auth · OIDC
16 ms
BFF · App
21 ms
Cache · DB
24 ms
Serialização
10 ms
Render · client
19 ms
Orçamento p99 fim a fim
≤ 250ms
Meta padrão para APIs transacionais; jornadas críticas operam sob 120ms.
Burn-rate alerta
14m
Alerta dispara quando o budget mensal é consumido 2× mais rápido que o esperado em janela curta.
Detecção
< 60s
Tempo médio entre o evento real e o alerta acionado — anomalia detectada no agregado de 1 minuto.
04 · SLA de resolução

Compromisso
em contrato.

Severidade dita resposta. SLA não é aspiração — é cláusula contratual com janela de detecção, primeiro contato e resolução-alvo. Cada plano de suporte ajusta os números; estes são o piso TecLimit.

Severidade
Detecção
Primeiro contato
Mitigação
Resolução-alvo
SEV-1 · Crítico Indisponibilidade total Serviço fora do ar, perda de receita ou risco regulatório.
≤ 60sAuto · paging
≤ 5minOn-call confirmado
≤ 30minRollback ou bypass
≤ 4hRCA pública em 5d
SEV-2 · Alto Degradação severa Função crítica indisponível para parte dos usuários ou SLO comprometido.
≤ 3minMétrica + log
≤ 15minOn-call em sala
≤ 2hWorkaround ativo
≤ 24hFix em produção
SEV-3 · Médio Função parcial afetada Bug visível mas não-bloqueante; existe alternativa ou retry resolve.
≤ 15minAnomalia + ticket
≤ 1hHorário comercial
≤ 8hPlano de ação
≤ 5d úteisSprint corrente
SEV-4 · Baixo Cosmético ou pedido Inconsistência menor, pedido de melhoria, débito técnico identificado.
Reportado
≤ 4hTriage diário
N/A
Backlog priorizadoPróxima janela
05 · Ciclo do incidente

Detecção, resposta,
aprendizado.

Toda ocorrência percorre o mesmo trilho — do alerta automático à RCA publicada. Cada etapa tem dono, cronômetro e artefato. Falhar é aceitável; aprender devagar não.

01 · Detect

Sinal vira alerta

SLO burn-rate, anomalia em métrica RED ou erro novo no trace pageiam o on-call automaticamente.

≤ 60s
02 · Acknowledge

On-call assume

Pager confirmado, sala de guerra aberta no Slack, comunicação inicial ao status page e cliente.

≤ 5min
03 · Mitigate

Parar a sangria

Rollback, feature flag, bypass de cache, traffic shift. Estancar primeiro, entender depois.

≤ 30min
04 · Resolve

Restaurar plenamente

Causa raiz isolada, fix validado em staging, deploy progressivo, métrica volta ao verde.

≤ 4h
05 · Communicate

Atualizações honestas

Status page atualizado a cada marco, e-mail aos stakeholders, canal dedicado a clientes em SEV-1.

a cada 30min
06 · Learn

RCA blameless

Análise sem culpado, ações corretivas com dono e prazo, mudanças de design para tornar o erro impossível.

5 dias
06 · Comunicação de incidentes

A verdade,
antes do boato.

Cliente que descobre primeiro pelo Twitter perdeu duas vezes. Mantemos canais oficiais com cadência e tom calibrados — clareza sob pressão é treinada, não improvisada.

Status page público

status.teclimit.com · sempre visível

Página independente da plataforma, hospedada fora da nossa infraestrutura. Histórico de incidentes, manutenções programadas e métricas de uptime auditáveis.

Atualizaçãoa cada 30 minutos durante incidente
Histórico90 dias visíveis · arquivo permanente
Inscriçãoe-mail · RSS · webhook · SMS

Canal direto ao cliente

e-mail + chat dedicado

Em SEV-1 e SEV-2, abrimos canal dedicado por cliente com engenheiro responsável e líder técnico. Sem fila, sem tickets — comunicação direta enquanto o incidente vive.

Acessoslack-connect · teams · whatsapp
Cadênciaprimeiro contato em 5 minutos
EncerramentoRCA enviado em até 5 dias úteis

RCA blameless

retrospectiva sem culpado

Documento técnico detalhado: linha do tempo, decisões tomadas, hipóteses descartadas, ações corretivas. Compartilhado com o cliente; quando relevante, publicado no blog de engenharia.

Estruturatimeline · 5 whys · ações
Donoscada ação tem responsável e prazo
Auditoriaacompanhamento mensal das ações
07 · Indicadores operacionais

Os números que
sustentamos.

Médias agregadas da operação TecLimit nos últimos 12 meses, em projetos onde operamos a plataforma sob SLA. Base ilustrativa por fluxo crítico — cada cliente recebe seu painel real em onboarding.

Uptime médio
99.992%
↑ 0.04
Janela móvel de 90 dias · serviços de produção sob SLA
MTTD
42s
↓ 18s
Mean Time To Detect · do evento ao alerta acionado
MTTR · SEV-1
28min
↓ 6min
Mean Time To Recover · até retorno ao SLO
Erro budget
62%
≈ estável
Saldo médio do orçamento de erro mensal · 30d trailing
“Você não pode operar o que não enxerga. Observabilidade não é luxo de SRE — é o sistema nervoso da plataforma.
— Posicionamento técnico TecLimit

Sua operação merece visibilidade total.

Conte-nos sobre seus serviços críticos, SLA atual e gaps de observabilidade. Em uma conversa devolvemos um plano de instrumentação concreto.