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

Бриф, проходящий все шесть проверок, даёт вопрос с ответом: дизайн соответствует указанным потокам и контракту отказа, или названное ограничение мешает. Когда ограничение позже меняется, запись показывает, какое решение нужно пересмотреть, а какое может остаться. Это делает упражнение многоразовым, а не разовым спором.