WordPress Vedlikehold & Support i Bergen

WordPress-vedlikehold i Bergen handler sjelden om å bygge noe nytt. Det handler om å holde et nettsted som allerede tar bestillinger, viser kapasitet og selger opplevelser oppe, raskt og lovlig, måned etter måned, mens turistsesongen, cruisetrafikken og maritime arbeidsmønstre i Vestland endrer belastningen rundt det. Denne siden beskriver hvordan løpende drift og støtte ser ut for en virksomhet som driver fra Bergen.

Utgangspunktet er alltid det eksisterende nettstedet, ikke et idealisert ett. Plugin-inventaret, hosting-oppsettet, backup-historikken, bookingmotoren og sikkerhetsposisjonen kartlegges først, deretter låses en månedlig rytme med oppdaterings- og hendelsesvinduer som respekterer når Vestland-trafikken faktisk topper.

#WordPress-vedlikehold og støtte i Bergen

Et nettsted i Bergen som tar betalt eller bookinger møter en sammensetning av krav som er typisk for Vestland, men sjelden like synlige i innlandsbyer. Vipps i kassen eller i bookingsteget, Bring eller PostNord der det sendes varer, 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 sesongen: sommertrafikk mot Bryggen og fjordene, cruiseanløp som fyller sentrum på noen timer, og hotell- og restaurantflater som må holde booking, meny og kapasitet synkronisert når været eller ankomstlisten snur. Vedlikeholdsarbeidet handler om å holde alle disse delene i drift når WordPress-kjernen, WooCommerce, bookingplugins 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 bookingflate eller kasse oppdages før gjestene 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 Vipps-, booking- eller WooCommerce-oppdatering som bryter innsjekking eller bestilling koster omsetning per time i høysesong
• 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, sesongtekster, menyoppdateringer og småfeil uten at det må settes opp et eget prosjekt

#Markedet og det tekniske miljøet i Bergen

Bergen er Norges nest største by og et viktig senter for maritim, energi og teknologiindustri. Det digitale miljøet er mindre konsentrert enn i hovedstaden, men det er praktisk: maritime leverandører, energirelaterte tjenester, hospitality rundt Vågen og Bryggen, og opplevelsesaktører som selger turer mot Hardanger, Sognefjorden og øvrige Vestland-destinasjoner. Det praktiske utslaget for vedlikehold er at mange Bergen-baserte virksomheter har et nettsted bygget raskt før en sesong, 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 sommersesongen, med et plugin-utvalg som vokste etter behov for booking, flerspråklighet og betalinger, er den vanligste situasjonen vi tar over i Bergen. 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 booking- eller kasseflyt som sist ble testet før forrige cruise-sesong.

Lokale betalings- og leveringsvaner 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 hospitality og opplevelser er det bookingbekreftelsen og kapasitetsstatusen som er like kritiske som selve betalingen. Der det sendes varer, dominerer Posten og Bring sammen med PostNord. Det styrer hva vi overvåker tettest: bookingflyt, betalingstilbakekall, fraktberegning der det er relevant, og sider som bærer turisttrafikk på engelsk og tysk i tillegg til norsk.

#Turismesesong og kapasitetstopp

Sesongen i Bergen er ikke en jevn kurve. Trafikken stiger kraftig når cruiseanløp, fjordturisme og sommerferie overlapper, og faller når været og kalenderen demper reiselivet. For WordPress-drift betyr det tre konkrete ting.

For det første må oppdateringer i testmiljø og produksjon planlegges utenom de timene der hotell, restaurant og opplevelsesaktører tar flest bestillinger. Et oppdateringsvindu midt i morgenrush for innsjekking, eller midt i kveldsbestilling, er en unødvendig risiko. For det andre må ytelsesreferansen fra onboardingen ikke bare måles i lavsesong. En Lighthouse-score i februar sier lite om hvordan produktsider, bookingsteg og bildegallerier oppfører seg når cruisegjestene fyller mobilnettet i juli. For det tredje må hendelsesrespons ha en eskaleringsvei som tar høyde for at en nede bookingflate en lørdag i høysesong er en annen type hendelse enn samme feil en tirsdag i november.

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 sesongen topper. Det er ikke teater. Det er den eneste måten å holde risikoen synlig for den som eier omsetningen i Vestland.

#Maritim og hospitality WordPress-omsorg

Maritim sektor i Bergen bruker ofte WordPress til kataloger, karrieresider, prosjektomtaler 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 anbudsforespørsel er like kostbar som en brutt kasse, bare at tapet først synes uker senere i pipeline-rapporten.

