Ndani kontrollet e shëndetit të VPN-së nga kontrollet e shëndetit të aplikacionit

Procesi i tunelit tuaj mund të punojë ndërkohë që lidhja e mbrojtur është e papërdorshme, dhe një faqe web që dështon nuk është provë se tuneli u thye. Kur një sondë përfaqëson të gjitha të tjerat, një politikë rindezjeje rindez komponentin e gabuar dhe e quan këtë automatizim. Çdo kontroll më poshtë emëron shtresën që vëzhgon, veprimin që shkakton dështimi i saj dhe provën se veprimi funksionoi. Hapi i fundit e kthen të gjithë grupin në një faqe që dikush mund ta ndjekë në orën tre të mëngjesit.

Hapi 1: emëroni shtresën që vëzhgon çdo kontroll

Pyetni se çfarë mund të shohë vërtet çdo sondë përpara se të shkruani ndonjë prej tyre. Gjallëria provon se demoni punon, një shtrëngim duarsh ose një listë partnerësh provon se lidhja ekziston, një kërkesë e rrugëzuar provon dorëzimin dhe një kërkim provon zgjidhjen. Ato dështojnë pikërisht në atë rend dhe asnjëra nuk nënkupton tjetrën. Një kontroll procesi i gjelbër pranë një tuneli të vdekur është rasti normal, jo kundërthënie.

Shkruani katër kontrollet në atë rend, me komandën e saktë dhe daljen e pritur për secilën. Një sondë, daljen e pritur të së cilës nuk mund ta deklaroni, do të lexohet ndryshe nga çdo operator që sheh alarmin. Vendosni të njëjtën listë në tekstin e alarmit, jo vetëm në runbook, që personi i zgjuar natën ta takojë shtresën përpara simptomës. Mbani çdo komandë gati për t’u kopjuar në hostin që e ekzekuton.

Më pas shtoni kontrollin e aplikacionit si pika e pestë, e veçantë. Një faqe, shërbimi i llogarive e së cilës është jashtë, nuk e justifikon rindezjen e tunelit.

Hapi 2: lidhni çdo dështim me një veprim të vetëm

Për çdo kontroll, vendosni çfarë rindizet, çfarë mbetet e bllokuar dhe çfarë thërret një njeri. Një dështim i shtresës së tunelit mund të justifikojë rindezjen e tunelit; një dështim i zgjidhësit tregon integrimin e DNS-së në klient; një dështim i shtresës së aplikacionit pothuajse nuk duhet ta prekë kurrë tunelin.

Thoni çfarë nuk duhet të bëjë një dështim, sepse vlerat e parazgjedhura të rrezikshme janë ato lejuese. Një gjendje e pashëndetshme nuk duhet të bëhet kurrë leje për trafik të drejtpërdrejtë të aplikacionit, pasi një rrugë rezervë që e anashkalon tunelin në heshtje heq arsyen pse ekziston tuneli. Ngushtoni edhe veprimet: rindezja e një komponenti të përbashkët sepse një destinacion është i ngadaltë e kthen një problem lokal në problem të gjithë flotës. Ai gjithashtu shkatërron provën që ju nevojitej për të gjetur shkakun.

Hapi 3: mbani sondat të padëmshme dhe të lira

Përdorni kërkesa të vogla, vetëm-lexim: një burim statik, një pikë fundore shëndeti që raporton varësinë e vet ose një lidhje TCP me një port që ju kontrolloni. Shmangni kredencialet, shfletimin privat dhe çdo gjë që ndryshon gjendjen në çdo interval, sepse një sondë që shkruan është një test ngarkese sipas orarit.

Regjistroni destinacionin, pritshmërinë e rrugës dhe afatin kohor për çdo sondë. Pritshmëria e rrugës është fusha që njerëzit e lënë jashtë, dhe është ajo që ndan një dështim tuneli nga një gabim rrugëtimi kur e lexoni alarmin më vonë. Nxirrni intervalin dhe pragun e dështimit nga koha e rikuperimit që premtoni, dhe mbani afatin kohor më të shkurtër se intervali. Një sondë që ende punon kur fillon tjetra raporton një dështim dy herë dhe duket si dridhje.

Hapi 4: thyeni çdo shtresë dhe shikoni nëse sonda e duhur bëhet e kuqe

Ndaloni procesin e tunelit dhe konfirmoni se kontrolli i procesit dështon ndërkohë që DNS mund të përgjigjet ende nga cache. Ndryshoni një rrugë dhe konfirmoni se kërkesa e rrugëzuar dështon ndërkohë që procesi dhe shtrëngimi i duarve mbeten të shëndetshëm. Thyeni vetëm DNS dhe konfirmoni se kontrolli i aplikacionit raporton zgjidhje dhe jo një gabim tuneli. Nëse dy sonda lëvizin gjithmonë bashkë, keni më pak kontrolle nga sa mendoni.

Testoni drejtimin e rikuperimit me të njëjtën disiplinë. Pasi të rivendosni shtresën, sonda duhet të pastrohet pa një rindezje manuale, dhe veprimi që u aktivizua nuk duhet të lërë pas asnjë anashkalim. Vëzhgoni një cikël të plotë përpara se t’i besoni gjendjes së gjelbër, sepse një sondë që pastrohet vetëm me dorë fsheh një rrugë rikuperimi të thyer.

Hapi 5: vendosni runbook-un atje ku tregon alarmi

Një faqe me pesë rreshta mbart të gjithë projektimin: shtresë, komandë, rezultat i pritur, veprim në dështim, pronar. Shtoni një rresht për çdo sondë për atë që nuk e teston me qëllim. Ky rresht është ai që e ndalon personin tjetër të shtojë një kontroll të gjashtë që mat gjithçka dhe nuk dallon asgjë. Lidhni faqen nga teksti i alarmit, përndryshe askush nuk do ta hapë ndërsa incidenti është aktiv.

Në vendosjet me kontejnerë, një kusht varësie formëson nisjen dhe asgjë tjetër. Rendi i nisjes dhe kushti i shëndetit në Compose dokumentacioni përshkruan se si gatishmëria përcakton rendin në të cilin nisin shërbimet; asgjë nga kjo nuk zbaton më pas një politikë dalëse, dhe asgjë nga kjo nuk dështon e mbyllur kur tuneli bie. Zbatimi i vazhdueshëm kërkon politikën e vet dhe sondën e vet, të shkruara në të njëjtën faqe.

Runbook-u është i gatshëm kur shtresa e duhur rikuperohet pa e lexuar askush një sajt të papërdorshëm si tunel të thyer. Kjo teston dokumentin, jo tunelin.