Agende uma conversaAgende uma conversaConte seu casoContato
Agende uma conversa

O que faz, exatamente, um engenheiro de confiabilidade (SRE)?

Um engenheiro de confiabilidade (SRE, site reliability engineer) mantém os serviços em produção confiáveis usando engenharia de software: instrumenta os sistemas para os problemas ficarem visíveis, escreve alertas que disparam em falhas reais, encontra a causa de incidentes recorrentes e a corrige em código ou configuração, planeja capacidade e ensaia a recuperação. Na Clouditive, cada correção é verificada no sistema em execução antes de darmos o trabalho por concluído.

Um alerta que nunca disparou é uma suposição. Uma falha que volta todo dia vira normal, até custar uma release ou um relatório.

Fundamentos de SRE e observabilidade custa US$ 5.000 por 2 semanas: métricas, logs e traces conectados, 3 SLOs definidos, alertas testados até disparar e um runbook.

O que você recebe, passo a passo

Tudo o que o pacote inclui, na ordem em que chega. O preço e a duração não mudam.

  1. Passo 1: Os sinais

    Métricas, logs e traces conectados.

  2. Passo 2: Os SLOs

    3 SLOs definidos.

  3. Passo 3: Alertas e runbook

    Alertas testados até disparar, e um runbook.

  4. 2 semanas

    US$ 5.000

Quer continuar depois do pacote? Some engenheiros por hora com as tarifas publicadas, com prazo mínimo de 6 meses. Como funciona o staff augmentation.

Comprovado em trabalho real

Clientes reais, números com data e uma nota clara sobre o que não foi feito.

A Clouditive construiu nosso jogo do zero junto conosco: o cliente em Unity 6, o servidor autoritativo em Java 25, o launcher e um livro-razão de valor que aguentou 40 vendas em paralelo. 39 smoke tests de ponta a ponta jogam com clientes Unity reais depois de reiniciar os dois servidores.

CTO

Observabilidade e SRE para uma plataforma SaaS fintech

Análise de investimentos / Fintech

Status: Plataforma em produção, trabalho em andamento

  1. desenvolvimento
  2. 1 hora de teste
  3. controles
  4. produção
  • ~3xmais releases em produção por semana
  • 23% → 4%de falhas em releases de produção
  • 0 → 275regras de alerta em produção
  • 72 sde rollback, ensaiado em desenvolvimento

Desenhado a partir do caso. O produto é um sistema do cliente e não é exibido.

Ver o caso

Para a plataforma SaaS de análise de portfólios da MPI, na AWS EKS, nosso trabalho inclui:

  • Uma stack de observabilidade com VictoriaMetrics, Loki, Tempo, Pyroscope e Grafana, com alertas testados até disparar.
  • O armazenamento de logs deixou de ser recriado cerca de três vezes por dia pela consolidação de nós.
  • O scale down deixou de interromper de uma vez a maioria dos relatórios em execução, e os relatórios longos terminam sem problema quando a capacidade diminui.
  • Uma falha de falta de memória em relatórios grandes, diagnosticada e corrigida.
  • Auditorias de custo do cluster e da nuvem.

Prefere pagar por hora?

Some engenheiros à sua própria equipe com as tarifas publicadas, em vez de comprar um pacote.

  • Você entrevistaVocê conhece o engenheiro que fará o trabalho.
  • Mínimo de 6 mesesCobrança por hora trabalhada.
  • Reposição sem custoSe ele sair ou não se encaixar, fazemos a reposição e cobrimos a transição sem custo.
Ver como funciona o staff augmentation
  • Líder / ArquitetoUS$55–⁠60por hora
  • SêniorUS$45–⁠50por hora
  • PlenoUS$35–⁠40por hora
  • JúniorUS$30por hora

US$ por hora, desenhado em uma única escala

Para continuar lendo

Perguntas frequentes

Para que serve a observabilidade?

Ela responde por que um sistema se comporta como se comporta a partir dos sinais que ele emite (métricas, logs, traces e perfis), sem publicar código novo para descobrir.

Observabilidade faz parte do DevOps?

Sim. Não dá para ser dono de como o software roda sem vê-lo rodar. No nosso trabalho, ela fica com o SRE: instrumentação, alertas e as correções que vêm depois.

Quais são as 3 principais ferramentas de observabilidade?

