WordPress Vedlikehold & Support i Stavanger

WordPress-vedlikehold i Stavanger handler sjelden om å bygge noe nytt. Det handler om å holde et nettsted som allerede bærer leverandørforespørsler, karriereflater, dokumentnedlasting og B2B-kontakt oppe, raskt og lovlig, måned etter måned, mens energi- og leverandørkjeden rundt Forus endrer arbeidsmønstre og sikkerhetskrav rundt det. Denne siden beskriver hvordan løpende drift og støtte ser ut for en virksomhet som driver fra Stavanger.

Utgangspunktet er alltid det eksisterende nettstedet, ikke et idealisert ett. Plugin-inventaret, hosting-oppsettet, backup-historikken, skjemaene som fanger anbud og henvendelser, og sikkerhetsposisjonen kartlegges først, deretter låses en månedlig rytme med oppdaterings- og endringsvinduer som respekterer når industriell B2B-trafikk i Rogaland faktisk er kritisk.

#WordPress-vedlikehold og støtte i Stavanger

Et nettsted i Stavanger som støtter energi-, olje- og gassrelatert virksomhet eller leverandører til den, møter en sammensetning av krav som er typisk for Rogaland, men sjelden like synlige i byer uten tung industriell B2B. Vipps og kortbetaling der det selges kurs, merch eller tjenester, BankAxept ved siden av Visa og Mastercard, Klarna der delbetaling brukes, og over det hele et lovverk som krever at siden er universelt utformet etter WCAG. Ved siden av dette ligger Forus-rytmen: arbeidsdager der forespørselsskjemaer, HSE-dokumenter, karrieresider og prosjektkataloger må fungere når innkjøpere og partnere faktisk er på jobb. Vedlikeholdsarbeidet handler om å holde alle disse delene i drift når WordPress-kjernen, plugins, temaer og betalings- eller CRM-integrasjoner oppdateres ut av takt med hverandre.

#Hva som inngår i den løpende driften

• Oppetidsovervåking med korte kontrollintervaller og varsling til en skriftlig kanal, slik at en nede kontakt- eller dokumentflate oppdages før leverandører eller kandidater rapporterer den, ikke etterpå
• Testede oppdateringer av WordPress-kjerne, plugins og temaer i et testmiljø før produksjon, med dokumentert tilbakeføring per syklus, fordi en oppdatering som bryter et anbudsskjema eller en dokumentportal koster pipeline per arbeidsdag
• Daglige sikkerhetskopier med 30 dagers oppbevaring og prøvd gjenoppretting, ikke bare en backup-fil som ingen har forsøkt å rulle tilbake
• Sikkerhetsovervåking: malware-skanning, filintegritetskontroll, overvåking av innloggingsforsøk og en Web Application Firewall tilpasset WordPress-spesifikke angrepsmønstre
• Kontroll av at universell utforming ikke forfaller mellom oppdateringer, siden kravet i Norge gjelder også private nettsteder og håndheves av Tilsynet for universell utforming av ikt
• Noen utviklertimer i måneden satt av til mindre endringer, karriereoppdateringer, dokumentlenker og småfeil uten at det må settes opp et eget prosjekt

#Markedet og det tekniske miljøet i Stavanger

Stavanger er Norges energihovedstad og et voksende teknologisenter med sterk etterspørsel etter digitale enterprise-løsninger. Forus-området samler energiaktører, leverandører, tjenesteselskaper og rådgivning knyttet til olje, gass, fornybar energi og offshore-støtte. Det digitale miljøet er mindre forbrukerdrevet enn i reiselivsbyer, men det er praktisk: B2B-kataloger, karriereflater, prosjektomtaler, HSE- og kompetansesider, og skjemaer som mater CRM eller rekrutteringsverktøy. Det praktiske utslaget for vedlikehold er at mange Stavanger-baserte virksomheter har et nettsted bygget raskt før en kontraktfase eller en rekrutteringsrunde, ofte av et byrå eller en frilanser som siden har gått videre, og som nå trenger noen til å ta over driften uten å bygge alt på nytt.

