Hva en liten VPN-driftsbok må svare på i en fart

Den driftsansvarlige som tok over klokken 02:00, kunne ikke si om tjenesten var sunn, fordi dokumentet forklarte designet og aldri sa hva som skulle kjøres. Å gi filen til noen andre og deretter forlate rommet er den eneste testen som betyr noe. De fleste små VPN-notater feiler den allerede på andre side. Formen nedenfor består testen, og ingenting av det trenger å være langt.

Start med et kart en trøtt person kan skumme gjennom

Skriv ned hva noen må slå opp i en fart: navnene klientene kobler til, portene daemonen lytter på, adressepoolene den deler ut, hvordan klientnavn løses opp, og hvilke nettverk bak tunnelen som skal kunne nås. Legg til buildnummeret du faktisk kjører, og navngi komponenten som eier hver bevegelig del, fordi ruter, pakkefilter og klientprofiler ofte konfigureres tre forskjellige steder. Noter også de ytre avhengighetene: hostingkontoen, opplinken, identitetsleverandøren og de private nettverkene i den fjerne enden. En tabell eller et håndtegnet diagram bærer dette bedre enn avsnitt, fordi leseren skummer i stedet for å lese.

Navngi deretter personene som kan godkjenne en nødendring, med en kontaktvei som ikke avhenger av at tunnelen er oppe. En eskaleringslinje uten reserve er en blindgate i nettopp den hendelsen som trenger den. To navn og ett telefonnummer er nok; kartet er ikke en personaloversikt.

Hver kontroll trenger svaret som regnes som sunt

For hver tjeneste setter du kommandoen og linjen som betyr at den lyktes ved siden av hverandre, slik at leseren aldri må utlede den ene av den andre i en fart. Prosessstatus og nåbarhet ende-til-ende ligger på ulike lag: det ene viser at daemonen godtok konfigurasjonen, det andre at en klient kan bruke det tunnelen tilbyr. Skriv begge linjene, og si hvilken feil hver av dem fanger, fordi en kontroll uten oppgitt resultat blir en diskusjon om hvorvidt utdata ser bra ut.

systemctl status openvpn-server@lab
ss -lntu | grep 1194

Kjør begge, og behandl dem som separate bevis i stedet for en sekvens. En grønn enhet kan stå ved siden av en tunnel ingen kan bruke, og det motsatte skjer når en lytter overlever en brutt rute. Oppgi laget hver linje observerer, og leseren vet hvilken som skal troes når de er uenige.

Tre feil dekker de fleste netter

Endepunkt utilgjengelig, identitet avvist og tilkoblet uten nyttig trafikk forklarer nesten alt som vekker noen. For hver av dem, list de to første kontrollene og personen det eskaleres til, slik at ingen må finne opp en diagnoseorden klokken 02:00. Utilgjengelighet peker som regel på stien eller lytteren, en avvist identitet på et sertifikat, et legitimasjonslager eller en klokke, og en tom tilkobling på ruter, videresending eller navneoppslag. De tre grenene leser ulike logger, og derfor må grenen velges før loggen åpnes.

Lenk til dokumentasjonen ovenfor i stedet for å lime inn kommandoer du ikke har kjørt på denne verten. En utestet kommando kopiert fra et annet miljø er verre enn en peker, fordi den ser autoritativ ut og feiler stille.

Skriv endringen som en sekvens, ikke som et avsnitt

For enhver endring, noter kontrollpunktet du kan gå tilbake til, kontrollen som bekrefter suksess og betingelsen som utløser tilbakerulling, i den rekkefølgen. Ta med en vei tilbake som ikke går gjennom tunnelen, fordi nettopp endringen du gjør kan stenge den. Noter hvordan gjeldende tilbakekallinger ville blitt gjenopprettet i stedet for et eldre øyeblikksbilde, fordi en utdatert liste stille godtar legitimasjon som ble trukket den morgenen. Nummererte imperative trinn tåler press; prosa blir tolkning.

Øv den veien tilbake før du trenger den, hver gang endringen er stor nok til å bety noe. En tilbakerulling skrevet fra hukommelsen er et gjett med en dato på.

Legitimasjon bor et annet sted

Vis til passordbehandleren, hvelvet eller den forseglede konvolutten, og si hvem som kan åpne den, i stedet for å sitere materiale i filen. Private nøkler, engangskoder for gjenoppretting og profiler som bygger inn en hemmelighet hører hjemme i beskyttet lagring, og siden bør forklare hvordan en autorisert driftsansvarlig når dem klokken 02:00. Bruk aldri en levende hemmelighet som eksempel, fordi eksempler blir limt inn i billetter og chat-tråder. En peker pluss en tillatelsesliste er alt dokumentet trenger.

Gå gjennom filen etter en reell endring eller en gjenopprettingsøvelse, slett stier som ikke finnes lenger, og noter hvis oppgave den neste vedlikeholdsbeslutningen er. Hold en endringslogg med tre kolonner til slutt: dato, hva som ble endret, hvem som verifiserte det. Det er den siden som forteller neste leser om resten er oppdatert, og systemctl-dokumentasjonen fra systemd er en bedre lenke enn en parafrase av tjenestekommandoer som vil drive.