Напишіть бриф із дизайну 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

Бриф, який проходить усі шість перевірок, дає питання з відповіддю: дизайн відповідає зазначеним потокам і контракту відмови, або назване обмеження цьому заважає. Коли обмеження згодом змінюється, запис показує, яке рішення треба переглянути, а яке може залишитися. Це робить вправу багаторазовою, а не одноразовим спором.