Et nettsted som ble satt opp under press før en anbudsrunde eller en kampanje for kompetanseheving, med et plugin-utvalg som vokste etter behov for skjemahåndtering, flerspråklighet og dokumentnedlasting, er den vanligste situasjonen vi tar over i Stavanger. Det betyr som regel at den første måneden inneholder mer opprydding enn vedlikehold: utdatert PHP, plugins som ikke lenger oppdateres, en backup-rutine som ser ut til å kjøre men ikke kan gjenopprettes, og et kontaktskjema eller en dokumentportal som sist ble testet før forrige større WordPress-oppgradering.

Lokale betalings- og arbeidsvaner avgjør hvilke deler av siden som er mest forretningskritiske. I Norge betaler godt over halvparten med Vipps der det er forbrukerbetaling, kortbetaling via BankAxept, Visa og Mastercard ligger like bak, og Klarna dekker delbetaling. For energi- og industriell B2B i Stavanger er det like ofte skjemaet, dokumentnedlastingen og karriereflaten som er like kritiske som en kasse. Det styrer hva vi overvåker tettest: forespørselsflyt, filnedlasting, innlogging til begrensede områder der det finnes, og sider som bærer engelsk i tillegg til norsk for internasjonale leverandørkjeder.

#Energi, Forus og industriell B2B-omsorg

Energisektoren rundt Stavanger og Forus bruker ofte WordPress til kataloger, karrieresider, prosjektomtaler, HSE-innhold og B2B-forespørsler mer enn til klassisk nettbutikk. Driftsrisikoen ligger da i skjemaer, dokumentnedlasting, flerspråklige sider og integrasjoner mot CRM eller rekrutteringsverktøy. En plugin-oppdatering som bryter et kontaktskjema for en leverandørforespørsel er like kostbar som en brutt kasse, bare at tapet først synes uker senere i pipeline-rapporten.

Industriell B2B-side har også en annen kalender enn forbrukerhandel. Trafikken følger arbeidsuken, skiftplaner og innkjøpssykluser mer enn helgehandel. Det betyr at oppdateringer i testmiljø og produksjon må planlegges utenom mandagsmorgen når forespørsler og anbudsmateriale lastes opp, og utenom midt på dagen når dokumentportaler og karriereflater brukes aktivt av ansatte og partnere. Et oppdateringsvindu midt i Forus-arbeidsdagen er en unødvendig risiko.

Vi bytter ikke ut en fungerende B2B-stack for å standardisere på vår egen. Vi dokumenterer hva som finnes, lukker de største hullene i backup og sikkerhet, og legger en rytme som lar karriere- og prosjektinnhold oppdateres uten at hver tekstendring blir et utviklingsprosjekt.

#Endringsvinduer for industriell B2B i Rogaland

Oppdateringer i Stavanger planlegges etter virksomhetens arbeidskalender, ikke etter en generisk ukerytme. For en energi- eller leverandørvirksomhet rundt Forus kan det bety å unngå mandagsmorgen og midt på arbeidsdagen. For en karriereflate kan det bety å unngå perioder med aktiv rekrutteringskampanje. For en dokumentportal kan det bety å unngå dager der partnere forventer tilgang til oppdaterte HSE- eller kompetansefiler.

Praksis i driften ser slik ut:

1. Avtale vinduet skriftlig. Hvilke ukedager og klokkeslett som er tillatt for utrulling til produksjon, og hvilke som er forbeholdt hendelsesrespons.
2. Kjør alltid i testmiljø først. Kjerne, plugins og temaer oppdateres i testmiljø, deretter testes skjemaer, dokumentnedlasting, Vipps der det er relevant, og kritiske landingssider.
3. Hold tilbakeføringsplanen klar. Før produksjon kjører, skal siste verifiserte backup og tilbakeføringstrinn være dokumentert.
4. Varsle før og etter. Skriftlig melding når vinduet åpner, og kort status når det er lukket, inkludert hva som ble endret og hva som ble verifisert.
5. Logg avvik. Hvis vinduet må brukes utenom plan på grunn av en sikkerhetsoppdatering, logges begrunnelsen i månedsrapporten.

