Matriz de responsabilidades em observabilidade e automação: o que exigir do fornecedor em produção

RACI é uma forma simples de evitar a frase perigosa “isso não estava no escopo”. R significa responsável pela execução, A significa autoridade final ou aprovador, C representa quem deve ser consultado e I identifica quem precisa receber informação sobre o andamento ou o incidente.

Para funcionar, a matriz deve nomear papéis, não apenas departamentos. “TI” é amplo demais. Prefira funções como líder de operações do cliente, responsável pelo processo de negócio, engenheiro do fornecedor, administrador de infraestrutura e gestor do contrato.

Também é recomendável criar uma linha para cada atividade relevante. “Monitorar a automação” é genérico; “verificar falhas de execução a cada cinco minutos”, “classificar incidentes críticos em até 15 minutos” e “executar rollback aprovado” são atividades que podem ser auditadas.

A matriz RACI organiza papéis, mas precisa estar conectada ao contrato, ao SOW ou ao documento de escopo. Sem essa conexão, ela pode ser tratada como uma recomendação operacional sem força para definir aceite, prazo de atendimento ou consequência por descumprimento.

A primeira cláusula deve definir o objeto operacional. Em vez de contratar “monitoramento da automação”, descreva quais ambientes, fluxos, servidores, APIs, filas, credenciais técnicas e janelas de atendimento estão incluídos. Liste também o que fica fora do escopo, como alterações em sistemas de terceiros sem acesso autorizado.

Uma redação prática pode ser: “O fornecedor será responsável por configurar, manter e revisar os mecanismos de detecção previstos no anexo técnico, incluindo métricas, logs estruturados, alertas e procedimentos de triagem dos componentes listados no inventário de produção”. O anexo deve conter a lista exata dos componentes.

A cláusula de incidentes precisa diferenciar tempo de detecção, tempo de reconhecimento, tempo de resposta e tempo de recuperação. Esses relógios medem coisas diferentes. Um fornecedor pode reconhecer um alerta em dez minutos, mas levar duas horas para recuperar o fluxo, e ambos os prazos devem ser tratados de maneira transparente.

Para integrações, inclua uma regra de responsabilidade compartilhada. O fornecedor responde pela detecção de erros de autenticação, mudança de contrato, aumento de rejeições e duplicidade identificável; o cliente responde por fornecer credenciais válidas, aprovar mudanças de negócio e manter contatos autorizados atualizados.

Mudanças de API merecem uma cláusula própria. Ela deve estabelecer como notificações de terceiros serão recebidas, quem avalia o impacto, quando uma alteração precisa de homologação e qual é o procedimento para congelar ou reverter uma implantação. O guia sobre testes de contratos e mudanças de API em produção detalha práticas que podem ser incorporadas ao anexo técnico.

Para incidentes graves, adote uma obrigação de análise pós-incidente com prazo, conteúdo mínimo e tratamento das ações corretivas. A orientação do NIST sobre tratamento de incidentes de segurança reforça a necessidade de preparar, detectar, analisar, conter, erradicar, recuperar e registrar aprendizados, uma lógica útil também para falhas operacionais não relacionadas à segurança.

Por fim, trate evidências como entregáveis de aceitação. O contrato pode estabelecer que uma etapa só será considerada concluída quando o fornecedor apresentar painel, amostras de logs, teste de alerta, runbook, histórico de aprovação e comprovação de recuperação. Isso reduz disputas porque substitui opiniões por artefatos verificáveis.

A Trait estrutura projetos com diagnóstico, implementação ponta a ponta e suporte contínuo. A observabilidade é desenhada junto com a automação, não adicionada depois que o fluxo já falhou em produção.

Em uma operação de e-commerce, um fluxo de atualização de pedidos dependia de uma API externa e de um servidor que também executava rotinas administrativas. A responsabilidade foi dividida entre detecção da fila acumulada, correção técnica, aprovação de reprocessamento e comunicação sobre pedidos afetados.

O aceite exigiu um painel do Metabase com volume processado, falhas por tipo, idade dos itens pendentes e taxa de reprocessamento. Os logs estruturados permitiram separar erro de autenticação, indisponibilidade temporária e dado inválido, evitando que toda falha recebesse o mesmo tratamento.

Em um caso anonimizado de SaaS, uma mudança no formato de resposta de uma API fez a automação concluir algumas chamadas sem registrar o resultado esperado. O fornecedor ficou responsável por detectar a divergência e interromper o processamento seguro; o cliente aprovou a regra de negócio para tratar os registros afetados.

O runbook no Trello registrou o procedimento de contenção, os contatos, o critério de escalonamento e a evidência necessária para reabrir o fluxo. A divisão evitou que a equipe comercial tentasse corrigir uma falha técnica manualmente, ao mesmo tempo em que preservou a decisão do cliente sobre comunicação aos usuários.

Esses exemplos mostram por que um painel isolado não comprova maturidade. A prova nasce da combinação entre sinal, alerta, responsável, ação, registro e critério de encerramento. O modelo de trilha de auditoria automatizada com n8n, Metabase e Trello pode ajudar a organizar essa cadeia de evidências.

A Trait recomenda que cada marco tenha um pacote de evidências com identificação do ambiente, data, versão da configuração e responsável pelo aceite. Quando possível, a geração é automatizada para reduzir registros manuais e preservar o histórico de alterações.