Scrivete un brief di progettazione VPN che qualcuno possa davvero rivedere

La maggior parte delle revisioni di progetto si blocca sulla prima domanda, perché la richiesta descrive un prodotto e non una decisione. Un brief che nomina i flussi, i responsabili e il comportamento in caso di guasto si può risolvere in una riunione. Un brief che dice costruite una VPN sicura non si può risolvere affatto. Passate i sei controlli qui sotto prima di inviare qualsiasi cosa, e la revisione diventa un confronto invece di un dibattito.

Primo, la domanda è una decisione o un desiderio

Una decisione ha alternative e un'osservazione che sceglierebbe tra loro. Se non riuscite a nominare cosa guardereste per sceglierne una, la domanda è ancora un desiderio. Scrivete prima le alternative, anche se la lista ha solo due voci. Poi scrivete il compromesso che le separa.

Un desiderio tende anche a nascondere il pubblico. Dite chi deve approvare il progetto, perché lo stesso brief si legge diversamente per un responsabile di rete, un revisore della sicurezza e un approvatore finanziario.

Fermatevi qui se la risposta è nessuno, perché una decisione senza proprietario sarà rifatta da chi si lamenta più forte. È un problema di governance e non un problema di progettazione.

Secondo, nominate i flussi e i rifiuti

Elencate l'origine, la destinazione e l'applicazione di ogni flusso che deve funzionare. Poi elencate i flussi che devono continuare a fallire, perché un progetto che li permette in silenzio ha cambiato il requisito senza dirlo. La sovrapposizione degli indirizzi e la raggiungibilità a monte appartengono a questa lista come vincoli e non come sorprese.

Siate precisi sulla direzione. Una sede che può avviare connessioni verso la sede centrale è un progetto diverso da una che può accettarle, e la differenza appare in ogni regola che scrivete dopo.

Annotate anche i client e il loro stato di gestione, perché un dispositivo gestito con un agente può fare cose che un portatile portato dall'utente non può.

Tenete la lista abbastanza corta da poterla testare. Dieci flussi che potete verificare valgono più di quaranta che non potete.

Controllo 3: separate i fatti dalle ipotesi

Marcate ogni affermazione che avete verificato e marcaté quelle che non avete verificato. L'indirizzamento pubblico, la capacità disponibile e l'accesso amministratore sono le tre ipotesi che cambiano più spesso la risposta. Se una di esse è sconosciuta, dite come cambia il progetto quando risulta nell'uno o nell'altro senso.

Una rete illustrativa va bene purché sia etichettata. Il problema è una filiale ipotetica che acquisisce in silenzio un secondo collegamento a monte o un blocco di indirizzi pubblici che non ha mai avuto.

Verificate l'ipotesi che potete controllare prima della revisione, perché un solo fatto misurato elimina un intero ramo di discussione.

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

Quarto, scrivete il contratto di guasto

Dite cosa succede quando il tunnel è inattivo e siate espliciti sulle due promesse diverse. Ripristinare nuove connessioni dopo una riconnessione è facile da promettere. Preservare le sessioni già stabilite durante un guasto è un requisito molto più forte, e vincola la scelta della tecnologia.

Poi decidete il ripiego: bloccare il traffico, instradarlo per un'altra via approvata o fare qualcosa di diverso per applicazione. Un ritorno silenzioso a un percorso diretto è una decisione di progetto anche quando nessuno l'ha scritta.

Aggiungete l'obiettivo di ripristino in linguaggio chiaro, come quanto a lungo una sede può operare in stato degradato e chi dichiara l'incidente.

Controllo 5 e 6: scegliete la cucitura e registrate il cambiamento

Scegliete una cucitura su cui discutere, perché una revisione che cerca di risolvere tutto non risolve nulla. L'instradamento, l'autorizzazione e la crittografia sono tre cuciture diverse, e il brief deve dire di quale parla la domanda. RFC 4301 è un promemoria utile qui, perché separa le decisioni di politica, il traffico protetto e le associazioni di sicurezza invece di trattarli come un solo oggetto.

Poi registrate cosa è cambiato dopo la decisione, comprese le ipotesi riviste. È quella registrazione che rende più breve la revisione successiva.

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

Un brief che supera tutti e sei i controlli produce una domanda con una risposta: il progetto soddisfa i flussi dichiarati e il contratto di guasto, oppure un vincolo nominato lo impedisce. Quando il vincolo cambia più avanti, la registrazione mostra quale decisione va rivista e quale può restare. È questo che rende l'esercizio riutilizzabile e non un dibattito una tantum.