Hendelsesvinduer er noe annet enn planlagte oppdateringer. En bekreftet sikkerhetshendelse eller produksjonsnedetid utløser SLA-arbeidsflyten uansett klokkeslett når avtalen dekker det. Forskjellen er at eskaleringen i en aktiv anbuds- eller rekrutteringsperiode kan inkludere raskere beslutningsvei for tilbakeføring, fordi tapet per time er høyere når forespørsler eller kandidater står i kø.

#Verktøyene vi drifter med

Overvåking settes opp med oppetidskontroll og PageSpeed-måling, sikkerhetsskanning kjøres med Wordfence eller tilsvarende, og oppdateringer på tvers av flere nettsteder orkestreres fra ett kontrollpanel. Sikkerhetskopier lagres adskilt fra produksjonsserveren med versjonering, slik at en kompromittert server ikke tar med seg backupene. Valgene tilpasses det som allerede er på plass hos kunden, vi bytter ikke ut en fungerende stack for å standardisere på vår egen.

#Slik foregår overtakelsen

Overtakelse av et eksisterende nettsted følger en fast rekkefølge som holder risikoen lav:

1. Onboarding-revisjon, en gjennomgang av WordPress-installasjonen: plugin-inventar, hosting, PHP-versjon, backup-status, sikkerhetsposisjon, B2B-skjemaer og dokumentflater, og en Lighthouse-referanse å måle mot senere.
2. Overvåking og sikkerhetskopier på plass, oppetid, ytelse og sikkerhet settes under overvåking, daglige backups med prøvd gjenoppretting etableres, og et testmiljø klargjøres for oppdateringstesting.
3. Første testede oppdateringssyklus, kjerne, plugins og temaer oppdateres i testmiljø, kritiske skjemaer og dokumentnedlasting testes, og endringene flyttes til produksjon i et avtalt Rogaland-vindu med tilbakeføringsplan klar.
4. Månedlig rytme, testede oppdateringer, backups, sikkerhetsskann, ytelseskontroller og en månedsrapport med målinger, beslutninger og gjenværende risiko.
5. Hendelsesrespons, ved nedetid eller en bekreftet sikkerhetshendelse utløses SLA-arbeidsflyten: respons, avgrensning, dokumentert tidslinje og rotårsak, oppretting og oppdatert rapport.

#Problemene vi oftest tar over

Henvendelsene fra Stavanger-bedrifter handler stort sett om de samme tingene:

• En oppdatering brøt et forespørselsskjema eller en dokumentportal midt i arbeidsuken, og ingen oppdaget det før pipeline-tallene falt. Når oppdateringer testes i testmiljø mot B2B-flytene først, og produksjon bare skjer i avtalte endringsvinduer, fanges denne typen feil før den når leverandører eller kandidater.
• Redaktører overskriver karriere- eller prosjektsider eller publiserer halvferdige HSE-dokumenter. Redaksjonelle arbeidsflyter med revisjonshistorikk, planlagt publisering og riktige brukerroller fjerner mesteparten av den friksjonen.
• En hostingleverandør med ustabil oppetid under kampanjer eller anbudsperioder. Vi overvåker serveren uavhengig av leverandørens egne tall og kan flytte et nettsted når infrastrukturen svikter gjentatte ganger.
• En side som har stått uten oppdateringer siden forrige større kontraktfase og nå har sårbare plugins, malware eller en backup som ikke virker. Da starter vi med en opprettingsliste før den jevne driften begynner.

#Hva du kan vente deg

Resultatet av løpende, testet vedlikehold er udramatisk, og det er poenget. Færre supporthenvendelser fordi feil fanges i testmiljø i stedet for i produksjon. Stødigere lastetider når caching, bildeoptimalisering og databaseopprydding er på plass og holdes ved like, også når en karriere- eller anbudskampanje topper. Kortere nedetid ved hendelser fordi backupene faktisk lar seg gjenopprette og responsrutinen er øvd inn. Vi måler før og etter og legger tallene i månedsrapporten i stedet for å love en bestemt prosent på forhånd.

