A transferência operacional é o momento em que uma solução desenvolvida in loco deixa de ser algo que o Engenheiro de Campo (FDE) opera por instinto e passa a ser algo que a equipe do cliente opera de forma consciente e planejada. A transferência operacional significa que o cliente consegue operar o sistema no dia a dia, depurá-lo quando falha e realizar alterações seguras sem a sua presença.
Considere a seguinte situação: você desenvolveu um serviço interno de triagem de sinistros assistido por IA para a HarborView Insurance, executado no Kubernetes com banco de dados PostgreSQL, cache Redis e chamadas de modelo protegidas por um gateway interno. O projeto piloto foi bem-sucedido, a liderança quer que você coloque a solução em produção e sua saída do local está prevista para ocorrer em três semanas.
Nessa etapa final, a questão principal não é se o sistema funciona hoje. A questão é se a HarborView consegue mantê-lo em funcionamento durante um incidente numa noite de terça-feira e se consegue modificá-lo no próximo trimestre sem criar acidentalmente uma falha de segurança ou um problema de confiabilidade.
Uma transferência geralmente falha porque as partes atribuem significados diferentes à palavra “concluído”. Para você, isso pode significar que o backlog foi zerado e os dashboards indicam status positivo (verde). Para o cliente, pode significar que eles conseguem realizar deploys sem precisar acioná-lo, e que a equipe de segurança aprovou os controles de acesso e registro de logs.
Defina “concluído” como um conjunto de critérios de sucesso que abranjam confiabilidade, segurança e a responsabilidade pela entrega. O objetivo não é garantir a ausência total de incidentes, mas sim assegurar que, quando um incidente ocorrer, o cliente seja capaz de detectá-lo, diagnosticá-lo e recuperar o sistema sem depender do seu conhecimento interno exclusivo.
Explore uma maneira simples de avaliar se a transferência foi realmente concluída.
O princípio a ser adotado é que cada critério de sucesso precisa de um responsável e de uma evidência concreta. Uma evidência é algo que você pode apontar, como um link para um runbook, uma solicitação de acesso concluída, uma entrada na escala de plantão ou um deploy bem-sucedido realizado pela equipe do cliente enquanto você observa.
Evidências valem mais que promessas Se um requisito de transferência de responsabilidade não puder ser verificado em uma análise rápida, ele ainda não é um requisito.
Quando a transferência de responsabilidade é falha, a primeira interrupção do serviço gera um segundo problema. A interrupção é técnica, mas o segundo problema é a confusão sobre quem é o responsável, o que prolonga a falha e inicia um ciclo de atribuição de culpa.
Imagine que o HarborView receba um alerta informando que a latência p95 dobrou e que as requisições estão excedendo o tempo limite (timeout). O engenheiro de plantão abre o painel e vê dez alertas ruidosos disparando simultaneamente. Ele não sabe qual alerta é relevante, não tem permissão para reiniciar o deploy no Kubernetes em produção e não encontra um runbook que descreva o comportamento “normal” do gateway do modelo.
Ele entra em contato com você, você responde com três informações que obteve durante a fase de desenvolvimento, e o sistema volta a funcionar. Duas semanas depois, o problema se repete, mas desta vez você está em um voo, e a interrupção dura três horas a mais. A causa raiz pode ser um cache stampede (sobrecarga repentina no cache) ou um pool de conexões de banco de dados mal dimensionado, mas a longa duração do incidente deveu-se à ausência de fundamentos operacionais, e não ao bug em si.
Veja como a falta de elementos essenciais na transferência de responsabilidade transforma incidentes simples em problemas prolongados e confusão sobre as responsabilidades.