„WordPress“ svetainės priežiūra nėra vien įskiepių atnaujinimo mygtukas. Veikianti verslo svetainė priklauso nuo temos, įskiepių, serverio, formų, el. pašto, analitikos ir išorinių integracijų. Pakeitimas vienoje vietoje gali paveikti kitą, todėl priežiūrai reikia aiškaus plano, atsakomybės ir patikros po darbų.
Geras planas atsako į keturis klausimus: kas tikrinama, kaip dažnai, kas priima sprendimą ir kaip svetainė atkuriama, jei pakeitimas sukelia problemą.
Atsarginė kopija turi būti atkuriama, o ne tik sukuriama
Prieš atnaujinimus reikia turėti naują duomenų bazės ir failų kopiją. Tačiau vien automatinio pranešimo apie sukurtą kopiją nepakanka. Periodiškai būtina patikrinti, ar kopija iš tiesų pasiekiama, nėra sugadinta ir gali būti atkurta atskiroje aplinkoje.
Kopijų dažnis priklauso nuo svetainės pokyčių. Reprezentacinei svetainei gali pakakti retesnių kopijų, o el. parduotuvei, kur kasdien keičiasi užsakymai ir klientų duomenys, reikia dažnesnio grafiko. Bent viena kopija turėtų būti saugoma ne tame pačiame serveryje kaip svetainė.
Atnaujinimus diekite kontroliuojamai
„WordPress“ branduolio, temos ir įskiepių atnaujinimai taiso saugumo spragas, suderinamumą ir klaidas. Oficialioje „WordPress“ dokumentacijoje rekomenduojama naudoti naujausias įskiepių bei temų versijas ir prieš automatinius atnaujinimus pasirūpinti atkūrimo galimybe.
Praktinė seka:
- Patikrinkite pakeitimų aprašymą ir žinomas suderinamumo problemas.
- Sukurkite naują atsarginę kopiją.
- Jei svetainė kritinė, pirmiausia atnaujinkite testinėje aplinkoje.
- Atnaujinkite komponentus mažomis grupėmis.
- Išvalykite talpyklą.
- Patikrinkite svarbiausius lankytojo scenarijus.
- Užfiksuokite, kas ir kada pakeista.
Automatiniai atnaujinimai tinka ne visiems komponentams. Mažos rizikos įskiepius galima atnaujinti automatiškai, o mokėjimų, formų, daugiakalbystės ar individualaus funkcionalumo komponentus verta prižiūrėti kontroliuojamai.
Po atnaujinimo tikrinkite realias funkcijas
Svetainė gali atsidaryti be klaidos, tačiau svarbi funkcija vis tiek gali neveikti. Po priežiūros darbų patikrinkite:
- pagrindinį puslapį ir svarbiausius nukreipimo puslapius;
- kontaktų bei užklausų formas;
- laiško gavimą ir siuntėjo adresą;
- prisijungimą bei vartotojų roles;
- paiešką, filtrus ir katalogą;
- pirkimo arba rezervacijos kelią;
- slapukų pasirinkimą ir analitikos žymas;
- vaizdą telefone ir kompiuteryje.
Jei svetainė turi individualių integracijų, kiekvienai verta turėti trumpą testavimo scenarijų. Taip patikra nepriklauso nuo to, ar administratorius prisimena visas projekto detales.
Saugumo priežiūra yra nuolatinis procesas
Saugumui neužtenka vieno įskiepio. Reikia prižiūrėti visą grandinę: prieigos teises, slaptažodžius, administratorių paskyras, serverio versijas, atsargines kopijas ir įtartiną veiklą.
Reguliariai peržiūrėkite:
- ar nėra nenaudojamų administratorių;
- ar vartotojai turi tik darbui reikalingas teises;
- ar nenaudojami įskiepiai ir temos pašalinti;
- ar PHP ir duomenų bazės versijos palaikomos;
- ar nėra netikėtų failų pakeitimų;
- ar formos apsaugotos nuo automatinio šlamšto;
- ar SSL sertifikatas galioja.
Įvykus incidentui svarbiausia ne pažadas, kad „nulaužti neįmanoma“, o aiškus reagavimo procesas: kas gauna pranešimą, kaip izoliuojama problema, iš kurios kopijos atkuriama ir kaip patikrinama priežastis.
Stebėkite ne tik svetainės pasiekiamumą
Pasiekiamumo patikra parodo, ar serveris atsako, bet neatskleidžia visų problemų. Svetainė gali grąžinti 200 būseną, nors forma neveikia, puslapis labai sulėtėjęs arba dalis turinio nerodoma.
Naudingas stebėjimo rinkinys apima:
- pasiekiamumą ir serverio klaidas;
- SSL galiojimą;
- pagrindinių puslapių greitį;
- formų pateikimą;
- 404 ir 5xx šuolius;
- neplanuotus indeksavimo pokyčius;
- analitikos duomenų nutrūkimą.
Greitį verta vertinti pagal realių lankytojų duomenis ir svarbiausių šablonų testus, o ne vien vienkartinį balą. Po naujo įskiepio ar dizaino pakeitimo galima iškart palyginti, ar nepablogėjo pagrindinio turinio atvaizdavimas ir išdėstymo stabilumas.
Atsakomybių matrica
Priežiūros sutartyje turi būti aišku ne tik ką daryti, bet ir kas priima sprendimą. Pavyzdinė matrica:
| Situacija | Priežiūros partneris | Svetainės savininkas | Patvirtinimas |
|---|---|---|---|
| Kritinis saugumo atnaujinimas | Įvertina riziką, sukuria kopiją, diegia ir testuoja | Informuojamas | Pagal iš anksto sutartą tvarką |
| Naujas funkcionalumas | Įvertina apimtį ir pateikia planą | Patvirtina poreikį bei biudžetą | Prieš programavimą |
| Turinio pakeitimas | Gali įgyvendinti techninę dalį | Pateikia ir patvirtina turinį | Prieš publikavimą |
| Incidentas | Diagnozuoja, izoliuoja, atkuria, dokumentuoja | Paskiria kontaktinį asmenį | Pagal incidento lygį |
| Vartotojo prieiga | Sukuria mažiausių teisių paskyrą | Patvirtina asmenį ir rolę | Prieš suteikiant prieigą |
Matrica apsaugo nuo dviejų kraštutinumų: pavojingų pakeitimų be verslo patvirtinimo ir ilgo laukimo, kai kritinį incidentą reikia stabdyti nedelsiant.
Incidentų prioritetai ir reakcija
Vienodas terminas visoms užduotims nėra praktiškas. Incidentus verta suskirstyti pagal poveikį:
- P1 – kritinis: svetainė nepasiekiama, neveikia mokėjimai, įtariamas duomenų saugumo pažeidimas;
- P2 – didelis: neveikia pagrindinė forma, prisijungimas ar svarbi integracija, bet svetainė pasiekiama;
- P3 – vidutinis: klaida paveikia dalį puslapių arba turi laikiną apėjimą;
- P4 – planinis: kosmetinis netikslumas, turinio korekcija ar naujas pageidavimas.
Kiekvienam lygiui sutariamas reagavimo laikas, komunikavimo kanalas ir sprendimo tikslas. Reagavimo laikas reiškia, kada pradedama diagnostika, o ne pažadą, kad bet kokia problema bus visiškai pašalinta per tą patį laiką.
Atkūrimo testo priėmimo kriterijai
Atkūrimas laikomas patikrintu tik jei testinėje aplinkoje atsidaro pasirinkti puslapiai, galima prisijungti, veikia kritinė forma ar pirkimo kelias, o duomenų bazės laikas atitinka kopijos žymą. Užfiksuokite kopijos datą, atkūrimo trukmę, trūkstamus duomenis ir testo rezultatą.
Verslui svarbūs du rodikliai: kiek duomenų galima prarasti tarp kopijų ir per kiek laiko paslauga turi būti atkurta. El. parduotuvei valandos senumo duomenų praradimas gali būti reikšmingas, o retai atnaujinamai reprezentacinei svetainei ta pati riba gali būti priimtina. Šiuos tikslus reikia sutarti pagal realią žalą, o ne pasirinkti vienodą paketą visoms svetainėms.
Kasdieniai, savaitiniai ir mėnesiniai darbai
Kasdien arba automatiškai: pasiekiamumo stebėjimas, saugumo pranešimai, kritinių formų ir atsarginių kopijų būklė.
Kas savaitę: atnaujinimų peržiūra, pakeitimų diegimas, funkcijų patikra, šlamšto ir klaidų žurnalų kontrolė.
Kas mėnesį: vartotojų prieigos, greičio tendencijos, 404 klaidos, disko vieta, licencijos, analitikos ir SEO būklė.
Kas ketvirtį: atkūrimo testas, nenaudojamų komponentų auditas, PHP ir serverio būklė, svarbiausių naudotojo kelių peržiūra.
Tikslus dažnis priklauso nuo svetainės svarbos, srauto ir pakeitimų kiekio. El. parduotuvės bei užklausas generuojančios svetainės paprastai reikalauja trumpesnio reakcijos laiko nei retai keičiama informacinė svetainė.
Aiškiai atskirkite priežiūrą nuo vystymo
Priežiūra užtikrina esamo sprendimo stabilumą: atnaujinimus, stebėjimą, kopijas ir smulkius taisymus. Vystymas keičia funkcionalumą, dizainą ar integracijas. Abi veiklos gali būti vykdomos kartu, tačiau jų apimtis ir planavimas skiriasi.
Priežiūros susitarime verta nurodyti:
- kas įtraukta į mėnesinę apimtį;
- kokios užduotys skaičiuojamos atskirai;
- reakcijos laiką pagal incidento svarbą;
- kas tvirtina rizikingus pakeitimus;
- kur saugomos prieigos ir dokumentacija;
- kaip perduodami atliktų darbų rezultatai.
SeoRocket „WordPress“ svetainių administravimo ir techninės priežiūros paslauga skirta svetainėms, kurioms reikia ne epizodinio atnaujinimo, o nuoseklios techninės atsakomybės. Jei planuojami nauji moduliai ar integracijos, juos verta atskirai įtraukti į programavimo darbų planą.
Ką turi parodyti mėnesio priežiūros suvestinė
Trumpa suvestinė turi atsakyti: kas pakeista, kas patikrinta, kokių incidentų buvo, kokia rizika liko ir kokį sprendimą reikia priimti klientui. Įrankių pranešimų kopija be paaiškinimo nėra ataskaita. Jei neatliktas planuotas atnaujinimas, turi būti nurodyta priežastis ir nauja data.
Patikimos priežiūros požymiai
Patikima „WordPress“ priežiūra yra pasikartojantis procesas: kopija, kontroliuojamas pakeitimas, realių funkcijų testas ir stebėjimas. Kai atsakomybės bei reakcijos tvarka sutartos iš anksto, mažiau laiko prarandama aiškinantis problemą jau jai įvykus.
