Black Friday-beredskab: Gør din butik klar til at overleve springet
Din butik kører fint i 364 dage om året. Så ankommer Black Friday, trafikken stiger 20 gange, og hjulene falder af på det værst tænkelige tidspunkt. Her er tidsplanen, der forhindrer det.
Sagen om Black Friday-fejl er, at de næsten aldrig er overraskende i bagklogskab. Bagefter ved alle præcis, hvad der gik i stykker: Søge-slutpunktet, der altid var lidt langsomt, databasen, der ikke havde noget headroom, tredjepartsskriptet, der timede ud. Det hele var synligt i oktober. Ingen kiggede, for i oktober var stedet fint.
Så dette er organiseret som en nedtælling snarere end en liste, fordi timingen er den faktiske rådgivning. At gøre det rigtige i den forkerte uge er, hvordan hold ender med at lave risikable ændringer onsdag før.
Seks uger ud: find loftet
Du kan ikke forberede dig på en belastning, du ikke har målt. Det første job er at finde ud af, hvor din butik faktisk går i stykker, og det skal ske tidligt nok, at fastsættelse af det, du finder, er roligt arbejde snarere end nødarbejde.
Load-test mod en kopi af produktionen med realistiske datamængder - en staging database med 40 produkter vil med glæde tjene trafik, der ville ødelægge dit rigtige katalog. Rampe gradvist, og hold øje med det punkt, hvor reaktionstiden begynder at stige, mens gennemstrømningen stopper. Denne bøjning er dit loft, og det er næsten altid lavere end folk gætter.
Test rejsen, ikke hjemmesiden. Alle kan tjene en cachelagret hjemmeside under belastning. Det, der betyder noget, er at gennemse produkt tilføje til indkøbskurven checkout, i den andel, fordi de sidste to er de uoverskuelige, og de er hvor du vil falde over.
Den mest almindelige Black Friday-fejl er ikke webserveren - det er databasen, der drukner i indkøbskurv og session skriver, at den ikke kan cache sin vej ud af. Se databaseforbindelser og lås ventetider under testen, ikke kun CPU. Et webniveau, der skaleres vandret foran en database, der ikke gør det, er den klassiske form for en dårlig eftermiddag.
Fire uger ud: gør butikken cachevenlig
Den største enkeltstående løftestang er, hvor meget af din trafik, der aldrig når frem til din oprindelse overhovedet. Hver anmodning besvaret fra kanten er kapacitet, du ikke behøvede at købe.
Cache på kanten
- Hjemmeside, kampagne landingssider
- Kategori- og produktsider
- Søgeresultater, hvis du kan tåle korte TTL'er
- Alle billeder, CSS og JavaScript
Omgå altid
- Indkøbskurv og betaling
- Min konto og ordrehistorik
- Alt med en session cookie til stede
- Levende bestand tæller, hvis du viser dem
Få bypass-reglerne lige nu, ikke under hastværket. Mekanismen er cookies: din platform sætter en genkendelig cookie, når en kunde har en indkøbskurv eller logger ind, og cachen omgår sin tilstedeværelse. Test det ordentligt - tilføj noget til en indkøbskurv, gennemse væk, kom tilbage, bekræft vognen overlevede, og at et frisk inkognitovindue stadig får en cached side.
Så tjek dit cache-hitforhold, og fortsæt med at tjekke det. Hvis det er under 85 % på en butik, så find ud af hvorfor, før trafikken kommer frem, snarere end efter.
To uger ud: sikkerhedsventilen og frysen
Der sker to ting her, og begge handler om, hvad du gør, når forberedelse ikke er nok.
Sæt et venteværelse på plads og prøv det. Ikke nødvendigvis tændt – konfigureret, testet og skiftet væk. Det er den eneste mekanisme, der forringes yndefuldt, når efterspørgslen virkelig overstiger kapaciteten, og det værste tidspunkt at konfigurere en for første gang er, mens webstedet falder over.
Start ændringen fryse. Ingen nye plugins, ingen temaændringer, ingen afhængighedsopgraderinger, ingen "hurtige" migreringer. Hver Black Friday post mortem indeholder en ændring, som nogen har foretaget i de sidste fjorten dage, der virkede harmløs. Hvis en ændring virkelig er påkrævet, sendes den tidligt på ugen og får en hel observationsdag.
Ugen før: Gentag de kedelige ting
Bekræft, hvem der faktisk er på vagt
Med telefonnumre, ikke Slack-håndtag. Find ud af, hvem der kan træffe beslutningen om at åbne venteværelset uden at spørge nogen.
Kontroller certifikatets udløbsdatoer
Et certifikat, der udløber i løbet af din travleste uge, er sket for flere butikker, end nogen indrømmer.
Bekræft, at din rollback virker
Ikke at det eksisterer – at du har kørt det for nylig og ved, hvor lang tid det tager.
Hæv TTL'er bevidst
Længere cachelevetider end normalt for kampagneperioden, med en plan for udrensning, når priserne ændrer sig.
Opvarm cachen, før du annoncerer
Gennemsøg dine kampagnesider, så de første tusinde rigtige besøgende ikke er alle cachefejl, der ankommer samtidigt.
Skriv beskeden "vi har travlt" på forhånd
Uanset hvad der står på køsiden, skal du skrive det roligt nu i stedet for under pres senere.
På dagen: se tre numre
Dashboards under en spike er for det meste støj. Disse tre fortæller dig, hvad der rent faktisk sker:
Oprindelsesanmodninger pr. sekund er noget, man kan stole på. Hvis den samlede trafik er tredoblet, og den oprindelige trafik knap nok bevæger sig, gør din caching sit arbejde, og du kan slappe af. Hvis oprindelsestrafik sporer den samlede trafik, kører du effektivt uden et CDN og bør straks finde ud af hvorfor.
Modstå trangen til at optimere live. En ændring, der tydeligvis er korrekt kl. 14 på Black Friday, har en meget dårligere track record end at gøre ingenting. Venteværelset er dit indgreb; brug det, og lad koden være.
Ofte stillede spørgsmål
Hvordan forbereder jeg mit e-handelswebsted til Black Friday?
Arbejd baglæns fra datoen. Seks uger ud, test hele købsrejsen mod data i produktionsstørrelse for at finde ud af, hvor webstedet går i stykker. Fire uger ud, maksimer hvad der kan cachelagres ved kanten, og kontroller, at indkøbskurven og checkoutet er korrekt omgået cachen. To uger ud, konfigurere og teste et venteværelse og begynde en ændring fryse. Ugen før skal du opvarme cachen, bekræfte arrangementer til rådighed, og bekræfte tilbagekaldelsen.
Hvor meget trafik kan jeg forvente på Black Friday?
Butikker ser ofte 10 til 30 gange om dagen, koncentreret i et par timer i stedet for jævnt fordelt. Multiplikatoren betyder mindre end koncentrationen: det samme antal besøgende, der ankommer over 24 timer, ville være umærkeligt, og ankommer på 90 minutter er det, der bryder ting. Brug dine egne tidligere år som baseline og plan for peak time, ikke den daglige total.
Hvad går normalt først i stykker under belastningen af Black Friday?
Databasen, i de fleste tilfælde. Webservere kan skaleres vandret og cachelagres foran, men cart skriver, session skriver og lageropdateringer alle konvergerer på en enkelt database, der ikke kan cachelagres væk. Watch forbindelse tæller og lås venter under belastning test snarere end kun CPU, da fejlen ofte vises som kø i stedet for mætning.
Skal jeg fryse implementeringer inden Black Friday?
Typisk starter de to uger. Næsten hver eneste Black Friday-hændelse post mortem identificerer en ændring, der blev foretaget kort tid før, og som syntes at være lav risiko. Hvis en ændring er virkelig nødvendigt, skib det tidligt på ugen, så det får en hel dag med reel trafik under observation, snarere end i de sidste dage, hvor der ikke er tid til at mærke et problem.
Kan en CDN håndtere Black Friday trafik på egen hånd?
Det håndterer det cachevenlige flertal, som normalt er det meste af det - browsing, produktsider, billeder og aktiver. Den kan ikke cachelagre indkøbskurven, udtjekningssiden eller kontosiden, så din oprindelse skal stadig tjene disse sider. Det realistiske mål er, at oprindelsesbelastningen forbliver nogenlunde flad, mens den samlede trafik multiplicerer, hvilket efterlader din database fri til at håndtere de skriver, der rent faktisk genererer indtægter.
Black Friday belønner det kedelige arbejde, du udfører seks uger før tid. Find dit loft med en realistisk belastningstest, cache alt, hvad der ikke er personligt, har et venteværelse konfigureret og testet, fryse ændringer, og på dagen se oprindelse anmodninger per sekund over alt andet. Målet er en dag, hvor der ikke sker noget interessant.
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
