Fecha o Bloco C (DevOps). Foco: você entende como código sai do laptop do dev até produção, como detectar problemas em produção antes do cliente reclamar, e identifica quando time tem cultura DevOps saudável vs quando opera no susto.
Pré-requisito: Semana 6 (Docker/k8s) ajuda mas não obrigatório. Tempo estimado: 3-4 horas de leitura + 1 hora de exercício. Output prático: você opina com substância em discussão sobre pipeline de deploy e sabe identificar lacunas de observability na operação do cliente.
Por que essa semana importa
CI/CD e observability são onde maturidade técnica de empresa fica MAIS visível. Empresa boa deploya 5-50 vezes por dia sem problema. Empresa imatura deploya 1x por semana com medo e descobre bug pelo cliente reclamando.
Quando cliente diz:
"Nosso pipeline tá lento, deploy demora 30 min, fica quebrando pra deploy de feature flag, tivemos 3 incidentes em produção esse mês que descobrimos pelo cliente"
...você entende cada problema e propõe solução concreta. Sem repertório, você assenta.
Bônus: agentes do Team Studio são oportunidade clara de melhorar observability de cliente. "Agente que monitora 50 métricas e avisa por WhatsApp antes do cliente perceber" é venda fácil pra qualquer empresa que sofre com incidentes não detectados.
1. CI/CD - do commit até produção
CI/CD é a esteira automatizada que pega código novo, testa, e coloca em produção. Sigla composta:
- CI (Continuous Integration): integrar código novo de devs múltiplos em uma branch comum, com testes automáticos a cada commit
- CD (Continuous Delivery OU Continuous Deployment): continuar essa esteira até produção. "Delivery" exige aprovação manual no fim. "Deployment" é 100% automático.
1.1 Anatomia de um pipeline típico
[Dev faz commit] → [Pipeline dispara automaticamente]
↓
[1. Lint] (regras de estilo de código)
↓
[2. Build] (compila TypeScript, bundla, etc)
↓
[3. Tests] (unit tests, integration tests)
↓
[4. Security scan] (vulnerabilidades em dependências)
↓
[5. Build container image]
↓
[6. Push pra registry]
↓
[7. Deploy em staging]
↓
[8. Smoke tests / E2E em staging]
↓
[9. Aprovação manual] (opcional, geralmente em prod)
↓
[10. Deploy em produção]
↓
[11. Health check pós-deploy]
↓
[12. Notificar Slack/WhatsApp]
Cada passo PRECISA passar pro próximo rodar. Falha em qualquer etapa = pipeline para, dev recebe notificação.
1.2 Tipos de teste no pipeline
- Lint: regras de estilo (ESLint, Prettier, Pylint). Garante consistência.
- Type check: TypeScript, MyPy, etc. Pega erros de tipo antes de runtime.
- Unit tests: testa funções isoladas. Rápido (segundos).
- Integration tests: testa interações entre componentes (app + banco). Lento (minutos).
- E2E tests: testa fluxo completo do usuário via browser (Playwright, Cypress). Muito lento.
- Visual regression tests: detecta mudanças visuais não esperadas.
- Performance tests: bench de latência, throughput.
- Security tests: SAST (static), DAST (dynamic), SCA (dependencies).
Pipeline maduro tem todos. Pipeline jovem tem unit + integration. Pipeline imaturo só tem lint + build.
1.3 Ferramentas CI/CD principais
GitHub Actions: mais popular hoje, integrado nativamente ao GitHub. Free pra repos públicos, pago para privados em escala.
GitLab CI: integrado ao GitLab. Forte em empresa com GitLab on-prem.
CircleCI: SaaS especializado, foi padrão de mercado pré-GitHub Actions.
Jenkins: open source clássico, self-hosted. Empresa grande tradicional ainda usa muito. Curva de aprendizado íngreme.
Argo CD: GitOps pra Kubernetes. Estado declarativo em Git, Argo sincroniza com cluster.
Spinnaker: orquestração de deploy multi-cloud. Usado pela Netflix, complexo.
Sinal de empresa madura: pipeline rápido (5-10 min do commit a deploy), testes confiáveis (não flakey), histórico claro de runs.
1.4 Trunk-based development vs Git Flow
Git Flow (clássico, anos 2010): branches longas (develop, feature, release, hotfix). Deploy organizado mas lento.
Trunk-based development (moderno, 2020+): todo dev commita direto na main (ou em branches que duram horas), features incompletas atrás de feature flags. Permite múltiplos deploys por dia.
Pergunta de reunião:
"Trunk-based ou Git Flow? Quantos deploys/dia em produção?"
Time fazendo 10+ deploys/dia = maduro. Time fazendo 1/semana = imaturo OU produto crítico (financeiro às vezes deploya menos por compliance).
2. Estratégias de deploy - sem derrubar produção
Você não pode simplesmente parar app antiga e ligar a nova. Usuários ficariam fora. Existem estratégias pra fazer isso suavemente:
2.1 Blue-Green deployment
Dois ambientes paralelos: Blue (versão atual) e Green (versão nova).
Blue (v1.0) ← Tráfego entra aqui
Green (v1.1) ← Pronta, aguardando
→ Troca tráfego instantaneamente
Blue (v1.0) ← Standby
Green (v1.1) ← Tráfego entra aqui
Vantagens: - Zero downtime - Rollback em 1 segundo (volta tráfego pra Blue) - Testes finais em Green antes de receber tráfego
Desvantagens: - Custa 2x infra durante a janela - Database migrations complicam (Blue e Green compartilham banco)
2.2 Rolling deployment
Atualiza instâncias UMA POR VEZ.
10 instâncias v1.0
↓
9 instâncias v1.0 + 1 instância v1.1 (em teste)
↓
8 v1.0 + 2 v1.1
↓
...
↓
0 v1.0 + 10 v1.1
Vantagens: - Sem custo extra de infra - Detecta problema cedo (1 instância nova com erro = stop rollout)
Desvantagens: - Durante rollout, usuários veem versões diferentes (pode causar bugs sutis) - Mais lento que blue-green
2.3 Canary release
Versão nova vai pra PEQUENA porcentagem dos usuários primeiro. Se ficar bom, expande gradualmente.
99% dos usuários → v1.0
1% dos usuários → v1.1 (canary)
monitora métricas do 1%...
99% v1.0 → 95% v1.0
1% v1.1 → 5% v1.1
(se métricas seguem ok, continua)
50% / 50% → 0% / 100%
Vantagens: - Detecta bug em 1% antes de afetar 100% - Permite "trial real" com usuários reais
Desvantagens: - Precisa de feature flagging ou roteamento inteligente - Métricas precisam ser confiáveis pra decisão automática
2.4 Feature flags / Feature toggles
Código novo entra em produção DESLIGADO. Ativa por flag (configuração externa).
if (featureFlag('new-checkout', { user: currentUser })) {
return <NovoCheckout />;
}
return <CheckoutAntigo />;
Permite: - Dark launch: feature em produção mas só dev/QA vê - Beta: ativa pra 5% dos usuários - Kill switch: desliga feature instantâneo se der problema - A/B testing: 50% vê v1, 50% vê v2, compara conversão - Gradual rollout: 1% → 5% → 25% → 100%
Ferramentas: LaunchDarkly (líder, caro), Unleash (open source), Flagsmith, AWS AppConfig.
2.5 Como escolher
| Caso | Estratégia |
|---|---|
| App pequena, downtime aceitável | Recreate (mata antiga, sobe nova) |
| App média, sem feature flags | Blue-Green ou Rolling |
| App grande com feature flags | Canary + Feature flags |
| Mudanças MUITO arriscadas | Canary com 0.1% → monitoramento rigoroso |
Pergunta de reunião:
"Qual estratégia de deploy de vocês? Tem feature flags? Quanto tempo de rollback?"
Resposta mede maturidade. Empresa madura usa canary + flags. Empresa imatura faz recreate à noite e cruza dedos.
3. Observability - os 3 pilares
Observability é a capacidade de ENTENDER ESTADO INTERNO do sistema só olhando outputs externos. Sem ela, você descobre problema pelo cliente reclamando.
3 pilares clássicos: logs, métricas, traces.
3.1 Logs - o diário do sistema
Mensagens de texto que app escreve sobre o que está fazendo.
[2026-05-25 10:23:45] INFO User 123 logged in via OAuth
[2026-05-25 10:23:47] DEBUG Loading dashboard for user 123
[2026-05-25 10:23:48] ERROR Failed to fetch user data: timeout after 5s
[2026-05-25 10:23:48] WARN Retrying with degraded mode (no avatar)
Níveis: TRACE, DEBUG, INFO, WARN, ERROR, FATAL. Em produção, geralmente WARN pra cima.
Estrutura: - Texto puro (clássico): difícil de buscar/analisar em escala - Estruturado (JSON): cada log é objeto JSON, fácil de filtrar - Structured + machine-parseable: padrão moderno, indexado por tools
Ferramentas: - ELK Stack (Elasticsearch + Logstash + Kibana): clássico, self-hosted - Loki + Grafana: alternativa moderna, simples - Datadog Logs: SaaS premium - Splunk: enterprise tradicional, caro - CloudWatch Logs / GCP Logging / Azure Monitor: cloud nativo
Custo dos logs em escala: rapidamente vira o item mais caro de observability. 1 TB/dia de logs em Datadog custa ~US$ 50k/mês.
3.2 Métricas - números agregados
Valores numéricos coletados em intervalos regulares (a cada segundo, minuto).
Exemplos: - CPU usage: 45% - Request count: 1,250/min - Latency p95: 350ms - Error rate: 0.2% - Active users: 3,400
Tipos: - Counter: só sobe (total de requests) - Gauge: pode subir/descer (CPU usage) - Histogram: distribuição de valores (latência p50/p95/p99) - Summary: similar a histogram, agregação client-side
Ferramentas: - Prometheus + Grafana: combo padrão open source moderno - Datadog Metrics: SaaS líder - New Relic: enterprise tradicional - AWS CloudWatch Metrics / GCP Monitoring: cloud nativo
3.3 Traces - a jornada da request
Quando request entra no sistema distribuído, ela passa por múltiplos serviços. Trace registra toda a jornada.
Trace ID: abc-123
Span 1: API Gateway [10ms]
└─ Span 2: Auth Service [5ms]
└─ Span 3: User Service [200ms]
└─ Span 4: Postgres query [180ms] ← gargalo aqui
└─ Span 5: Order Service [50ms]
└─ Span 6: Redis [2ms]
Trace mostra ONDE está o gargalo. Sem trace, você adivinha.
Ferramentas: - Jaeger: open source, popular - Zipkin: alternativa open source - Datadog APM: SaaS dominante - OpenTelemetry: PADRÃO emergente (vendor-neutral)
3.4 OpenTelemetry - o futuro
OpenTelemetry (OTel) é especificação aberta pra coletar logs+métricas+traces de forma padronizada. Funde os 3 pilares numa coleção unificada.
Por que importa: lock-in de Datadog/New Relic vira problema quando conta sobe. OTel permite trocar destination sem reescrever instrumentação.
Sinal de empresa moderna: usa OTel.
3.5 Os 4 sinais de ouro (Golden Signals)
Conceito popularizado pelo Google SRE. 4 métricas que TODA aplicação deveria expor:
- Latency (latência): quanto tempo demora pra responder
- Traffic (tráfego): quantas requests por segundo
- Errors (taxa de erro): quantas % das requests falham
- Saturation (saturação): quão perto da capacidade máxima
Empresa que monitora só "site tá no ar" perde 95% do que importa.
4. Alerting - quando acordar alguém
Não basta ter métricas. Precisa ALERTAR quando algo errado acontece. Mas alerting mal feito vira fadiga (engenheiro ignora alertas).
4.1 Boas práticas de alerting
Actionable: alerta só dispara quando ação humana é necessária. Senão é só ruído.
Specific: alerta diz EXATAMENTE o problema, não vago. - Ruim: "API caiu" - Bom: "Endpoint /api/checkout retornando 500 em 8% das requests nos últimos 5 min"
Time-bound: alerta tem janela específica. - Ruim: "Latency alta" - Bom: "Latency p99 acima de 2s por 5 min consecutivos"
Severity correta: - P1/Critical: acorda gente às 3 da manhã. Sistema fora ou perdendo dinheiro. - P2/Warning: precisa olhar em horário de trabalho. - P3/Info: log informativo, não acorda ninguém.
4.2 SLO-based alerting (moderno)
Alerta baseado em error budget (cota de erro).
Exemplo: SLO = 99.9% de uptime. Error budget mensal = 43 min de downtime.
Alerta dispara quando: - Burn rate alto (vai estourar budget em poucas horas): P1 - Budget consumido > 50%: P2 - Budget consumido > 80%: P1
Mais inteligente que alertar em cada erro pequeno.
4.3 On-call
Sistema de plantão pra atender incidentes 24/7.
Ferramentas: PagerDuty (líder), Opsgenie, VictorOps, Splunk On-Call.
Boas práticas: - Rotação semanal (não mesma pessoa sempre) - Plantão remunerado (não-trivial) - Runbook claro pra cada tipo de alerta - Post-mortem após cada incidente significativo
5. Onde Team Studio entra em CI/CD e observability
Caso 1: agente que automatiza parte do pipeline
Cliente tem pipeline manual de aprovação de PR. Agente analisa diff, identifica padrões (linting, security, complexidade), comenta no PR com sugestões. Reduz tempo de code review humano em 30-50%.
Integração: GitHub Actions com webhook pro agente. Agente usa LLM pra analisar diff e responde via API do GitHub.
Caso 2: agente que melhora observability
Cliente tem dashboards mas ninguém olha. Agente roda 24/7 sobre métricas, detecta anomalias semanticamente ("conversão caiu 30% em SP, novos clientes idem"), notifica time no WhatsApp com diagnóstico inicial.
Integração: agente consome Prometheus/Datadog API, processa com LLM, manda WhatsApp via Evolution.
Caso 3: agente que escreve postmortem
Após incidente, agente puxa logs+traces+métricas relevantes do período, gera primeiro draft de postmortem em markdown, time edita e publica. Reduz tempo de postmortem de 4h pra 30 min.
Integração: agente roda quando alerta crítico dispara, gera relatório, posta no Slack/Notion.
Pergunta de reunião:
"Quantas horas/mês o time gasta operacionalmente em pipeline, alerts, postmortems? Onde mais dói?"
6. Cinco perguntas que destravam reunião sobre CI/CD e observability
6.1 "Quantos deploys em produção por dia? Tempo do commit até produção?"
Por que importa: métricas DORA. < 1 deploy/dia + tempo > 1 dia = imaturo. 10+ deploys/dia + tempo < 1 hora = elite.
6.2 "Vocês monitoram os 4 golden signals em produção? Como descobrem problema antes do cliente?"
Por que importa: revela observability real. Time imaturo descobre problema por reclamação.
6.3 "Tem feature flags? Usam pra dark launch e canary?"
Por que importa: feature flags são marco de maturidade. Sem flags, deploy é sempre arriscado.
6.4 "Qual o MTTR de vocês? Tempo médio entre alerta e resolução?"
Por que importa: MTTR alto (horas) = problema. MTTR baixo (minutos) = time bem instrumentado.
6.5 "Quem está de plantão hoje? Como é a rotação on-call?"
Por que importa: sem on-call documentado = ninguém atende incidente noturno bem. Bandeira amarela.
7. Exercício prático
Cenário: cliente Team Studio em discovery. SaaS com 4 anos, R$ 15M ARR, 12 devs. Diz:
"Nosso processo de deploy é horrível. Cada deploy demora 45 min, falha 30% das vezes, ninguém quer fazer. Acabamos deployando 1x por semana no Saturday morning. Cliente reclama de bugs que poderiam ter sido pegos. Conseguem nos ajudar a virar 'continuous deployment'?"
Pratique: 1. Liste 5 perguntas pra entender root cause antes de propor solução 2. Identifique 3 razões comuns pra pipeline falhar 30% das vezes 3. Proponha plano de 3 meses pra sair de "1 deploy/semana" pra "10 deploys/dia" 4. Identifique 1 oportunidade pra Team Studio dentro disso
(Sugestões no fim.)
8. Material extra
Leitura essencial: - "Accelerate" (Nicole Forsgren et al) - pesquisa State of DevOps Report, base científica das métricas DORA - "Site Reliability Engineering" (Google) - capítulos sobre incident response e SLOs - "Observability Engineering" (Charity Majors et al) - livro moderno sobre observability além de logs/métricas
Vídeos: - "What is CI/CD?" (vários canais, ~15 min) - intro padrão - "OpenTelemetry Explained" - busca no YouTube
Hands-on (3 horas): - Configure GitHub Actions pra um repo pessoal: lint + test + deploy - Instale Sentry free tier numa app e gere erros pra ver tracking - Brincadeira opcional: Prometheus + Grafana com docker compose, monitora uma aplicação local
9. Sugestões pro exercício prático (veja só depois de tentar)
5 perguntas pra entender root cause:
- "O que faz o pipeline demorar 45 min? Qual etapa é a mais lenta?"
- "Qual o tipo de falha em 30% das vezes? Test failures? Build issues? Deploy errors?"
- "Vocês têm cobertura de testes? Quanto?"
- "O deploy semanal junta quantas features/commits? É big bang change?"
- "Tem rollback automático ou manual? Quanto tempo demora pra reverter?"
3 razões comuns pra 30% de falha:
- Testes flakey (intermittent): testes que falham aleatoriamente sem mudança no código. Time aceita "rodar de novo até passar". Mascarando bugs reais.
- Big bang deploys: deploy semanal acumula 50+ commits. Probabilidade de bug é exponencial. Cada deploy menor = menor chance de problema.
- Falta de testes em integração crítica: pipeline só roda unit tests. Bugs aparecem em integração e só são pegos em produção.
Plano 3 meses:
Mês 1: Estabilizar pipeline atual - Fix testes flakey (uma semana investigando e corrigindo) - Adicionar testes de integração nas rotas críticas - Configurar rollback automático quando deploy falha smoke test - Resultado esperado: pipeline falha < 10%
Mês 2: Reduzir tamanho de deploy - Implementar feature flags simples (LaunchDarkly ou Unleash) - Mover de Git Flow pra trunk-based - Deploy passa de semanal pra 2-3x por semana - Resultado esperado: deploys menores, mais previsíveis
Mês 3: Continuous deployment - Pipeline 100% automatizado (sem aprovação manual) - Canary deployment (1% → 100% gradual) - Observability completa (Datadog ou similar) - Resultado esperado: 5-10 deploys/dia, MTTR < 30 min
Oportunidade pra Team Studio:
Agente "deploy assistant": analisa cada PR antes de merge, prediz risco (baseado em arquivos tocados, complexidade, histórico), recomenda canary strategy. Não substitui time DevOps, complementa. Setup: 3-4 semanas. Valor: reduz bugs em produção em 30-50%, mensurável.
10. Próxima semana
Esta semana fecha o Bloco C (DevOps). O Bloco D (APIs e Integrações) começa em seguida:
- Semana 8: REST, GraphQL e webhooks - anatomia de APIs modernas, REST vs GraphQL sem dogma, webhooks bem feitos (HMAC, idempotência, retry, DLQ), rate limiting
- Semana 9: Autenticação corporativa (OAuth, SAML, SSO) - OAuth 2.0 com PKCE, OpenID Connect, SAML 2.0 enterprise, SSO com Active Directory/Entra ID, JWT em detalhe, secrets management. Fecha o Bloco D.