Bloco F · Semana 13 Tempo estimado: 22 min de leitura + ~2-3h de prática (mapear SLAs Team Studio) Output prático: você propõe SLA do Team Studio com base em números reais, não em chute
TL;DR
Agora que você sabe arquitetar (Semana 12), precisa prometer com segurança. Cliente médio/grande vai pedir SLA, vai perguntar "qual seu RTO?", vai pedir métricas DORA. Sem repertório aqui, você ou promete demais (e queima a operação) ou subentrega (e perde venda).
Você vai sair desta semana sabendo:
- SLA vs SLO vs SLI - o sanduíche da confiabilidade e por que separar evita briga
- SLA composto - a matemática que pega 90% dos vendedores: se 5 serviços têm 99.9% cada, seu SLA real é menor
- Métricas DORA - gold standard de performance de engenharia (4 métricas + 4 tiers de performance)
- Percentis p50/p95/p99/p99.9 - por que média é mentira e como pensar em latência
- RPO vs RTO - quanto dado posso perder vs em quanto tempo eu volto
- SLA real dos providers em 2026 - AWS, GCP, Azure, Supabase, Vercel, Cloudflare
- Como negociar SLA com cliente sem se enforcar - pegadinhas, janelas de manutenção, force majeure, crédito
- Como Team Studio mede confiabilidade hoje - estado atual + próximos passos
- 5 perguntas pra reunião sobre SLA
- Exercício prático - SaaS B2B brasileira pedindo SLA de 99.99% do Team Studio
Como chegamos aqui (recap Semana 12)
Semana 12 te deu arquitetura: monolito vs microserviços, padrões e anti-padrões, ADR. Você consegue defender escolhas estruturais.
Mas arquitetura é meio. SLA é fim. Cliente não compra "monolito modular" - compra promessa de disponibilidade, latência e recuperação. Quem traduz arquitetura em SLA realista vende mais e queima menos.
1. SLA vs SLO vs SLI: o sanduíche da confiabilidade
Três siglas próximas que confundem em reunião. Vamos separar.
SLI (Service Level Indicator) - a métrica
SLI é o que você mede. Número concreto. Exemplos: - Uptime: % de requisições que retornaram com status 2xx ou 3xx - Latência p95: tempo de resposta abaixo do qual 95% das requisições caem - Throughput: requisições por segundo - Erro rate: % de requisições com status 5xx - Durabilidade: % de dados que permanecem íntegros após 1 ano
SLI é factual. Você coleta de log/métrica.
SLO (Service Level Objective) - a meta interna
SLO é a meta interna que você compromete a atingir. Exemplo:
- SLO uptime: 99.9% mensal (43 min de downtime permitido por mês)
- SLO latência p95: abaixo de 200ms
- SLO erro rate: abaixo de 0.1%
SLO é interno, sem compromisso contratual com cliente. Time se cobra disso. Quando SLO está em risco, vira error budget (orçamento de erro): quanto downtime ainda posso "gastar" antes de quebrar o objetivo do mês.
SLA (Service Level Agreement) - a promessa contratual
SLA é o que você promete por contrato. Em geral é mais frouxo que o SLO - você se compromete com um número que sabe atingir, e mira internamente um número melhor.
Exemplo Team Studio: - SLO interno: 99.9% uptime mensal - SLA contratual: 99.5% uptime mensal (com crédito se quebrar)
A diferença de 0.4% é o buffer que protege você de pequenos incidentes sem pagar crédito ao cliente.
Por que separar evita briga
Se você promete SLA = SLO ao cliente, qualquer incidente vira evento contratual. Toda manutenção planejada, todo bug de provedor, toda atualização vira "vocês quebraram SLA".
Buffer protege relacionamento e protege caixa.
Exemplos práticos
| Cenário | SLI | SLO | SLA |
|---|---|---|---|
| API Team Studio | % req 2xx/3xx | 99.9% | 99.5% |
| Latência WhatsApp | p95 envio | 1.5s | 3s |
| Erro rate Mission Control | % req 5xx | 0.1% | 1% |
| Backup completeness | % backups com restore validado | 100% | 95% (mensal) |
2. SLA composto: a matemática que pega gente desprevenida
Pergunta capciosa em reunião: "Vocês usam AWS sa-east-1 (SLA 99.99%), Supabase (SLA 99.95%), Cloudflare (SLA 100%), OpenAI (SLA 99.9%) e Caddy interno (sem SLA). Qual o SLA real do Team Studio?"
Resposta certa: produto dos SLAs, não soma.
A matemática
Se você depende de N serviços em cadeia (chamada síncrona), seu uptime real é o produto dos uptimes:
SLA_real = SLA_1 × SLA_2 × SLA_3 × ... × SLA_n
Exemplo concreto Team Studio:
- AWS sa-east-1 EC2: 99.99%
- Supabase: 99.95%
- Cloudflare: 100% (na verdade ~99.99%)
- OpenAI API: 99.9% (real, não declarado)
- Caddy interno: ~99.95%
SLA real = 0.9999 × 0.9995 × 0.9999 × 0.999 × 0.9995 = 0.9978 = 99.78%
Downtime permitido com 99.78%: ~95 minutos por mês.
Se você prometeu 99.9% como SLA, está com buffer negativo de 0.12% - vai quebrar quase sempre.
Tabela de impacto
Quantos noves do sistema dependendo do número de dependências, assumindo 99.99% cada:
| Dependências | SLA composto | Downtime/mês |
|---|---|---|
| 1 | 99.99% | 4.3 min |
| 2 | 99.98% | 8.6 min |
| 3 | 99.97% | 13 min |
| 5 | 99.95% | 21.6 min |
| 10 | 99.9% | 43 min |
| 20 | 99.8% | 86 min |
Cada dependência adicional come uma fatia do uptime. Sistema com 20 serviços em cadeia, mesmo com cada serviço a 4 noves, oferece só 3 noves.
Como mitigar (parcialmente)
- Reduzir cadeia síncrona - usar event-driven onde possível (vimos na Semana 12). Falha de consumer não derruba producer.
- Caching - se OpenAI estiver fora, Team Studio responde com cache de resposta anterior pra perguntas frequentes.
- Fallback gracioso - se LLM principal cai, usar LLM secundário (Anthropic se OpenAI cai, ou vice-versa).
- Circuit Breaker - abrir conexão com dependência morta, evitar timeout em cascata.
- Multi-region - se uma região da AWS cai, redirecionar pra outra. Caro mas eleva noves.
- Honestidade contratual - SLA realista que reflete dependências, não sonho.
Cenário Team Studio composto
Pra cliente PME (sem multi-region), Team Studio honestamente entrega ~99.5-99.8% efetivo. Pra cliente grande que paga upgrade, Team Studio pode entregar 99.9% via multi-region + fallback LLM. Pra 99.99% é necessário arquitetura completamente diferente (5-10x custo).
Em vez de mentir, Team Studio propõe 3 níveis: - Tier 1 (PME, ~R$ 800/mês): SLA 99.5% (sem multi-region) - Tier 2 (média empresa, ~R$ 3-6k/mês): SLA 99.9% (multi-region + fallback LLM) - Tier 3 (enterprise, sob negociação): SLA 99.95-99.99% (arquitetura dedicada)
3. Métricas DORA: o gold standard de performance de engenharia
DORA = DevOps Research and Assessment. Programa de pesquisa da Google (originalmente independente, comprado em 2018) que publica anualmente o State of DevOps Report desde 2014.
Eles concluíram que 4 métricas previzem performance de organizações de engenharia. Em 2026 isso virou linguagem comum em reuniões com CTOs.
As 4 métricas DORA
1. Deployment Frequency
O que mede: quão frequente você implanta código em produção.
- Elite: múltiplos deploys por dia
- High: deploys diários a semanais
- Medium: deploys semanais a mensais
- Low: deploys mensais ou menos
Por que importa: deploy frequente significa que mudanças são pequenas, testáveis e revertíveis. Deploy raro significa changesets gigantes, alto risco, dificuldade de revert.
2. Lead Time for Changes
O que mede: tempo desde commit até código rodando em produção.
- Elite: menos de 1 hora
- High: 1 dia a 1 semana
- Medium: 1 semana a 1 mês
- Low: mais de 1 mês
Por que importa: lead time baixo = ciclo rápido de feedback. Cliente reporta bug → você corrige → deploy → cliente vê em horas.
3. MTTR (Mean Time to Restore)
O que mede: tempo médio pra restaurar serviço após incidente.
- Elite: menos de 1 hora
- High: menos de 1 dia
- Medium: 1 dia a 1 semana
- Low: mais de 1 semana
Por que importa: incidente vai acontecer. Maturidade está em quão rápido você volta. MTTR alto = cliente furioso, perda de receita, reputação.
4. Change Failure Rate
O que mede: % de deploys que causam falha em produção (rollback, hotfix, downtime).
- Elite: 0-15%
- High: 16-30%
- Medium: 31-45%
- Low: 46-60%
Por que importa: deploy que quebra = falha de testes/processo. Taxa alta indica fragilidade.
Estado da indústria em 2026
Estado do State of DevOps Report 2024-2025: - Apenas ~18% das empresas estão no tier Elite em todas as 4 métricas - ~31% em High - ~36% em Medium - ~15% em Low
Empresas Elite têm 2x mais probabilidade de superar metas de negócio.
Métricas DORA pro Team Studio
Aplicando hoje: - Deployment Frequency: 5-10 deploys por dia em Mission Control (High/Elite) - Lead Time: ~30 min de commit a produção (Elite) - MTTR: ~15 min em incidentes recentes (Elite) - Change Failure Rate: estimado ~10-15% (Elite/High borderline)
Em reunião com CTO: Team Studio mostra métricas DORA reais como prova técnica. Vale mais que qualquer pitch de slide.
4. Percentis p50, p95, p99, p99.9: o jogo dos percentis
Por que média (mean) é mentira
Imagine: tenho 1000 requisições. 990 retornam em 100ms. 10 retornam em 5.000ms (5s).
- Média: (990 × 100 + 10 × 5000) / 1000 = 149ms
Conclusão errada: "média de 149ms, sistema rápido."
Realidade: 1% dos usuários (10 em 1000) está esperando 5 segundos. Esses 10 vão reclamar.
Média esconde outliers. Percentis revelam.
Como percentis funcionam
Ordena todas as latências e pega o valor em posição X%:
- p50 (mediana): latência abaixo da qual 50% das requisições caem
- p95: latência abaixo da qual 95% caem (5% acima)
- p99: latência abaixo da qual 99% caem (1% acima)
- p99.9: latência abaixo da qual 99.9% caem (0.1% acima - usuários muito raros, mas vão reclamar muito)
No exemplo acima: - p50 = 100ms - p95 = 100ms (ainda dentro dos 990 rápidos) - p99 = 5000ms (entra nos 10 lentos) - p99.9 = 5000ms
Insight: usuário típico vê 100ms. Usuário azarado (1%) vê 5s.
Tail latency: o usuário furioso é p99
Em produto B2C com 1 milhão de requisições/mês: - p99 = 1% = 10.000 requisições/mês acima do threshold - p99.9 = 0.1% = 1.000 requisições/mês
Esses milhares de usuários reclamam. Time pensa "sistema está bom (média 149ms)" e ignora.
Em B2B isso é pior: cliente B2B com 100 funcionários usando seu produto vê o p99 toda hora. "Vocês são lentos" vira percepção institucional.
Como medir
Histograma de latência. Cada request adiciona à bucket apropriado.
Ferramentas:
- Prometheus com histogram metric: request_duration_bucket{le="0.1"}, le="0.5", etc.
- Datadog/New Relic: percentis nativos
- CloudWatch: percentis em métricas custom
- OpenTelemetry: padrão moderno (vimos na Semana 7)
Latency budget e como dividir em microserviços
Cliente tolera 1 segundo de latência total. Sua arquitetura tem 5 serviços em cadeia:
Budget = 1000ms
Por serviço (média) = 200ms
Mas algumas chamadas são paralelas (não somam), outras são caches (não consumindo budget). Latency budget é a alocação consciente de "quanto cada parte pode demorar."
Em microserviços, isso vira matéria complexa. Em monolito, é simples: latência é uma só.
Cenário Team Studio
Mission Control: - p50: ~80ms - p95: ~250ms - p99: ~800ms - p99.9: ~2.5s (provavelmente chamadas LLM lentas)
Pro cliente isso é "rápido o suficiente". Pra cliente que exige p99 < 500ms: precisa otimizar (caching de queries LLM, paralelização de calls).
5. RPO e RTO em decisões de backup
Duas siglas que aparecem em toda reunião sobre disaster recovery.
RPO (Recovery Point Objective)
Quanto dado posso perder? Medido em tempo (minutos, horas, dias).
- RPO = 0: zero perda de dado. Replicação síncrona. Caro.
- RPO = 1h: aceita perder até 1 hora de dado. Backup horário ou replicação assíncrona.
- RPO = 1 dia: aceita perder até 24h. Backup diário.
RTO (Recovery Time Objective)
Em quanto tempo eu volto? Medido em tempo.
- RTO = 0: zero downtime. Sistema failover automático. Multi-region.
- RTO = 1h: aceita 1h pra restaurar. DR plan documentado, time treinado.
- RTO = 1 dia: aceita 24h. Backup restaurável, sem failover automático.
Trade-off custo vs RPO/RTO
| Estratégia | RPO | RTO | Custo |
|---|---|---|---|
| Sem backup | Infinito | Infinito | 0 |
| Backup diário | 24h | Horas | Baixo |
| Backup horário | 1h | Horas | Médio |
| Replicação assíncrona | Minutos | Minutos | Alto |
| Replicação síncrona | 0 | Segundos | Muito alto |
| Multi-region active-passive | Minutos | < 30 min (com automação) | Muito alto |
| Multi-region active-active | 0 | Zero | Astronômico |
Cliente quer RPO e RTO baixos sem entender custo. Sua função é traduzir requisito em preço.
Cenário Team Studio hoje
Mission Control (Supabase + VPS): - RPO: 24h (Supabase backup automático + Hostinger snapshot diário 03h) - RTO: ~2-4h (restaurar Supabase via dashboard + restaurar VPS via snapshot)
Evolution API (mensagens WhatsApp): - RPO: 24h (pg_dump diário cron 03h + retenção 7d) - RTO: ~1h (pg_restore num container novo)
Sites de clientes (Caddy + arquivos estáticos): - RPO: ~horas (sync em VPS, snapshot diário Hostinger) - RTO: < 1h (restaurar via snapshot)
Pra cliente PME, esses números são aceitáveis. Cliente médio/grande pode exigir RPO = 1h ou RTO = 30 min. Aí precisa upgrade de infraestrutura ($$).
Tabela de estratégia de backup
| Frequência | Tipo | Retenção | Restore | Custo |
|---|---|---|---|---|
| Continuous | WAL streaming | 7 dias | Point-in-time | Médio |
| 1h | Snapshot | 24 versões | Lento | Baixo |
| Diário | Full + incremental | 30 dias | Médio | Baixo |
| Semanal | Full | 12 semanas | Lento | Muito baixo |
| Mensal | Full + archive | 7 anos (compliance) | Muito lento | Médio |
Em geral: usar combinação de várias frequências (4-3-2-1 rule: 4 cópias, 3 mídias diferentes, 2 sites, 1 offsite).
6. SLA real dos providers em 2026
Tabela de SLA dos providers principais que Team Studio (ou cliente) provavelmente usa:
| Provider | Serviço | SLA declarado | Notas |
|---|---|---|---|
| AWS | EC2 single instance | 99.5% mensal | Multi-AZ sobe pra 99.99% |
| AWS | EC2 multi-AZ | 99.99% mensal | Premium |
| AWS | RDS Multi-AZ | 99.95% mensal | |
| AWS | S3 Standard | 99.99% availability, 99.999999999% durability | "11 noves" famosos |
| AWS | Lambda | 99.95% mensal | |
| GCP | Compute Engine | 99.5% (single zone), 99.99% (regional) | |
| GCP | Cloud Run | 99.95% | |
| Azure | VM single | 99.9% | |
| Azure | VM Premium SSD | 99.9% | |
| Supabase | Free tier | Best effort (sem SLA) | |
| Supabase | Pro | 99.9% | Recente, antes era 99.5% |
| Supabase | Team/Enterprise | 99.99% | Premium |
| Cloudflare | CDN/DNS | 100% (com créditos se cair) | Histórico ~99.99% real |
| Vercel | Hobby | Best effort | |
| Vercel | Pro | 99.99% | |
| Vercel | Enterprise | 99.99% | Com SLA negociável |
| Netlify | Free | Best effort | |
| Netlify | Pro | 99.99% | |
| OpenAI | API | Sem SLA público | Histórico ~99.9% |
| Anthropic | API | Sem SLA público | Histórico ~99.95% |
| Stripe | Payments | 99.99% | |
| Twilio | Voice/SMS | 99.95% |
Como ler SLA do provider
SLA tem letras miúdas. Sempre:
- Janela de manutenção planejada: geralmente exclusa do cálculo
- Force majeure: exclui (Sandy, COVID, war)
- Período de medição: mensal vs trimestral muda muito
- Crédito vs reembolso: AWS dá crédito (futuro), não reembolso
Crédito de SLA vs realidade do downtime
Empresa grande não compensa downtime com crédito. Cliente perde milhões em 1h de downtime, AWS dá 10% de crédito do mês ($300 num gasto de $3.000).
Cliente médio fica satisfeito com crédito porque é simbólico.
Em SLA com Team Studio, definir o que é crédito (sem inflar): - 99.5% < uptime ≤ 99.0% → 5% de crédito no mês seguinte - 99.0% < uptime ≤ 98.0% → 10% de crédito - < 98.0% → 25% de crédito - < 95.0% → direito de rescisão sem multa
Isso protege Team Studio (crédito limitado) e protege cliente (saída em caso extremo).
7. Como negociar SLA com cliente sem se enforcar
Princípio: SLA é promessa, não fé
Antes de aceitar 99.9% no contrato, você mediu ou calculou compostamente que consegue entregar. Se nunca mediu, não promete.
Pegadinhas comuns que clientes colocam no contrato
1. Uptime sem definir o que é "uptime"
Cliente escreve: "Team Studio garante 99.9% uptime."
Problema: o que é uptime? Por feature? Por endpoint? Por requisição? Pelo tempo total?
Solução: definir explicitamente. "Uptime = % de requisições à API Mission Control que retornaram status 2xx ou 3xx no período mensal, excluindo janelas de manutenção planejada com aviso prévio de 24h."
2. Sem janela de manutenção planejada excluída
Cliente escreve: "99.9% uptime, qualquer downtime conta."
Problema: você precisa fazer manutenção (patches, updates). Sem exclusão, manutenção planejada consome SLA.
Solução: incluir "exceto janelas de manutenção planejada anunciadas com 24h de antecedência, máximo de 4h por mês."
3. Sem force majeure adequado
Cliente escreve: "SLA aplica em todos os casos."
Problema: provedor cai por motivo absurdo (incêndio em datacenter, ataque DDoS coordenado, evento meteorológico). Você fica responsável.
Solução: cláusula de force majeure inclui falhas de provedores upstream listados explicitamente (AWS, Supabase, Cloudflare).
4. Crédito ilimitado
Cliente escreve: "Em caso de quebra de SLA, Team Studio paga indenização por dano emergente e lucro cessante."
Problema: cliente pode reclamar milhões por 1h de downtime.
Solução: crédito limitado a porcentagem da mensalidade. "Crédito máximo: 25% da mensalidade do mês afetado, sem indenização adicional."
Como Team Studio se posiciona
Por porte de cliente:
Cliente PME (~R$ 800/mês): - SLA 99.5% uptime mensal - Janela manutenção: 4h/mês - Crédito até 25% mensalidade
Cliente média empresa (~R$ 3-6k/mês): - SLA 99.9% uptime mensal - Janela manutenção: 2h/mês - Crédito até 50% mensalidade - Failover LLM (OpenAI → Anthropic se necessário)
Cliente enterprise (sob negociação): - SLA 99.95% uptime mensal - Janela manutenção: 1h/mês com 7d de aviso - Crédito até 100% mensalidade - Failover LLM + multi-region - SLA composto documentado (cliente sabe que depende de AWS+Supabase+OpenAI)
Cláusulas que protegem Team Studio
-
SLA mensal, não diário: 99.5% mensal = 3.6h tolerável. 99.5% diário = 7 min tolerável (impossível operacionalmente).
-
Exclui terceiros não-Team-Studio: se cliente integra Team Studio com sistema dele que cai, isso não conta no SLA.
-
Janela de manutenção exclusa: tem que ter, sem isso você acaba pagando pra patch obrigatório.
-
Force majeure expandido: inclui falha de provedores upstream listados (AWS, Supabase, Cloudflare, OpenAI, Anthropic).
-
Cap de crédito: máximo % da mensalidade. Sem indenização por dano emergente/lucro cessante.
-
Período de medição mensal: 1 incidente de 4h não destrói 12 meses de relacionamento.
-
Direito de rescisão se SLA quebra repetidamente: cliente pode sair sem multa se você quebra 3 meses consecutivos. Te força a melhorar.
8. Como Team Studio mede confiabilidade hoje
Estado atual da observabilidade:
Uptime monitoring
Mission Control:
- Uptime Robot (free tier) faz HTTP check a cada 5 min nos endpoints /api/health
- Alerta via email + WhatsApp se 2 falhas consecutivas
Sites de clientes:
- Uptime Robot pra cada domínio crítico (PME paga)
- Cron interno faz curl /health em 30+ domínios a cada 5 min
Latência
Mission Control:
- Logs estruturados com duration_ms por request
- Grafana (futuro) ou query Postgres pra agregação ad-hoc
- Sem percentis automatizados ainda
Evolution API: - Logs do Docker com timestamp - Tempo de delivery WhatsApp não medido sistematicamente
MTTR
Medido em incidentes reais. Histórico recente:
- Migração Renata Reginato (2026-05-19): cache DNS stale, ~30 min pra identificar root cause + ~30 min pra fix
- Heredoc bug Kanban (2026-05-23): ~10 min de downtime Mission Control + rollback via tag git
- ACME challenge fail (vários casos): ~5-15 min de cert renewal manual
Sem alerting formal ainda, MTTR é "tempo até George ver o problema".
Change Failure Rate
Estimado em ~10-15% (deploys que precisam hotfix ou rollback). Baseline informal, sem tracking formal.
Próximas etapas
Roadmap de observabilidade Team Studio:
- Setup Prometheus + Grafana pra Mission Control (próximas 2-4 semanas)
- Histograms de latência em endpoints críticos
- Alerting com PagerDuty ou Opsgenie (free tier) baseado em SLO
- Error budget tracking mensal automático
- Status page pública (status.teamstudio.com.br via Statuspage ou Uptime Robot)
- Postmortems documentados pra incidentes > 30 min de impacto
Cliente B2B sério vai pedir esses artefatos. Hoje Team Studio responde "estamos implementando" - em 3-6 meses, responde "está implementado, aqui está o dashboard".
9. 5 perguntas pra reunião sobre SLA
1. "Vocês têm SLA documentado interno (SLO) diferente do SLA contratual?"
Por que: cliente sofisticado opera com buffer SLA/SLO. Se ele não tem essa distinção, é sinal de imaturidade - você pode educar (e cobrar por isso). Se ele tem, conversa fica mais rica.
2. "Como vocês medem SLA? SLI específicos? Periodicidade?"
Por que: cliente que mede mensal é diferente de cliente que mede diário. Cliente que mede via uptime robot é diferente de cliente que mede via custom dashboard. Define exigência.
3. "Quando vocês quebram SLA, qual o procedimento?"
Por que: postmortem? Crédito automático? Reunião de root cause? Esperar cliente reclamar? Sinal de maturidade operacional.
4. "Qual o RPO e RTO de vocês pros dados que Team Studio vai gerenciar?"
Por que: define infraestrutura necessária do Team Studio pra atender. RPO = 24h é uma coisa, RPO = 1h é outra (vai exigir replicação contínua).
5. "Vocês têm métricas DORA? Quais valores aceitáveis pra fornecedor que vocês contratam?"
Por que: cliente com DORA é cliente que entende performance de engenharia. Vai apreciar Team Studio ter números. Cliente sem DORA - você pode introduzir o conceito.
10. Exercício prático: SaaS B2B pedindo SLA de 99.99%
Cenário: SaaS B2B brasileira de gestão de RH (PeopleControl, 80 clientes, R$ 5M ARR) quer contratar Team Studio pra: - Atendimento WhatsApp 24h pros funcionários dos clientes (~50.000 funcionários) - Geração automática de holerites em PDF - Análise de turnover com insights pros HR managers
CTO da PeopleControl, Carla, manda email:
"Adoramos a proposta. Pra fechar, precisamos de SLA de 99.99% no Team Studio. Isso são apenas ~4 minutos de downtime por mês. Está alinhado?"
Sua tarefa: responder de forma profissional, honesta e protetora.
Resposta esperada (passo a passo)
Passo 1: Calcule o SLA composto realista
Dependências críticas pra Team Studio entregar o serviço pra PeopleControl:
- AWS sa-east-1 EC2 (assumindo single-AZ): 99.5%
- Supabase Pro: 99.9%
- Cloudflare CDN: 99.99%
- OpenAI API (sem SLA, real ~99.9%): 99.9%
- Caddy interno: 99.95%
SLA composto (cadeia de provedores do Team Studio) = 0.995 × 0.999 × 0.9999 × 0.999 × 0.9995 = 0.9924 = 99.24%
Se incluíssemos na conta o sistema da própria PeopleControl (~99.9%), o composto fim-a-fim cairia pra ~99.14%. Mas esse pedaço está fora do que o Team Studio controla, então não entra no SLA que o Team Studio promete.
Pra entregar 99.99% real, Team Studio precisaria: - AWS multi-AZ ou multi-region: +R$ 5-10k/mês - Supabase Enterprise: +R$ 3-5k/mês - LLM failover Anthropic redundante: +20% custo LLM - Monitoring + on-call estruturado: +R$ 3-5k/mês
Custo upgrade: ~R$ 11-20k/mês adicional só de infraestrutura.
Passo 2: Responda com transparência
Oi Carla,
Obrigado pela mensagem. SLA de 99.99% é meta nobre e quero ser
transparente sobre o que isso significa tecnicamente pra Team
Studio entregar pra vocês.
O serviço Team Studio depende de uma cadeia de provedores: AWS
(infra), Supabase (banco), OpenAI (LLM), Cloudflare (CDN) e
sistemas internos. Calculando o SLA composto real considerando
o SLA contratual de cada provedor:
- AWS sa-east-1 EC2: 99.5%
- Supabase Pro: 99.9%
- Cloudflare: 99.99%
- OpenAI API (sem SLA formal, histórico ~99.9%): 99.9%
- Caddy interno: 99.95%
SLA composto real (produto, não soma) ≈ 99.24%, equivalente a
~5h30 de downtime tolerado por mês.
Pra entregar 99.99% de verdade (não 'no papel'), Team Studio
precisaria upgrade pra:
1. AWS multi-AZ ou multi-region (+R$ 5-10k/mês)
2. Supabase Enterprise tier (+R$ 3-5k/mês)
3. LLM failover Anthropic redundante (+20% custo LLM)
4. Monitoring + on-call estruturado 24/7 (+R$ 3-5k/mês)
Adicional ~R$ 11-20k/mês só de infraestrutura, fora o custo
operacional do Team Studio operar essa estrutura.
Proposta alternativa em 3 níveis pra discussão:
**Tier 1 (atual proposta)**:
- SLA 99.5% uptime mensal
- Janela manutenção: 4h/mês com aviso 24h
- Crédito até 25% mensalidade em quebra
- Custo: dentro da proposta atual
**Tier 2 (upgrade média)**:
- SLA 99.9% uptime mensal
- Failover LLM (Anthropic backup pra OpenAI)
- Janela manutenção: 2h/mês com aviso 24h
- Custo: +R$ 5k/mês na proposta
**Tier 3 (enterprise grade real)**:
- SLA 99.95% uptime mensal
- Multi-region AWS + Supabase Enterprise
- LLM failover + caching agressivo
- Status page pública + status reports mensais
- Janela manutenção: 1h/mês com aviso 7 dias
- Custo: +R$ 15k/mês na proposta
99.99% real exigiria arquitetura dedicada e custo significativo
adicional, que provavelmente excede ROI pra 50.000 funcionários
recebendo holerite mensal e tirando dúvidas via WhatsApp.
Posso entrar numa call de 30 min pra explicar a matemática e
discutir qual tier faz sentido pro caso de uso de vocês?
Abraço,
George
Resultado esperado
Em 80% dos casos, cliente entende a matemática e escolhe Tier 1 ou Tier 2 (Tier 2 vira upgrade natural pra rotina B2B com 50k usuários). Em 15% dos casos, cliente exige Tier 3 e topa pagar. Em 5% dos casos, cliente vai pro concorrente que mente sobre SLA - e meses depois vai voltar pra você (após o concorrente quebrar promessa).
Princípio: honestidade radical em SLA preserva relacionamento e protege caixa.
Resumo de uma frase
SLA bom é matematicamente fundamentado (composto dos providers + buffer protetor), tem letras miúdas que protegem você (janela manutenção, force majeure, cap de crédito), e é negociado em tiers que matchem porte e exigência do cliente - quem promete 99.99% sem entender SLA composto vai quebrar o contrato dentro de 6 meses.
Próximos passos
Próximas semanas do Bloco F:
- Semana 14: Custo, pricing, TCO real, modelos de precificação
- Semana 15: Reuniões com TI corporativo - táticas e armadilhas práticas
- Semana 16: Vendor lock-in, exit strategy, checklist do CTO maduro (fecha trilha)
Glossário rápido (termos novos desta semana)
- SLI (Service Level Indicator): a métrica concreta que você mede (uptime, latência, etc)
- SLO (Service Level Objective): meta interna que você compromete a atingir
- SLA (Service Level Agreement): promessa contratual com cliente, geralmente mais frouxa que SLO
- Error budget: orçamento de erro mensal antes de quebrar SLO ("ainda posso ter 15 min de downtime")
- SLA composto: produto dos SLAs de cada dependência em cadeia
- DORA: DevOps Research and Assessment, programa de pesquisa do Google
- State of DevOps Report: relatório anual com benchmark de performance de engenharia
- Deployment Frequency: métrica DORA - frequência de deploy em produção
- Lead Time for Changes: métrica DORA - tempo de commit até produção
- MTTR (Mean Time to Restore/Repair): métrica DORA - tempo médio pra restaurar serviço após incidente
- Change Failure Rate: métrica DORA - % de deploys que causam falha
- p50, p95, p99, p99.9: percentis de latência
- Tail latency: latência dos percentis altos (p99+) onde usuários frustrados moram
- Latency budget: alocação consciente de latência entre componentes
- RPO (Recovery Point Objective): quanto dado posso perder, medido em tempo
- RTO (Recovery Time Objective): em quanto tempo restauro serviço, medido em tempo
- Force majeure: cláusula que exclui responsabilidade em eventos extraordinários
- Status page: página pública que mostra status de cada componente do serviço
- Postmortem: documento pós-incidente analisando root cause e ações corretivas