SRE: mercado

Vaga

uma vaga aberta que passou pelo filtro de qualidade e lista pelo menos duas tecnologias

Candidato observado

um candidato cujo stack contém esta tecnologia; um agregado — nenhum registro individual sai do perímetro

Candidato compatível

ainda não contado

Janela

vagas abertas no momento em que o snapshot foi gerado

Junior SRE — raro (entrada típica: DevOps Pleno / Backend Pleno + interesse em confiabilidade). O salto Júnior → Pleno — depois da resolução do primeiro incidente de produção + a primeira configuração de SLO para um serviço. Pleno → Sênior — propriedade de SLO multisserviço + domínio de on-call (propriedade das métricas Mean Time to Detect / Recovery) + programação de automação em nível Backend Pleno/Sênior. Sênior → Staff / Principal — estratégia de confiabilidade para toda a organização + liderança da cultura de production engineering + mentoria técnica. Fluxo de carreira: DevOps Pleno (2-3 anos) → SRE Júnior / Pleno (1-2 anos) → Sênior → ou Staff / Principal SRE, Engineering Manager (SRE), um movimento para Backend Distributed Systems Sênior, ou especialização em Chaos Engineering ou Performance Engineering.

A distinção original do Google (livro Site Reliability Engineering): DevOps — uma cultura / filosofia ("quebrar os silos entre Dev e Ops"). SRE — uma implementação concreta da filosofia DevOps por meio de práticas específicas: SLI / SLO / error budgets + redução de toil + automação em primeiro lugar + 50% do tempo em engenharia vs trabalho operacional + post-mortems sem culpados. SRE = "o que acontece quando você pede a um engenheiro de software para projetar um time de operações". Realidade prática 2026: 70% de sobreposição no nível de stack (ambos usam K8s + Terraform + Prometheus + Grafana). Diferenças observáveis em empresas de produto: 1) Profundidade em programação — o SRE escreve mais ferramentas próprias em Go / Python (lógica de autoscaling, automação de deploy, algoritmos de planejamento de capacidade). O DevOps Engineer com mais frequência configura ferramentas existentes. 2) Disciplina de SLI / SLO — o SRE é dono da arquitetura de SLO (Pyrra / OpenSLO / Sloth), da aplicação da política de error budget e de alertas calibrados pelas taxas de consumo do SLO. O DevOps muitas vezes configura monitoramento sem SLO formal. 3) Domínio de plantão — o SRE participa de escala de plantão regular (24×7 para serviços críticos), é mais forte em comando de incidentes + condução de post-mortems. O DevOps Engineer geralmente fica de plantão apenas para o próprio produto. 4) Regra dos 50% de engenharia — política do Google: um SRE não deve gastar >50% do tempo em trabalho operacional, o resto é automação de engenharia. O DevOps Engineer não tem essa proteção. 5) Teoria de sistemas distribuídos — entrevistas de SRE muitas vezes incluem teorema CAP / algoritmos de consenso / modelos de consistência / análise de modos de falha. Entrevistas de DevOps — mais ferramentas práticas. Em startups essa diferenciação costuma ser difusa (uma pessoa = DevOps e SRE ao mesmo tempo).

SLI (Service Level Indicator) — uma métrica mensurável da saúde do serviço (disponibilidade / latência / taxa de erros / throughput). SLO (Service Level Objective) — um valor-alvo para um SLI (por exemplo, 99.9% de disponibilidade em 30 dias). SLA (Service Level Agreement) — um compromisso contratual com os clientes (geralmente mais fraco que o SLO, por exemplo 99.5% se o SLO é 99.9%, para manter uma margem de segurança). Error budget = 100% − SLO. Se o SLO é 99.9% em 30 dias → error budget = 0.1% = 43 minutos de indisponibilidade/mês. Quando o error budget se consome rápido → congelar deploys de novas funcionalidades, focar o time no trabalho de confiabilidade. Quando o error budget está saudável → lançar funcionalidades de forma agressiva. Montagem prática do framework (12 passos): 1) Identificar as jornadas críticas do usuário (CUJs) voltadas ao cliente. 2) Escolher SLIs para cada CUJ (normalmente disponibilidade + latência para síncrono, throughput + atualidade para assíncrono). 3) Escolher a meta inicial de SLO (regra: um pouco abaixo do desempenho atual). 4) Configurar a medição dos SLIs (Prometheus + Grafana ou gerenciado). 5) Configurar alertas por burn rate (multijanela: consumo rápido 1h a taxa de 14.4×, consumo lento 6h a taxa de 6× — fórmula do Google). 6) Configurar SLO como código (Pyrra / OpenSLO / Sloth) para controle de versão. 7) Documentar a política de error budget (o que acontece quando ele se esgota — congelamento de funcionalidades? revisão de incidentes?). 8) Revisão trimestral dos SLOs (ajuste das metas com base no desempenho real + impacto nos clientes). 9) Rastreamento de toil + roadmap de redução (meta: <50% do tempo em toil). 10) Cultura de post-mortem — sem culpados, foco em itens de ação. 11) Integração de chaos engineering (Gremlin / Chaos Mesh — testar o SLO sob falhas com antecedência). 12) Dashboard de confiança para clientes (página de status pública — Statuspage / Atlassian / Better Uptime).

