DevOps
& SRE.
Plataforma interna que o time do cliente opera sem nós no meio. Pipeline com revisão por PR, deploy contínuo com canary, error budget que alguém respeita. Começa com postmortem do que está quebrando hoje, termina com runbook na wiki do cliente.
Self-service que o dev usa. Sem ticket de infra.
Plataforma interna de desenvolvedor não é Backstage instalado. É um conjunto pequeno de golden paths que cobre 80% do que o time precisa fazer toda semana — provisão de serviço, deploy, observabilidade, secret rotation — com defaults seguros e fuga prevista para os outros 20%.
- 01
Catálogo & ownership claro
Backstage ou Port com inventário vivo dos serviços. Quem mantém, em qual SLO, com qual on-call. Atualiza sozinho a partir do Git — não fica desatualizado.
- 02
Golden paths que viram template
Novo serviço HTTP, novo job batch, nova função stream. Cookiecutter + workflow + dashboards prontos. Day-zero tem CI verde, deploy em staging e métrica chegando.
- 03
Self-service guardrails
Provisão de bucket, fila, banco efêmero, ambiente de PR. Por API, com policy. Sem abrir Jira de infra para nada do dia-a-dia.
- 04
Secret & credential management
Vault, Doppler, AWS Secrets, OCI Vault. Rotação automática, audit trail, OIDC para CI/CD. Senha em variável de ambiente é cheiro de sistema antigo — a gente arruma.
- 05
Métricas DORA reais
Lead time, deploy frequency, change failure rate, MTTR. Coletadas do pipeline real, não preenchidas em planilha. Fica visível pra todo mundo.
- 06
Documentação que o dev lê
Markdown ao lado do código, exemplos copiáveis, ADR para decisões. Confluence intransitável não conta como documentação.
Deploy contínuo com canary. Rollback que dispara sozinho.
Pipeline não é "Jenkins com 28 plugins". É contrato versionado entre dev e operação: o que entra em produção, em que velocidade, com qual rede de proteção. GitOps resolve a parte fácil — declarativo, reconciliação. A parte difícil é o que fazer quando o canary degrada o p95.
CI matricial, OIDC para cloud, cache reproduzível. Workflow versionado por path.
Para cliente self-hosted. Runners dedicados, review apps por MR, deploy auto em homolog.
GitOps puro. Canary por header, por porcentagem, por região. Análise automática contra Prometheus — rollback se p95 ou error rate degradar.
Quando o cliente prefere modelo pull-only. Image automation, Helm controller, multi-tenant.
Quando o legado pede. Migração gradual para o que serve, sem big-bang descabido.
Build assinado, audit trail.
- 01
Trunk-based + branch-by-flag
Branches longos morrem em dia 5. Feature flag (Unleash, LaunchDarkly, ConfigCat) faz o resto. Deploy desacopla de release — quem libera é o produto, não o pipeline.
- 02
Canary que mede o que importa
Análise automática contra Prometheus: latency p95, error rate, saturation, métrica de negócio. Se piorou, rollback. Sem humano no loop para o caminho feliz.
- 03
Promotion entre ambientes
Mesmo artefato (mesmo SHA) percorre dev → staging → prod. Sem rebuild. Sem "funciona em homolog mas em prod não".
- 04
Supply chain assinado
Build em runner efêmero, imagem assinada com cosign, SBOM gerado, política de admission no cluster. Quem deployou, com qual SHA, em qual hora — auditável.
- 05
Database migration coordenada
Schema migration entra antes do código que depende, em backward-compatible. Nunca quebra deploy por causa de banco. Para casos difíceis, integramos com a prática de Dados.
Quando faz sentido. Quando não, a gente diz.
Kubernetes resolve um problema específico: orquestrar muitos serviços com requisitos de scheduling não-triviais. Para 4 microsserviços e um job, ECS Fargate ou Cloud Run é melhor escolha — e a gente fala isso. Quando o caso pede K8s, a gente opera com a régua dos times que sustentam isso há 8+ anos.
- 01
Managed quando dá
EKS, AKS, OKE, GKE. Self-hosted só quando regulação ou ar-gapped exige. Operar control plane não é hobby — é custo.
- 02
Multi-cluster, não multi-tenant fingido
Cluster por blast radius, não por time. Argo CD ou Rancher para gestão. Service mesh só quando o problema dele aparece.
- 03
Service mesh quando cabe
Istio, Linkerd, Cilium. Mutual TLS, policy de tráfego, observabilidade L7. Não instala porque é tendência — instala se mTLS é requisito ou tráfego inter-serviço justifica.
- 04
Autoscaling honesto
HPA por métrica de negócio (RPS, queue depth) — não só CPU. KEDA para event-driven. Cluster autoscaler com node pools por classe.
- 05
Resource governance
Requests/limits que correspondem ao que o serviço usa. PriorityClass, PDB, QoS. OOMKill às 3h tem causa raiz, não fica como ruído.
- 06
Upgrade sem terror
Versão N-1 sempre. Plano de upgrade testado em cluster de staging. Operadores com compatibilidade verificada antes de mexer.
SLI ligado ao negócio. Error budget que alguém respeita.
Observabilidade não é "Datadog instalado". É o engenheiro de plantão abrir uma página e responder em 90 segundos: está quebrado? para quem? desde quando? o que mudou? Para isso, a stack tem que ser opinionada — não 14 ferramentas concorrentes lidas em série.
Coleta pull, label-based, recording rules para o que repete. Federation por região quando precisa.
Indexa label, não corpo. Custo de retenção compatível com long tail. LogQL alinhado com PromQL.
Sampling inteligente, exemplars do Prometheus pulam direto pra trace relevante. OTLP nativo.
13 meses de métrica em S3 por custo de hot-set. Multi-tenant para holdings com várias unidades.
Dashboard versionado em git, alerta com runbook embutido, anotação de deploy. Single pane de verdade.
- O·01
SLI com critério
Disponibilidade medida no que o usuário sente — não em ping. Login funciona, checkout completa, relatório carrega abaixo de 4s. SLI sintético + RUM para o que importa.
- O·02
SLO acordado com produto
99,9% de checkout em janela de 30 dias é mais útil que 99,99% de "tudo". O número sai de uma conversa entre eng e produto — não cai do céu.
- O·03
Error budget como freio
Queimou o budget? Deploy congela, prioridade vira confiabilidade. Acordado em contrato, não negociado a quente. Funciona porque tem trava.
- O·04
Stack opinionada
Prometheus + Grafana + Loki + Tempo, ou Datadog, ou New Relic. Uma escolha por cliente, integrada. OpenTelemetry como protocolo — sem lock-in de SDK.
- O·05
Alerta com contexto
Disparo carrega: dashboard relevante, runbook do incidente parecido anterior, último deploy, owner. Não chega "CPU alta" — chega "checkout p95 acima de 2s desde 03:14, último deploy às 02:51, runbook anexo".
- O·06
Chaos & load engineering
Game day trimestral. k6/Gatling para carga, LitmusChaos/AWS FIS para falha. Hipótese antes do experimento. Resultado vira backlog.
Tudo que existe foi declarado. Tudo que muda passa por PR.
Infrastructure as code não é sobre a ferramenta — é sobre o hábito. Mudança de produção entra por pull request, com plan visível, revisão por alguém que entende, e aplicação em janela. Console é para diagnóstico, não para mudança.
Terraform · OpenTofu
Padrão para infra de cloud. Módulos versionados, remote state com lock, plan em CI revisado por humano. Workspaces por ambiente.
Pulumi
Para times que já vivem em TypeScript ou Python e ganham reaproveitando código de domínio. Mesmo provider model do Terraform por baixo.
Crossplane
Plataforma interna que entrega Composite Resources ao dev. Pede um banco PostgreSQL com 3 linhas de YAML; recebe RDS provisionado, secret rotacionado, dashboard publicado.
Ansible
Configuração de host quando ainda existe host. Bare-metal, on-prem, fleet de VM. Idempotente, audit trail, rotinas reutilizáveis.
Argo Workflows · Temporal
Orquestração de pipelines longos: ETL diário, rotinas DBA, jobs de migração. Retry, backoff, observabilidade. Cron + bash não é orquestração.
Policy as code
OPA/Gatekeeper, Conftest, Checkov. Política versionada, testada em CI, aplicada em admission. Compliance que vive no repo, não em PDF.
- 01
State seguro & auditável
Remote state com lock, criptografia at-rest, audit log de quem aplicou o quê. Drift detection rodando diário.
- 02
Módulos versionados
Registry interno, semver, changelog. Dev consome v1.4.2, não main. Refatoração não quebra ambiente.
- 03
Plan obrigatório no PR
Bot posta o diff de infra no comentário. Reviewer vê o que vai mudar antes de aprovar. Apply só em main, com janela.
- 04
Reaplicável em qualquer região
Mesmo código provisiona na us-east-1 e na sa-east-1. Sem hard-code, sem dado regional disperso. DR vira exercício real, não plano em PDF.
Conta de cloud previsível. Sem reserva no escuro.
FinOps não é planilha de fim de mês com gráfico vermelho. É hábito diário com três frentes: visibilidade (cada dólar com dono e produto), otimização (rightsizing, savings plan, descomissionamento) e governança (orçamento por equipe, alerta antes de estourar). A meta é o time de produto tomar decisão técnica sabendo o custo dela — em PR, não em retrospectiva trimestral.
- 01
Visibilidade granular & tagging
Tag policy aplicada por OPA antes de provisionar. Custo por equipe, por produto, por ambiente. Showback mensal automático — cada gestor recebe o que sua área consumiu, sem pedir.
- 02
Custo de Kubernetes resolvido
OpenCost ou KubeCost agregando uso real por namespace e label. Workload compartilhado é rateado por CPU·hora e GB-mês — não dividido na unha em planilha.
- 03
Rightsizing contínuo
Recomendação semanal por workload: instância superdimensionada, volume gp2 que vira gp3, RDS com IOPS provisionado ocioso. Implementação por PR, com aprovação do dono.
- 04
Savings Plans & Reservations
Cobertura calculada com base na linha de base real, não em estimativa do vendor. Compromisso parcial (60–70% da base), spot/preemptive para picos. Recompra automatizada.
- 05
Orçamento & alerta proativo
Budget por equipe com alerta em 50/75/90/100%. Anomaly detection (Cost Explorer, Cloud Billing, OCI Cost Analysis) avisa antes do humano notar.
- 06
Custo no PR
Infracost no pipeline. Mudança de Terraform mostra +US$ 412/mês no comentário antes do merge. Decisão arquitetural sai informada — não em ticket de surpresa.
- 07
Descomissionamento ativo
Snapshot órfão, EBS desanexado, IP elástico parado, ambiente de staging esquecido. Auditoria mensal corta gordura — em média 11–18% da fatura nos primeiros 3 meses.
Engenheiro com nome. Não número de chamado.
Plantão de SRE em formato de catraca de nível 1 com upsell não funciona — só vira ponte até alguém sênior ser acordado. Aqui o sênior está acordado desde o primeiro alerta, com contexto, com histórico e com autonomia para corrigir. Não só escalar.
- P·01
SLA formal por severidade
Sev1 — primeiro toque em 5 min, mitigação em 30 min. Sev2 — toque em 15 min. Definido em contrato, com multa se descumprirmos.
- P·02
On-call rotation transparente
Você sabe o nome de quem está no plantão da semana. Calendário compartilhado. Se prefere alguém específico, a gente combina.
- P·03
Runbook na wiki do cliente
Não na nossa. Atualizado a cada incidente. Alguém além de nós consegue ler, executar e — se quiser — sair sem dependência.
- P·04
Postmortem em 5 dias úteis
Sev1 e Sev2 obrigatório. Escrito por quem estava no incidente. Blameless, com ação de engenharia, owner e prazo. Vira backlog priorizado.
- P·05
Game day trimestral
Failover ensaiado, perda de dependência simulada, AZ derrubada em ambiente espelho. DR que ninguém testou não existe.
- P·06
Sem lock-in
Contrato anual, mas saída em 30 dias com handover. Recontrata se for melhor que as alternativas — não por inércia.
Hype não vai pra produção.
- NÃO
Kubernetes para 3 microsserviços
ECS Fargate, Cloud Run, Container Apps resolvem com menos custo cognitivo. K8s entra quando o problema dele aparece — não antes.
- NÃO
Service mesh "porque é boas práticas"
Mesh resolve mTLS forçado, policy de tráfego e observabilidade L7. Se nenhum dos três é requisito, é overhead disfarçado.
- NÃO
Migração big-bang de Jenkins
Strangler fig. Pipeline crítico fica até o último, novos times nascem na stack nova, descomissionamento gradual. Big-bang é receita de incidente.
- NÃO
SRE como rebranding de NOC
Plantão sem error budget, sem SLO, sem postmortem é catraca. Se é isso que precisa, um terceirão resolve por metade do preço.
Pipeline lento, deploy assustador, ou plantão sem nome? Conta o problema.
45 min com um SRE sênior. Sem pitch.