Black Friday parathed: gør din butik overleve spike
Din butik kører fint i 364 dage om året. Så kommer Black Friday, trafikken går 20x, og hjulene kommer af på det værst mulige tidspunkt. Her er tidslinjen, der forhindrer det.
Sagen om Black Friday fiaskoer 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, fordi i oktober stedet var fint.
Så dette er organiseret som en nedtælling snarere end en liste, fordi timingen er det faktiske råd. 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 iscenesættelsesdatabase med 40 produkter vil med glæde tjene trafik, der ville ødelægge dit rigtige katalog. Rampe gradvist og se efter det punkt, hvor responstiderne begynder at klatre, mens gennemstrømningen stopper. Den 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øj til kurv 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 venter under testen, ikke kun CPU. Et webniveau, der skaleres vandret foran en database, der ikke gør, er den klassiske form for en dårlig eftermiddag.
Fire uger ud: gør butikken cacheable
Den største enkeltstående løftestang er, hvor meget af din trafik aldrig når 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 tolerere korte TTL'er
- Alle billeder, CSS og JavaScript
Altid omgå
- Kurv og checkout
- Min konto og ordrehistorik
- Alt med en session cookie til stede
- Levende lager 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 shopper 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 din cache hit ratio og holde kontrollere det. Hvis det er under 85% på en butik, finde ud af hvorfor før trafikken ankommer snarere end efter.
To uger ud: sikkerhedsventilen og frysen
Der sker to ting her, og begge handler om, hvad man gør, når forberedelse ikke er nok.
Sæt et venteværelse på plads og test det. Ikke nødvendigvis tændt - konfigureret, testet og en skifte 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" migrationer. Hver Black Friday post-mortem indeholder en ændring, som nogen har foretaget i de sidste fjorten dage, der virkede harmløse. Hvis der virkelig er brug for en ændring, sendes den tidligt på ugen og får en hel observationsdag.
Ugen før: øve de kedelige ting
Bekræft, hvem der faktisk er på opkald
Med telefonnumre, ikke Slack-håndtag. Fastslå, hvem der kan træffe beslutningen om at aktivere 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 dine rollback-funktioner
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 cache levetider end normalt for kampagneperioden, med en plan for udrensning, når priserne ændrer sig.
Varm cachen, før du annoncerer
Gennemsøg dine kampagnesider, så de første tusinde rigtige besøgende ikke alle cache misser ankommer samtidigt.
Skriv beskeden "Vi har travlt" på forhånd
Uanset hvad køen side siger, 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 den, der skal stole på. Hvis den samlede trafik tredobler og oprindelse trafik knap nok bevæger sig, er din caching gør sit job, og du kan slappe af. Hvis oprindelsestrafik sporer den samlede trafik, kører du effektivt uden et CDN og bør finde ud af hvorfor med det samme.
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 din intervention; brug det og lad koden være alene.
Ofte stillede spørgsmål
Hvordan forbereder jeg mit e-handelssite til Black Friday?
Arbejd baglæns fra datoen. Seks uger ud, load-test den fulde køb rejse mod produktions-størrelse data for at finde, hvor webstedet bryder. Fire uger ud, maksimere, hvad der kan cachelagres på kanten og kontrollere, at vognen og kassen korrekt omgå cachen. To uger ud, konfigurere og teste et venteværelse og begynde en ændring fryse. Ugen før, varm cachen, bekræft tilkaldearrangementer og bekræft tilbagerulning.
Hvor meget trafik skal jeg forvente på Black Friday?
Butikker ofte se 10 til 30 gange en normal dag, koncentreret i et par timer i stedet for at sprede jævnt. 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 plejer at bryde først under Black Friday belastning?
Databasen, i de fleste tilfælde. Webservere kan skaleres vandret og cachelagres foran, men indkøbskurv 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 i stedet for kun CPU, da fejlen ofte vises som kø i stedet for mætning.
Skal jeg fryse deployeringer inden Black Friday?
Typisk fra to uger. Næsten hver Black Friday hændelse post mortem identificerer en ændring foretaget kort tid før, der syntes 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 bemærke et problem.
Kan en CDN håndtere Black Friday trafik på egen hånd?
Det håndterer det cacheable flertal, som normalt er det meste af det - browsing, produktsider, billeder og aktiver. Det kan ikke cache indkøbskurv, checkout eller konto sider, så din oprindelse stadig nødt til at tjene dem. 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 gør seks uger tidligt. 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 i IT - for det meste hosting - 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, sikker infrastruktur enkel at bruge.