Linux / sistemas a fundo: processos, namespaces, cgroups, redes (TCP/IP, DNS, balanceamento de carga), depuração de desempenho (strace / perf / eBPF). Stack de observabilidade: Prometheus + Grafana (PromQL a fundo), tracing distribuído (Tempo / Jaeger / OpenTelemetry), logs (Loki / ELK), APM gerenciado (Datadog / Grafana Cloud / Honeycomb) — o SRE "enxerga" o sistema através das métricas. Prática de SLO: SLI / SLO / error budget (veja a pergunta específica), alertas por burn rate, SLO como código. Resposta a incidentes + plantão: PagerDuty / Opsgenie, runbooks, post-mortems sem culpados, avaliação de severidade. Kubernetes: operação em produção (nível CKA) — workloads, redes, troubleshooting. IaC + automação: Terraform / OpenTofu, Ansible; a habilidade-chave do SRE é reduzir o toil (trabalho manual repetitivo) por meio de automação, com meta de <50% do tempo em toil. CI/CD: deploys seguros — canary, blue-green, progressive delivery, rollback. Programação: Python e / ou Go em nível de escrever ferramentas de automação sustentáveis, não "scripts". Sistemas distribuídos: modos de falha, retry / timeout / circuit breaker, idempotência, consistência — a base para planejamento de capacidade e DR. Chaos engineering: Gremlin / Chaos Mesh — verificar a confiabilidade antes do incidente. O ponto principal: o SRE trata a confiabilidade como produto — mede (SLO), automatiza a rotina e elimina sistematicamente as causas dos incidentes em vez de apagar incêndios manualmente. Inglês é obrigatório — a literatura de SRE (livro de SRE do Google) e a comunidade são de língua inglesa.

Sim, 41% das vagas de SRE são totalmente remotas ou híbridas. O trabalho de SRE — baseado em nuvem + dashboards de monitoramento. Empresas de outsourcing — quase sempre remotas. Empresas de produto russas — híbrido ou remoto após o período de experiência. Bancos russos — híbrido/presencial compliance de segurança. Empresas de tecnologia internacionais — totalmente remoto padrão. Ressalva específica para SRE: a rotação de on-call — exige internet confiável + backup de energia + espaço silencioso para resposta a emergências noturnas. Algumas empresas exigem uma auditoria do setup de home-office antes de uma oferta remota de SRE. Fuso horário — cargos de SRE normalmente exigem sobreposição com o fuso principal da equipe (empresas dos EUA frequentemente querem 4+ horas de sobreposição com PT/ET). Hubs de relocação: Polônia / Alemanha / Canadá / Sérvia / Geórgia. Inglês para remoto internacional de SRE — obrigatório (comando de incidentes no Zoom em inglês sob estresse).

Production Engineer (PE) — o termo do Facebook / Meta para SRE. Mesma disciplina, responsabilidades quase idênticas — foco em confiabilidade + automação + plantão + planejamento de capacidade + sistemas distribuídos. A diferença é historicamente filosófica: SRE do Google — "um engenheiro de software que por acaso faz ops", PE do Facebook — "um engenheiro integrado a um time de produto para cuidar da confiabilidade". Na prática de 2026 — quase totalmente sobrepostos. Outros títulos equivalentes: Reliability Engineer (LinkedIn), Infrastructure Engineer (frequentemente se sobrepõe a SRE), Production Operations Engineer (termo legado). Como ler as vagas 2026: procure sinais na descrição — se ela menciona "SLI/SLO", "error budgets", "redução de toil", "50% do tempo em engenharia", "post-mortems sem culpados", "escala de plantão" — é um cargo no estilo SRE, independentemente do título. Se menciona "configuração de CI/CD", "migração para a nuvem", "infraestrutura como código", mas SEM menção a SLO — é DevOps geral.

