WordPress Vedlikehold & Support i Trondheim

WordPress-vedlikehold i Trondheim handler sjelden om å bygge noe nytt. Det handler om å holde et nettsted som allerede bærer søknader, påmeldinger, forskningsformidling og studentrettet informasjon oppe, raskt og lovlig, måned etter måned, mens NTNU-kalenderen, semesterstart og konferanseperioder endrer belastningen rundt det. Denne siden beskriver hvordan løpende drift og støtte ser ut for en virksomhet som driver fra Trondheim.

Utgangspunktet er alltid det eksisterende nettstedet, ikke et idealisert ett. Plugin-inventaret, hosting-oppsettet, backup-historikken, søknads- og påmeldingsflytene og sikkerhetsposisjonen kartlegges først, deretter låses en månedlig rytme med oppdaterings- og hendelsesvinduer som respekterer når forsknings- og studenttrafikken i Trøndelag faktisk topper.

#WordPress-vedlikehold og støtte i Trondheim

Et nettsted i Trondheim som knyttes til forskning, utdanning, studenttjenester eller spin-off-virksomhet rundt NTNU møter en sammensetning av krav som er typisk for en universitetsby, men sjelden like synlige i byer uten sterk akademisk sesong. Vipps i kassen eller i påmeldingssteget der det selges kurs og arrangementer, Bring eller PostNord der det sendes materiell, BankAxept ved siden av Visa og Mastercard, Klarna for delbetaling, og over det hele et lovverk som krever at siden er universelt utformet etter WCAG. Ved siden av dette ligger studentkalenderen: semesterstart, søknadsfrister, eksamensperioder og konferanseuker som fyller landingssider på noen dager. Vedlikeholdsarbeidet handler om å holde alle disse delene i drift når WordPress-kjernen, plugins, temaer og betalingsintegrasjoner 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 søknads- eller påmeldingsflate oppdages før brukerne rapporterer den, ikke etterpå
• Testede oppdateringer av WordPress-kjerne, plugins og temaer i et testmiljø før utrulling, med dokumentert tilbakeføring per syklus, fordi en oppdatering som bryter søknad, påmelding eller dokumentnedlasting koster tillit og tid per time i toppperioder
• 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, semestertekster, arrangementssider og småfeil uten at det må settes opp et eget prosjekt

#Markedet og det tekniske miljøet i Trondheim

Trondheim er Norges teknologihovedstad, hjem til NTNU og et blomstrende forskningsdrevet startup-økosystem. Det digitale miljøet er formet av universitetet, forskningsinstitutter, studentorganisasjoner og selskaper som vokser ut av forskningsmiljøer. Det praktiske utslaget for vedlikehold er at mange Trondheim-baserte virksomheter har et nettsted bygget raskt før et prosjekt, et konferanseprogram eller en søknadsrunde, 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 semesterstart eller en konferanse, med et plugin-utvalg som vokste etter behov for påmelding, flerspråklighet, dokumentnedlasting og betalinger, er den vanligste situasjonen vi tar over i Trondheim. 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 en søknads- eller påmeldingsflyt som sist ble testet før forrige semester.

Lokale betalings- og sesongvaner avgjør hvilke deler av siden som er mest forretningskritiske. I Norge betaler godt over halvparten med Vipps, kortbetaling via BankAxept, Visa og Mastercard ligger like bak, og Klarna dekker delbetaling. For forskningsformidling og studentrettede tjenester er det søknadsbekreftelsen, påmeldingsstatusen og dokumentnedlastingen som er like kritiske som selve betalingen. Der det sendes materiell, dominerer Posten og Bring sammen med PostNord. Det styrer hva vi overvåker tettest: søknads- og påmeldingsflyt, betalingstilbakekall der det er relevant, og sider som bærer engelsk i tillegg til norsk for internasjonale forskere og studenter.

#NTNU-sesong og studenttrafikk

Sesongen i Trondheim er ikke en jevn kurve. Trafikken stiger kraftig rundt semesterstart, søknadsfrister, opptaksperioder og konferanseuker, og faller når semesteret er i gang og kalenderen demper ekstraordinære hendelser. For WordPress-drift betyr det tre konkrete ting.

For det første må oppdateringer i testmiljø og produksjon planlegges utenom de dagene og timene der søknad, påmelding og arrangementssider tar flest treff. Et oppdateringsvindu midt i en søknadsdeadline, eller midt i første uke av semesteret, er en unødvendig risiko. For det andre må ytelsesreferansen fra onboardingen ikke bare måles i rolige uker. En Lighthouse-score i juli sier lite om hvordan landingssider, skjemaer og dokumentarkiver oppfører seg når studenttrafikken topper i august og januar. For det tredje må hendelsesrespons ha en eskaleringsvei som tar høyde for at en nede søknadsflate en fredag før deadline er en annen type hendelse enn samme feil en tirsdag midt i semesteret.

Vi skriver disse vinduene inn i vedlikeholdsavtalen: når oppdateringer kan gå til produksjon, når gjenopprettingstestene skal kjøres, og hvordan SLA-en eskaleres når studentsesongen topper. Det er ikke teater. Det er den eneste måten å holde risikoen synlig for den som eier tillit og oppetid i Trøndelag.

#Forskningsnettsteder og oppetidskrav

