Czy Raspberry Pi wystarczy do VPN w biurze? Zdefiniuj pracę

Raspberry Pi z czterema gigabajtami to opis maszyny, a nie wymóg biura. Może dobrze obsłużyć garść zdalnych użytkowników, a może paść już pierwszego popołudnia, gdy ktoś kopiuje duży plik przez tunel. Liczba pamięci nie powie ci, który z tych scenariuszy nastąpi. Zamiana zakupu w test odbiorczy zastępuje tę niepewność wynikiem, którego możesz bronić.

Zamień pytanie w test odbiorczy

Test odbiorczy nazywa pracę, warunki i próg zaliczenia, zanim dotrze jakikolwiek sprzęt. Dla bramy VPN pracą jest zbiór równoczesnych czynności, a warunkami są zaangażowane ścieżki i usługi. Próg zaliczenia to to, co użytkownik nazwałby użytecznym, a nie to, co raportuje miara. Bez wszystkich trzech liczba nie ma żadnego twierdzenia.

Napisz test tak, żeby ktoś inny mógł go przeprowadzić. Samo to ograniczenie usuwa większość mglistych kryteriów, przez które takie decyzje ciągną się tygodniami. Czyni też wynik porównywalnym, gdy przyjdzie następny przegląd.

Wynik może uzasadnić Raspberry Pi, inne urządzenie albo usługę zarządzaną. Wszystkie trzy są uprawnionymi odpowiedziami na to samo pytanie. Test rozstrzyga między nimi, a karta specyfikacji nie.

Zapisz pracę, nie liczbę osób

Rozdziel czynności zamiast liczyć użytkowników. Otwarcie aplikacji webowej, skopiowanie dużego pliku i uruchomienie interaktywnego terminala nakładają bardzo różne obciążenia na tę samą bramę. Zanotuj, które z nich nakładają się w zwykłej godzinie, bo to właśnie nakładanie zamienia trzy łatwe zadania w jedno trudne.

Zapisz też kierunek. Zdalni użytkownicy pobierający z biurowego serwera plików zużywają łącze wysyłowe biura, a szybkie połączenie klienta nie wyrówna ograniczonej ścieżki po drugiej stronie.

Jeśli tunel przenosi też zwykłe przeglądanie, uwzględnij ten ruch w teście. Sam dostęp prywatny zaniża to, co brama zobaczy, gdy biuro zacznie używać jej do wszystkiego.

Zmierz złożone urządzenie

Testuj tę wersję, protokół i uwierzytelnianie, które zamierzasz wdrożyć. Zanotuj, która ścieżka przetwarzania pakietów jest aktywna, zamiast pożyczać miarę z innego builda. Przepustowość zależy od tej ścieżki, więc obserwacja z innej opisuje inny system. Chodzi o zmierzenie własnej konfiguracji, a nie najlepszej dostępnej.

Uwzględnij usługi, które będą dzielić płytę. Filtrowanie DNS, monitorowanie lub magazyn konkurują o ten sam procesor i pamięć, a brama zmierzona samotnie nie jest tą, którą będziesz prowadzić.

Obserwuj aktywność procesora, nacisk na pamięć, błędy interfejsów i czasy ukończenia podczas pracy ciągłej. Utrzymuj szyfrowanie i kontrolę dostępu włączone przez cały czas, bo liczba uzyskana bez nich opisuje usługę, której nikt nie zatwierdził.

Ustal budżet przestoju przed sprzętem

Jedna tania brama to rozsądny wybór, gdy jej przestój jest do zniesienia, a odtworzenie proste. Zapisz akceptowany czas niedostępności i to, kto może odtworzyć konfigurację, wymienić nośnik i odebrać dostęp utraconemu klientowi. To te czynności decydują, jak długo przestój naprawdę trwa. Żadna z nich nie pojawia się na karcie specyfikacji.

Jeśli administrator dociera do bramy tylko tym samym tunelem, zaplanuj niezależną ścieżkę odtworzenia. Zapasowa płyta, której konfiguracji i kluczy nie da się odtworzyć i której nikt nie posiada, nie jest planem odtworzenia.

Wskaż osobę, a nie zespół. Odtworzenie zależne od grupy to odtworzenie, które czeka, aż grupa będzie dostępna. Nazwisko jest też tym, co czyni plan sprawdzalnym.

Wybierz najmniejszy system, który przechodzi

Wybierz najmniejszy utrzymywany system, który przechodzi zadeklarowane wymagania z zapasem. Więcej pamięci pomaga, gdy pamięć jest ograniczeniem, i nic nie daje ścieżce już nasyconej. Zapas powinien być podanym marginesem, a nie przymiotnikiem. Wtedy następna modernizacja też ma kryterium.

Zapisz obciążenie, wynik i datę obok wdrożenia. Następne pytanie o wydajność zaczyna się wtedy od dowodów, a nie od karty specyfikacji. Ten zapis to różnica między decyzją a domysłem.