Uebfaqja nuk është e disponueshme: shkaqet, diagnoza dhe veprimi i menjëhershëm
Kontrolloni DNS-në, lidhjen, TLS-në dhe përgjigjet e aplikacionit, riktheni shërbimin me siguri dhe parandaloni përsëritjen e incidenteve.
Çfarë do të përfitoni
Njohuri që mund t’i zbatoni.
- Lokalizoni dështimet e faqes nga DNS deri tek aplikacioni
- Ndërthurni kodet e gjendjes, regjistrat dhe vëzhgimet nga jashtë
- Parandaloni përsëritjen e incidenteve përmes komunikimit dhe analizave pas incidentit
Shkoni drejtpërdrejt te seksioni i duhur
- Simptoma të ngjashme në shfletues mund të kenë shkaqe të ndryshme
- Disponueshmëria është një zinxhir varësish
- Stabilizoni shërbimin gjatë incidentit
- Përdorni analizën pas incidentit për ta përmirësuar sistemin
Shfaqni të gjithë 6 seksionet
Konfirmoni kush preket, pastaj shqyrtoni me radhë DNS, lidhjen, TLS dhe HTTP. Riktheni një shërbim që dihet se është i sigurt, ruani provat dhe komunikoni qartë; më pas trajtoni shkaqet teknike dhe organizative.
Simptoma të ngjashme në shfletues mund të kenë shkaqe të ndryshme
Një faqe që nuk ngarkohet kurrë, shfaq një gabim ose kthen përmbajtje bosh mund t'i duket njësoj e paarritshme vizitorit. Serveri i uebit mund të jetë ndalur ose mbingarkuar pas një publikimi apo rritjeje të menjëhershme të trafikut, një domen mund të zgjidhet te destinacioni i gabuar, ose kodi, shtojcat, konfigurimi apo burimet e shteruara mund të prodhojnë gabime HTTP 500, 502 ose 503.
Kontrolloni nga një rrjet i jashtëm për të dalluar dështimet lokale nga ato më të gjera, shqyrtoni shërbimin përkatës Nginx, Apache ose të kontejnerit dhe rishikoni përditësimet ose ndryshimet e fundit të konfigurimit. Ndikimi në prodhim e bën diagnostikimin e shpejtë dhe të strukturuar më të përshtatshëm sesa improvizimin.
Disponueshmëria është një zinxhir varësish
Midis shfletuesit dhe aplikacionit ndodhen DNS, rrjeti, TLS, CDN ose proxy i kundërt, serveri i uebit, mjedisi i ekzekutimit, baza e të dhënave dhe shërbimet e jashtme. Përcaktoni fillimisht nëse incidenti është global, rajonal, specifik për një ofrues apo i kufizuar te një pajisje. Pastaj kontrolloni zgjidhjen e emrit, lidhjen TCP, certifikatën dhe përgjigjen HTTP.
Një 502 ose 504 ndryshon nga DNS NXDOMAIN ose një 500 i gjeneruar nga aplikacioni. Identifikuesit e korrelacionit dhe vulat kohore e lidhin përvojën e vizitorit me regjistrat e serverit. Një vendosje versioni ose ndryshim në DNS, firewall, certifikatë apo bazën e të dhënave pak para incidentit është një e dhënë e dobishme, jo provë më vete.
Stabilizoni shërbimin gjatë incidentit
Objektivi i parë është rikthimi i sigurt i shërbimit. Kthimi te një version që dihet se funksionon, çaktivizimi i një funksioni të prishur ose kalimi te një instancë e shëndetshme mund të jetë më i mirë sesa një riparim kompleks nën presion. Regjistroni çdo veprim, kohën, përgjegjësin dhe rezultatin.
Komunikoni funksionin e prekur, kohën e fillimit, ndikimin te përdoruesit, gjendjen aktuale dhe përditësimin e ardhshëm. Mbani hamendësimet jashtë mesazheve publike. Nëse dyshohet komprometim, ruani provat dhe kufizoni qasjen para se ndryshimet e pakontrolluara të fshijnë regjistrat ose të ndryshojnë sistemet.
Përdorni analizën pas incidentit për ta përmirësuar sistemin
Ndani shkaktarin fillestar, shkakun teknik dhe faktorët organizativë që e përforcuan. Testet që mungojnë, përgjegjësitë e paqarta, kufijtë e dobët të burimeve dhe paralajmërimet e vonuara mund të kenë po aq rëndësi sa procesi që dështoi. Caktoni për çdo veprim korrigjues një përgjegjës, afat dhe kriter suksesi të verifikueshëm.
Kontrollet sintetike nga disa vende, metrikat e përdoruesve realë, regjistrat e strukturuar dhe gjurmët e shpërndara mund ta shkurtojnë diagnostikimin në të ardhmen. Vëzhgueshmëria e dobishme identifikon cila varësi dështon, që kur dhe për cilët përdorues, në vend që vetëm të raportojë se një faqe nuk punon.
Lista praktike e kontrollit
- 01
Konfirmoni shtrirjen me monitorim nga jashtë dhe më shumë se një rrjet.
- 02
Kontrolloni me radhë DNS, lidhjen, TLS dhe HTTP.
- 03
Lidhni ndryshimet e fundit me metrikat e infrastrukturës dhe regjistrat e aplikacionit.
- 04
Jepini përparësi dhe regjistroni një kthim pas ose masë kufizuese të sigurt.
- 05
Përfundoni një analizë pas incidentit me shkaqet, veprimet, përgjegjësit dhe afatet.
Pyetje të shpeshta
Cili është ndryshimi midis 502 dhe 504?
Të dyja zakonisht vijnë nga një gateway ose proxy. Një 502 tregon një përgjigje të pavlefshme ose të dështuar nga shërbimi pasues; një 504 tregon se pritja për shërbimin pasues e tejkaloi afatin kohor.
Kur duhet ta kontaktojmë ofruesin?
Kur matjet e lokalizojnë dështimin jashtë shtresës që kontrolloni ose kur ofruesi konfirmon një incident. Kohët, gjurmët dhe provat tuaja diagnostikuese ndihmojnë në përshkallëzimin e çështjes.
Oferta e përshtatshme
Si mund t’ju ndihmojë Bissolux
Kthejeni udhëzimin në një hap praktik. Kontrolloni përmbajtjen, çmimin dhe përjashtimet e ofertës përpara porosisë.
Reklamë · BissoluxMbështetje dhe operim IT
Na përshkruani sistemet dhe kërkesat tuaja. Do të biem dakord për punën, përgjegjësitë dhe kushtet përpara zbatimit. Kontakti ofrohet në anglisht.
Infrastrukturë IT
Na përshkruani sistemet dhe kërkesat tuaja. Do të biem dakord për punën, përgjegjësitë dhe kushtet përpara zbatimit. Kontakti ofrohet në anglisht.
