Klijent Vam piše u petak u 16:40: „Sajt ne radi.“ Za njega je to jedna rečenica. Za Vas je to pet mogućih uzroka, a samo dva od njih su u samom sajtu. Ostali su u domenu, u sertifikatu, u mejlu, u mreži između posetioca i servera ili kod hostera. Agencija koja drži hosting za klijente ipak prima poziv, jer klijent ima jednu fakturu i jednog izvođača. Zato je razvrstavanje uzroka deo usluge, a ne uzgredni posao.
Ovaj tekst daje redosled provere koji se završava za petnaestak minuta, tabelu uzroka sa podelom odgovornosti, obrazac tiketa koji hoster može da obradi iz prvog čitanja i tri rečenice kojima se klijentu odgovara. Primeri polaze od pravila koja naša podrška objavljuje, ali redosled važi bez obzira na to gde su sajtovi smešteni.
Prvo pitanje: vidi li problem još neko
Pre bilo kakve dijagnoze otvorite sajt sa sopstvenog telefona preko mobilnih podataka, ne preko kancelarijske mreže. Ako se otvara, problem je na strani klijenta: njegov preglednik, keš, antivirus, mreža ili DNS keš na računaru. Ako se ne otvara ni kod Vas, uzrok je negde između domena i servera.
Od klijenta tražite četiri stvari, i to u jednoj poruci, da ne vodite prepisku od dvadeset reči po poruci:
- tačan tekst greške ili snimak ekrana, ne opis („beli ekran“ i „greška 500“ su dva različita kvara);
- vreme kada je prvi put primetio problem;
- uređaj i mrežu sa koje gleda (telefon na mobilnim podacima ili računar u kancelariji);
- da li je pre toga neko nešto menjao: novi dodatak, nova tema, promena domena, prelazak na drugi mejl.
Četvrta stavka rešava iznenađujuće veliki deo slučajeva. Kvar koji je počeo odmah posle ažuriranja je skoro uvek u sajtu. Kvar koji je počeo bez ikakve promene najčešće nije.
Šest mesta na kojima kvar nije u sajtu
Tabela ispod povezuje ono što klijent vidi sa najverovatnijim uzrokom i sa tim ko ga rešava. Podela odgovara onome što i naš Pravilnik o pružanju podrške kaže o hosteru: hoster održava server, Vi održavate sajt.
| Šta klijent vidi | Najverovatniji uzrok | Ko rešava |
|---|---|---|
| Beli ekran ili greška 500 posle ažuriranja | Dodatak ili tema se sukobljavaju sa verzijom PHP-a | Vi ili Vaš developer, hoster pomaže logom |
| „Sajt nije pronađen“, a juče je radio | Istekao domen ili pogrešan DNS zapis | Vlasnik domena; hoster samo šalje podsetnike |
| Upozorenje o sertifikatu | Istekao ili nije izdat sertifikat, često posle promene DNS-a | Zavisi od uzroka, prvo se proverava DNS |
| Cloudflare greška 521, 522 ili 524 | Server ne odgovara CDN-u ili ga firewall blokira | Hoster ili administrator servera |
| Mejlovi ne stižu ili završavaju u spamu | Prekoračen limit slanja ili nepodešeni SPF i DKIM | Zajednički: hoster daje limite, Vi podešavate DNS |
| Sajt je spor ili pada samo ponekad | Potrošeni resursi ili pun disk | Vlasnik naloga, uz pomoć podrške |
Domen i DNS
Istekao domen izgleda isto kao pao server: sajt se ne otvara. Razlika je u tome što nijedan tiket hosteru ne pomaže. Hoster šalje podsetnike, ali obnova domena je odluka vlasnika. Proverite datum isteka u whois podacima pre nego što pišete bilo kome. Ako je domen aktivan, a sajt se i dalje ne rešava, uporedite A zapis sa IP adresom koju Vam je hoster dao. Posle prelaska na drugi server ili na CDN najčešće ostane stari zapis.
Cloudflare i slične usluge ispred servera
Ako je sajt iza Cloudflare-a, klijent neće videti grešku Vašeg servera nego Cloudflare-ovu stranicu sa trocifrenim kodom. Prema Cloudflare dokumentaciji, 521 znači da server odbija konekcije, najčešće zato što aplikacija ne radi ili što firewall blokira Cloudflare adrese. Kod 522 je isteklo vreme za povezivanje: ako Cloudflare ne dobije odgovor na početku veze u roku od 19 sekundi, ili ne dobije potvrdu zahteva u roku od 90 sekundi posle uspostavljene veze, prikazuje se 522. Najčešći uzrok koji dokumentacija navodi je upravo to da su Cloudflare adrese ograničene ili blokirane u .htaccess, iptables ili firewall-u.
Za Vas je praktična posledica jasna: kod u opsegu 52x je gotovo uvek zadatak za hostera ili administratora servera. Pišite mu odmah, sa kodom, umesto da ponovo instalirate dodatke.
Mejl
„Ne stižu nam mejlovi“ ima barem tri različita uzroka: poruke se ne šalju, ne primaju ili ih primalac ne vidi. Kod nas je ograničenje 20 poruka na sat po nalogu, radi zaštite ugleda servera, i povećava se na zahtev. Klijent koji pošalje obaveštenje stotini ljudi odjednom to ograničenje udari za nekoliko minuta.
Druga polovina priče je autentifikacija. Prema Google smernicama za pošiljaoce, od 1. februara 2024. svi koji šalju ka Gmail adresama moraju da imaju SPF ili DKIM, a oni koji šalju više od 5.000 poruka dnevno moraju da imaju SPF, DKIM i DMARC. Stopa prijava spama mora ostati ispod 0,30 odsto, a preporuka je ispod 0,10 odsto. Za agenciju to znači da DNS zapisi za mejl nisu sitnica koja se ostavi za kraj, nego deo isporuke sajta.
Resursi i disk
Pun disk i prekoračeni resursi daju najzbunjujuće simptome: sajt radi, ali se ne može sačuvati porudžbina, mejl se vraća, baza javlja grešku. Praćenje potrošnje je obaveza korisnika naloga i vidi se na početnoj strani cPanela. Ako se prostor napuni, hoster ne odgovara za prekid rada sajta, mejla ili baze. Zato pogledajte brojke pre nego što zovete bilo koga. Kako se ograničenja naloga postavljaju i kako se vide na nivou paketa, objašnjava tekst o WHM-u za preprodavce.
Redosled provere od petnaest minuta
Kad nema vremena za razmišljanje, važi isti redosled svaki put:
- Otvorite sajt sa mobilnih podataka i zabeležite tačnu grešku i kod.
- Proverite domen: da li je aktivan i na koji se IP rešava.
- Proverite sertifikat: ko ga je izdao i do kada važi.
- Uđite u cPanel naloga klijenta i pogledajte disk i potrošnju resursa.
- Otvorite dnevnik grešaka. Greška sa imenom fajla i linijom koda znači da je uzrok u sajtu.
- Tek sad, ako ništa od prethodnog ne objašnjava kvar, pišite hosteru.
Redosled ima jednu prednost koju timovi tek kasnije prepoznaju: tiket koji pišete na šestom koraku sadrži odgovore na sve što bi Vas hoster inače pitao.
Tiket koji hoster može da reši iz prvog čitanja
Najčešći razlog zašto tiket traje tri poruke umesto jedne je što u prvoj nedostaje podatak. Pošaljite sve odjednom:
- domen i nalog na koji se odnosi;
- tačno vreme prvog pojavljivanja problema, sa vremenskom zonom;
- tačan tekst greške ili HTTP kod i sa koje mreže ste ga videli;
- šta ste već isključili (domen aktivan, DNS tačan, disk nije pun);
- da li je pre kvara bilo promene na sajtu ili na serveru;
- šta tačno tražite: pregled logova, provera firewall-a, provera servera.
Zatim računajte sa pravilima hostera. Kod nas je garantovani rok za prvi odgovor najkasnije 24 sata od prijema zahteva, a zahtevi stižu mejlom ili preko tiket sistema. Podrška radi radnim danima od 9 do 17 časova. U praksi se odgovara mnogo brže, ali tiket poslat u petak u 16:40 ne može da se obeća kao rešen do subote ujutru. Zato u ugovoru sa klijentom ne sme da stoji obećanje koje je strože od uslova pod kojima sami kupujete uslugu. Kako se to piše klauzulu po klauzulu, pokriva tekst o tome šta agencija sme da obeća klijentu.
Tri rečenice za klijenta
Klijent u prvom trenutku ne traži objašnjenje uzroka. Traži da zna da je neko preuzeo problem. Odgovor od tri rečenice obično je dovoljan:
- Šta je utvrđeno: „Sajt je nedostupan i uzrok nije u sadržaju, nego u podešavanju domena.“
- Ko radi na tome: „Prijavili smo problem i pratimo ga.“
- Kada sledi sledeća poruka: „Javljamo se do 12 časova sa novim stanjem, ili ranije ako se reši.“
Namerno nema vremena popravke. Rok koji zavisi od trećeg lica ne treba obećavati u svoje ime. Obećajte ono što kontrolišete: kada ćete se javiti.
Posle incidenta, kad se sve smiri, pošaljite kratak zapis: šta se desilo, šta je uzrok, šta je urađeno i šta se menja da se ne ponovi. Takva poruka košta pet minuta, a klijent iz nje vidi razliku između agencije koja drži stvar pod kontrolom i one koja samo prosleđuje tikete.
Kada je pitanje za plaćenu uslugu, a ne za podršku
Klijent koji traži odgovor u nedelju uveče ili za sat vremena ne traži podršku iz hosting paketa. Traži dežurstvo, a to se ugovara i naplaćuje posebno. U našim paketima za održavanje servera vreme odgovora ide od hitne intervencije u roku od 4 sata radnim danom, preko 2 sata, do odgovora u roku od 30 minuta, 24 sata dnevno tokom cele godine, uz nadzor sistema. Dodatni sat rada van paketa je 100 evra plus PDV. Detalji su na stranici održavanje servera.
Klijentu koji ima samo jedan sajt i nekoliko upita dnevno takav paket nije potreban. Za onog čiji sajt nosi porudžbine ili interni sistem, razlika od dva sata do sledećeg radnog dana je novac, i to treba reći jasno, pre prvog kvara.
Zašto se razvrstavanje lakše radi kada je svaki klijent na svom nalogu
Dijagnoza je znatno brža kada svaki klijent ima odvojen nalog sa sopstvenim panelom, bazom, mejlovima i resursima. Pun disk jednog klijenta ne obara sajt drugog, a log koji čitate pripada jednom sajtu, ne njih trideset. Agencijama koje vode više klijenata zato odgovara paket sa odvojenim nalogom po klijentu, a jednim mestom za pristup svima. Ostale uslove i način rada podrške pogledajte na stranici podrška.
Šta zastoji rade sa pretragom
Google u svojoj dokumentaciji navodi da kod grešaka iz grupe 5xx crawler privremeno usporava obilazak sajta, a već indeksirani URL-ovi se zadržavaju u indeksu, ali se na kraju izbacuju ako se greška ne ispravi. Kada server ponovo vrati ispravan odgovor, obilazak se postepeno vraća na staro. Jedan kratak zastoj ne menja pozicije, ali sajt koji pada iz nedelje u nedelju hoće. Zato incident ne zatvarajte kad sajt proradi, nego kad znate zašto je pao.
Pre nego što krivite sajt, hostera ili klijenta, proverite domen, sertifikat i potrošnju resursa. Tri provere od po dva minuta ukinu najveći deo nepotrebnih tiketa.
