Engenheiro(a) de Confiabilidade (SRE)

SLIs, SLOs & SLAs

Por quê: Você define um SLO realista a partir de dados reais de usuários e o acorda com o dono do produto, e a meta reflete o que o usuário tolera, não um número arbitrário de noves.

Error Budgets

Por quê: Você acompanha o consumo do budget e aplica a política, e quando o orçamento acaba o time pausa releases arriscadas em vez de discutir se deve continuar.

Metrics Collection

Por quê: Você controla cardinalidade e nomenclatura entre serviços, e uma consulta de dashboard continua rápida e um alerta merece confiança durante um incidente real.

Logging & Aggregation

Por quê: Você gera métricas a partir de logs e define retenção pensando em conformidade, e consegue alertar sobre um padrão de erro mantendo sob controle o custo e os limites legais.

Incident Response

Por quê: Você classifica a severidade, atribui papéis e mitiga antes de diagnosticar por completo, e uma queda visível ao cliente é contida em minutos em vez de debatida por dez pessoas.

Incident Communication

Por quê: Você atualiza a status page e as partes interessadas com impacto claro e horário da próxima atualização, e clientes e executivos ficam informados sem interromper quem está resolvendo.

Capacity Planning

Por quê: Você projeta a demanda e encontra o gargalo antes de um lançamento, e pede folga de capacidade antes de um pico de tráfego em vez de escalar durante ele.

Load Testing & Performance

Por quê: Você executa testes de carga e de longa duração com uma ferramenta como o k6 e interpreta os resultados, e um vazamento de memória ou uma query lenta aparece no teste e não no dia da release.

Infrastructure as Code

Por quê: Você descreve a infraestrutura em código com state versionado, e um ambiente pode ser reconstruído após uma falha e as mudanças são revisadas como código de aplicação.

CI/CD Pipelines

Por quê: Você usa rollout canary ou blue-green com rollback testado, e uma release ruim é revertida automaticamente antes de afetar a maioria dos usuários.