Sprint de recuperação pós-incidente: quando contratar uma squad alocada e como restaurar a produção sem perder governança

Contratar uma squad alocada para recuperação pós-incidente pode ser a forma mais rápida de restaurar a produção, mas não deve ser uma reação impulsiva. Depois de uma indisponibilidade, falha de integração ou degradação severa de desempenho, a empresa precisa equilibrar três urgências: reduzir o impacto aos usuários, preservar evidências e evitar que um hotfix mal testado crie outro problema.

O primeiro objetivo é estabilizar o serviço, não encontrar um culpado. O segundo é entender se a equipe interna tem disponibilidade, senioridade e contexto suficientes para conduzir a resposta sem abandonar clientes, roadmap e controles de segurança.

Uma empresa com 50 engenheiros pode continuar sem capacidade real para um incidente crítico. Se todo o time está dividido entre suporte, manutenção e entregas comerciais, adicionar a crise à mesma fila apenas aumenta o tempo de recuperação. A decisão deve considerar capacidade efetiva, e não headcount.

Práticas de resposta a incidentes recomendam separar contenção, erradicação e recuperação. O guia do NIST sobre tratamento de incidentes é uma referência útil para estruturar responsabilidades, evidências e comunicação durante a resposta.

Uma squad externa faz sentido quando entrega uma capacidade que está faltando, como arquitetura, SRE, segurança, engenharia de dados ou conhecimento em uma integração crítica. Ela não substitui o comando do CTO nem deve receber acesso irrestrito antes de existir uma regra clara de autorização, registro e revisão.

O erro mais caro é começar alterando o sistema antes de delimitar o incidente. Antes de qualquer hotfix, registre a linha do tempo, o primeiro sinal observado, as mudanças recentes, os serviços afetados, os usuários impactados e o que já foi tentado. Esse material forma a base do diagnóstico e evita repetir ações que falharam.

Nas primeiras 48 horas, a squad deve produzir um mapa mínimo da arquitetura. Ele precisa mostrar fluxo de requisições, dependências externas, filas, bancos, pontos de autenticação, rotinas agendadas, mecanismos de cache e caminhos de deploy. O objetivo não é documentar tudo, mas identificar onde uma alteração pode ampliar o raio de impacto.

O segundo artefato é uma matriz de hipóteses. Para cada hipótese, registre evidência favorável, evidência contrária, teste possível, risco do teste e responsável. Um exemplo: aumento de latência no banco pode ser investigado com análise de consultas, saturação de conexões e comparação entre períodos, sem reiniciar componentes em produção de forma indiscriminada.

Também é necessário preservar evidências antes de limpar filas, apagar logs ou reverter ambientes. A documentação do Google sobre resposta a incidentes reforça a importância de papéis definidos, comunicação operacional e aprendizado posterior, em vez de tratar o incidente como uma sequência improvisada de comandos.

Ao final do discovery, a liderança deve receber uma decisão explícita: aplicar contenção imediata, fazer rollback, desativar uma funcionalidade, migrar tráfego, corrigir a causa provável ou manter o serviço parcialmente limitado. Cada opção precisa indicar risco, prazo, critério de sucesso e plano de reversão.

A OrbeSoft aplica essa etapa antes de propor a execução completa. A lógica é simples: uma squad que aceita qualquer hotfix sem questionar o diagnóstico pode ser rápida para alterar código e lenta para resolver o problema real.

Um contrato emergencial não deve ser apenas uma autorização para trabalhar por hora. Ele precisa delimitar o escopo da resposta, os níveis de acesso, os responsáveis por aprovação, as condições de encerramento e os artefatos que comprovam o trabalho realizado. Isso protege a empresa e também evita que a squad opere sem direção.

Comece definindo o resultado esperado em duas camadas. A primeira é o resultado operacional, como restaurar o fluxo de login, reduzir erros de API ou recuperar uma fila de processamento. A segunda é o resultado de estabilização, como eliminar a causa raiz provável, criar alertas acionáveis e validar um procedimento de reversão.

SLIs são indicadores medidos, como percentual de requisições bem-sucedidas, p95 de latência ou tempo de processamento de uma fila. SLOs são as metas para esses indicadores, por exemplo manter 99,9% das requisições críticas bem-sucedidas durante a janela de observação. Não confunda SLO com promessa absoluta de disponibilidade.

Inclua no contrato uma tabela com SLI, fonte de dados, linha de base, meta temporária, responsável e frequência de medição. Para um SaaS B2B, a tabela pode separar operações de autenticação, faturamento, consulta de dados e integrações externas, pois uma média geral pode esconder uma falha grave em um fluxo específico.

Os entregáveis mínimos devem incluir linha do tempo do incidente, mapa de arquitetura afetada, matriz de hipóteses, registro de mudanças, análise de causa, plano de correção, testes executados, runbook, recomendações de observabilidade e relatório executivo. Se houver dados sensíveis, o contrato também deve estabelecer princípio do menor privilégio, rastreabilidade de acesso e descarte ou devolução de cópias.

Para empresas que precisam justificar despesas a investidores, auditorias ou programas de fomento, cada entrega deve ter data, autor, evidência e aceite. O guia de governança técnica para projetos com FAPESC, FINEP e BNDES ajuda a conectar execução técnica, prestação de contas e velocidade de produto.

O formato outcome-based pode funcionar quando o resultado é mensurável e a dependência da contratante está bem definida. Se a causa ainda é desconhecida, combine uma fase curta de diagnóstico com critérios de aceite, em vez de prometer uma correção fechada antes de conhecer o problema. O modelo de contrato outcome-based para alocação de equipes pode servir como base de negociação.

A recuperação não termina quando o painel fica verde. Um hotfix pode restaurar o serviço e continuar escondendo dívida técnica, ausência de testes ou um processo de deploy que ninguém consegue repetir. Por isso, cada mudança emergencial deve gerar uma decisão sobre permanência: manter, refatorar, substituir ou remover.

O runbook precisa ser operacional, não um documento genérico. Ele deve informar sinais de alerta, consultas úteis, pré-condições, comandos autorizados, sequência de diagnóstico, limites de intervenção, contatos, critérios de escalonamento e passos de reversão. Uma pessoa que não participou do incidente deve conseguir executar um cenário controlado usando o material.

A transferência de conhecimento funciona melhor em sessões curtas e baseadas em evidências. Peça à squad externa que explique o fluxo em um diagrama, conduza uma simulação de falha e acompanhe um engenheiro interno executando o procedimento. Registre dúvidas e transforme as lacunas em tarefas com prazo.

Mantenha o código, os painéis, os repositórios e as decisões na infraestrutura da contratante. A equipe alocada pode contribuir com branches e revisões, mas a propriedade técnica não deve depender de contas pessoais, documentos privados ou conhecimento concentrado em uma única pessoa.

Uma governança saudável também reduz a tensão entre CEO e CTO. O CEO precisa de previsibilidade para clientes, caixa e mercado; o CTO precisa evitar que a pressão por velocidade crie uma nova crise. O guia de governança prática para equipes alocadas oferece referências para rituais, indicadores e relatórios sem transformar a operação em burocracia.

Na prática da OrbeSoft, a saída é planejada desde o primeiro dia. A squad entra com uma missão delimitada, deixa artefatos auditáveis e trabalha para que o time interno consiga operar e evoluir o sistema com menos dependência externa.