Częściowo zarządzana VPN: etykieta nie mówi, kto jest na dyżurze

O ósmej rano pada połączenie, a pierwsze pytanie brzmi, kto powinien je naprawić. Sformułowanie częściowo zarządzana VPN nie odpowiada na to, bo nazywa ustalenie handlowe, a nie podział pracy. Dwaj dostawcy mogą używać tego samego sformułowania z przeciwnym podziałem: jeden utrzymuje urządzenie po stronie klienta, drugi tylko obserwuje własną bramę. Dopóki zadania nie są zapisane, etykieta jest domysłem przebranym za opis.

Zacznijcie od połączenia, które padło

Nazwijcie punkt końcowy, który przestał odpowiadać, godzinę i to, co robił użytkownik, gdy się zepsuło. Potem wypiszcie elementy na tej ścieżce: laptop, łącze lokalne, bramę po stronie klienta, bramę dostawcy i zasób za nią. Każdy z nich ma albo właściciela w umowie, albo lukę. Uporządkowanie ich zajmuje dziesięć minut i rozstrzyga następne trzy godziny.

Objaw wspólny dla wielu użytkowników wskazuje wspólny element, a objaw podążający za jednym laptopem wskazuje klienta. To rozróżnienie trafia zgłoszenie do właściwej kolejki, zanim ktokolwiek otworzy konfigurację.

Ustalcie oba punkty końcowe przed ustawieniami

Zdecydujcie, kto jest właścicielem bramy po stronie klienta, a kto odległego punktu końcowego. Gdy te dwa są ustalone, każda strona wie, co może sprawdzić i o co musi poprosić. Wszystko inne w ustaleniu staje się od tego miejsca łatwiejsze.

Dostawca może monitorować własną bramę, podczas gdy klient pozostaje odpowiedzialny za lokalne łącze internetowe, usługę katalogową albo aplikację docelową. Urządzenie należące do klienta może nadal podlegać umowie serwisowej dostawcy, dlatego własność i to, kto utrzymuje skrzynkę, to dwa różne pytania. Zapiszcie obie odpowiedzi dla każdego punktu końcowego, bo to na drugiej zwykle różnią się odnowienia.

Wspólne obiekty potrzebują dokładnie jednego właściciela

Tożsamości, poświadczenia, chronione prefiksy, propozycje i umowa o routingu zwrotnym to wspólne obiekty, a wspólne obiekty gniją najszybciej. Jeśli obie strony mogą zmienić jeden, obie to zrobią, a każda zmiana wygląda lokalnie poprawnie, podczas gdy uzgodniony przepływ się psuje. Dajcie każdemu obiektowi jednego właściciela i jeden proces zmiany oraz wymagajcie powiadomienia drugiej strony, zanim zmiana wejdzie w życie. Alternatywą jest dziennik zmian, który czyta się jak dwoje ludzi naprawiających różne połowy tej samej maszyny.

Klasyczna awaria to zmiana selektora po jednej stronie i zmiana NAT po drugiej w tym samym tygodniu. Żaden z inżynierów nie zrobił nic złego, a tunel i tak przestał przenosić aplikację.

Kto przyjmuje pierwsze zgłoszenie

Z góry ustalcie, kogo wzywa się pierwszego, co każda strona może czytać i w którym momencie sprawa zmienia ręce. Podajcie punkt końcowy, czas próby i dozwolony przepływ, aby obie strony mogły skorelować to samo zdarzenie.

Wąskie podsumowanie stanu jest zwykle użyteczniejsze niż nieocenzurowana konfiguracja i nie ujawnia sekretów. Monitoring należy do tego, kto posiada element, a nie do tego, kto posiada logo, więc pytajcie, która strona widzi stan tunelu, która widzi aplikację i kogo budzi każdy alert. Umieśćcie drogę poza godzinami pracy obok każdego alertu, bo pulpit, na który nikt nie ma dyżuru, to dokumentacja.

Zdefiniujcie uprawnienie do zmian z taką samą starannością. Dostawca edytujący selektor, podczas gdy klient edytuje NAT, sprawia, że obie lokalne konfiguracje wyglądają wiarygodnie, a tunel nadal zawodzi.

Czego etykieta nigdy nie mówi

Wpiszcie do rzeczywistej umowy utrzymanie oprogramowania, rotację poświadczeń, zatwierdzone kopie konfiguracji i ścieżkę odzyskiwania. Model wspólnej odpowiedzialności, taki jak model publikowany przez AWS pokazuje, jak daleko podział może się przesunąć między usługami, i jest to przykład, a nie definicja warunków waszego dostawcy. Wyprowadzanie czegokolwiek ze sformułowania częściowo zarządzana to sposób, w jaki rozmowa o odnowieniu odkrywa lukę.

Zakres powinien nazywać zwykłego operatora i ścieżkę eskalacji dla każdej zależności. Jakkolwiek oferta nazywa usługę, w praktyce znaczy to właśnie ta lista.