Et dashbord fullt av
oransje varsler
Hostingleverandøren sendte en e-post om «kritisk sårbarhet» i forrige uke. Du logget inn i wp-admin for første gang på lenge, og der sto det og lyste: oransje varsler nedover hele pluginlisten og en WordPress-versjon som ikke er oppdatert på flere måneder. Byrået som bygde siden, har vært taust siden siste faktura.
Slike e-poster får vi videresendt hver måned. WordPress vedlikehold sto i tilbudet en gang, men byrået gikk videre til neste prosjekt, og ansvaret for WordPress-drift forsvant et sted mellom to kontaktpersoner. Driftsavtalen ble aldri signert.
Og hos mange leverandører betyr «vedlikehold» fortsatt én ting: noen trykker «oppdater alt» siste fredag i måneden og sender faktura etterpå.
Håp er ingen driftsmodell.
Av hackede CMS-er kjører WordPress
Fra nedetid til varsel
Garantert oppetid på Pro
For en ferdig testet oppdatering (CI/CD)
Sju tegn på at WordPress-siden mangler vedlikehold
- 01
WordPress-versjonen ligger mer enn én versjon bak. Kjører du 6.4 mens 6.7 er ute, er hullene som ble tettet underveis offentlig kjent.
- 02
Pluginlisten lyser oransje. Står WooCommerce eller Yoast der, eller noe annet som behandler brukerdata, haster det ekstra.
- 03
Ingen har oversikt over admin-tilgangene. Den forrige utvikleren har en. Praktikanten fra 2023 har nok en også.
- 04
Gjenoppretting fra backup er aldri testet. «Hostingen tar jo backup» er en antakelse, ikke en rutine.
- 05
Siden laster tregere enn i fjor. Databasen eser ut, og hver plugin som står urørt legger på sine millisekunder.
- 06
Et staging-miljø ble aldri satt opp, så hver oppdatering går rett i produksjon — dekkskift mens bilen ruller.
- 07
Byrået som bygde siden svarer ikke lenger. Eller de svarer at nettsiden ikke er deres bord nå.
Dette legger vi i
«testet oppdatering»
Hver oppdatering av WordPress selv eller en plugin går først til staging — en kopi av produksjonssiden med samme database og samme PHP 8.4-runtime. Der kjører testene. Skjemaer sendes inn, betalingsflyten gjennomføres, innlogging og API-integrasjoner verifiseres, og en visuell regresjonstest sammenligner skjermbilder piksel for piksel.
Først når alt lyser grønt, deployes endringen til produksjon gjennom CI/CD-pipelinen, kjørt med WP-CLI i stedet for oppdateringsknappen i dashbordet.
Automatisert er runden unnagjort på under 15 minutter. Manuelt: tre timer. Og hos leverandøren som bare trykker «oppdater alt», tar den null minutter — helt til dagen det går galt og regningen kommer med renter.
Når serveren gir opp
midt på natten
En plugin-oppdatering river med seg PHP-prosessen, eller serveren slutter rett og slett å svare. Klokken er 03:14 og forsiden er hvit.
Overvåkningen vår fanger nedetiden innen 60 sekunder og varsler automatisk. En senior-utvikler vurderer alvorlighetsgraden og starter feilsøkingen der og da — ikke etter frokost.
De færreste sider har bruk for dette, og det sier vi gjerne høyt: for de aller fleste holder Basis eller Pro i massevis. Unntaket er omsetningen som aldri tar pause. Driver du en nettbutikk som selger mens du sover, eller en tjeneste kundene forventer å nå hele døgnet, betaler nødrespons utenfor arbeidstid seg første gangen den brukes.
WordPress vedlikehold i tre SLA-nivåer
Samme side, med og uten vedlikehold
En WordPress-side står aldri stille. Revisjoner hoper seg opp i databasen, objektcachen mister treffprosent og hver forsømt plugin legger på sine egne millisekunder for hver eneste forespørsel. Etter et år måles forskjellen i hele sekunder [1].
Plattformen er halve jobben
FrankenPHP med intelligent cache
Sikkerhet i flere lag
Backup som lar seg gjenopprette
Overvåkning hvert minutt
Innholdet i en driftsavtale
Vedlikehold er oppgavene, drift er ansvaret rundt dem. En driftsavtale samler begge deler under én månedspris og ett telefonnummer, og hos PXL hviler den på fire faste rutiner.
Overvåkning. Oppetiden måles hvert minutt; nedetid varsles innen 60 sekunder, ikke i en månedsrapport tre uker senere. Sårbarhetsskanningen kjører daglig og dekker både WordPress selv og alle temaer og plugins.
Oppdateringer. Veien til produksjon går alltid gjennom staging og automatiserte tester — aldri rett fra dashbordet, uansett hvor liten endringen ser ut. Sikkerhetsoppdateringer hopper over køen og rulles ut innen 48 timer.
Backup og gjenoppretting. Daglig backup, gjenopprettingstest med jevne mellomrom. En utestet backup er en zip-fil med godt rykte.
Responstid. SLA-en tallfester alt: 8 timer på Basis, 30 minutter på Enterprise. Hvem som rykker ut, og hvor raskt, er avtalt lenge før noe går galt — ikke improvisert klokken fire om natten.
Brenner det? Akutt WordPress-hjelp først. Vil du heller begynne i den rolige enden, kan du først lese deg opp på hva en WordPress-nettside koster, fra utvikling til løpende drift. Begge veier ender påfallende ofte i samme driftsavtale, den ene bare med høyere puls underveis.
Gjøre jobben selv?
For en enkel blogg uten integrasjoner: ja. Dokumentasjonen på WordPress.org er god, og mye av jobben lar seg automatisere med WP-CLI og cron.
Spørsmålet er om det faktisk blir gjort. Hver uke. Leser du changelogen før du trykker oppdater, og forstår du hvorfor WooCommerce 9.4 brått knekte betalingspluginen som hadde fungert i tre år? Har gjenopprettingen vært testet én eneste gang?
De fleste som driver en bedrift, har jo en bedrift å drive. Timene bør gå dit.
Regnestykket er nøkternt. Oppryddingen etter én sikkerhetshendelse koster fra 15 000 til 80 000 kr. En nettbutikk med 50 000 kr i daglig omsetning som blir liggende nede et helt døgn, taper fortjeneste nok til å dekke driftsavtalen i et halvt år — og kundetilliten som ryker, står ikke i noe regneark.