Black Friday: inżynierska checklista przygotowania platformy

Black Friday 2026 wypada w piątek 27 listopada, a Cyber Monday w poniedziałek 30 listopada. Od dziś dzieli Cię od tego szesnaście tygodni i to jedyna dobra wiadomość w tym tekście, bo większości rzeczy, które decydują o przetrwaniu szczytu, nie da się zrobić w listopadzie. To nie jest lista pomysłów na promocje. To harmonogram inżynierski: co zmierzyć we wrześniu, co przebudować w październiku, co zamrozić w listopadzie i czego nie ruszać w ostatnim tygodniu. Samą mechanikę pękania platformy pod obciążeniem rozłożyliśmy osobno w tekście o tym, co się psuje przy 10× ruchu. Tutaj chodzi o kolejność i daty.

Szczyt to nie jeden dzień, tylko kilkanaście minut w kilku dniach

Zanim ułożysz harmonogram, ustal, na co dokładnie się przygotowujesz. Dane z 2025 roku mówią dwie rzeczy naraz: szczyt rozkłada się na kilka dni, ale w środku każdego z nich siedzi kilkanaście minut, które decydują o wszystkim.

• Rekordowy dzień to niekoniecznie piątek. Według Adobe Analytics amerykańscy klienci wydali online 11,8 mld USD w Black Friday 2025 i 14,25 mld USD w Cyber Monday, który był najwyższym jednodniowym wynikiem w historii tego rynku (komunikat Adobe z 2 grudnia 2025).
• W Polsce rozkład jest podobny. W Black Weekend 2025, czyli od 28 listopada do 1 grudnia, użytkownicy wykonali blisko 30 mln transakcji BLIK na prawie 5 mld zł. Rekordowy był Cyber Monday z 8,6 mln transakcji, wobec 8 mln w sam Black Friday (komunikat BLIK z 2 grudnia 2025).
• Szczyt w szczycie liczy się w minutach. Adobe podaje 16 mln USD wydawanych co minutę między 20:00 a 22:00 w Cyber Monday, a Shopify raportuje rekordowe 5,1 mln USD sprzedaży na minutę o 12:01 czasu wschodniego w Black Friday (komunikat Shopify z 2 grudnia 2025).

Wniosek dla planowania pojemności: średnia dzienna jest bezużyteczna. Punktem odniesienia jest najwyższa minuta, bo to ona wyczerpuje pulę połączeń i kolejkę wątków. Wniosek dla kalendarza jest równie konkretny: skoro rekord potrafi paść w poniedziałek, okno zamrożenia zmian nie może się kończyć w sobotę rano, gdy zespół odetchnie z ulgą po piątku.

Warto też zauważyć rzecz, którą sygnalizuje Adobe: w 2025 roku Black Friday rósł szybciej niż Cyber Monday (9,1% wobec 7,1% rok do roku). Kolejność tych dwóch dni bywa różna w różnych latach i na różnych rynkach, więc plan techniczny ma obejmować oba, a nie zakładać, który wygra.

Harmonogram: co robić i kiedy

Poniższa tabela jest szkieletem całego tekstu. Kolumna „czego nie robisz” jest w niej tak samo ważna jak kolumna „co robisz”, bo większość awarii w szczycie ma źródło w zmianie wprowadzonej za późno, a nie w braku mocy.

Harmonogram dla Black Friday 27 listopada 2026. Daty są konkretne celowo: każdy tydzień zwłoki zabiera opcje, zamiast je dokładać.

Zastrzeżenie na wstępie: ta checklista zakłada, że masz kontrolę nad infrastrukturą i kodem. Na zamkniętym SaaS część punktów jest poza Twoim zasięgiem i Twoim zadaniem staje się co innego: ustalić na piśmie, co dostawca gwarantuje w szczycie, jakie ma limity API i kiedy ogłasza własne zamrożenie zmian.

Wrzesień: najpierw pomiar, potem cokolwiek innego

Wrzesień ma jeden cel: zamienić przypuszczenia w liczby. Bez nich każda decyzja w październiku jest loterią, bo nie wiadomo, czy wąskim gardłem jest baza, integracja z magazynem czy front. Do zrobienia są trzy rzeczy: test obciążeniowy, wartości bazowe i inwentaryzacja limitów.

