Como estruturar SRE e runbooks operacionais ao contratar uma squad alocada

SRE, ou engenharia de confiabilidade de sites, é a disciplina que conecta engenharia de software à operação confiável do produto. Em vez de tratar incidentes como algo isolado, o SRE coloca métricas, automação, limites de risco e aprendizado contínuo no centro da operação. A referência mais conhecida dessa abordagem continua sendo o livro do Google sobre SRE, que explica conceitos como SLI, SLO e error budget, úteis para qualquer produto digital com ambição de escala Site Reliability Engineering. Para uma empresa com squad alocada, a pergunta certa não é “quem faz tudo”, e sim “quem é dono de quê”. Em geral, a squad externa pode assumir implementação de monitoramento, instrumentação de logs, correção de alertas, automação de rollback, melhorias de deploy, hardening de serviços e atualização dos runbooks. Já o time interno normalmente precisa manter a autoridade sobre política de acesso, decisões de risco, aceitação de indisponibilidade, prioridade de incidentes críticos e relacionamento com áreas como segurança, compliance e negócio. Essa divisão evita dois erros comuns. O primeiro é terceirizar a operação e perder visão do sistema. O segundo é centralizar tudo no CTO ou no time interno e transformar a squad em executora sem responsabilidade real. Se você já passou por isso, a leitura de como alinhar CEO e CTO ao contratar um squad externo ajuda a resolver o principal problema político do tema: quem decide, quem executa e quem responde quando algo quebra. A regra prática que usamos em projetos maduros é esta: a squad alocada deve operar o que ela constrói, pelo menos durante a fase de transição, mas nunca sem supervisão interna. A empresa não deve depender de um fornecedor para interpretar impacto de negócio, aprovar mudanças de alto risco ou definir exceções de SLA. Isso protege a operação e reduz vendor lock-in, porque o conhecimento do sistema fica documentado e distribuído.

SLI é o indicador de confiabilidade que você mede. SLO é a meta que você aceita para esse indicador. On-call é o esquema de plantão e resposta que coloca pessoas certas na rota certa quando a meta é ameaçada. O erro mais comum é tratar esses três elementos como detalhe técnico, quando na verdade eles definem expectativa, custo e prioridade. Para uma squad alocada, os SLIs precisam ser poucos, claros e ligados ao uso real do produto. Exemplos práticos incluem disponibilidade da jornada crítica, latência da API principal, taxa de erro em login, sucesso de processamento assíncrono e tempo para restaurar serviço. Em vez de dezenas de métricas, escolha um conjunto pequeno que reflita o que realmente machuca cliente e operação. Os SLOs devem ser negociados com o negócio, não apenas com engenharia. Se o produto atende clientes enterprise, uma queda breve pode ter impacto maior do que em um app de uso casual. Para evitar metas artificiais, combine o SLO com análise de criticidade, sazonalidade e risco de receita. A lógica do error budget, detalhada pela própria documentação do Google SRE, ajuda a impedir que a empresa force estabilidade impossível ou sacrifique inovação sem critério SLIs, SLOs e error budgets. No on-call, a regra de ouro é separar resposta primária, suporte especializado e autoridade de decisão. A squad alocada pode estar na linha de frente, mas o time interno precisa guardar a capacidade de aprovar trade-offs mais sensíveis, como congelar release, degradar funcionalidade ou interromper uma integração crítica. Esse desenho evita dependência operacional excessiva e facilita o handoff depois do período de estabilização. Outro cuidado importante é não transformar on-call em punição. Se o plantão só apaga incêndio sem mudar causa raiz, a operação piora mês após mês. É por isso que contratos de alocação bem desenhados costumam combinar SLAs, postmortem obrigatório e metas de redução de recorrência, algo que conversa diretamente com o template de contrato outcome-based para alocação de equipes.

Transferência de conhecimento não acontece por acaso. Se você não criar rituais, artefatos e critérios de saída, a equipe externa tende a concentrar entendimento na cabeça de poucos profissionais, o que aumenta o risco de lock-in. Para evitar isso, o foco precisa estar em documentação viva, pares mistos, revisão de incidentes e micro-sprints de aprendizado. Um modelo útil é o 30/60/90 dias. Nos primeiros 30 dias, a squad mapeia arquitetura, monitoração, fluxos críticos e incidentes recorrentes. Em 60 dias, ela já deve ter atualizado runbooks, feito treinamento com o time interno e corrigido os alertas mais ruidosos. Em 90 dias, o time interno precisa conseguir executar os principais procedimentos sem depender de uma pessoa específica do fornecedor. Na prática, isso significa exigir artefatos verificáveis. Exemplos: diagrama operacional, catálogo de serviços, matriz de dependências, runbook por jornada crítica, checklist de deploy, playbook de incidentes e registro de pós-mortem com ações concluídas. Para aprofundar o lado de saída e transição, combine este conteúdo com como comprar squads alocados sem risco e com como provar que uma squad alocada deixou seu time interno autônomo. A OrbeSoft costuma insistir nesse ponto porque já viu muitas empresas confundirem presença com autonomia. O time externo estava lá, as reuniões aconteciam, mas o conhecimento não migrava. A pergunta certa não é se o fornecedor “sabe fazer”, e sim se o seu time consegue operar depois que ele sair. Se a resposta for não, a estrutura ainda não está madura.

O primeiro erro é contratar apenas por capacidade de entrega e esquecer responsabilidade operacional. A empresa recebe código, mas continua sem saber quem monitora, quem corrige e quem documenta. Isso costuma aparecer como dependência crônica do CTO, que vira o único ponto de contato para tudo o que é crítico. O segundo erro é definir métricas de vaidade. Número de PRs, horas gastas ou quantidade de alertas fechados dizem pouco sobre confiabilidade. O que interessa é reduzir indisponibilidade, diminuir recorrência de incidentes, melhorar o tempo de restauração e estabilizar jornadas críticas. O terceiro erro é não alinhar o desenho operacional com o contrato, o que torna qualquer cobrança posterior frágil. Também é comum ver runbooks excessivamente genéricos. Documentos do tipo “verifique o ambiente” ou “reinicie o serviço” não ajudam quando o problema é dependência externa, fila parada ou credencial expirada. O runbook precisa ser específico, executável e testado. Se ele nunca foi usado em simulado, trate como hipótese, não como processo. Por fim, muita empresa esquece que a operação muda junto com o produto. Uma estrutura que fazia sentido no MVP pode não servir após crescer em usuários, integrações ou exigências regulatórias. Esse é um bom momento para revisitar arquitetura, priorização e governança, especialmente se você já percebe sinais de escala. Para isso, o material escalar sem quebrar: sinais, checklist e plano técnico para migrar de MVP para produto 1.0 é uma boa leitura complementar.