WordPress for store bedrifter, skalerbarhet og sikkerhet

De fleste artikler om Enterprise WordPress starter i arkitekturdiagrammet. Vi starter et annet sted: i uke 40 av driften, lenge etter at lanseringsfesten er over. Det er der en stor WordPress-installasjon enten holder seg i live eller begynner å råtne innenfra. Skalerbarhet og sikkerhet er ikke noe du kjøper ved lansering. Det er noe du beholder gjennom en rutine som tåler at folk slutter, at leverandører bytter prismodell og at en fredag ettermiddag går galt.

En stor organisasjon har sjelden problemer med å bygge noe nytt. Problemet er at den allerede har 40 nettsteder, 12 integrasjoner, fire byråer i rullering og en plugin som ingen tør å oppdatere fordi ingen husker hva den gjør. Denne guiden handler om hvordan WordPress ser ut når den driftsdelen er ryddig, og hva arkitekturen din faktisk må tåle for at rutinen skal være mulig i det hele tatt.

#Oppdateringer er en prosess, ikke en knapp

Knappen “oppdater alle” i wp-admin er designet for en blogg med tre utvidelser. På en installasjon med WooCommerce, en ERP-kobling og 60 utvidelser er den samme knappen en produksjonshendelse uten plan.

Rutinen vi bruker har fire faste ledd, og de kjøres i samme rekkefølge hver gang:

1. Frys tilstanden. wp db export og en filkopi av wp-content/uploads tas før noe annet skjer. Dumpen navngis med dato og hvilken oppdatering som er i ferd med å skje, ikke backup-final-2.sql.
2. Kjør oppdateringen på staging. Ikke på en staging som ble klonet i fjor, men på en som er hentet fra produksjon samme dag.
3. Verifiser funksjonelt, ikke visuelt. At forsiden laster betyr ingenting. Det som må verifiseres er kassen, skjemainnsendingen, innloggingen og den ene integrasjonen som er vanskelig å teste.
4. Deploy med en definert vei tilbake. Det siste leddet er tema for et eget avsnitt lenger ned, fordi det er det som oftest mangler.

#Staging som faktisk ligner produksjon

En staging-kopi er verdiløs hvis den avviker på de punktene som ryker. De vanligste avvikene vi finner hos nye kunder er de samme hver gang: PHP-versjonen er ulik mellom miljøene, objektbufringen er slått av på staging, og betalings- eller ERP-integrasjonen peker mot et sandkassemiljø som oppfører seg mildere enn det ekte.

Det siste punktet er ikke til å komme utenom, du skal ikke sende testordre inn i regnskapet. Men da må du vite at du ikke har testet den delen, i stedet for å tro at du har gjort det. Skriv det ned i oppdateringsloggen som utestet, og planlegg en verifisering i produksjon rett etter deploy, med noen som ser på loggene mens den kjører.

Verktøymessig holder vi oss til wp-env eller Docker lokalt, Composer for å låse versjoner av utvidelser som finnes på Packagist, og en composer.lock som er sjekket inn. Det som ikke finnes i Composer, altså premium-utvidelser med egen lisensserver, legges inn i repoet med versjonsnummer i mappenavnet. Det er lite elegant og det virker.

#Rekkefølgen som gjør feilsøking mulig

Oppdater én ting av gangen når det er mulig. Kjerne, så utvidelser, så tema, med en funksjonell test mellom hvert steg. Dette føles tregt helt til den dagen noe brekker, og du kan si nøyaktig hvilken pakke som gjorde det i stedet for å binærsøke i 23 samtidige endringer.

Unntaket er sikkerhetsoppdateringer med aktivt utnyttet sårbarhet. Da går de ut først, alene, og testingen skjer i etterkant. Den avveiningen er bevisst: risikoen for å stå åpen er større enn risikoen for at en patch-versjon brekker noe.

#Backup er ikke en fil, det er en gjenoppretting du har øvd på