Test obciążeniowy, który ma coś zepsuć

Test obciążeniowy nie służy do potwierdzenia, że jest dobrze. Służy do znalezienia warstwy, która pęka pierwsza, i liczby, przy której to się dzieje. Uruchamiasz go na środowisku zbliżonym do produkcji, na realnym katalogu i na pełnej ścieżce zakupowej, aż do złożenia zamówienia i płatności w trybie testowym. Wąskie gardło prawie nigdy nie siedzi na stronie głównej.

Nasza reguła kciuka (rekomendacja, nie standard branżowy): celuj w co najmniej dwukrotność najwyższej minuty z zeszłego roku. Jeśli nie masz danych z zeszłego roku, przyjmij dziesięciokrotność swojej zwykłej godziny szczytu. Nie chodzi o ładny wynik, tylko o zobaczenie pierwszego błędu i zapamiętanie natężenia, przy którym się pojawił.

Wynik zapisz jako liczby, nie jako wrażenie. „Przy 420 zamówieniach na minutę czas odpowiedzi checkoutu rośnie dwukrotnie, przy 610 wyczerpuje się pula połączeń do bazy” to zdanie, którym będziesz płacić za wszystkie decyzje w październiku. „Chyba wytrzyma” nie kupuje niczego.

Wartości bazowe, czyli co u Ciebie znaczy „zdrowo”

AWS w materiale o gotowości na zaplanowane wydarzenia (whitepaper „Infrastructure Event Readiness”, wersja archiwalna z grudnia 2018) zaleca spisanie wartości powrotu do normy dla kluczowych metryk jeszcze przed wydarzeniem. Brzmi banalnie do momentu, w którym o pierwszej w nocy patrzysz na wykres i nie wiesz, czy 900 ms to już awaria, czy zwykły wieczór w Twoim sklepie.

Ten sam dokument zwraca uwagę na proporcjonalność: dziesięciokrotny wzrost liczby transakcji na load balancerze może wymagać dwudziestokrotnego wzrostu pojemności po stronie zapisu i odczytu danych. Skalowanie warstw nie jest ani liniowe, ani równomierne, więc pojemność planuje się osobno dla każdej warstwy, a nie jednym mnożnikiem dla całości.

Limity: Twoje i cudze

Najbardziej upokarzające awarie szczytu nie biorą się z braku mocy, tylko z limitów, o których nikt nie pamiętał. Zrób ich listę we wrześniu, bo część podnosi się wyłącznie przez zgłoszenie, a zgłoszenia mają swoje terminy.

• Limity chmury i hostingu: liczba instancji, przepustowość, połączenia do bazy, limity funkcji serverless, limity kont na region. Sprawdź, które podnosi się automatycznie, a które przez ticket.
• Limity API integracji: bramka płatnicza, ERP, kurierzy, marketplace, systemy mailingowe. Zapytaj wprost o limit żądań na sekundę i o to, co się dzieje po jego przekroczeniu.
• Limity planu i licencji: pakiety wyszukiwania, CDN, monitoringu i narzędzi analitycznych bywają rozliczane od wolumenu, a przekroczenie kończy się przycięciem usługi w najgorszym momencie.
• Terminy dostawców: Google Cloud przyjmuje zgłoszenie peak eventu (usługa dostępna w ramach Premium Support) najpóźniej 30 dni przed wydarzeniem, a AWS zaleca uruchomienie Countdown Premium na 2 do 3 tygodni przed krytycznym wydarzeniem.

Przelicz te terminy na daty i wpisz je do kalendarza jeszcze dziś. Dla 27 listopada 2026 wychodzi 28 października jako ostatni moment na zgłoszenie w modelu 30 dni i pierwsze dni listopada w modelu 2 do 3 tygodni. To nie są terminy Twojego zespołu, tylko cudze, więc nie negocjujesz ich w listopadzie przez telefon.

Październik: ostatni miesiąc, w którym wolno ruszać architekturę