Roadmap: 1) Base de DevOps sólida — domínio de Linux + Docker + Kubernetes (CKA) + plataforma cloud a fundo + IaC (Terraform). Sem essa base não faz sentido entrar em SRE. 2) Programação nível Backend Middle — Go (padrão para SRE — Kubernetes / Prometheus / a maior parte do tooling de SRE em Go) ou Python a fundo (análise de dados + scripting). Livros: "The Go Programming Language" Donovan / Kernighan, "Fluent Python" Ramalho. 3) Livro "Site Reliability Engineering" do Google (PDF gratuito) — leitura obrigatória, leia duas vezes. 4) "The Site Reliability Workbook" do Google — complemento prático (estudos de caso + exercícios). 5) Domínio de SLI / SLO — configure SLO-as-code (Sloth / Pyrra / OpenSLO) para um serviço real, configure alertas de burn-rate (multi-window: rápido 1h 14.4×, lento 6h 6×). 6) Teoria de sistemas distribuídos — teorema CAP, modelos de consistência (linearizability / sequential / causal / eventual), consenso (noções de Paxos / Raft), análise de modos de falha. Livros: "Designing Data-Intensive Applications" Martin Kleppmann (leitura obrigatória 2026), "Database Internals" Petrov. 7) Chaos engineering — Chaos Mesh / Gremlin / LitmusChaos. Configure experimentos de chaos no seu próprio cluster K8s. Livro: "Chaos Engineering" Nora Jones / Casey Rosenthal. 8) Domínio de load testing — k6 (moderno, baseado em JS, em alta) ou Gatling (Scala DSL) ou Locust (Python). Configure load tests integrados ao CI. 9) Observabilidade a fundo: Prometheus avançado (domínio de PromQL + recording rules + federation), Grafana avançado (templating + alerting), Loki + Tempo + OpenTelemetry. Caso de uso: distributed tracing entre microsserviços. 10) Treinamento de incident response — noções de incident command, framework de post-mortems blameless, comunicação durante incidentes. Recursos: "Incident Response & Computer Forensics" Luttgens / Pepe / Mandia, treinamento de gestão de incidentes do Google. 11) Pet project: faça deploy de um app distribuído no K8s com setup completo de SLO + experimentos de chaos + simulação de on-call. Documente como um sistema production-ready. Cursos RU: Slurm SRE, Otus "SRE", Karpov.Courses SRE Track. Internacional (EN): "Database Reliability Engineering" Campbell / Majors, talks USENIX SREcon (YouTube gratuito), Google Cloud SRE Certification Path. DevOps Middle + interesse → SRE Junior — 4-10 meses (é preciso reforçar programação + teoria de sistemas distribuídos).

701 active open SRE positions — premium segment of the DevOps direction. Geography: the US, India, the UK. The real market is broader thanks to a huge international remote segment. Time to close a Senior SRE role — 6-12 weeks (longer than general DevOps due to rare-skill requirements: programming + distributed systems + on-call mastery combination).

Um SRE Sênior é dono do ciclo completo de engenharia de confiabilidade + liderança técnica. Programação em nível de Backend Pleno+: domínio de Go (padrão para automação de SRE) ou Python a fundo — no nível de "consigo escrever lógica de autoescalonamento em nível de produção / algoritmos de planejamento de capacidade / operators K8s personalizados". Domínio profundo de Kubernetes: escala de produção (nós), Operators (Kubebuilder / Operator SDK), CRDs personalizados, padrões de multitenancy. Teoria de sistemas distribuídos: compreensão profunda do teorema CAP, modelos de consistência (linearizabilidade / sequencial / causal / eventual), algoritmos de consenso (Paxos / Raft), taxonomia de modos de falha, padrões de tratamento de partições de rede. Domínio de observabilidade: Prometheus avançado (domínio de PromQL + recording rules + federação + remote_write), Grafana avançado (templating + transformations + alerting), domínio de integração Loki + Tempo + OpenTelemetry, tracing distribuído entre microsserviços. Domínio de arquitetura de SLI / SLO: SLO-as-code (Pyrra / OpenSLO / Sloth), design de política de error budget + automação de aplicação, tuning de alertas multi-window burn-rate (evitar fadiga de alertas). Domínio de comando de incidentes: liderar a resposta a incidentes sob pressão, facilitação de post-mortems sem culpados, análise de fatores contribuintes (não causa raiz — pensamento moderno), priorização de itens de ação. Domínio de chaos engineering: Chaos Mesh / Gremlin / LitmusChaos — desenhar experimentos de caos, facilitação de GameDays. Domínio de planejamento de capacidade: metodologia de testes de carga (k6 / Gatling / Locust), modelos de previsão de recursos, análise de folga, tratamento de picos de carga. Engenharia de desempenho: otimização guiada por profiling (perf / bpftrace / flamegraphs), diagnóstico de vazamentos de memória, tuning do GC, análise de desempenho de rede. Service mesh a fundo: Istio / Linkerd / Cilium — gestão de tráfego, políticas de retry, circuit breakers, injeção de falhas. System design para confiabilidade: projetar alta disponibilidade multirregião e multi-AZ no quadro branco, planejamento de RPO / RTO, estratégias de recuperação de desastres, arquitetura baseada em células para limitar o raio de impacto. Soft skills: escrita de ADRs, comunicação de incidentes (atualizações da status page + chamadas com stakeholders em crise), disciplina no rodízio de plantão, colaboração entre times (Backend / DevOps / Platform / Segurança), mentoria de SRE Pleno. Inglês para Sênior+ OBRIGATÓRIO — SRE é intensamente transversal + a comunidade fala inglês (USENIX SREcon, artigos).