#Hvorfor Stavanger-bedrifter velger WPPoland

Vi har drevet med WordPress siden 2007 og har sett plattformen gå fra bloggverktøy til forretningskritisk infrastruktur. Vi vet hva som ryker når et nettsted skaleres under anbuds- eller rekrutteringspress, og hva en kunde faktisk trenger sammenlignet med det de tror de trenger.

Vi er ikke et hostingselskap som selger vedlikehold som tillegg. Vi er utviklere som drifter nettsteder, både de vi har bygget selv og de andre har bygget. Vi leser koden fordi vi skriver den, og du snakker direkte med personen som gjør arbeidet, ikke med et ledd imellom.

#Sikkerhet og samsvar i en norsk kontekst

Sikkerhet i drift handler mer om disiplin enn om enkeltgrep. Herdet serveroppsett, WAF-regler tilpasset WordPress, parametriserte databasespørringer mot SQL-injeksjon, output-escaping mot cross-site scripting og hastighetsbegrensning på innlogging er grunnlinjen. Det som gjør det forretningskritisk i Norge, er at et nettsted som behandler kundedata også er underlagt GDPR, håndhevet av Datatilsynet, og at en flate som selger til forbrukere må følge angrerett og opplysningsplikt overvåket av Forbrukertilsynet. For energi- og leverandørnettsteder kommer ofte også strengere forventninger til tilgangskontroll, revisjonsspor og dokumenthåndtering. Et vedlikeholdsoppdrag som ignorerer dette etterlater en juridisk risiko, ikke bare en teknisk.

Universell utforming hører til samme bilde. WCAG-kravet gjelder også for private nettsteder i Norge, og en oppdatering som introduserer et utilgjengelig skjema eller en kontrastfeil er ikke bare en designsvakhet, den kan utløse pålegg fra tilsynet. Derfor inngår en tilgjengelighetskontroll i oppdateringssyklusen, ikke som et engangsprosjekt.

#Ytelse som forretningssignal

Lastetid betyr noe også i B2B. En treg dokumentportal eller karriereflate på mobil eller på kontornett mister henvendelser på samme måte som en nede flate gjør det. Ytelsesarbeidet i driften dekker:

• Ressurser, bilder levert som responsive WebP og AVIF, CSS renset og delt per rute, JavaScript redusert og lastet etter behov.
• Caching, flere lag: nettlesercache, CDN, applikasjonscache og databasecache med fornuftig invalidering, slik at en cachelagring ikke serverer et utdatert dokument, en utdatert stillingsannonse eller en utdatert pris der det finnes handel.
• Nettverk, HTTP/3, Brotli-komprimering og ressurshint der det faktisk flytter målingen.
• Rendering, kritisk CSS innlinjet, ikke-kritiske stilark lastet asynkront, og lazy loading av bilder under folden.

Hver endring måles mot en referanse fra onboardingen, og der det er relevant også mot en måling under aktiv kampanje, slik at effekten er etterprøvbar i månedsrapporten.

#Spørsmål Stavanger-bedrifter stiller

Kan dere overta et nettsted dere ikke har bygget selv? Ja, det er det vanligste tilfellet. Revisjonen kartlegger hva som finnes, og den første måneden går ofte mer til opprydding enn til jevn drift.

Hva skjer hvis en oppdatering bryter skjema eller dokumentportal? Oppdateringer kjøres i testmiljø og testes mot kritiske B2B-flyter før produksjon, og hver syklus har en tilbakeføringsplan. Skulle noe likevel slippe gjennom, ruller vi tilbake først og finner årsaken etterpå.

Jobber dere bare med bedrifter i Stavanger? Vi har tyngdepunkt i norske byer inkludert Stavanger og Rogaland, men drifter nettsteder for kunder i hele Norge og utenfor. Driften er uansett ekstern.

Hvordan faktureres løpende vedlikehold? Vedlikehold faktureres månedlig etter en avtalt pakke. Pris settes individuelt etter omfang, antall nettsteder, endringsvinduer og responskrav, og avtales skriftlig før arbeidet starter.

