Napisz brief projektowy VPN, który ktoś naprawdę może przejrzeć

Większość przeglądów projektu zatrzymuje się na pierwszym pytaniu, bo prośba opisuje produkt, a nie decyzję. Brief, który nazywa przepływy, właścicieli i zachowanie przy awarii, można rozstrzygnąć na jednym spotkaniu. Briefu ze słowami zbudujcie bezpieczny VPN nie da się rozstrzygnąć wcale. Przejdź sześć kontroli poniżej, zanim cokolwiek wyślesz, a przegląd stanie się porównaniem zamiast sporu.

Po pierwsze, czy pytanie jest decyzją czy życzeniem

Decyzja ma alternatywy i obserwację, która wybrałaby między nimi. Jeśli nie potrafisz nazwać, na co byś patrzył, żeby wybrać jedną, pytanie wciąż jest życzeniem. Najpierw zapisz alternatywy, nawet jeśli lista ma tylko dwa punkty. Potem zapisz kompromis, który je rozdziela.

Życzenie ma też skłonność do ukrywania odbiorców. Powiedz, kto musi zatwierdzić projekt, bo ten sam brief czyta się inaczej właścicielowi sieci, recenzentowi bezpieczeństwa i osobie zatwierdzającej finanse.

Zatrzymaj się tutaj, jeśli odpowiedź brzmi nikt, bo decyzję bez właściciela zrobi ponownie ten, kto najgłośniej się skarży. To problem zarządzania, a nie problem projektu.

Po drugie, nazwij przepływy i odmowy

Wymień źródło, cel i aplikację dla każdego przepływu, który musi działać. Potem wymień przepływy, które muszą nadal zawodzić, bo projekt, który po cichu je dopuszcza, zmienił wymaganie, nie mówiąc o tym. Nakładanie się adresów i osiągalność w górę należą do tej listy jako ograniczenia, a nie niespodzianki.

Bądź konkretny co do kierunku. Lokacja, która może inicjować połączenia do centrali, to inny projekt niż ta, która może je przyjmować, a różnica widać w każdej regule, którą potem napiszesz.

Zwróć też uwagę na klientów i stan ich zarządzania, bo zarządzane urządzenie z agentem może robić rzeczy, których przyniesiony laptop nie może.

Trzymaj listę na tyle krótką, by dało się ją sprawdzić. Dziesięć przepływów, które możesz zweryfikować, jest lepsze niż czterdzieści, których nie możesz.

Kontrola 3: oddziel fakty od założeń

Zaznacz każde twierdzenie, które zweryfikowałeś, i zaznacz te, których nie zweryfikowałeś. Publiczne adresowanie, dostępna przepustowość i dostęp administratora to trzy założenia, które najczęściej zmieniają odpowiedź. Jeśli jedno z nich jest nieznane, powiedz, jak projekt się zmienia, gdy wyjdzie w którąkolwiek stronę.

Sieć ilustracyjna jest w porządku, dopóki jest oznaczona. Problemem jest hipotetyczna filia, która po cichu zyskuje drugie łącze w górę albo publiczny blok adresów, którego nigdy nie miała.

Zweryfikuj założenie, które możesz sprawdzić, przed przeglądem, bo jeden zmierzony fakt usuwa całą gałąź dyskusji.

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

Po czwarte, napisz kontrakt awarii

Powiedz, co się dzieje, gdy tunel jest wyłączony, i bądź wyraźny co do dwóch różnych obietnic. Przywrócenie nowych połączeń po ponownym połączeniu jest łatwe do obiecania. Zachowanie sesji, które już zostały ustanowione przez awarię, to znacznie silniejsze wymaganie i ogranicza wybór technologii.

Potem zdecyduj plan zapasowy: zablokuj ruch, poprowadź go inną zatwierdzoną drogą albo zrób coś innego dla każdej aplikacji. Cichy powrót do bezpośredniej drogi to decyzja projektowa, nawet gdy nikt jej nie zapisał.

Dodaj cel przywrócenia prostym językiem, na przykład jak długo lokacja może działać w stanie obniżonej sprawności i kto ogłasza incydent.

Kontrola 5 i 6: wybierz szew i zapisz zmianę

Wybierz jeden szew do dyskusji, bo przegląd, który próbuje rozstrzygnąć wszystko, nie rozstrzyga niczego. Routing, autoryzacja i szyfrowanie to trzy różne szwy, a brief powinien powiedzieć, o którym jest pytanie. RFC 4301 to przydatne przypomnienie, bo oddziela decyzje polityki, ruch chroniony i asocjacje bezpieczeństwa, zamiast traktować je jako jeden obiekt.

Potem zapisz, co się zmieniło po decyzji, w tym zrewidowane założenia. To ten zapis sprawia, że następny przegląd jest krótszy.

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

Brief, który przechodzi wszystkie sześć kontroli, daje pytanie z odpowiedzią: projekt spełnia podane przepływy i kontrakt awarii albo nazwane ograniczenie mu przeszkadza. Gdy ograniczenie zmieni się później, zapis pokazuje, którą decyzję trzeba ponownie rozważyć, a która może zostać. To czyni ćwiczenie wielokrotnego użytku, a nie jednorazowym sporem.