En sikkerhetskopi du aldri har gjenopprettet er en hypotese. Vi har sett kopier som kjørte grønt i to år og viste seg å inneholde databasen uten wp_options, fordi tabellen var stor nok til å treffe en timeout i skriptet.

Tre ting gjør forskjellen:

• Test gjenoppretting på en fast rytme. Hent den nyeste kopien inn i et tomt miljø, kjør wp core verify-checksums, logg inn, åpne en produktside. Det tar under en time. Sett det i kalenderen.
• Ha kopier på et annet sted enn produksjonen. En kopi som ligger på samme server som nettstedet, hos samme leverandør, med samme tilgangsnøkkel, beskytter mot diskfeil og ingenting annet. Løsepengevare og en kompromittert admin-konto tar begge deler.
• Definer RPO og RTO i tall, og få dem godkjent. Hvor mye data tåler organisasjonen å miste, og hvor lenge kan nettstedet være nede. Et nettsted med nettbutikk og et rent innholdsnettsted har ikke samme svar, og prisen på driften følger det svaret.

For norske virksomheter kommer personopplysningene inn her også. Backupen inneholder kundedata, så den er en behandling i seg selv: lagringssted, oppbevaringstid og sletterutine må være beskrevet, ikke bare eksistere. Når en sletteforespørsel etterkommes i produksjon, må du vite hva som skjer med den samme raden i kopiene, og kunne forklare det.

#Planen for å rulle tilbake

Dette er punktet som oftest mangler helt. Spørsmålet er enkelt: hvis deployen om 20 minutter viser seg å være feil, hva gjør du konkret, og hvor lang tid tar det?

Filer er den lette delen. Med en deploy som bytter symlink mellom to utsjekkede versjoner er tilbakerullingen ett steg og tar sekunder. Databasen er den vanskelige delen, fordi en oppdatering som har migrert skjemaet eller skrevet om serialisert data ikke lar seg reversere ved å legge tilbake koden.

Derfor deler vi endringer i to klasser før de planlegges:

• Reversible. Tema, mesteparten av utvidelsene, konfigurasjon, innhold. Tilbakerulling er bytte av kode.
• Ikke reversible uten datatap. Kjernemigrasjoner, WooCommerce-oppdateringer som berører ordretabeller, endringer i egendefinerte tabeller. Her er veien tilbake å gjenopprette databasen fra dumpen du tok i steg 1, og da mister du alt som er skrevet siden. Det avgjør tidspunktet: slike deployer legges når skrivetrafikken er lavest, ikke når det passer kalenderen.

Vedlikeholdsvinduet skal være avtalt med dem som eier innholdet, ikke bare med teknologene. Et redaksjonelt team som publiserer en kampanje midt i vinduet er ikke ulydige, de er uinformerte.

#Hva arkitekturen må tåle for at rutinen skal fungere

Når driften er ryddig, er det arkitekturen som setter taket. Og her er poenget ikke “kjøp en større server”. Vertikal skalering treffer en vegg, og den veggen kommer alltid på et ubeleilig tidspunkt.

#Horisontal skalering forutsetter at applikasjonen er tilstandsløs

Å kjøre flere identiske kopier av applikasjonslaget bak en lastbalanserer, med Docker og Kubernetes eller en enklere oppsettsform, krever at ingen node eier noe unikt. I praksis betyr det tre ting for et WordPress-oppsett: wp-content/uploads flyttes til delt lagring eller objektlagring, sesjoner og bufring legges i Redis i stedet for på lokal disk, og wp-cron slås av til fordel for en systemstyrt cron som kjører fra ett sted.

Det siste er en klassiker. Standard wp-cron utløses av trafikk. På et nettsted med mange noder og mye trafikk betyr det at samme planlagte jobb kan starte flere ganger parallelt, og på et nettsted med lite trafikk betyr det at den ikke starter i det hele tatt. Begge feilene finnes i produksjon hos folk som tror de har planlagte jobber.

#Databasen er nesten alltid flaskehalsen