Hospitality-siden er mer umiddelbar. Hotell, restaurant, cafe og opplevelsesaktører rundt sentrum og ut mot fjordene trenger at bookingkalender, meny, sesongpriser og betalingssteg holder seg synkronisert. Typiske WordPress-oppsett kombinerer et tema med bookingplugin, oversettelsesplugin og Vipps eller kortbetaling. Når disse oppdateres uavhengig av hverandre, er regresjon i bookingsteget den vanligste feilen vi ser i revisjoner. Derfor testes oppdateringer i testmiljø mot den faktiske bookingflyten før produksjon, ikke bare mot forsiden.

Vi bytter ikke ut en fungerende hospitality-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 sesongtekster og menyendringer skje uten at hver tekstendring blir et utviklingsprosjekt.

#Testmiljø- og hendelsesvinduer i Vestland

Oppdateringer i Vestland planlegges etter virksomhetens kalender, ikke etter en generisk ukerytme. For en opplevelsesaktør kan det bety å unngå dager med kjent cruisetrafikk. For et hotell kan det bety å unngå morgen- og ettermiddagsvinduer knyttet til innsjekking og utsjekking. For en maritim B2B-side kan det bety å unngå mandagsmorgen når forespørsler og anbudsmateriale lastes opp.

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 booking, Vipps, 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 høysesong kan inkludere raskere beslutningsvei for tilbakeføring, fordi tapet per time er høyere når bookingene 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, booking- eller kasseflyt, 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ø, booking og kritiske skjemaer testes, og endringene flyttes til produksjon i et avtalt Vestland-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 Bergen-bedrifter handler stort sett om de samme tingene:

• En oppdatering brøt booking eller kasse midt i sesongen, og ingen oppdaget det før bestillingene falt. Når oppdateringer testes i testmiljø mot bookingflyten først, og produksjon bare skjer i avtalte vinduer, fanges denne typen feil før den når gjestene.
• Redaktører overskriver sesongsider eller publiserer halvferdige menyer 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. 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 sommer 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 turisttrafikken 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 Bergen-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 sesongtrykk, 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 kasse eller bookingflate som selger til forbrukere må følge angrerett og opplysningsplikt overvåket av Forbrukertilsynet. 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 bookingsteg 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 kjøps- eller bookingbeslutningen tas på sekunder, ofte på mobilnett i sentrum eller om bord før en fjordtur. En treg bookingflate på mobil mister salg 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 pris, meny eller lagerstatus.
• 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 høysesongsmåling, slik at effekten er etterprøvbar i månedsrapporten.

#Spørsmål Bergen-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 booking eller kasse? Oppdateringer kjøres i testmiljø og testes mot booking 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 Bergen? Vi har tyngdepunkt i norske byer inkludert Bergen og Vestland, 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 Bergen. 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 bestilling 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 booking eller kasse tar imot en testbestilling 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 bestillinger 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 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-, booking- og fraktleverandø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 bookingintegrasjon eller en større WooCommerce-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 produktside eller bookingside, en testbestilling gjennom booking eller kasse, og et 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 bestilt, 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 hotell eller en opplevelsesaktør i Bergen som tar bestillinger gjennom hele døgnet i høysesong betyr et RPO på ett døgn at bookinger i verste fall bare eksisterer hos betalingsleverandøren 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 for maritim B2B, 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 omsetningen, 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, bestillingsnumre 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, booking eller kasse, skjemaer, bilder, integrasjoner mot Vipps, Klarna og eventuelle fraktleverandø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: transaksjoner hos betalingsleverandøren, bookingbekreftelser på e-post, fraktetiketter hos Bring eller PostNord 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 booking, 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 Bergen

En praktisk driftskalender for Vestland skiller mellom lavsesong, oppbygging, høysesong og etterarbeid. Lavsesong er tiden for større oppdateringer, PHP-oppgraderinger, temaopprydding og full gjenopprettingstest. Oppbygging før sommeren er tiden for å låse plugin-versjoner som er testet, varme CDN-cache for de viktigste landingssidene, og bekrefte at flerspråklige bookingsteg 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 kampanjesider, arkivere utdaterte menyer 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 cruisetrafikk fordi noen fulgte en generisk månedsliste i stedet for virksomhetens kalender i Bergen.

#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 Stavanger, vedlikehold og support i Trondheim og WordPress-utvikler i Oslo for hvordan avtalen tilpasses der.

#Start en samtale

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