Tåler nettsiden kampanjetrafikken? Slik gjør dere driften klar før lansering

Kategori: Hosting og drift

En kampanje, produktlansering eller medieomtale kan sende mange besøkende til nettsiden på kort tid. Da hjelper det lite at løsningen fungerer godt på en vanlig arbeidsdag. Driftsmiljøet må håndtere både trafikkmengden og handlingene brukerne utfører når de kommer inn.

Forberedelsene bør derfor ta utgangspunkt i en konkret trafikksituasjon, ikke i en generell forventning om at hostingen «skal tåle mye». Målet er å finne ut hvor belastningen oppstår, redusere unødvendig arbeid i løsningen og vite hva dere skal gjøre dersom kapasiteten likevel blir presset.

Start med hendelsen, ikke serveren

Før dere vurderer mer kapasitet, må dere beskrive hva som faktisk skal skje. En kampanje som sender brukere til en cachet informasjonsside, belaster løsningen annerledes enn en lansering der alle skal søke, logge inn, fylle ut skjema eller gjennomføre kjøp.

Avklar minst følgende:

• Når forventes trafikken å starte, og hvor lenge kan toppen vare?
• Hvilke land eller regioner kommer brukerne fra?
• Hvilke landingssider skal motta trafikken?
• Hvilke handlinger skal brukerne utføre?
• Hvilke eksterne tjenester er brukerreisen avhengig av?
• Hva er konsekvensen dersom nettsiden blir treg eller utilgjengelig?

Et konkret scenario kan være at et nyhetsbrev sendes til hele kundebasen klokken ni, og at mottakerne ledes til en produktside med bestillingsskjema. Da må testen omfatte både produktsiden, skjemaet, kvitteringen og eventuelle integrasjoner mot CRM eller e-postsystem. Det er ikke nok å måle forsiden.

Kartlegg hele kjeden frem til brukeren

En moderne nettside leveres gjennom flere lag. Forespørselen kan gå via DNS, CDN og brannmur før den når webserveren, applikasjonen, databasen og eksterne tjenester. Flaskehalsen kan ligge hvor som helst i denne kjeden.

Lag en enkel oversikt over komponentene som kampanjen er avhengig av. Noter hvem som har ansvar for hvert ledd, hvordan det overvåkes, og hva som kan gjøres dersom det svikter. Dette gjør det lettere å skille mellom problemer i hostingen og feil i eksempelvis betalingsløsningen, skjematjenesten eller en integrasjon.

Oppetid hos hostingleverandøren er bare én del av bildet. En server kan være tilgjengelig samtidig som utsjekken feiler, databasen svarer for sakte eller innloggingen stopper. For virksomheten er det den samlede tjenesten som må virke.

Test realistisk før trafikken kommer

En kapasitetstest bør etterligne forventet bruk, men gjennomføres kontrollert. Begynn med lav belastning og øk gradvis. Følg med på responstid, feil, prosessorbruk, minne, databaseaktivitet og antall samtidige prosesser mens testen pågår.

Test gjerne flere typer trafikk hver for seg:

1. Besøk på sider som kan leveres fra cache.
2. Besøk på dynamiske sider som søk, innlogging og handlekurv.
3. Innsending av skjema eller gjennomføring av kjøp.
4. Kall til integrasjoner som må svare før brukeren kan gå videre.

En slik inndeling viser hva som faktisk skaper belastning. Dersom vanlige sidevisninger håndteres godt, men skjemaet blir tregt, bør dere undersøke skjemabehandling og integrasjoner før dere kjøper en større server.

Produksjonsmiljøet gir mest realistiske resultater, men belastningstesting der kan påvirke ekte brukere og data. Avtal derfor tidspunkt, omfang og stoppkriterier med driftsleverandøren. I et testmiljø må serveroppsett, database, caching og integrasjoner ligne produksjon tilstrekkelig til at resultatene har verdi.

Bruk caching til å redusere arbeidet

Caching gjør at ferdig generert innhold kan leveres uten at applikasjonen og databasen bygger siden på nytt for hver besøkende. For en kampanjeside kan dette gi stor avlastning, forutsatt at siden faktisk kan caches.

Kontroller at de viktigste landingssidene blir cachet, og at cachen er fylt før kampanjen starter. Test også hva som skjer når innholdet publiseres eller oppdateres. En feilkonfigurert tømming kan føre til at all trafikk plutselig sendes direkte til applikasjonen.

Ikke alt innhold bør caches likt. Handlekurv, kontoopplysninger, personlige priser og skjemakvitteringer må vanligvis behandles dynamisk. En god konfigurasjon skiller tydelig mellom offentlig innhold og brukeravhengige svar. Feil her kan være både et ytelsesproblem og et personvernproblem.

La CDN-et ta den trafikken det kan

Et CDN kan levere bilder, stilark, skript og cachede nettsider fra noder nærmere brukeren. Det reduserer belastningen på hovedserveren og kan gi jevnere levering når trafikken kommer fra flere geografiske områder.