Forskningsmiljøer i Trondheim bruker ofte WordPress til prosjektkataloger, publikasjonsoversikter, konferanseprogrammer, karriereflater for stipendiater og B2B- eller samarbeidsskjemaer mer enn til klassisk nettbutikk. Driftsrisikoen ligger da i skjemaer, dokumentnedlasting, flerspråklige sider og integrasjoner mot CRM, e-postverktøy eller påmeldingsløsninger. En plugin-oppdatering som bryter et søknadsskjema for en konferanse eller en forskningsutlysning er like kostbar som en brutt kasse, bare at tapet først synes når fristen har gått ut og henvendelsene mangler.

Oppetid for et forskningsnettsted er ikke et kosmetisk mål. Når en utlysning, et konferanseprogram eller et studentrettet skjema er nede under en kjent topp, mister virksomheten ikke bare trafikk, den mister tillit hos partnere, søkere og studenter. Derfor testes oppdateringer i testmiljø mot den faktiske søknads- eller påmeldingsflyten før produksjon, ikke bare mot forsiden.

Vi bytter ikke ut en fungerende forsknings- eller studentstack 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 semestertekster og arrangementssider oppdateres uten at hver tekstendring blir et utviklingsprosjekt.

#Testmiljø- og hendelsesvinduer i Trøndelag

Oppdateringer i Trondheim planlegges etter virksomhetens kalender, ikke etter en generisk ukerytme. For et forskningsprosjekt kan det bety å unngå dager med kjent søknadsfrist. For en studentrettet tjeneste kan det bety å unngå første ukene i august og januar. For et konferansenettsted kan det bety å unngå dagene rett før og under påmeldingstopp.

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 søknad, påmelding, Vipps der det er relevant, skjemaer 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 søknads- eller semesterstarttopper kan inkludere raskere beslutningsvei for tilbakeføring, fordi tapet per time er høyere når søkere og studenter 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, søknads- eller påmeldingsflyt, 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ø, søknad og kritiske skjemaer testes, og endringene flyttes til produksjon i et avtalt Trøndelag-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 Trondheim-bedrifter handler stort sett om de samme tingene:

• En oppdatering brøt søknad eller påmelding midt i en deadline, og ingen oppdaget det før henvendelsene falt. Når oppdateringer testes i testmiljø mot søknadsflyten først, og produksjon bare skjer i avtalte vinduer, fanges denne typen feil før den når søkere og studenter.
• Redaktører overskriver semester- eller konferansesider eller publiserer halvferdige programtekster på flere språk. Redaksjonelle arbeidsflyter med revisjonshistorikk, planlagt publisering og riktige brukerroller fjerner mesteparten av den friksjonen.
• En hostingleverandør med ustabil oppetid under trafikkspisser rundt semesterstart. 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 semester 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 studenttrafikken 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 Trondheim-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 semester- eller konferansetrykk, 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 personopplysninger 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 forsknings- og studentrettede sider kommer ofte også strengere forventninger til samtykke, lagringstid og tilgangskontroll på søknadsdata. 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 søknadssteg 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 i et marked der kortbetaling og Vipps gjør at påmeldingsbeslutningen tas på sekunder, ofte på mobilnett rundt campus. En treg søknadsflate på mobil 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 en utdatert frist, et utdatert program eller en utdatert pris.
• 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 semesterstartsmåling, slik at effekten er etterprøvbar i månedsrapporten.

#Spørsmål Trondheim-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 søknad eller påmelding? Oppdateringer kjøres i testmiljø og testes mot søknad, påmelding og betaling 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 Trondheim? Vi har tyngdepunkt i norske byer inkludert Trondheim og Trøndelag, 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, sesongkrav 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 Trondheim. 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 søknad 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 søknad eller påmelding tar imot en testinnsending 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 søknader 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 betalings-, påmeldings- og e-postleverandø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 påmeldingsintegrasjon 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 søknads- eller arrangementside, en testinnsending gjennom skjema eller påmelding, og et bilde eller dokument 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 søkt, påmeldt, 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 et forsknings- eller studentrettet nettsted i Trondheim som tar søknader gjennom en kjent deadline 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 prosjektflate, er det samme tapet vesentlig billigere i direkte omsetning, men kan fortsatt koste i tillit 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 oppetid 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, søknadsnumre 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, søknad eller påmelding, skjemaer, bilder, integrasjoner mot Vipps, Klarna og eventuelle e-postleverandører. 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 påmelding, 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.

#Sesongkalender for drift i Trondheim

En praktisk driftskalender for Trøndelag skiller mellom rolige semesteruker, oppbygging før semesterstart, høysesong rundt opptak og konferanser, og etterarbeid. Rolige uker er tiden for større oppdateringer, PHP-oppgraderinger, temaopprydding og full gjenopprettingstest. Oppbygging før august og januar er tiden for å låse plugin-versjoner som er testet, varme CDN-cache for de viktigste landingssidene, og bekrefte at flerspråklige søknads- og påmeldingssteg fortsatt fungerer. Høysesong er tiden for minimale endringer, tette overvåkingsintervaller og rask tilbakeføring hvis noe glipper. Etterarbeid er tiden for å rydde midlertidige arrangementssider, arkivere utdaterte frister 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 semesterstart fordi noen fulgte en generisk månedsliste i stedet for virksomhetens kalender i Trondheim.

#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 Stavanger for hvordan avtalen tilpasses der.

#Start en samtale

Hvis virksomheten din i Trondheim 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.