Hvordan foregår kommunikasjonen? Via en skriftlig billettkanal med en månedlig statusrapport. Telefon brukes når en beslutning må avblokkeres eller en hendelse skal gjennomgås.

#Teknisk omfang

Denne siden holder seg til WordPress-vedlikehold og støtte. Arbeidet tar utgangspunkt i tjenesten i tittelen: gjennomgang av nåsituasjonen, et risikokart, prioriterte tiltak, akseptkriterier og verifisering etter hver endring for en virksomhet i Stavanger. Dukker en annen plattform eller et annet system opp underveis, behandles det som kontekst for driften, ikke som en grunn til å bytte tema.

#Sikkerhetskopier og gjenoppretting som er testet

En sikkerhetskopi uten testet gjenoppretting er en antakelse, ikke en beredskap. Den vanligste svakheten vi finner i revisjonsfasen er ikke at backup mangler. Det er at backupen kjører, rapporterer grønt og aldri har blitt rullet tilbake til et fungerende nettsted. Et arkiv kan være ubrukelig på måter loggen ikke fanger opp: databasedumpen ble tatt uten --single-transaction mens en skjemainnsending ble skrevet, tegnsettet ble eksportert som latin1 i stedet for utf8mb4 slik at norske tegn kommer tilbake som spørsmålstegn, wp-content/uploads ble hoppet over fordi katalogen passerte en størrelsesgrense i abonnementet, eller arkivet ligger på samme disk som den serveren du nettopp mistet. Forskjellen mellom en sikkerhetskopi og et gjenopprettingspunkt er én konkret handling: at noen har lagt arkivet inn i et rent miljø og bekreftet at nettstedet kommer opp, at innlogging virker, at skjemaer og dokumentnedlasting fungerer, og at bildene faktisk vises.

3-2-1-prinsippet er minstekravet, ikke en ambisjon. Tre kopier av dataene, lagret på to ulike medier eller lagringstyper, og minst én kopi utenfor lokasjonen til produksjonsserveren. For et WordPress-nettsted i drift betyr det i praksis den daglige kopien hos hostingleverandøren, en uavhengig kopi i objektlagring hos en annen leverandør, og en versjonert kopi med lengre oppbevaring som produksjonsmiljøet ikke har skriverettigheter til. Begrunnelsen for den tredje kopien er ikke diskhavari, det er løsepengevirus og utilsiktet sletting. Et angrep som får skrivetilgang på serveren rammer også de sikkerhetskopiene serveren selv kan skrive til, og en automatisert slettejobb treffer ofte begge steder før noen rekker å se varselet. Derfor skal minst én kopi være uforanderlig, med object lock eller tilsvarende, eller ligge bak påloggingsinformasjon som verken webserveren eller WordPress-installasjonen har. Utvidelsen som brukes i driftsmiljøer er 3-2-1-1-0: én kopi uforanderlig eller frakoblet, og null feil i siste verifisering.

Et komplett øyeblikksbilde består av fire deler, og de tas sjelden samtidig. En backuprutine som bare dekker to av dem gir en falsk trygghet som først viser seg under press:

• Filene. Hele installasjonen, inkludert wp-content/plugins, wp-content/themes, wp-content/mu-plugins og egen kode som ligger utenfor wp-content. Kjernefilene kan alltid hentes tilbake fra WordPress selv og verifiseres med wp core verify-checksums, men et spesialtilpasset tema eller en integrasjon skrevet for kunden finnes bare i arkivet ditt.
• Databasen. En konsistent dump laget med wp db export eller mysqldump med --single-transaction og riktig tegnsett, slik at skjemainnsendinger som skrives mens eksporten pågår ikke havner halvveis i filen. Serialiserte verdier i wp_options og wp_postmeta er grunnen til at en domene- eller URL-endring etter gjenoppretting må gjøres med wp search-replace, aldri med søk og erstatt i SQL-filen, fordi lengdeprefikset i den serialiserte strengen da blir feil og innstillinger stille slutter å lastes.
• Opplastingene. wp-content/uploads er nesten alltid den største delen og den som først utelates for å holde arkivet lite. Mediebiblioteket og PDF-arkiver kan godt sikkerhetskopieres med et annet intervall enn databasen, men det skal være en dokumentert beslutning i vedlikeholdsavtalen, ikke en bieffekt av en størrelsesgrense hos leverandøren.
• Serverkonfigurasjonen. wp-config.php med nøkler og salt, .htaccess eller nginx-konfigurasjonen med omskrivingsregler og omdirigeringer, PHP-innstillinger som memory_limit, max_input_vars og upload_max_filesize, cron-oppsettet, sertifikater, DNS-oppføringer og hvilke API-nøkler som peker mot betaling, CRM eller rekrutteringsleverandører. Denne delen mangler i de fleste plugin-baserte backupløsninger, og det er nettopp den som avgjør om en gjenoppretting tar minutter eller en arbeidsdag.

