Напишете бриф за дизайн на VPN, който някой наистина може да прегледа

Повечето прегледи на дизайн спират на първия въпрос, защото заявката описва продукт, а не решение. Бриф, който назовава потоците, собствениците и поведението при отказ, може да бъде разгледан в една среща. Бриф със думите изградете сигурен 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

Бриф, който минава през всички шест проверки, произвежда въпрос с отговор: дизайнът отговаря на посочените потоци и на договора за отказ, или посочено ограничение го възпрепятства. Когато ограничението се промени по-късно, записът показва кое решение трябва да се преразгледа и кое може да остане. Това прави упражнението многократно използваемо, а не еднократен спор.