Pergunte a três pessoas numa call de incidente por onde a requisição que falha passa de verdade, e você normalmente vai ouvir três caminhos diferentes, ou um caminho dito com toda a certeza que está desatualizado há dois anos. A maioria das sessões longas de troubleshooting é longa justamente porque o raciocínio correu na frente do modelo: hipóteses sobre um load balancer que nem está no caminho, capturas num firewall por onde o tráfego nunca passa, logs lidos de um proxy que só atende o outro data center. O hábito de quem tem experiência parece mais lento e é mais rápido: não começar o troubleshooting enquanto o caminho não estiver escrito, hop a hop (cada equipamento por onde o tráfego passa), com as incertezas marcadas como incertezas.
A resolução de nomes faz parte do caminho
O caminho não começa no primeiro roteador; começa no nome. Qual resolver responde, qual view ele entrega, se um arquivo hosts passa por cima dele, se o service discovery está atualizado: cada uma dessas coisas decide para onde os pacotes vão antes mesmo de o primeiro ser enviado. Ambientes com split-horizon falham de um jeito que parece exatamente falha de rede: metade dos clientes chega ao endereço interno, a outra metade vai atrás do público, e o padrão do sintoma segue os grupos de clientes de cada resolver, e não algo no transporte. Um modelo que pula a resolução de nomes pulou justamente o hop que mais vezes explica o "funciona para uns, não para outros".
A volta é um caminho à parte
Pensar no caminho de ida é natural; é no caminho de volta que os modelos erram sem ninguém perceber. Equipamentos stateful, que guardam o estado de cada conexão, como firewalls, load balancers e gateways (network address translation), partem do princípio de que veem os dois sentidos da conversa, e um retorno assimétrico quebra esses equipamentos em silêncio: a ida chega ao destino, a resposta desvia do equipamento stateful, e ele derruba a sessão como tráfego desconhecido. O policy routing e as múltiplas saídas fazem da volta uma decisão que o modelo da ida nunca enxerga. Escrever o caminho de volta separadamente, e marcá-lo como desconhecido quando ele é desconhecido, transforma toda uma classe de falhas misteriosas num suspeito com nome, que dá para testar.
Reescritas e terminações mudam o sentido da evidência
Cada hop de NAT, de (source NAT, o NAT de origem) e de proxy muda o que um endereço significa, e cada terminação TLS muda o que dá para ver. Depois de uma reescrita de origem, os logs do backend registram fielmente o cliente errado; depois de um proxy, a conversa com o upstream (o lado dos servidores) é outra sessão, que só tem em comum com a do cliente a intenção; a cada terminação TLS, começa uma nova história de certificado e a anterior termina. Isso não é detalhe de implementação: são as fronteiras que definem onde a evidência precisa ser coletada e como ela deve ser interpretada. Um modelo de caminho que marca essas fronteiras transforma "os logs dizem X" numa pergunta mais precisa: de que lado de qual fronteira veio esse X, e sobre quem ele fala?
O que você não sabe também vai no mapa
A coisa mais valiosa que um modelo de caminho pode fazer é admitir o que ele não contém. Um inventário de middleboxes (equipamentos no meio do caminho) que ninguém conhece, uma ordem de equipamentos que ninguém verificou, uma rota de volta que ninguém confirmou: escritos no mapa, viram os primeiros itens de trabalho; deixados de fora, viram as suposições que invalidam, em silêncio, todas as conclusões tiradas em cima delas. Um modelo proposto com os desconhecidos à vista é um plano. Um diagrama cheio de certeza, com os desconhecidos escondidos, é uma armadilha que ainda não disparou.