Camada a camada: percorrer a pilha sem pular

Para que o modelo serve, de fato

Todo mundo que fez uma prova de redes sabe recitar as camadas. Bem menos gente sabe dizer para que o modelo serve durante um incidente, e a resposta é mais estreita e mais útil do que a versão da prova.

Ele não é uma descrição de como os dados se movem fisicamente. É uma ordem de busca com a qual dois estranhos conseguem concordar. Quando você diz que o problema está abaixo da camada três, um engenheiro que você nunca viu — num fabricante, numa operadora, às três da manhã — sabe o que você descartou e o que não. Esse vocabulário comum vale mais durante um escalonamento do que qualquer propriedade técnica do modelo.

Ou seja, o modelo se paga como disciplina para cobrir terreno numa sequência acordada, e é assim que deve ser usado: não porque os pacotes o respeitam, mas porque as pessoas respeitam.

A pergunta anterior a "qual camada"

Aqui está o que a versão de prova deixa de fora, e é a correção mais útil disponível para quem já conhece o modelo.

Pergunte qual pilha antes de perguntar qual camada.

Um caminho moderno quase nunca tem uma pilha só. Um usuário em uma rede privada virtual tem uma pilha interna correndo dentro de uma externa. Um túnel entre sites significa o mesmo. Um proxy ou balanceador termina uma conexão e origina outra, então o fluxo do lado cliente e o do lado servidor são duas conversas diferentes que por acaso são vizinhas dentro de um equipamento. Transporte criptografado embrulha uma sessão dentro de outra. Contêineres acrescentam uma camada dois virtual que só existe dentro de um host.

Então, quando alguém diz que a falha está na camada quatro, a pergunta imediata é: camada quatro de qual conversa? Cliente para proxy, ou proxy para servidor? Dentro do túnel ou fora dele? São objetos diferentes, com tamanhos máximos de segmento diferentes, comportamentos de reset diferentes, temporizadores diferentes, e falham de formas diferentes.

Errar isso é como uma tarde desaparece. A captura está limpa, os contadores estão saudáveis, tudo na camada quatro parece correto — e você estava olhando a pilha externa enquanto a falha estava dentro do túnel.

De baixo para cima, de cima para baixo, ou pelo meio

Três abordagens, cada uma correta em circunstâncias diferentes, e a escolha é julgamento, não regra.

De baixo para cima — começar na camada física e subir. Correto quando algo foi tocado fisicamente: uma instalação nova, uma mudança de lugar, uma janela de manutenção, qualquer coisa em que uma mão esteve perto do equipamento. Também correto quando vários serviços sem relação entre si falham juntos, o que costuma indicar algo compartilhado e baixo.

De cima para baixo — começar na aplicação e descer. Correto quando uma aplicação se comporta mal e todo o resto no mesmo caminho vai bem. Se o e-mail do usuário funciona e o compartilhamento de arquivos funciona e só aquela aplicação está quebrada, a camada física já respondeu a pergunta para você, e percorrê-la é teatro.

Pelo meio — começar na camada três e ir para onde a resposta apontar. É o que gente experiente de fato faz, e não é preguiça. A camada três é onde há mais informação disponível a baixo custo: resolve, alcança, o caminho é o esperado. Um único traceroute frequentemente elimina quatro camadas numa direção, e aí você está bissectando em vez de subindo.

A instrução de sempre começar por baixo é bom conselho para quem ainda não sabe escolher, e é um hábito que vale superar de propósito, e não por acidente.

A regra sobre pular não é a regra que as pessoas repetem

Todo mundo diz para nunca pular uma camada. Todo mundo pula camadas, inclusive quem diz isso, porque verificar um cabo que quinhentos usuários funcionando compartilham não é diligência, é ritual.

A regra de verdade é mais estreita e vale enunciar com cuidado:

Você pode pular uma camada. Você não pode esquecer que pulou.

O modo de falha não é o pulo. É o momento, duas horas depois, em que você está convencido de que o problema é da aplicação porque esgotou todo o resto — exceto que você nunca verificou o caminho físico, você assumiu, e a suposição virou silenciosamente um achado na sua cabeça.

Manter uma lista escrita do que foi verificado contra o que foi assumido custa quase nada e é a diferença entre uma busca que converge e uma que dá voltas. Suposições são aceitáveis. Suposições não rotuladas não são.

A camada da falha não é a camada do sintoma

É aqui que mora a maior parte dos diagnósticos errados, e merece ser dito com todas as letras.

Resolução de nomes lenta se apresenta como aplicação lenta. Todo nome acaba resolvendo, então a verificação passa e alguém escreve que a resolução está boa — enquanto cada carregamento de página paga dois segundos extras lá na frente.

Uma incompatibilidade de unidade máxima de transmissão se apresenta como uma aplicação que funciona para requisições pequenas e trava nas grandes, o que parece exatamente um defeito de aplicação e não é.

Um certificado expirado se apresenta como página de erro da aplicação, e metade dos relatos vai dizer que a aplicação caiu.

Dois por cento de perda de pacotes se apresenta como banco de dados lento, porque as retransmissões são invisíveis para todos, menos para quem está olhando os contadores certos.

Nos quatro casos o sintoma está em cima, a falha está embaixo, e o caminho mais rápido para a resposta é desconfiar da camada em que a reclamação chegou. A reclamação diz onde alguém percebeu. Não diz onde a falha está, e tratar as duas como a mesma coisa é a razão mais comum de uma falha sobreviver ao primeiro dia.

As camadas que não estão no modelo

Os profissionais brincam com a camada oito, e a piada carrega peso.

Falhas que parecem técnicas e não são: uma licença que expirou, uma fatura que não foi paga e o serviço foi suspenso, uma regra de firewall que a segurança removeu de propósito sem avisar ninguém, uma conta desativada por um processo de desligamento, uma mudança congelada porque é fechamento de trimestre.

Isso não é exótico. Ao longo de trinta anos é uma parcela substancial do total, e o sinal costuma ser que a evidência técnica está limpa demais — tudo configurado corretamente, tudo no ar, e a coisa continua sem funcionar. Quando a pilha parece perfeita, pare de subir e vá perguntar quem mudou o quê, quem foi cobrado, e quem tem autoridade sobre a coisa que parou.

E a limitação honesta

O modelo não encaixa muito bem na infraestrutura moderna, e fingir o contrário gera discussão em vez de solução.

Criptografia não fica em uma camada, ela embrulha várias. Um balanceador que inspeciona conteúdo de aplicação enquanto toma decisões de transporte opera em duas camadas ao mesmo tempo por projeto. Infraestrutura em nuvem esconde as camadas um a três por inteiro, e nenhuma insistência no modelo vai lhe dar acesso a elas.

Nada disso torna o modelo inútil. Torna-o um vocabulário compartilhado, e não um mapa do território — e vocabulário compartilhado é exatamente do que você precisa no ponto em que terá de entregar o problema a alguém que não estava lá, que é o assunto da próxima parte.