Skriv og les skilles: én primærdatabase for skriving, replikaer for lesing. Det hjelper ikke hvis spørringene i seg selv er dårlige, og på en moden WordPress-installasjon er de vanligste årsakene kjedelige og velkjente:

• Autoloadede opsjoner. wp_options med flere megabyte autoload = yes lastes på hver eneste forespørsel. Sjekk størrelsen med en gang, det er den billigste målingen som finnes.
• Transienter uten utløp som hoper seg opp når objektbufringen ikke er på plass.
• Metaspørringer uten indeks, typisk et filter i en produktkatalog eller et arkiv som sorterer på et egendefinert felt.
• Søk som går mot LIKE %...%. Når katalogen vokser, flyttes søk til ElasticPress eller tilsvarende, ikke fordi det er moderne, men fordi et fulltekstsøk mot en stor wp_posts låser tabellen.

Query Monitor lokalt og et APM-verktøy i produksjon finner disse på en ettermiddag. Vi setter varsling på tregeste spørring per endepunkt, ikke på gjennomsnittet, fordi gjennomsnittet skjuler nøyaktig den spørringen som ødelegger kassen.

#Edge, bufring og det bufringen ikke løser

En stor del av forespørslene bør aldri nå PHP. Med Cloudflare, Akamai eller tilsvarende serveres anonym trafikk fra et punkt nær brukeren, og opprinnelsesserveren ser bare det som må være dynamisk. For Core Web Vitals er dette den tyngste enkeltspaken, særlig for TTFB.

Avveiningen ligger i invalidering. Bufringen er verdiløs hvis den serverer gammel pris, og den er farlig hvis den serverer en innlogget brukers side til en annen. Regelen vi holder oss til: buffer aggressivt på anonym trafikk, sett en eksplisitt purge ved publisering og ved priser og lagerendring, og ha en variasjonsnøkkel som skiller innlogget fra ikke innlogget. Test det siste med en gang, for det er den feilen som blir en personvernhendelse og ikke bare en irritasjon.

#Sikkerhet som drift, ikke som produkt

WordPress får urettferdig mye kritikk for sårbarheter som i praksis sitter i utvidelser og i rutiner. Kjernen har et modent sikkerhetsteam og en bakoverkompatibilitet som gjør automatiske mindre oppdateringer trygge for de fleste.

Det som faktisk avgjør sikkerhetsnivået i en stor organisasjon er mer prosaisk:

• Tilganger som følger folk ut av døra. Administratorkontoer for byråer og tidligere ansatte er den vanligste funnkategorien i revisjonene våre. Gjennomgang av brukerlisten hvert kvartal, med rollen begrunnet, koster en time.
• Roller som er smalere enn Administrator. En redaktør trenger ikke plugin-installasjon. DISALLOW_FILE_EDIT og DISALLOW_FILE_MODS i wp-config.php fjerner hele klassen “noen redigerte temaet i wp-admin”.
• Tofaktor på alt som kan logge inn, inkludert SSH og hostingpanelet, ikke bare wp-admin.
• Revisjonsspor. Hvem endret hva og når. Uten dette blir en hendelse en diskusjon i stedet for en undersøkelse.
• Leverandørkjeden. Hver utvidelse er kode fra noen andre som kjører med dine rettigheter. Vi fører en liste med eier, siste utgivelse og hva som skjer hvis prosjektet dør. En utvidelse uten oppdatering på to år er en beslutning som skal tas bevisst, ikke en tilstand du oppdager under en revisjon.

For norske virksomheter ligger det et lag til oppå dette. NSMs grunnprinsipper for IKT-sikkerhet gir en struktur som gjenkjennes av både revisor og ledelse, og kravene til universell utforming av IKT betyr at et offentlig nettsted i praksis skal måles mot WCAG. Det siste treffer WordPress-prosjekter konkret: et tema med for lav kontrast eller en karusell uten tastaturnavigasjon er ikke bare en designsak, den er et avvik noen kan klage på. Ta det i temautviklingen, ikke i et tilgjengelighetsoverlegg som legges på til slutt.

