Scrieți un brief de proiectare VPN pe care cineva chiar îl poate revizui

Majoritatea reviziilor de design se blochează la prima întrebare, pentru că cererea descrie un produs, nu o decizie. Un brief care numește fluxurile, responsabilii și comportamentul la eșec poate fi rezolvat într-o singură ședință. Un brief care spune construiți un VPN sigur nu poate fi rezolvat deloc. Parcurgeți cele șase verificări de mai jos înainte de a trimite ceva, iar revizia devine o comparație în loc de o dezbatere.

În primul rând, întrebarea este o decizie sau o dorință

O decizie are alternative și o observație care ar alege între ele. Dacă nu puteți numi la ce v-ați uita pentru a alege una, întrebarea este încă o dorință. Scrieți mai întâi alternativele, chiar dacă lista are doar două puncte. Apoi scrieți compromisul care le separă.

O dorință tinde, de asemenea, să ascundă publicul. Spuneți cine trebuie să aprobe designul, pentru că același brief este citit diferit de un proprietar de rețea, un revizor de securitate și un aprobator financiar.

Opriți-vă aici dacă răspunsul este nimeni, pentru că o decizie fără proprietar va fi refăcută de cel care se plânge cel mai tare. Aceasta este o problemă de guvernanță, nu o problemă de design.

În al doilea rând, numiți fluxurile și refuzurile

Enumerați sursa, destinația și aplicația pentru fiecare flux care trebuie să funcționeze. Apoi enumerați fluxurile care trebuie să continue să eșueze, pentru că un design care le permite în tăcere a schimbat cerința fără să spună. Suprapunerea adreselor și accesibilitatea în amonte fac parte din această listă ca restricții, nu ca surprize.

Fiți concret în privința direcției. O locație care poate iniția conexiuni către sediul central este un design diferit de una care le poate accepta, iar diferența apare în fiecare regulă pe care o scrieți apoi.

Observați și clienții și starea lor de administrare, pentru că un dispozitiv administrat cu un agent poate face lucruri pe care un laptop adus de utilizator nu le poate face.

Țineți lista suficient de scurtă pentru a fi testată. Zece fluxuri pe care le puteți verifica sunt mai bune decât patruzeci pe care nu le puteți.

Verificarea 3: separați faptele de presupuneri

Marcați fiecare afirmație pe care ați verificat-o și marcați-le pe cele pe care nu le-ați verificat. Adresarea publică, debitul disponibil și accesul administratorului sunt cele trei presupuneri care schimbă cel mai des răspunsul. Dacă una dintre ele este necunoscută, spuneți cum se schimbă designul când se dovedește într-o direcție sau alta.

O rețea ilustrativă este în regulă atâta timp cât este etichetată. Problema este o sucursală ipotetică ce dobândește în tăcere o a doua legătură în amonte sau un bloc de adrese publice pe care nu l-a avut niciodată.

Verificați presupunerea pe care o puteți controla înainte de revizie, pentru că un singur fapt măsurat elimină o ramură întreagă de discuție.

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

În al patrulea rând, scrieți contractul de eșec

Spuneți ce se întâmplă când tunelul este căzut și fiți explicit în privința celor două promisiuni diferite. Restabilirea conexiunilor noi după o reconectare este ușor de promis. Păstrarea sesiunilor care erau deja stabilite pe durata unei defecțiuni este o cerință mult mai puternică și limitează alegerea tehnologiei.

Apoi decideți planul de rezervă: blocați traficul, direcționați-l pe o altă cale aprobată sau faceți altceva pentru fiecare aplicație. O revenire tăcută la o cale directă este o decizie de design chiar și atunci când nimeni nu a scris-o.

Adăugați obiectivul de recuperare în limbaj simplu, cum ar fi cât timp poate funcționa o locație în stare degradată și cine declară incidentul.

Verificarea 5 și 6: alegeți cusătura și înregistrați schimbarea

Alegeți o singură cusătură pentru dezbatere, pentru că o revizie care încearcă să rezolve tot nu rezolvă nimic. Rutarea, autorizarea și criptarea sunt trei cusături diferite, iar brief-ul trebuie să spună despre care este întrebarea. RFC 4301 este un memento util aici, pentru că separă deciziile de politică, traficul protejat și asocierile de securitate în loc să le trateze ca un singur obiect.

Apoi înregistrați ce s-a schimbat după decizie, inclusiv presupunerile revizuite. Acea înregistrare este ce face următoarea revizie mai scurtă.

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

Un brief care trece toate cele șase verificări produce o întrebare cu răspuns: designul îndeplinește fluxurile enunțate și contractul de eșec, sau o restricție numită îl împiedică. Când restricția se schimbă mai târziu, înregistrarea arată ce decizie trebuie revizuită și care poate rămâne. Asta face exercițiul reutilizabil, și nu o dezbatere unică.