Escreva um briefing de design de VPN que alguém possa realmente revisar

A maioria das revisões de design para na primeira pergunta, porque o pedido descreve um produto e não uma decisão. Um briefing que nomeia os fluxos, os responsáveis e o comportamento em caso de falha pode ser resolvido numa reunião. Um briefing que diz construam uma VPN segura não pode ser resolvido de modo algum. Passe pelas seis verificações abaixo antes de enviar qualquer coisa, e a revisão torna-se uma comparação em vez de um debate.

Primeiro, a pergunta é uma decisão ou um desejo

Uma decisão tem alternativas e uma observação que escolheria entre elas. Se não consegue nomear o que olharia para escolher uma, a pergunta ainda é um desejo. Escreva primeiro as alternativas, mesmo que a lista tenha apenas dois itens. Depois escreva o compromisso que as separa.

Um desejo também tende a esconder o público. Diga quem tem de aprovar o design, porque o mesmo briefing é lido de forma diferente por um responsável de rede, um revisor de segurança e um aprovador financeiro.

Pare aqui se a resposta for ninguém, porque uma decisão sem dono será refeita por quem se queixar mais alto. Isso é um problema de governança e não um problema de design.

Segundo, nomeie os fluxos e as recusas

Liste a origem, o destino e a aplicação de cada fluxo que tem de funcionar. Depois liste os fluxos que têm de continuar a falhar, porque um design que os permite em silêncio mudou o requisito sem o dizer. A sobreposição de endereços e o alcance a montante pertencem a esta lista como restrições e não como surpresas.

Seja específico quanto à direção. Um local que pode iniciar ligações para a sede é um design diferente de um que as pode aceitar, e a diferença nota-se em cada regra que escrever depois.

Anote também os clientes e o seu estado de gestão, porque um dispositivo gerido com um agente pode fazer coisas que um portátil trazido pelo utilizador não pode.

Mantenha a lista curta o suficiente para ser testada. Dez fluxos que pode verificar valem mais do que quarenta que não pode.

Verificação 3: separe os factos das suposições

Marque cada afirmação que verificou e marque as que não verificou. O endereçamento público, o débito disponível e o acesso de administrador são as três suposições que mais vezes mudam a resposta. Se uma delas for desconhecida, diga como o design muda quando se revelar em qualquer dos sentidos.

Uma rede ilustrativa é aceitável desde que esteja identificada. O problema é uma sucursal hipotética que adquire em silêncio um segundo acesso a montante ou um bloco de endereços públicos que nunca teve.

Verifique a suposição que consegue confirmar antes da revisão, porque um único facto medido elimina um ramo inteiro de discussão.

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

Quarto, escreva o contrato de falha

Diga o que acontece quando o túnel está em baixo e seja explícito quanto às duas promessas diferentes. Restaurar ligações novas após uma reconexão é fácil de prometer. Preservar sessões que já estavam estabelecidas durante uma falha é um requisito muito mais forte, e condiciona a escolha da tecnologia.

Depois decida o plano alternativo: bloquear o tráfego, encaminhá-lo por outra via aprovada ou fazer algo diferente por aplicação. Um retorno silencioso a um caminho direto é uma decisão de design mesmo quando ninguém a escreveu.

Acrescente o objetivo de recuperação em linguagem clara, como quanto tempo um local pode operar em estado degradado e quem declara o incidente.

Verificação 5 e 6: escolha a costura e registe a mudança

Escolha uma costura para discutir, porque uma revisão que tenta resolver tudo não resolve nada. O encaminhamento, a autorização e a cifragem são três costuras diferentes, e o briefing deve dizer de qual é a pergunta. RFC 4301 é um lembrete útil aqui, porque separa decisões de política, tráfego protegido e associações de segurança em vez de as tratar como um único objeto.

Depois registe o que mudou após a decisão, incluindo as suposições revistas. É esse registo que torna a revisão seguinte mais curta.

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

Um briefing que passa as seis verificações produz uma pergunta com resposta: o design cumpre os fluxos declarados e o contrato de falha, ou uma restrição nomeada impede-o. Quando a restrição mudar mais tarde, o registo mostra que decisão tem de ser revista e qual pode manter-se. Isso torna o exercício reutilizável e não um debate pontual.