Ideia principal

O banco da folha de pagamento agora vive no ambiente Azure do cliente. Uma manhã, a aplicação para de responder. É o motor do fornecedor, o SQL Server do cliente, uma regra de rede alterada na véspera, um certificado, uma configuração de IAM, uma saturação de conexões, uma cota, uma latência?

Responder "o banco está com o cliente, o problema não é nosso" não funciona. Para o usuário que não consegue fechar a folha, é o serviço do fornecedor que está fora do ar.

O contrato deslocou uma responsabilidade; a percepção continua onde estava.

Por que isso importa

Isso impõe uma obrigação que não vem do contrato, e sim da situação: supervisionar o recurso externalizado e a conectividade dele o suficiente para entender de onde vem um incidente. Não administrar a infraestrutura do cliente, mas ter os sinais — disponibilidade, latência, erros de conexão, saturação, estado de saúde.

É um custo que o arranjo não mostra no momento em que você o negocia, e que depois nunca desaparece.

Nuances e limites

A supervisão não torna o fornecedor capaz de agir: ver a pane e conseguir consertá-la são duas coisas.

E a obrigação tem um limite: além de certo ponto, supervisionar todo o ambiente do cliente equivale a operá-lo, que era justamente o que a divisão deveria evitar.

Questões em aberto

• Que nível de supervisão basta para diagnosticar sem invadir a operação do cliente?