#Integrasjoner uten å låse deg fast

En bedriftsnettside snakker med resten av huset: CRM, ERP, e-postplattform, lagersystem, kanskje BankID eller Vipps i kassen. Modenheten i REST API og GraphQL gjør at WordPress fint kan være innholdsnavet i det bildet, med en frontend som hentes separat der det gir mening.

To ting avgjør om integrasjonene blir et aktivum eller en gjeld. Det første er hvor koden bor. Integrasjonslogikk hører hjemme i en egen plugin under versjonskontroll, ikke i functions.php i temaet, og ikke i et grensesnitt for lavkodeflyt som ingen kan lese i en diff. Da overlever den et temabytte, og den kan rulles tilbake alene.

Det andre er hva som skjer når motparten er nede. En synkron kobling som venter på SAP gjør at nettstedet ditt går ned når SAP gjør det. Køer, tidsavbrudd med fornuftige verdier og en definert oppførsel ved feil er billigere å bygge inn fra start enn å ettermontere under en hendelse.

#Multisite og redaksjonell styring på tvers av land

For en organisasjon med mange markeder er Multisite fortsatt den mest forutsigbare måten å kjøre mange nettsteder på én kodebase. Fordelen er reell: én oppdateringsrutine i stedet for 40, delte brukere og delt tema, separate innhold og domener.

Avveiningene skal være kjent før du velger den:

• Oppdateringer treffer alle nettstedene samtidig. Det er en styrke i drift og en risiko ved en dårlig utvidelse.
• Databasen får et tabellsett per nettsted. På noen hundre nettsteder blir enkelte vedlikeholdsoperasjoner tunge.
• En kompromittert superadmin er en kompromittert portefølje, ikke ett nettsted.

Redaksjonelt er gevinsten større enn den tekniske. En arbeidsflyt med utkast, juridisk gjennomgang og publisering gir en revisjonsvei for hvem som godkjente hva. I praksis er det dette som gjør at et lokalt markedsteam får publisere selv, uten at sentral kommunikasjon mister oversikten.

#Eierskap, kompetanse og kostnadsbildet

Lukkede bedriftssystemer krever lisens før første kodelinje. WordPress er åpen kildekode, så budsjettet flyttes fra lisens til utvikling og drift. Det er en reell forskjell, men den er ikke gratis: en installasjon uten fast vedlikehold koster mer i tapt tid over tre år enn lisensen den erstattet.

Eierskapet er poenget som holder over tid. Koden og dataene er dine, så du kan bytte hosting eller byrå uten å bygge på nytt. Det forutsetter at leveransen faktisk er overførbar: repo hos deg, dokumentert miljøoppsett, ingen hemmelige skript på en laptop. Be om det i kontrakten, ikke i sluttfasen av prosjektet.

Kompetansebasen er den siste praktiske grunnen. Det finnes et stort miljø rundt WordPress, også lokalt gjennom meetups og WordCamp, og dokumentasjonen i WordPress Developer Handbook er åpen. For en organisasjon betyr det at neste utvikler kan settes inn i koden uten en leverandørspesifikk sertifisering.

#Konklusjon: det logiske valget for store bedrifter

WordPress er ikke lenger en underdog i bedriftsverdenen. Den skalerer horisontalt, den kan driftes med de samme rutinene som resten av infrastrukturen din, og den lar deg beholde kode og data.

Men ingen av delene kommer av seg selv. Det som skiller en stor WordPress-installasjon som holder i årevis fra en som forfaller, er de kjedelige tingene i denne artikkelen: oppdateringer som testes før de treffer produksjon, sikkerhetskopier noen har gjenopprettet på ordentlig, og en skrevet plan for hvordan du kommer deg tilbake når en endring var feil.

Er dere klare for å rydde i den korporative WordPress-driften? Kontakt WPPoland for en Enterprise-revisjon.

Se vår WordPress-sikkerhetsrevisjon.