Hvor ofte gjenopprettingen bør testes. En gjenopprettingstest er en øvelse, ikke en kontroll av at filen finnes. Intervallet vi anbefaler, og som settes skriftlig i vedlikeholdsavtalen sammen med resten av omfanget, er en full gjenoppretting til et rent testmiljø hvert kvartal, og i tillegg etter hver strukturelle endring: bytte av hostingleverandør, migrering, ny PHP-versjon, ny betalings- eller CRM-integrasjon eller en større WordPress-oppgradering. Mellom kvartalstestene holder det med en lettere kontroll, der arkivet pakkes ut, databasedumpen importeres i et midlertidig miljø og fem punkter sjekkes: forsiden, innlogging til wp-admin, en karriere- eller prosjektside, et testskjema og et dokument eller bilde fra mediebiblioteket. To detaljer avgjør om testen er verdt noe. Prosedyren skal være skrevet ned og kunne følges av en annen person enn den som satte opp backupen, og tiden testen faktisk tok skal noteres, fordi det tallet er det eneste realistiske grunnlaget for RTO-en du oppgir til ledelsen.

RPO og RTO, forklart i klartekst. RPO, Recovery Point Objective, svarer på hvor mye data virksomheten tåler å miste, målt i tid. Kjører backupen én gang i døgnet, er RPO i verste fall et helt døgn: alt som ble sendt inn, skrevet eller lastet opp etter siste kopi er borte. RTO, Recovery Time Objective, svarer på hvor lenge nettstedet kan være nede før tapet ikke lenger er akseptabelt, og den klokken inkluderer alt, ikke bare filkopieringen: å finne ut hva som skjedde, hente arkivet ned, importere databasen, teste, endre DNS og varme opp cachen. For en B2B-virksomhet i Stavanger som mottar leverandørforespørsler gjennom arbeidsuken betyr et RPO på ett døgn at innsendinger i verste fall bare eksisterer i e-postloggen og ikke i WordPress, og at de må avstemmes manuelt etterpå. For et nettsted som først og fremst er en katalog eller en kontaktflate, er det samme tapet vesentlig billigere i direkte omsetning, men kan fortsatt koste i anbud og oppfølging. De konkrete verdiene settes i vedlikeholdsavtalen, fordi de bestemmer arkitekturen og kostnaden: kontinuerlig replikering av databasen med hyppige inkrementelle kopier ligger i en annen prisklasse enn en nattlig dump, og valget skal tas av den som eier pipeline og omdømme, ikke av en standardinnstilling i en plugin.

Den første timen etter et datatap. Rekkefølgen betyr mer enn hastigheten, fordi de fleste tap blir større av forhastede tiltak enn av selve hendelsen:

