Већина прегледа дизајна застане на првом питању, јер захтев описује производ, а не одлуку. Бриф који именује токове, власнике и понашање при отказу може се решити на једном састанку. Бриф са речима изградите безбедан VPN не може се решити уопште. Прођите кроз шест провера испод пре него што нешто пошаљете, и преглед постаје поређење уместо расправе.

Прво, да ли је питање одлука или жеља

Одлука има алтернативе и запажање које би изабрало између њих. Ако не можете да именујете у шта бисте гледали да бисте изабрали једну, питање је још жеља. Прво запишите алтернативе, чак и ако листа има само две ставке. Затим запишите компромис који их раздваја.

Жеља такође има тенденцију да сакрије публику. Реците ко мора да одобри дизајн, јер се исти бриф различито чита власнику мреже, прегледачу безбедности и финансијском одобраваоцу.

Зауставите се овде ако је одговор нико, јер ће одлуку без власника поново донети онај ко се најгласније жали. То је проблем управљања, а не проблем дизајна.

Друго, именујте токове и одбијања

Наведите извор, одредиште и апликацију за сваки ток који мора да ради. Затим наведите токове који морају да наставе да не успевају, јер дизајн који их тихо дозвољава променио је захтев без да то каже. Преклапање адреса и доступност узводно припадају овој листи као ограничења, а не као изненађења.

Будите конкретни у погледу смера. Локација која сме да започне везе ка седишту је другачији дизајн од оне која сме да их прихвати, а разлика се види у сваком правилу које после напишете.

Обратите пажњу и на клијенте и стање њиховог управљања, јер управљани уређај са агентом може да ради ствари које донети лаптоп не може.

Држите листу довољно кратком за тестирање. Десет токова које можете да проверите боље је од четрдесет које не можете.

Провера 3: одвојте чињенице од претпоставки

Означите сваку тврдњу коју сте проверили, и означите оне које нисте. Јавно адресирање, доступна пропусност и приступ администратора су три претпоставке које најчешће мењају одговор. Ако је једна од њих непозната, реците како се дизајн мења када се покаже у било ком смеру.

Илустративна мрежа је у реду док је означена. Проблем је хипотетичка филијала која тихо добије други узводни линк или јавни блок адреса који никада није имала.

Проверите претпоставку коју можете да проверите пре прегледа, јер једна измерена чињеница уклања целу грану расправе.

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

Четврто, напишите уговор о отказу

Реците шта се дешава када је тунел доле, и будите експлицитни о два различита обећања. Враћање нових веза после поновног повезивања лако је обећати. Чување сесија које су већ биле успостављене кроз отказ је много јачи захтев, и ограничава избор технологије.

Затим одлучите резервни план: блокирајте саобраћај, упутите га другим одобреним путем или урадите нешто другачије по апликацији. Тихи повратак на директан пут је дизајнерска одлука чак и када је нико није записао.

Додајте циљ опоравка једноставним језиком, на пример колико дуго локација сме да ради у погоршаном стању и ко проглашава инцидент.

Провера 5 и 6: изаберите шав и забележите промену

Изаберите један шав за расправу, јер преглед који покушава да реши све не решава ништа. Рутирање, ауторизација и шифровање су три различита шава, и бриф треба да каже о ком је питање. RFC 4301 је користан подсетник овде, јер раздваја политичке одлуке, заштићени саобраћај и безбедносне асоцијације уместо да их третира као један објекат.

Затим забележите шта се променило после одлуке, укључујући прегледане претпоставке. Тај запис чини следећи преглед краћим.

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

Бриф који прође свих шест провера даје питање са одговором: дизајн испуњава наведене токове и уговор о отказу, или га именовано ограничење спречава. Када се ограничење касније промени, запис показује која одлука мора поново да се размотри, а која може да остане. То чини вежбу вишекратно употребљивом, а не једнократном расправом.

Повезани чланци