🚀 DevOps e Operações

CI: cada commit é buildado e testado automaticamente. CD: código que passa nos testes vai para produção automaticamente (ou com um clique).

Sem CI/CD, deploy é manual, arriscado e infrequente. Ex: O Amazon deploya a cada 11.7 segundos. O Etsy faz 50+ deploys/dia. Só é possível porque cada deploy é testado, automatizado e reversível.

Plataforma de CI/CD do GitHub: workflows definidos em YAML, triggers por push/PR/schedule, runners Linux/macOS/Windows, marketplace de actions.

Integrado ao GitHub onde o código já vive. Free para repos públicos, generoso para privados. Ex: Workflow: push → lint (ESLint) → test (Jest) → build → deploy (Vercel). 5 minutos para configurar, roda para sempre.

Containers que empacotam aplicação + dependências em uma imagem reproduzível. Mesmo ambiente em dev, CI e produção.

"Funciona na minha máquina" mata produtividade. Ex: Sem Docker: "instala Python 3.11, pip install requirements.txt, configura PostgreSQL 15, Redis 7...". Com Docker: `docker compose up`. Pronto em 30 segundos, idêntico para todos.

Estratégias para atualizar produção sem interrupção: blue-green (dois ambientes), canary (percentual gradual), rolling (instância por instância).

Deploy sem estratégia = downtime. Ex: O Netflix usa canary deployment para cada mudança — 1% dos servidores recebem a nova versão. Se error rate sobe, auto-rollback em <2 minutos. Os outros 99% nunca são afetados.

Ambientes isolados para cada fase: dev (local), staging (réplica de prod), production (real). Cada um com sua config, dados e infra.

Testar em produção é negligência. Testar sem staging é risco. Ex: O Knight Capital perdeu US$440M em 45 minutos porque deployaram código de teste em produção sem staging. O código de teste comprou ações aleatoriamente. Irreversível.

Capacidade de reverter rapidamente para a versão anterior. Pode ser: redeploy da versão antiga, feature flag off, ou database rollback.

Se deploy sempre dá certo, você não precisa de rollback. Na realidade, 10-15% dos deploys têm problemas. Ex: O GitLab tem rollback automático: se health checks falham após deploy, reverte para a versão anterior em <1 minuto. Sem intervenção humana.

4 métricas DORA: deployment frequency, lead time for changes, change failure rate, mean time to recovery. Medem a saúde do processo de entrega.

Medir é o primeiro passo para melhorar. Ex: Times "elite" (Google, Amazon, Netflix): deploy múltiplas vezes/dia, lead time <1h, failure rate <15%, MTTR <1h. Times "low performers": deploy mensal, lead time >6 meses, failure rate >46%, MTTR >1 semana.

Definir infraestrutura em arquivos de código (Terraform, Pulumi, CloudFormation). Versionado no git, revisável em PR, reproduzível.

Infra clicada no console é irreproducivel e indocumentada. Ex: "Quem criou este security group? Com que regras? Por quê?" — com IaC, a resposta está no git blame. Sem IaC, ninguém sabe.

Ferramenta HashiCorp que provisiona infra em qualquer cloud (AWS, GCP, Azure, Cloudflare) com linguagem declarativa (HCL).

Multi-cloud e extensível. Maior ecossistema de providers. Ex: 20 linhas de Terraform criam: VPC + subnet + security group + EC2 + RDS PostgreSQL + load balancer. Reproduzível em qualquer conta AWS.

docker-compose.yml define todos os serviços do projeto: app, banco, cache, queue. `docker compose up` inicia tudo.

Elimina "works on my machine" para sempre. Ex: docker-compose.yml: PostgreSQL 15 + Redis 7 + n8n + app Node.js. Novo dev: clone repo → `docker compose up` → trabalhando em 2 minutos. Sem instalar nada.

Orquestrador de containers para escala. Gerencia deploys, scaling, self-healing, service discovery. É complexo — só use quando realmente precisa.

Kubernetes é poderoso mas tem overhead enorme. Ex: Uma startup com 3 devs rodando K8s gasta 40% do tempo em infra. A mesma startup com Vercel + Supabase gasta 5%. K8s faz sentido com 50+ serviços e time de platform engineering dedicado.

Gerenciamento seguro de API keys, senhas, tokens: environment variables, vaults (HashiCorp Vault, AWS Secrets Manager), .env (nunca commitado).

Credencial no código é brecha garantida. Ex: Em 2023, bots no GitHub escaneiam commits em <1 segundo procurando API keys expostas. AWS keys expostas geram instâncias de crypto mining em minutos — conta de US$50k overnight.

