Quando a integração muda por baixo de você

A falha que não se anuncia

Uma automação que para é um problema pequeno. Ela para, alguém percebe em uma hora, a causa é óbvia porque a última coisa mexida é a que quebrou.

A falha cara é a que continua rodando. Renomeiam um campo lá em cima, o código que o lê recebe nada, e nada é um valor legal em quase todo processo: uma observação vazia, um sinalizador não marcado, uma segunda linha de endereço ausente. Nada é levantado. O workflow produz registros indistinguíveis dos da semana passada, e faz isso pelo tempo que alguém levar para comparar dois números na mão.

O que muda de verdade

Quase tudo se resume a quatro formas.

Renomeiam ou movem um campo, normalmente dentro de uma arrumação que ninguém considerou externa. A resposta ganha um nível de aninhamento quando um fornecedor acrescenta um invólucro para paginação ou metadados. Uma lista de valores ganha um novo - um status de pedido, um tipo de documento - e o ramo que trata os valores conhecidos derruba o desconhecido sem dizer nada. Uma versão da API se aposenta, e o plano B acaba sendo um formato antigo em vez de um erro.

Nada disso é uma queda. Tudo isso é uma terça-feira à tarde nas notas de versão de outra empresa.

Três defesas, todas baratas

Um registro, caminho inteiro, toda manhã. Um objeto sintético que percorre tudo e é conferido no fim contra uma resposta conhecida. Ele exercita as junções entre sistemas, e a deriva mora nas junções. Quatro serviços saudáveis separadamente podem estar passando entre si algo que mudou.

Conferir a forma, não o status. Um duzentos com corpo legível não prova que o corpo signifique o que significava mês passado. Confira que os campos que você lê estão lá e no tipo esperado, e falhe alto quando não estiverem. São dez linhas, e elas transformam uma resposta silenciosamente errada numa parada visível.

Alertar por distribuição, não por exceção. Se mês passado ia para a via manual um item em vinte e hoje vai um em seis, o sinal é esse, e nenhuma exceção foi levantada para produzi-lo. Isso só funciona se os números normais foram escritos antes, que é o argumento defendido por uma linha de base medida.

Por que isto é uma questão de escopo e não de manutenção

Toda integração é uma dependência do calendário de versões de outra empresa. Isso não a torna uma má ideia: a entrega do caso de aluguel em para onde vão as quatro horas lê a disponibilidade de um sistema que não controlamos e ainda assim se paga. Isso a torna algo a precificar.

A versão prática: quando o escopo de um workflow é acertado, liste o que ele lê fora de si mesmo e, para cada item, diga o que acontece se a forma mudar. Na maioria a resposta será «para, e tudo bem». Aquelas em que a resposta é «segue, e a gente não saberia» precisam de um canário antes de subir, não depois do primeiro mês ruim.

A parte que ninguém quer nomear

Um workflow por quem nenhuma pessoa responde é conferido por quem passar, e na prática é conferido pelo cliente com a reclamação dele. O nome vai no documento de passagem com todo o resto, e pertence a alguém com opinião sobre o desenho, não a quem estava livre naquela semana. O argumento para tratar isso como etapa e não como uma tarde está em o que uma auditoria de processos precisa produzir, e não dá para acrescentar depois: quem já esqueceu o que era confuso não consegue escrever.