Men et CDN løser ikke automatisk kapasitetsproblemer i dynamiske funksjoner. Dersom hver besøkende må sende data til applikasjonen, slå opp informasjon i databasen eller vente på en ekstern tjeneste, vil hovedmiljøet fortsatt få arbeidet.

Før lansering bør dere kontrollere hvilke svar som leveres fra CDN, hvilke som går til hovedserveren, og hvor lenge innholdet lagres. Sørg også for en trygg metode for å tømme eller oppdatere cachen hvis feil innhold blir publisert.

Velg et driftsmiljø som kan endres raskt

Ved forventede trafikktopper er fleksibilitet ofte viktigere enn høy kapasitet hele året. Driftsmiljøet bør kunne skaleres på en kontrollert måte, enten manuelt eller automatisk. Samtidig må dere vite hva skalering faktisk omfatter.

Mer kapasitet på webserveren hjelper lite dersom databasen, filsystemet eller en ekstern integrasjon er begrensningen. Spør derfor hvordan miljøet håndterer økt trafikk i hvert lag, hvor lang tid en kapasitetsendring tar, og om endringen krever nedetid.

Valget mellom delt hosting, administrert plattform, virtuell server og mer sammensatte skyløsninger bør vurderes ut fra kompetanse og driftsbehov. Et avansert miljø er ikke nødvendigvis tryggere dersom ingen har ansvar for konfigurasjon, oppdateringer og hendelser. Det beste miljøet er et dere kan forstå, overvåke og gjenopprette innenfor virksomhetens krav.

Overvåk kapasitet og funksjon samtidig

Under kampanjen trenger dere mer enn et varsel om at forsiden er utilgjengelig. Overvåkingen bør vise både teknisk tilstand og om den viktigste handlingen fungerer.

Aktuelle signaler er blant annet:

• Responstid og feilrate for sentrale sider.
• Belastning på webserver, applikasjon og database.
• Andel trafikk som leveres fra cache og CDN.
• Køer, tidsavbrudd og feil i integrasjoner.
• Om skjema, innlogging eller betaling kan fullføres.
• Unormale endringer i antall bestillinger eller innsendinger.

Bestem på forhånd hvilke terskler som skal utløse handling. Varsler uten mottaker eller avtalt respons gir liten verdi. Det må være tydelig hvem som undersøker, hvem som kan øke kapasiteten, og hvem som beslutter å stanse kampanjen.

Sikre en vei tilbake

Backup er nødvendig før lansering, men den må passe til løsningen og endringstakten. For en nettbutikk kan det oppstå nye ordre mens en feil blir undersøkt. En full tilbakeføring av databasen kan da overskrive gyldige transaksjoner.

Avklar derfor hva som skal gjenopprettes i ulike situasjoner. En feil i kampanjesiden kan kanskje løses ved å rulle tilbake kode eller innhold uten å berøre databasen. En skadet database krever en annen plan. Kontroller at siste backup er fullført, at den oppbevares adskilt fra driftsmiljøet, og at ansvarlige vet hvordan gjenoppretting startes.

Frys unødvendige endringer

Rett før en stor kampanje bør dere begrense endringer som ikke er nødvendige. Oppdateringer av programvare, plugins, tema, serverkonfigurasjon og integrasjoner kan introdusere feil som blir vanskelige å skille fra kapasitetsproblemer.

Det betyr ikke at sikkerhetskritisk vedlikehold skal utsettes ukritisk. Poenget er å planlegge vedlikeholdet slik at løsningen er oppdatert og testet i god tid. Fastsett et tidspunkt der konfigurasjonen fryses, og krev en tydelig vurdering før noe endres etter dette.

Lag en enkel plan for lanseringsdagen

En praktisk driftsplan trenger ikke være omfattende. Den bør være kort nok til at den faktisk brukes, og inneholde:

• Tidspunkt for kampanjestart og forventet trafikktopp.
• Navn og kontaktpunkt for teknisk, redaksjonelt og forretningsmessig ansvar.
• Oversikt over dashbord og varsler som skal følges.
• Terskler for skalering, feilsøking og eventuell stans.
• Fremgangsmåte for å rulle tilbake siste endring.
• En reservevariant av landingssiden med færre dynamiske funksjoner.

Under lanseringen bør én person koordinere beslutningene. Utviklere og driftspersonell må få arbeide med feilen uten parallelle bestillinger fra flere hold. Samtidig må virksomheten ha noen som kan justere annonsering, utsendelser eller kundekommunikasjon dersom den tekniske kapasiteten blir presset.

Bruk erfaringen til å forbedre normal drift

Etter kampanjen bør dere samle målinger og hendelser mens de fortsatt er ferske. Sammenlign forventet trafikk med faktisk trafikk, og se hvilke komponenter som nærmet seg grensene. Noter også hva som fungerte godt, slik at neste lansering ikke starter fra bunnen av.

Den viktigste gevinsten er ikke bare at én kampanje går bra. Arbeidet gir bedre oversikt over driftsmiljøet, mer presis overvåking og tydeligere ansvar. Det gjør nettsiden enklere å vedlikeholde og reduserer tiden fra et problem oppstår til riktig tiltak blir satt inn.