A fronteira que evita a discussão das três da manhã

Há uma conversa que se repete igual em todas as empresas, sempre de madrugada e sempre com as mesmas frases. «Isso é de infraestrutura». «Não, a infraestrutura está no ar, isso é da aplicação». Enquanto isso, o serviço continua fora do ar e o relógio corre.
Essa discussão não se ganha com argumentos às três da manhã. Ela se evita escrevendo a fronteira antes, quando ninguém está nervoso.
Por que a fronteira sempre fica borrada
Porque a parte interessante do sistema é justamente a que fica no meio. Ninguém discute quem responde pelo hipervisor nem quem escreve o código da aplicação. Discute-se o motor de banco de dados, o certificado que expirou, a tarefa agendada que ninguém lembra de ter criado, a fila que encheu, o serviço que alguém deixou no modo manual.
É a faixa em que o fornecedor de infraestrutura diz «eu entrego a máquina saudável» e a equipe de aplicação diz «eu entrego o código funcionando», e os dois têm razão enquanto o usuário continua sem conseguir faturar.
Uma matriz que funciona de verdade: componente por componente
Nossa divisão é explícita e assinada antes de começar. A plataforma de nuvem e o sistema operacional são nossos: disponibilidade, aplicação de patches, monitoramento, backups e postura de segurança. O motor de banco de dados e a camada de aplicação continuam sendo da equipe do cliente, com uma ressalva que importa: damos apoio técnico sobre o motor, incluído e sem custo adicional, porque se recusar a olhar um banco de dados quando o serviço está fora do ar é uma forma cara de ter razão.
Para que uma matriz funcione, cada linha precisa de quatro coisas, e quase nenhuma as traz:
- O componente, nomeado com precisão. «Banco de dados» não é um componente: componentes são o motor, as instâncias, os backups, o armazenamento e o desempenho das consultas, e eles podem ter responsáveis diferentes.
- Quem opera e quem decide. Executar a mudança não é o mesmo que autorizá-la.
- O que acontece fora do horário. Uma responsabilidade que só vale de segunda a sexta deixa um buraco de dois dias.
- A regra para o imprevisto. Nenhum documento cobre todos os casos; o que se pode definir é quem coordena enquanto a situação se esclarece.
O compromisso que faz a matriz ser cumprida
Escrever a divisão não basta se não houver prazos que a sustentem. Em um incidente crítico, trinta minutos de resposta e quatro horas de resolução, com cobertura sete dias por semana e relatório de andamento a cada hora. E, se um caso não avança, ele escala sozinho: para o coordenador de serviço aos sessenta minutos, para o arquiteto de soluções aos cento e vinte e para a diretoria de operações aos duzentos e quarenta.
Essa última parte é a que dá mais tranquilidade, e não pelo número: pelo que significa. O cliente não precisa empurrar o caso. Não depende de alguém da sua equipe estar acordado insistindo para que o assunto suba de nível.
Como se constrói, na prática
- Inventário real de componentes, extraído do ambiente e não de um documento de três anos atrás.
- Uma revisão conjunta, com a equipe de aplicação do cliente na mesma sala, linha por linha.
- Os casos incômodos primeiro: o certificado, a tarefa agendada, o processo noturno que ninguém reivindica.
- Revisão quando o ambiente mudar, não uma vez por ano por calendário.
Leva meio dia. O incidente em que se descobre que ninguém a escreveu leva bem mais.
Se quiser ver como ficaria essa fronteira no seu caso, escreva para nós e a desenhamos com o seu inventário.
Artigos relacionados
Tema: Microsoft Azure