SRE · on-call ativo

Diogo Alves

> Site Reliability Engineer

Mais de 4 anos em DevOps e SRE. Construo e opero plataforma na AWS com Kubernetes, Terraform e GitOps, defino SLOs, automatizo o trabalho repetitivo e conduzo upgrades e migrações com planejamento e rollback.

diogo@sre: ~

$ whoami
diogo-alves · site reliability engineer

$ cat stack.yaml
cloud:           aws
orquestração:    kubernetes (eks) · karpenter
iac:             terraform + atlantis
gitops:          argo cd
observabilidade: elastic · opentelemetry
confiabilidade:  sli/slo · error budget

$ on-call --status
● escala ativa

$ 
4+anos em DevOps e SREcom escala de on-call
5ciclos de certificação PCI DSSponto focal técnico desde 2022
IaCmódulos Terraform criados e diversos PRs de infraestruturaterraform + atlantis, plan revisado antes do apply
294páginas de documentação técnica escritasrunbooks, decisões e guias para o time

01 · sobre

Plataforma estável, mudanças sem susto

Sou Site Reliability Engineer e trabalho com infraestrutura AWS e clusters Kubernetes: coloco ambientes no ar com Terraform, entrego aplicações via GitOps com Argo CD e faço parte de escala de on-call.

Gosto de confiabilidade medida: SLIs e SLOs com error budget e alertas por burn rate, observabilidade versionada como código e mudanças com plano de rollback. Automatizo o que é repetitivo, de Python em Lambda a agentes de IA com Claude Code, e respondo pela parte técnica da certificação PCI DSS.

02 · como eu trabalho

O que eu levo para qualquer time

--dry-run

Planejo antes de mexer

Toda mudança começa por quem é o dono, qual a janela e como voltar atrás. Prefiro checklist e validação a improviso.

--docs

Documento e compartilho

Escrevo pensando em quem vem depois: runbooks, decisões e aprendizados ficam registrados para o time inteiro usar.

--ownership

Assumo os erros

Quando algo dá errado, inclusive por erro meu, conto o que houve com transparência e ajusto o processo para não se repetir.

--listen

Escuto antes de propor

Começo entendendo a dor de quem usa a plataforma. A ferramenta certa vem depois, e muitas vezes é a mais simples.

--onboarding

Recebo bem quem chega

Gosto de passar conhecimento, acompanhar pessoas novas no time e estar por perto para ajudar no dia a dia.

--curious

Movido a desafio

Gosto de ser desafiado. Problema que eu nunca vi é um convite: estudo, testo em laboratório e aprendo no caminho. Quando falta uma ferramenta, escrevo uma.

03 · o que é SRE

Engenharia aplicada à operação

Site Reliability Engineering nasceu no Google, no começo dos anos 2000, com uma ideia simples: tratar a operação de sistemas como um problema de engenharia de software. Em vez de apagar incêndios manualmente, o SRE escreve código, automatiza e mede para que os sistemas fiquem confiáveis enquanto o produto continua evoluindo.

A pergunta central não é "o sistema pode cair?", e sim "quanto de falha é aceitável para o usuário?". Essa resposta vira um número, o SLO, e esse número guia as decisões: quando acelerar entregas e quando parar para investir em estabilidade.

01

SLIs, SLOs e error budget

Medir o que o usuário sente, como latência e taxa de erro, definir uma meta e usar a margem de erro como orçamento para mudanças.

02

Eliminar trabalho repetitivo

Tarefa manual que se repete vira automação. O tempo ganho vai para melhorias que fazem o sistema escalar sem escalar o time.

03

Observabilidade

Logs, métricas e traces para responder rápido "o que está acontecendo e por quê", com alertas que só tocam quando há impacto real.

04

Resposta a incidentes

On-call, mitigação primeiro e investigação depois, até a causa raiz. Cada incidente vira aprendizado e ação para não se repetir.

05

Mudanças seguras

Infraestrutura como código, revisão por pull request, entrega gradual e plano de rollback, porque a maior parte das falhas nasce de mudanças.

06

Capacidade e custo

Prever crescimento, dimensionar recursos e cuidar do custo da nuvem, para o sistema aguentar picos sem desperdício no resto do tempo.

tail -f dia-de-sre.log

  1. INFOrevisa dashboards, alertas da noite e consumo do error budget
  2. INFOrevisa um pull request de Terraform antes de aplicar na nuvem
  3. WARNlatência subindo em um serviço: investiga com logs, métricas e traces
  4. INFOtransforma uma tarefa manual recorrente em automação
  5. INFOapoia um time de desenvolvimento a colocar um serviço novo no ar
  6. OKexecuta uma mudança em produção com janela, validação e rollback pronto
  7. PAGEon-call acionado: mitiga primeiro, investiga a causa raiz depois

04 · o que eu sei

Onde eu entrego valor

Kubernetes e plataforma

Opero clusters EKS: upgrades de versão, autoscaling de nós com Karpenter, Helm, Ingress com AWS Load Balancer Controller e Network Policy.

na prática: upgrades de versão do EKS com imagem de servidor própria já com hardening

EKSKarpenterHelmKustomizeDocker

Infraestrutura como código e GitOps

Coloco ambientes no ar do zero com Terraform, revisão por PR no Atlantis e entrega contínua de clusters e aplicações com Argo CD.

na prática: conta, VPC, EKS e Vault de um ambiente isolado inteiro em Terraform