Październik jest na zmiany, które wymagają wdrożenia i ponownego testu. Reguła jest prosta: jeśli czegoś nie zdążysz wdrożyć i przetestować do połowy listopada, to nie jest zadanie na ten rok, tylko pozycja w backlogu na styczeń. Cztery obszary poniżej ułożyłem w kolejności, w jakiej zwykle się opłacają.

Cache i CDN, czyli zdejmowanie pracy z origin

Buforuj to, co dla większości odwiedzających wygląda tak samo: stronę główną, listingi kategorii, karty produktów, zasoby statyczne. Nie buforuj koszyka, cen kontraktowych w B2B ani stanów magazynowych blisko zera. Najczęstszy błąd to nie brak cache, tylko cache bez przemyślanej inwalidacji.

Uwaga na moment startu promocji. Zmiana cen w tysiącach produktów naraz unieważnia cały cache w jednej sekundzie, więc pierwsze minuty po północy uderzają w origin z pełną siłą, dokładnie wtedy, gdy ruch jest najwyższy. Zaplanuj rozgrzanie cache przed startem i sprawdź, co się dzieje, gdy ktoś wymusi masowe przeliczenie.

Kolejki: oddziel to, co natychmiast, od tego, co może poczekać

W szczycie natychmiast musi się wydarzyć rezerwacja stanu i autoryzacja płatności. Reszta może poczekać sekundę albo minutę: wysłanie zamówienia do ERP, aktualizacja marketplace, e-mail potwierdzający, przeliczenie rekomendacji. Każde z tych wywołań zrobione synchronicznie zamienia cudzy limit w Twoją awarię.

Kolejka potrzebuje trzech rzeczy, żeby była czymś więcej niż buforem: ponowień z rosnącym odstępem, zapisu przyczyny błędu przy każdej nieudanej próbie i alertu, gdy kolejka rośnie szybciej, niż jest przetwarzana. Architekturę takiej wymiany, razem z mapowaniem pól i obsługą błędów, rozkładamy w tekście o integracji sklepu B2B z ERP.

Stany magazynowe: overselling w szczycie jest regułą, nie wyjątkiem

Promocja koncentruje ruch na kilkunastu produktach, więc setki równoległych zamówień trafiają w ten sam wiersz w bazie. Jeśli sprawdzenie i pomniejszenie stanu nie dzieje się w jednej, atomowej operacji, sprzedasz więcej sztuk, niż masz. Przy normalnym ruchu to margines, w Black Friday to codzienność weekendu i realny koszt zwrotów.

Trzy zabezpieczenia, które warto mieć wdrożone przed listopadem: atomowa rezerwacja stanu w transakcji, bufor bezpieczeństwa na produktach objętych promocją oraz automatyczne wyłączenie sprzedaży poniżej ustalonego progu, zamiast ręcznego gaszenia pożaru przez obsługę.

Obserwowalność: dashboard, progi i właściciel alertu

Dashboard na szczyt nie pokazuje wszystkiego, tylko to, po czym poznasz, że tracisz sprzedaż. Zużycie procesora jest ciekawostką, skuteczność checkoutu jest metryką biznesową. Do każdego progu przypisz osobę, która dostaje alert i ma prawo podjąć decyzję, bo alert bez właściciela to tylko powiadomienie na kanale.

• Skuteczność checkoutu: udział rozpoczętych zamówień, które kończą się płatnością, liczony w oknach kilkunastominutowych.
• Czas odpowiedzi p95 osobno dla listingu, karty produktu i checkoutu, bo średnia ukrywa dokładnie tych użytkowników, którzy odchodzą.
• Głębokość kolejek i czas najstarszego zadania, czyli sygnał, że integracje przestają nadążać.
• Błędy 5xx i nieudane autoryzacje płatności w podziale na dostawcę, żeby od razu było widać, czyj to problem.
• Wykorzystanie puli połączeń do bazy, bo to zwykle pierwszy licznik, który dobija do sufitu.

