Tåler nettsiden trafikktoppen? Lag en driftsplan før kampanjen starter

Kategori: Hosting og drift

En kampanje, produktlansering eller medieomtale kan sende langt flere besøkende til nettsiden enn normalt. Da holder det ikke at løsningen fungerer godt på en vanlig tirsdag. Hostingmiljøet, applikasjonen og eksterne tjenester må kunne håndtere belastningen samtidig.

Mange forbereder innhold, annonser og utsendelser grundig, men lar kapasiteten være en antakelse. Resultatet kan bli en nettside som svarer sakte akkurat når interessen er størst. En praktisk kapasitetsplan gjør trafikkøkningen til en håndterbar driftssituasjon, ikke en overraskelse.

Start med å beskrive hva som faktisk skal skje

«Vi forventer mye trafikk» er ikke et tilstrekkelig grunnlag for tekniske valg. Driftsansvarlig trenger å vite når belastningen kommer, hvilke sider brukerne besøker, og hvilke handlinger de skal utføre.

En topp som fordeles gjennom en hel arbeidsdag, er noe annet enn en lenke som sendes til en stor mottakerliste samtidig. Det samme gjelder forskjellen mellom lesing av en artikkel og innsending av et skjema eller gjennomføring av et kjøp.

Lag en enkel hendelsesbeskrivelse som svarer på:

• Når starter kampanjen, og hvor lenge forventes økt trafikk?
• Kommer de besøkende gradvis eller omtrent samtidig?
• Hvilke land og regioner kommer trafikken fra?
• Hvilke landingssider skal motta trafikken?
• Skal brukerne lese, søke, laste ned, sende skjema eller kjøpe?
• Hvilke eksterne tjenester inngår i brukerreisen?
• Hva er konsekvensen dersom nettsiden eller en sentral funksjon stopper?

Dette gir et bedre beslutningsgrunnlag enn et generelt ønske om «kraftigere hosting».

Skill mellom innhold som kan caches, og arbeid som må utføres hver gang

Ikke alle sidevisninger belaster serveren likt. En ferdig mellomlagret landingsside kan ofte leveres uten at publiseringsløsningen og databasen må bygge siden på nytt. Et produktsøk, en handlekurv eller en personlig innlogget side krever derimot mer behandling for hver bruker.

Del derfor kampanjeflyten i to:

• Cachebart innhold: bilder, stilfiler, skript og offentlige sider som er like for alle.
• Dynamiske funksjoner: søk, skjemaer, innlogging, lagerstatus, handlekurv, betaling og personlige data.

Denne forskjellen avgjør hvor mye hjelp dere får av caching og CDN. Hvis nesten all trafikk går til en offentlig landingsside, kan mye leveres fra mellomlagrede kopier. Hvis kampanjen sender alle inn i et avansert bestillingsløp, må selve applikasjonen og databasen tåle belastningen.

Kontroller at caching faktisk virker

Det er ikke nok at driftsmiljøet har en cachefunksjon. Dere må kontrollere hvilke sider som mellomlagres, hvor lenge kopiene beholdes, og hva som får dem til å bli slettet.

En vanlig utfordring er at publisering eller redigering tømmer langt mer cache enn nødvendig. Dersom noen gjør en liten innholdsendring under kampanjen, kan mange forespørsler plutselig treffe serveren direkte. Det kan skape en belastningstopp på et uheldig tidspunkt.

Avklar derfor på forhånd hvilke sider som skal være cachet, hvilke informasjonskapsler som omgår cachen, og hvordan landingssiden varmes opp etter en tømming.

Bruk CDN til mer enn bilder

Et CDN distribuerer innhold via servere nærmere brukerne og reduserer trafikken som må helt inn til det primære driftsmiljøet. Det er særlig nyttig når målgruppen er geografisk spredt, eller når sidene inneholder mange og store filer.

Men et CDN løser ikke alle kapasitetsproblemer. Hvis hver sidevisning må behandles av publiseringsløsningen, eller hvis alle brukere sender data til samme skjema- og databaseløsning, ligger flaskehalsen fortsatt bak distribusjonslaget.

Kontroller derfor:

• hvilke filtyper og sider CDN-et leverer
• om komprimering og moderne bildeformater er aktivert
• hvordan gamle filer fjernes når innhold oppdateres
• om beskyttelse mot uønsket trafikk er riktig konfigurert
• om feil i det primære miljøet gir en forståelig reserveside

Målet er å redusere unødvendig arbeid i opprinnelsesserveren uten å vise utdatert eller feil innhold.

Test den faktiske brukerreisen under belastning

En enkel responstest av forsiden sier lite om kampanjens viktigste funksjon. Belastningstesten bør ligne handlingene dere forventer fra reelle brukere.

Hvis målet er påmeldinger, bør testen åpne landingssiden, hente nødvendige ressurser og sende inn et kontrollert testskjema. For en nettbutikk kan testen omfatte produktvisning, søk og opprettelse av handlekurv, men betalingssteg må gjennomføres i et trygt testoppsett.