Content Delivery Network distribui conteúdo estático em servers globais. Edge computing processa lógica perto do usuário.

CDN reduz latência drasticamente — serve de um datacenter a 50ms de distância em vez de 500ms. Ex: Cloudflare tem 300+ PoPs globais. Seu HTML estático é servido do PoP mais próximo do usuário. São Paulo? Serve de São Paulo. Lisboa? Serve de Lisboa.

Monitoramento e otimização de custos de cloud: right-sizing, reserved instances, spot instances, auto-scaling, tag-based cost allocation.

Cloud sem controle gasta 30-40% mais que necessário (Flexera). Ex: AWS Cost Explorer mostra: 60% do custo é em EC2 instances oversized (t3.xlarge rodando app que cabe em t3.small). Right-sizing economiza 50% instantaneamente.

Logs em formato JSON com campos padronizados: timestamp, level, service, trace_id, message. Pesquisáveis e filtráveis.

`console.log("deu erro")` não ajuda em produção. Ex: Log estruturado: `{"timestamp": "2024-01-15T10:30:00Z", "level": "error", "service": "payments", "trace_id": "abc123", "error": "timeout", "duration_ms": 5000}`. Filtrável, correlacionável, alertável.

Dados numéricos ao longo do tempo: request rate, error rate, latency, CPU, memory, queue depth. Prometheus + Grafana é o stack mais popular.

Métricas mostram tendências que logs não mostram. Ex: Latência P99 subindo gradualmente de 100ms para 500ms ao longo de 2 semanas — logs não mostram isso, métricas sim. Detecta problema antes de virar incidente.

Rastreia uma request do início ao fim em sistema distribuído. Cada serviço adiciona um span ao trace. Mostra onde o tempo é gasto.

Em microsserviços, "a request está lenta" não diz nada. Tracing mostra exatamente qual serviço é o gargalo. Ex: O Jaeger mostra: user-service (5ms) → order-service (10ms) → payment-service (2000ms) → notification (5ms). O bottleneck é payments. Sem tracing, levaria horas para descobrir.

Regras que disparam notificações quando métricas ultrapassam thresholds: error rate > 5%, latency P99 > 1s, CPU > 80%.

Sem alertas, você descobre problemas pelo Twitter. Ex: PagerDuty + Grafana: alert rota para o oncall via SMS/call. Escala automaticamente se não for atendido em 5 minutos. Time médio para saber de um problema: <2 minutos.

Painéis visuais com métricas-chave do sistema. Dashboards por serviço, por endpoint, por infra.

Dashboard bom = troubleshooting em minutos. Dashboard ruim = 50 gráficos que ninguém olha. Ex: O "golden signals" dashboard: request rate, error rate, latency, saturation. 4 gráficos que dizem 90% do que precisa saber. Menos é mais.

Endpoints que reportam saúde: /health (live?), /ready (aceitando requests?). Usados por load balancers e orchestrators para routing e restart.

Sem health check, load balancer envia tráfego para instância morta. Ex: Kubernetes liveness probe: se /health retorna 503 3x seguidas, mata o pod e cria novo. Readiness probe: se /ready retorna 503, remove do service (para de receber tráfego).

SLI (indicator): métrica real (latência P99 = 150ms). SLO (objective): meta interna (P99 < 200ms). SLA (agreement): compromisso com cliente (99.9% uptime).

Sem SLOs, "o sistema está lento" é subjetivo. Com SLOs, é mensurável. Ex: O Google define SLOs para cada serviço interno. Se error budget está sendo consumido rápido, congelam features e focam em confiabilidade. SLOs guiam priorização.

Lista atualizada dos 10 riscos mais críticos em aplicações web: injection, broken auth, sensitive data exposure, XSS, etc.

Conhecer os 10 previne a maioria dos ataques. Ex: SQL Injection ainda é o #3 em 2024. Um simples `SELECT * FROM users WHERE id = ${input}` sem sanitização expõe todo o banco. Prepared statements resolvem em 1 linha.

Evolução de auth: passwords → MFA → passwordless (magic links, passkeys, biometrics). OAuth2/OIDC para social login e SSO.

80% dos breaches envolvem credenciais comprometidas (Verizon DBIR). Ex: Passkeys (WebAuthn) eliminam phishing — a autenticação é bound ao domínio. Não funciona em site falso. Apple, Google e Microsoft suportam nativamente.

TLS encripta comunicação entre client e server. HTTPS = HTTP + TLS. Let's Encrypt oferece certificados gratuitos. Cloudflare oferece TLS automático.

HTTP sem TLS expõe dados em trânsito. Browsers marcam sites HTTP como "Not Secure". Google penaliza no SEO. Ex: Let's Encrypt automatiza: certbot renova certificados a cada 90 dias. Cloudflare: zero config, TLS automático para qualquer domínio.