Przy okazji przejdź ścieżkę zakupową na piechotę i policz kroki. Pod obciążeniem każde zbędne pole i każde dodatkowe przekierowanie kosztuje podwójnie, bo mnoży się przez liczbę osób w kolejce. Pomaga w tym audyt checkoutu w dziesięciu punktach, zrobiony w październiku, a nie w tygodniu przed startem.

Listopad: zamrożenie, runbook i plan wyjścia

W listopadzie nie budujesz odporności, tylko chronisz tę, którą masz. Trzy elementy załatwiają większość ryzyka: zamrożenie zmian z jasną ścieżką wyjątku, runbook na dzień szczytu i przećwiczony plan rollbacku.

Feature freeze: konkretne daty i ścieżka wyjątku

Zamrożenie działa tylko wtedy, gdy ma daty i właściciela decyzji. Nasza propozycja dla tego roku wygląda tak:

• Ostatnie wdrożenie funkcjonalne: piątek 13 listopada, z pełnym testem regresji i powtórzonym testem obciążeniowym.
• Zamrożenie od poniedziałku 16 listopada: koniec zmian w kodzie, motywie, integracjach i konfiguracji checkoutu.
• Odmrożenie nie wcześniej niż w środę 2 grudnia: po Cyber Monday, gdy metryki wrócą do wartości bazowych.
• Ścieżka hotfix: jedna osoba zatwierdza, poprawka ma test i gotowy rollback, a każda zmiana ląduje w logu, który czyta cały zespół.

To rekomendacja, nie norma branżowa, i warto ją dopasować do zespołu. Jeśli wdrażacie kilka razy dziennie za przełącznikami funkcji, z automatycznymi testami i szybkim rollbackiem, zamrożenie może być krótsze. Jeśli wdrożenie jest ręczne i zdarza się raz na dwa tygodnie, powinno być dłuższe, bo dłużej trwa też naprawa.

Runbook na dzień szczytu

Runbook to instrukcja obsługi wydarzenia, nie dokumentacja architektury. Przywoływany wcześniej materiał AWS wymienia sekcje, które sprawdzają się w praktyce, i warto się nimi posłużyć jako szkieletem.

• Opis wydarzenia: daty, godziny startu promocji, kryteria sukcesu, lista osób decyzyjnych po Twojej stronie i po stronie dostawców.
• Mapa systemów: co jest w grze, jakie obciążenie zakładasz na każdym elemencie i gdzie są pojedyncze punkty awarii.
• Wyniki testów: liczby z września i października, czyli przy jakim natężeniu co pęka.
• Progi i procedury: co robisz, gdy metryka przekroczy próg, kto to zatwierdza i jak wygląda powrót do normy.
• Kontakty i eskalacje: numery telefonów, nie adresy skrzynek zbiorczych, oraz potwierdzenie, że po drugiej stronie ktoś faktycznie dyżuruje.

Rollback i degradacja zamiast padu

AWS zaleca, żeby każdy krok przygotowań miał odpowiadające mu działanie awaryjne, zweryfikowane w środowisku testowym, wraz z odpowiedzią na pytanie, ile trwa wycofanie zmiany i jaka utrata danych jest akceptowalna. Plan rollbacku, którego nikt nie przećwiczył, jest wyłącznie deklaracją.

Drugą warstwą jest degradacja. Zamiast pozwolić, żeby padło wszystko, przygotuj przełączniki wyłączające rzeczy, bez których da się kupić: podpowiedzi wyszukiwarki, rekomendacje, opinie, liczniki, ciężkie widżety zewnętrzne. Sklep, który przez dwadzieścia minut działa uboższy, sprzedaje. Sklep, który nie odpowiada, nie sprzedaje wcale.

Czego nie robić w ostatnim tygodniu

Ostatni tydzień przed szczytem, czyli 20 do 26 listopada, jest po to, żeby nic się nie zmieniło. Poniższa lista to nie przesada ostrożnościowa, tylko katalog rzeczy, które regularnie kończą się awarią wtedy, gdy jest najdrożej.