Øk belastningen gradvis. Følg samtidig med på responstid, feil, prosessorbruk, minne, databaseaktivitet og køer. Da ser dere både når kvaliteten begynner å falle, og hvilken del av løsningen som er begrensningen.

Belastningstesting skal planlegges med driftsleverandøren. En ukontrollert test i produksjon kan påvirke reelle brukere eller bli tolket som uønsket trafikk.

Velg driftsmiljø etter konsekvens og endringsbehov

Det riktige driftsmiljøet er ikke nødvendigvis løsningen med flest tekniske funksjoner. Valget bør bygge på hvor kritisk nettsiden er, hvor variabel trafikken er, og hvor raskt teamet må kunne gjøre endringer.

Et enkelt, administrert miljø kan passe godt for en stabil bedriftsnettside med forutsigbar trafikk. Løsninger med flere servere, automatisk skalering og mer avansert trafikkstyring kan være relevante når trafikken varierer kraftig eller når nedetid får store konsekvenser.

Automatisk skalering må likevel behandles som en egenskap som skal testes, ikke som en garanti. Nye ressurser må starte raskt nok, applikasjonen må kunne kjøre på flere noder, og økt kapasitet i webserverne hjelper lite dersom databasen eller en ekstern tjeneste fortsatt er flaskehalsen.

Be om konkrete svar på følgende:

• Hvilke deler av miljøet kan skaleres?
• Skjer skaleringen automatisk eller manuelt?
• Hvor lang tid tar en kapasitetsøkning?
• Finnes det begrensninger i database, lagring eller nettverk?
• Hvem følger med og griper inn under trafikktoppen?
• Hvordan påvirker ekstra kapasitet kostnadene?

Frys unødvendige endringer før kampanjen

En trafikktopp er et dårlig tidspunkt for oppdatering av publiseringsløsningen, utskifting av tillegg eller større innholdsendringer. Selv en tilsynelatende liten endring kan påvirke cache, database eller integrasjoner.

Avtal et tidspunkt der løsningen går inn i en kontrollert endringsperiode. Kritiske sikkerhetsoppdateringer må fortsatt vurderes, men kosmetiske og valgfrie endringer kan vente til kampanjen er avsluttet.

Før frysen bør dere:

1. fullføre og godkjenne landingssider og skjemaer
2. oppdatere løsningen kontrollert og teste sentrale funksjoner
3. ta en fersk backup av filer, database og nødvendig konfigurasjon
4. kontrollere at backupen kan brukes til gjenoppretting
5. dokumentere hvordan siste endring kan rulles tilbake

Rollback-planen må være kort nok til å brukes under press. Den bør forklare hvem som tar beslutningen, hva som tilbakeføres, og hvordan teamet kontrollerer at løsningen fungerer etterpå.

Overvåk hele kjeden, ikke bare serveren

Serveren kan være tilgjengelig selv om kampanjen i praksis har stoppet. Et skjema kan feile, betalingsleverandøren kan svare sakte, eller e-postbekreftelser kan bli liggende i kø.

Sett derfor opp overvåking som dekker både teknisk kapasitet og forretningskritiske handlinger. Det kan omfatte tilgjengelighet, responstid, feilkoder, databaseforbindelser, køer og gjennomføring av et kontrollert testskjema.

Varsler må ha en tydelig mottaker. Avklar hvem som vurderer hendelsen, hvem som kan endre driftsmiljøet, og hvem som informerer kampanjeansvarlig. Et varsel uten ansvar og handlingsrom gir liten verdi.

Lag en enkel plan for selve kampanjedagen

Samle de viktigste avklaringene på én side. Planen bør angi tidspunkt, forventet trafikkmønster, ansvarlige personer, overvåkingspunkter, godkjente tiltak og kontaktvei til driftsleverandøren.

Definer også terskler for handling. Eksempler kan være vedvarende økning i svartid, uvanlig mange serverfeil eller fall i antall gjennomførte skjemaer. Tersklene bør tilpasses løsningen og testes på forhånd, ikke bestemmes mens problemet pågår.

Etter kampanjen bør dere sammenligne forventningene med det som faktisk skjedde. Se på trafikkmønster, cachetreff, ressursbruk, feil og respons fra eksterne tjenester. Da får dere et bedre grunnlag for neste kampanje og kan justere hostingkapasiteten uten å basere valget på magefølelse.

Kapasitetsplanlegging er et samarbeid

Profesjonell webhosting handler ikke bare om serverressurser. Resultatet avhenger av samspillet mellom innhold, kode, database, caching, CDN, integrasjoner og operative rutiner.

Den beste forberedelsen er derfor å samle kampanjeansvarlig, utvikler og driftsleverandør tidlig. Når alle kjenner brukerreisen, belastningen og konsekvensene av feil, blir det lettere å prioritere riktige tiltak. Da kan dere bruke tid og budsjett på den faktiske flaskehalsen fremfor å kjøpe kapasitet dere kanskje ikke får nytte av.