1. Stopp skrivingen. Sett nettstedet i vedlikeholdsmodus, deaktiver planlagte importer, synkroniseringsjobber og WP-Cron. En gjenoppretting som kjører mens nye data fortsatt skrives, gir to ufullstendige versjoner i stedet for én komplett.
2. Bevar bevisene før du rydder. Ta en kopi av dagens tilstand som den er, både filsystem, database og logger (tilgangslogg, PHP-feillogg og brukeraktivitet i WordPress). Ved mistanke om innbrudd er den kompromitterte tilstanden det eneste grunnlaget for å finne inngangspunktet, og en gjenoppretting over den sletter sporet permanent.
3. Fastslå tidspunktet, ikke symptomet. Finn siste kjente gode tilstand ved hjelp av logger, skjemainnsendinger og publiseringstidspunkter. Uten dette punktet velger du gjenopprettingspunkt på følelsen, og risikerer å rulle tilbake til en kopi som allerede inneholder feilen.
4. Velg den siste verifiserte kopien før det tidspunktet. Ikke den nyeste. En kopi som er tatt etter at malwaren ble skrevet inn, gjenoppretter malwaren sammen med innholdet.
5. Gjenopprett til et separat miljø først. Verifiser der: innlogging, skjemaer, dokumentnedlasting, bilder, integrasjoner mot Vipps, Klarna og eventuell CRM. Først når miljøet er godkjent, settes det i produksjon.
6. Avstem tidsrommet du mistet. Alt som skjedde mellom gjenopprettingspunktet og hendelsen må hentes fra kilder utenfor nettstedet: skjemainnsendinger som også gikk på e-post, transaksjoner hos betalingsleverandøren der det er relevant, og eventuell CRM-synkronisering.
7. Bytt alle passord og nøkler hvis kompromittering ikke kan utelukkes. Databasepassord, SSH- og FTP-tilgang, API-nøkler mot betaling og CRM, og saltene i wp-config.php, som samtidig logger ut alle aktive økter.
8. Skriv tidslinjen mens den er fersk. Hva som ble oppdaget, når, hvilket gjenopprettingspunkt som ble valgt og hva som ble avstemt manuelt. Denne loggen er både grunnlaget for rotårsaksanalysen og dokumentasjonen du trenger dersom personopplysninger var berørt: personvernforordningen artikkel 33 pålegger varsling til Datatilsynet uten ugrunnet opphold etter at bruddet ble oppdaget, med 72 timer som ytre frist.

Responstider og eskaleringsvei for et slikt forløp følger av vedlikeholdsavtalen og settes sammen med RPO og RTO, ikke som et løfte i etterkant. Det som avgjør utfallet er uansett arbeidet som ble gjort før hendelsen: at kopien var komplett, at den lå utenfor rekkevidde for det som gikk galt, og at noen hadde gjenopprettet den minst én gang mens det ikke hastet.

#Endringskalender for drift i Stavanger

En praktisk driftskalender for Rogaland skiller mellom rolige perioder, oppbygging før anbud eller rekruttering, aktive kampanjeuker og etterarbeid. Rolige perioder er tiden for større oppdateringer, PHP-oppgraderinger, temaopprydding og full gjenopprettingstest. Oppbygging før en anbuds- eller karrierekampanje er tiden for å låse plugin-versjoner som er testet, varme CDN-cache for de viktigste landingssidene, og bekrefte at skjemaer og dokumentnedlasting fortsatt fungerer. Aktive uker er tiden for minimale endringer, tette overvåkingsintervaller og rask tilbakeføring hvis noe glipper. Etterarbeid er tiden for å rydde midlertidige kampanjesider, arkivere utdaterte stillingsannonser og gjennomgå hva som faktisk feilet under trykket.

Denne kalenderen erstatter ikke SLA-en. Den gjør SLA-en gjennomførbar. Uten den ender oppdateringer opp midt i Forus-arbeidsdagen fordi noen fulgte en generisk månedsliste i stedet for virksomhetens kalender i Stavanger.

#Andre norske byer

Trenger du løpende WordPress-vedlikehold i en annen norsk by, er oppgavene de samme, men med lokal kontekst for drift og responstid. Se også vedlikehold og support i Bergen og vedlikehold og support i Trondheim for hvordan avtalen tilpasses der.

#Start en samtale

Hvis virksomheten din i Stavanger trenger noen til å overta drift og støtte av et WordPress-nettsted, ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens situasjon, peker på den mest presserende risikoen og gir en ærlig vurdering av hva som bør gjøres først. Pris og omfang avtales individuelt etter den gjennomgangen.