Resiliência operacional sem o discurso de RH
A gente costuma confundir resiliência com "aguentar firme". Na prática, o que funciona em uma organização moderna a resiliência e a inovação são dois mecanismos separados que precisam ser alimentados por estruturas diferentes. Resiliência é a capacidade de sistema de continuar entregando valor quando algo quebra. Inovação é a capacidade de gerar algo novo que o negócio adota. Se você trata os dois como a mesma coisa, pelo menos um vai falhar, e geralmente é a inovação.
Como montar isso sem virar burocracia
Eu comecei a trabalhar com isso há cerca de sete anos em uma empresa de fintech que tinha um problema específico: lançamento de feature nova travava toda semana porque o time de produto não sabia até que ponto a infraestrutura aguentava. A equipe de SRE nos cobrava, o time de produto cobrava o outro lado, e o resultado era um ciclo de quatro semanas para qualquer mudança que tocasse produção. A solução que funcionou foi simples e sem glamour. Criamos um pipeline de deploy que exigia três gates: primeiro, o teste de caos controlado rodando automaticamente no staging; segundo, a análise de impacto com métricas de SLI (Service Level Indicator) definidas antes do deploy; terceiro, um rollback automatizado que era testado semanalmente, não apenas documentado. A parte que ninguém conta é que o rollback automatizado precisou ser refatorado duas vezes porque a primeira versão só funcionava se o banco estivesse em um estado específico que nem sempre acontecia.
O passo a passo real que aplicamos foi o seguinte: Passo 1 — Definir os SLIs de cada serviço crítico. Isso não é sobre uptime genérico. É sobre latência p99, taxa de erro por endpoint, e tempo de recuperação. Se você não tem métrica operacional, não tem como dizer se algo quebrou ou não.
Passo 2 — Separar as squads de resiliência e inovação. Uma squad focada em estabilidade opera com cadência diferente da squad de produto. Misturar as duas num único scrum time é um dos erros mais comuns que eu vejo. O time de resiliência precisa de sprint dedicado para testes de caos, revisão de runbooks e automação de recovery. O time de inovação precisa de espaço para experimentação sem o peso da operação diária. Passo 3 — Criar um fundo de inovação com orçamento trancado. Eu vi várias empresas tentarem inovar com o orçamento operacional e nunca darem certo. Criei um fundo separado, cerca de 15% do investimento tecnológico anual, que não precisava de aprovação para projetos pilotos de até oito semanas. O dinheiro vinha da reserva de contingência, não do orçamento operacional.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Passo 4 — Implementar feature flags como padrão obrigatório. Qualquer feature nova vai atrás de uma flag. Isso permite que inovação avance no código, mas só chegue ao usuário quando os indicadores de resiliência estiverem OK. Isso também resolve o problema de rollback: você desliga a flag em segundos, não precisa de deploy reverso. Passo 5 — Rodar jogos de guerra trimestrais. Simulação de falha real, sem aviso prévio, em horário comercial. A equipe de resiliência provoca a falha. A equipe de resposta reage. O que funciona é documentado. O que falha vira backlog de melhoria. Isso parece óbvio, mas menos de 30% das empresas que eu consultei fazia isso de forma consistente.
O que ninguém avisa sobre inovação em escala
Existem duas armadilhas que começam parecendo vantagens. A primeira é a mentalidade de "innovate or die" aplicada de forma genérica. Isso gera projetos piloto que nunca saem do laboratório porque não há processo de handoff para produção. A segunda é achar que resiliência é um projeto com data de fim. Ela não termina. É um estado contínuo que precisa de manutenção constante, e o custo disso é subestimado em quase todos os planos que eu vejo. Um insight contra-intuitivo que aprendi na prática: quanto mais resiliente um sistema fica, mais ele precisa de inovação para não se tornar obsoleto. Sistemas muito estáveis tendem a acumular dívida técnica porque ninguém toca neles. A resiliência precisa de um mecanismo que force renovação periódica. Implementamos um processo de "chaos scheduling" onde, a cada trimestre, uma parte do sistema é forçada a passar por um ciclo de refatoração sob pressão de teste de caos.
O limite mais importante que encontrei: essa abordagem não funciona bem em times menores que cinco pessoas. A separação de funções exige escala mínima. Se você tem uma startup de cinco pessoas, o custo de separar resiliência de inovação pode matar o negócio. Nesse caso, o modelo recomendado é ter um único responsável por ambas as áreas, com processos simplificados e tooling automatizado que reduza a carga operacional. Não tente replicar o modelo enterprise em equipe pequena. Outro detalhe prático que faz diferença: a métrica de sucesso da inovação não pode ser o número de features lançadas. Isso mede atividade, não impacto. A métrica correta é o tempo entre a ideia validada e o deploy em produção com adoção medível. No nosso caso, esse tempo caiu de 4,2 semanas para 11 dias depois de implementarmos os quatro primeiros passos. A resiliência, medida pelo MTTR (Mean Time To Recovery), caiu de 47 minutos para 8 minutos no mesmo período.
A parte que dóiar: esse modelo depende de maturidade técnica da equipe. Se o time não domina automação de deploy, monitoramento e observabilidade, a complexidade do sistema aumenta sem a capacidade de sustentá-lo. Nesse cenário, o conselho é investir primeiro em fundação de engenharia antes de tentar implementar qualquer framework de inovação. Ferramentas como Kubernetes, Terraform e um bom sistema de logging Centralizado são pré-requisitos, não extras. Se você quer um recurso concreto para começar, o framework de resiliência baseado em SRE da Google está disponível gratuitamente e é um bom ponto de partida. O material original pode ser encontrado no site oficial do Google Cloud. Para inovação, o modelo de "dual operating system" proposto por John Kotter é mais útil do que qualquer framework de agilidade genérico.
O problema real que eu vejo hoje é que muitas empresas tentam copiar a estrutura sem adaptar ao tamanho e contexto. O resultado é uma camada extra de processos que desacelera tudo sem melhorar a resiliência de fato. O caminho mais direto é começar pelo passo 1, medir, ajustar e só então avançar para os próximos. Sem métricas, não há como saber se está funcionando.