• Migracja platformy albo cutover. Migrację planuje się poza szczytem i z zapasem, o czym pisaliśmy w tekście o migracji bez zatrzymywania sprzedaży. Listopad to najgorszy możliwy termin.
• Zimny start nowego kanału. Uruchamianie sprzedaży na nowym marketplace w tygodniu Black Friday to podwójne ryzyko: nowe integracje i nowe reguły. Jak wygląda taki start, opisaliśmy w tekście o zimnym starcie na marketplace.
• Zmiana bramki płatniczej albo dodanie nowej metody płatności. Nawet poprawnie wdrożona zmienia ścieżkę, na której nie masz danych historycznych.
• Redesign lub zmiany w checkoucie. Testy A/B na koszyku odkładasz na grudzień. W szczycie nie masz jak odróżnić efektu zmiany od efektu obciążenia.
• Szybka optymalizacja bazy. Dodanie indeksu na dużej tabeli produkcyjnej potrafi ją zablokować na minuty. Indeksy dokładasz we wrześniu, po teście, a nie w środę przed piątkiem.
• Wyciszanie alertów, bo hałasują. Progi ustala się na podstawie wartości bazowych, a nie na podstawie zmęczenia zespołu. Wyciszony alert to awaria zauważona przez klientów.

Osobna pułapka to pomysł, żeby na czas przeciążenia pokazać stronę z informacją o przerwie. Dokumentacja Google Search Central mówi wprost, że błędy 5xx skłaniają crawlery Google do spowolnienia crawlowania, a adresy, które uporczywie zwracają błąd serwera, są w końcu usuwane z indeksu. Kilkanaście minut kodu 503 nie zaszkodzi, ale weekend na stronie awaryjnej to koszt widoczności, który zapłacisz w kolejnych tygodniach.

Dzień szczytu: rytm zamiast heroizmu

Dobrze przygotowany szczyt jest nudny. Zespół nie improwizuje, tylko wykonuje plan, a wszystkie trudne decyzje zapadły wcześniej, na spokojnie. Praktyka, którą warto przenieść z dużych wdrożeń, to stały rytm i jeden kanał komunikacji.

• Dyżur z imienia i nazwiska: kto patrzy na dashboard w danym oknie czasowym, kto jest zapasowy i o której następuje zmiana.
• Jeden wspólny kanał: techniczny i biznesowy w tym samym miejscu, żeby decyzja o wyłączeniu funkcji nie wymagała szukania osoby decyzyjnej.
• Godzinne podsumowanie: trzy zdania o stanie, kluczowe metryki, problemy i przewidywany czas naprawy. Krótko, regularnie, także wtedy, gdy jest dobrze.
• Decyzje według progów: przekroczenie progu uruchamia zapisaną procedurę, a nie dyskusję o tym, czy to już jest problem.

W te dni obowiązuje też zasada odwrotna do zwykłej pracy: nie naprawiaj tego, co nie jest zepsute. Drobna poprawka wdrożona w piątek po południu jest w tym tygodniu największym ryzykiem, jakie zespół może na siebie ściągnąć.

Po szczycie: tydzień, który ustawia przyszły rok

Po Cyber Monday zostaje najcenniejszy materiał w całym roku: dane z realnego obciążenia, których żaden test nie odtworzy. Zrób post mortem w ciągu tygodnia, póki pamięć jest świeża, i zapisz trzy rzeczy: co pękło i przy jakich liczbach, co uratowało sytuację i czego zabrakło w runbooku.

Jeśli szczyt pokazał, że problemem nie był jeden błąd, tylko sufit platformy, to jest sygnał do decyzji, a nie do kolejnej łatki. Styczeń jest na to lepszym miesiącem niż listopad. Jak rozpoznać ten moment, rozkładamy w tekście o sygnałach wyrośnięcia z platformy SaaS.

W Seedlight budujemy platformy eCommerce frameworkiem BEAM i przygotowanie do szczytu traktujemy jako pracę ciągłą, a nie akcję listopadową: odporność projektujemy na etapie Engineering, a testy, monitoring i gotowość na sezon pilnujemy potem w Maintenance and Growth. Uczciwe zastrzeżenie: żadna checklista nie gwarantuje, że nic nie padnie. Daje natomiast to, że wiesz, co pęknie pierwsze, przy jakiej liczbie i co wtedy robisz.