Não fazemos ranking de fornecedores. O que já operamos em produção: VictoriaMetrics, Loki, Tempo, Pyroscope e Grafana na MPI, e OpenTelemetry para o Google Cloud na Autonomah.

O que significa um alerta testado até disparar?

Provocamos a condição de falha de propósito e verificamos que o alerta chega. Um alerta que nunca disparou é uma suposição, não um controle.

Quanto custa Fundamentos de SRE e observabilidade?

US$ 5.000 por 2 semanas, preço fixo: métricas, logs e traces conectados, 3 SLOs definidos, alertas testados até disparar e um runbook.

O SRE ainda está em alta?

Vendemos SRE porque os sistemas em produção continuam precisando dele: na MPI, o trabalho cobriu alertas, autoscaling, armazenamento de logs, falhas de falta de memória e custo.

Quanto custa um SRE por hora?

Nossas tarifas publicadas: US$ 55–⁠60 para Líder ou Arquiteto, 45–⁠50 Sênior, 35–⁠40 Pleno e 30 Júnior, com mínimo de 6 meses em staff augmentation (alocação de profissionais).

O que Fundamentos de SRE e observabilidade muda para o negócio

Cada entregável, nos termos que um CEO ou um conselho perguntam:

  • Métricas, logs e traces conectados: quando o produto fica lento ou falha, seu time vê onde e por quê, em vez de adivinhar.
  • 3 SLOs definidos: três metas escritas de quão confiável o produto precisa ser, para que "o app cai demais" vire um número que você acompanha.
  • Alertas testados até disparar: seu time fica sabendo de uma falha por um alerta, não por um cliente, e cada alerta foi disparado de propósito para mostrar que chega.
  • Um runbook: os primeiros passos escritos para cada alerta, para que quem estiver de plantão aja sem depender de quem construiu o sistema.
  • Na MPI, relatórios grandes que estouravam a memória foram diagnosticados e corrigidos, e o scale down deixou de interromper de uma vez a maioria dos relatórios em execução.

Quais são os quatro pilares da observabilidade?

A observabilidade costuma ser descrita por métricas, logs e traces, com profiling contínuo muitas vezes somado como quarto sinal. As métricas mostram que algo mudou, os logs mostram o que aconteceu, os traces mostram onde uma requisição gastou seu tempo e os perfis mostram qual código usou CPU ou memória. Na MPI, cada sinal tem seu próprio armazenamento (VictoriaMetrics, Loki, Tempo, Pyroscope), lidos juntos no Grafana.

Na Autonomah, a telemetria vai por OpenTelemetry para o Google Cloud, com um registro de custo por chamada e cada deploy em produção verificado para rodar o build exato que foi testado.

Na Nyravorn, um jogo online, ensaiamos backup e restore, e scripts de smoke test verificam que os dados dos jogadores sobrevivem a um reinício do servidor.

SRE é só DevOps?

Não. DevOps é uma forma de trabalhar que une construir e operar software; SRE é uma disciplina de engenharia específica dentro dessa ideia, focada em quão confiável é a produção. O engenheiro DevOps costuma ser dono do caminho até a produção: pipelines e infraestrutura como código. O SRE cuida do que acontece depois: sinais, alertas, incidentes, capacidade e recuperação. Na MPI fazemos as duas coisas para a mesma plataforma.

A IA vai substituir o SRE? No nosso trabalho, o engenheiro dirige e as ferramentas de IA assistem: nosso líder de plataforma na MPI trabalha assim. Os alertas continuam sendo testados até disparar e as correções continuam sendo verificadas no sistema em execução.

Uma alternativa open source ao Datadog

O OpenTelemetry coleta métricas, logs e traces uma única vez, e armazenamentos open source como Mimir, Loki e Tempo, lidos no Grafana, os guardam sem licença comercial por host. Em uma empresa norte-americana de serviços de transporte, tirar métricas e logs de um APM comercial reduziu o gasto com observabilidade em cerca de US$ 5.000 por mês, e os dashboards passaram de 18 para 135. O trabalho passa a ser configuração e manutenção, em vez de assinatura.

O que você precisa resolver?

Respondemos a todo pedido em até 1 dia útil. Assinamos um NDA antes da conversa, se você pedir.

Conte seu casoConversa de 30 min