Modelo de segurança onde nada é confiável por padrão — nem a rede interna. Cada request é autenticada, autorizada e encriptada.

Modelo de "perímetro seguro" (firewall) falha quando o atacante está dentro. Ex: O breach da SolarWinds (2020) — atacantes dentro da rede por 9 meses porque a rede interna era "trusted". Zero Trust teria exigido autenticação em cada lateral movement.

Lei Geral de Proteção de Dados: consentimento, minimização de dados, direito de exclusão, portabilidade, notificação de breach.

Multa de até 2% do faturamento. Ex: Implementar "right to be forgotten": DELETE de todos os dados do usuário em todas as tabelas, caches, backups, logs e terceiros. Sem arquitetura planejada para isso, é impossível.

Scanning automático de vulnerabilidades em dependências: Dependabot, Snyk, npm audit. CVEs em libs desatualizadas são o vetor mais comum de ataque.

Log4Shell (2021) afetou 35k+ pacotes Java. Se você não monitora dependências, não sabe se está vulnerável. Ex: Dependabot no GitHub abre PR automático quando encontra CVE em suas deps. Merge = seguro. Ignore = risco.

SAST (análise estática do código), DAST (teste da aplicação rodando), pentest (hacker ético atacando). Automatizar SAST/DAST na CI, pentest periodicamente.

Bugs de segurança pegos em review custam 10x menos que em produção, e 100x menos que após um breach. Ex: GitHub Code Scanning (CodeQL) roda SAST em cada PR — encontra SQL injection, XSS, path traversal automaticamente. Gratuito para repos públicos.

Processo estruturado para responder a incidentes: detectar, comunicar, diagnosticar, mitigar, resolver, post-mortem.

Pânico em incidente piora tudo. Processo claro reduz MTTR. Ex: O PagerDuty tem runbooks para cada tipo de incidente — "se error rate > 10%: 1. Check dashboard X, 2. Verify deployment Y, 3. Rollback if needed". Seguir runbook em vez de improvisar.

Documento após incidente: timeline, root cause, impacto, ações corretivas. Blameless: foca no sistema, não na pessoa.

Sem post-mortem, o mesmo incidente acontece de novo. Ex: O Google publica post-mortems internos para todos aprenderem. Template: "O que aconteceu" → "Por que aconteceu" → "O que vamos mudar" → "Action items com owners e deadlines".

Documentação passo-a-passo para cenários comuns: "banco lento", "serviço não responde", "disco cheio", "certificado expirado".

Em uma emergência às 3h da manhã, ninguém lembra o procedimento. O runbook é o GPS. Ex: Runbook "DB lento": 1. Checar pg_stat_activity (queries ativas), 2. Kill queries > 30s, 3. Check locks, 4. Verify disk space, 5. Check for missing indexes. Seguir sequencialmente.

Introduzir falhas deliberadas em produção para testar resiliência: matar instâncias, injetar latência, simular partition.

Você descobre fraquezas antes dos usuários. Ex: O Netflix Chaos Monkey mata instâncias EC2 aleatórias em produção. Se o sistema sobrevive, está resiliente. Se não, o time corrige antes que uma falha real aconteça.

Disciplina do Google que aplica engenharia de software a problemas de operações. Foco em automação, SLOs, error budgets e redução de toil.

SRE é o framework que permite operar sistemas confiáveis sem inflar o time. Ex: O Google define: se o error budget está OK (dentro do SLO), priorize features. Se o error budget está baixo, congele features e melhore confiabilidade. Objetivos alinhados automaticamente.

Rotação de pessoas responsáveis por responder a incidentes fora do horário. Boas práticas: compensação, rotação justa, ferramentas adequadas.

On-call mal feito causa burnout e turnover. Ex: O PagerDuty recomenda: rotação semanal, máximo 1 incidente/noite (se mais, os alertas estão errados), compensação em folga ou $, runbooks para cada alerta. Se o oncall é acordado toda noite, o problema é a engenharia, não a pessoa.

Padrões para construir sistemas resilientes: circuit breaker (para de chamar serviço falho), retry (tenta de novo com backoff), bulkhead (isola falhas), timeout (não espera para sempre).

Sem esses padrões, uma falha cascateia pelo sistema inteiro. Ex: Sem circuit breaker: serviço de pagamento cai → serviço de pedido espera → timeout → pool de conexões esgota → serviço de pedido cai → catálogo cai → tudo cai. Com circuit breaker: pagamento cai → circuit abre → pedido retorna "tente mais tarde" → sistema continua funcionando.