TerraformAtlantisTerragruntArgo CDCI/CD

Observabilidade

Logs, métricas e traces de ponta a ponta: pipelines de ingestão no Elasticsearch, Logstash, tiers de retenção, APM, OpenTelemetry e dashboards e alertas versionados como código.

na prática: migração de logs do CloudWatch para o Elastic, com retenção em camadas

Elastic StackOpenTelemetryZabbixCloudWatchGrafana (lab)

Confiabilidade

SLIs e SLOs com error budget e alertas por burn rate, resposta a incidentes com investigação até a causa raiz, on-call e mudanças com plano de rollback.

na prática: SLOs com error budget para fluxos críticos de negócio

SLI/SLOError budgetBurn rateRCAOn-call

Segurança e compliance

Hardening (reforço de segurança) de sistemas operacionais e clusters, gestão de vulnerabilidades multi-conta, segmentação de rede e a parte técnica de auditorias PCI DSS v4.0.1.

na prática: ponto focal técnico de certificação PCI DSS desde 2022

PCI DSSSecurity HubInspectorAWS WAFVault

Automação e IA

Automatizo o trabalho repetitivo com Python e Bash, de funções Lambda a pipelines, e uso agentes de IA com validação humana na operação.

na prática: runbooks transformados em skills do Claude Code

PythonBashAWS LambdaClaude CodeMCP

edu: Técnico em Redes de Computadores · Escola Dr. Solon Tavares (2017 a 2018) | lang: português nativo · inglês e espanhol básicos

05 · stack

Tecnologias com que já trabalhei

$ ls ~/stack | wc -l 0

aws/ Nuvem

EKSEC2Auto ScalingIAMOrganizationsVPCTransit GatewayRDSAuroraLambdaECRSSMAmazon MQCloudWatchPrivateLink

k8s/ Containers e orquestração

KubernetesKarpenterHelmKustomizeDockerAWS Load Balancer ControllerNetwork Policy

iac/ IaC, GitOps e CI/CD

TerraformAtlantisTerragruntArgo CDFluxBitbucket PipelinesGitLab CIGit

obs/ Observabilidade

ElasticsearchLogstashKibanaElastic APMOpenTelemetryZabbixGrafanaLokiTempoMimirClickHouseClickStack

sec/ Segurança

PCI DSS v4.0.1Security HubInspectorGuardDutyAWS WAFCloudflareHashiCorp VaultCIS Hardening

data/ Bancos e mensageria

MySQLPostgreSQLRedisRabbitMQKafka

code/ Linguagens e sistemas

PythonBashLinux

ai/ IA aplicada

Claude CodeSkillsAgentesMCP

usado em laboratório, ainda não em produção

06 · trajetória

Trajetória

Appmax · Porto Alegre, RS · desde 2021

  1. Site Reliability Engineer IV

    • Conduzi, como ponto focal técnico, a certificação PCI DSS v4.0.1 de 2026, com análise de GAP de cerca de 30 requisitos e alteração de escopo de um novo fluxo de cartão.
    • Criei a detecção de números de cartão (PAN) em logs com validação Luhn no Elasticsearch, em menos de 0,2 ms por documento.
    • Escrevi em Python (AWS Lambda) um gerenciador de vulnerabilidades multi-conta que apoiou a redução de vulnerabilidades no escopo PCI.
    • Empacotei os runbooks do time em skills do Claude Code e uso agentes de IA com validação humana na resposta a incidentes.
    • Contribuí com a frente de FinOps do time e atualizei o Zabbix de 6.2 para 8.0, trocando sistema operacional, banco e PHP.

    PCI DSSElasticsearchPythonClaude CodeFinOps

  2. Site Reliability Engineer III

    • Defini SLIs e SLOs com error budget e burn rate para os 3 fluxos críticos do banco digital, com dashboards e alertas versionados em Terraform.
    • Liderei a migração dos logs do monólito do CloudWatch para o Elastic, com retenção estipulada pelas normas do PCI DSS.
    • Atualizei o cluster PCI de cartão (EKS 1.28 → 1.30) com imagem de servidor (AMI) própria, já com hardening, e cortei cerca de 58% do custo de EC2.
    • Atualizei cerca de 20 bancos RDS para MySQL 8.0.41 e o Amazon MQ de 3.9 para 3.13, com teste de rollback antes de produção.
    • Criei o template de GMUD V2 com plano de rollback; a gestão de mudança passou a ser obrigatória no time.

    SLI/SLOEKSRDSTerraformElastic

  3. DevOps Engineer II

    • Construí o ambiente isolado do gateway de cartão (CDE PCI) em Terraform, com EKS, HashiCorp Vault e Network Policy; passou em todas as auditorias seguintes.
    • Reduzi o build do pipeline de CI/CD do monólito de 4m30s para 1m30s.

    VaultCI/CDDocker

  4. DevOps Engineer

    • Apliquei hardening, o reforço das configurações de segurança do sistema operacional, em 100% dos servidores e Auto Scaling Groups do escopo PCI.
  5. Analista de Implantação

    • Levantei as dores dos times e implementei soluções open source para resolvê-las.
  6. Analista de Suporte

    • Migrei e-mail e domínio para o Google Workspace e implantei o FreePBX.

07 · contato

Vamos conversar?

Para trocar ideia sobre SRE, Kubernetes, observabilidade ou automação.