Pierwszy dzień głosowania, godzina 17:00, szczyt ruchu - i system przestaje odpowiadać. Koszmarne scenario dla każdego organizatora BO. Jak się przed tym zabezpieczyć?

Anatomia przeciążenia

Typowy przebieg:

  1. Start głosowania → normalny ruch
  2. Promocja w mediach → wzrost ruchu
  3. Godziny szczytu (17-21) → przeciążenie
  4. Wolne odpowiedzi → użytkownicy odświeżają
  5. Więcej requestów → całkowita blokada

Czynniki ryzyka:

  • Pierwszy dzień głosowania
  • Ostatni dzień głosowania
  • Publikacja w mediach
  • Viralowy post w social media
  • Wysyłka SMS/email do wszystkich

Planowanie wydajności

Szacowanie ruchu

Wzór podstawowy:

Ruch szczytowy = (Populacja × Frekwencja × 30%) / Godziny szczytu

Przykład (miasto 200 tys.):
(200 000 × 15% × 30%) / 4h = 2 250 użytkowników/h = ~40/min

Mnożnik bezpieczeństwa: ×5-10 (na virale, media)

Wymagania infrastruktury

Rozmiar miastaRuch szczytowyMin. infrastruktura
<50 tys.20 req/min1 serwer + CDN
50-200 tys.50-100 req/min2 serwery + LB + CDN
200-500 tys.100-300 req/minAuto-scaling + CDN
>500 tys.300+ req/minCloud auto-scaling

Testy obciążeniowe

Kiedy testować:

  • 2-4 tygodnie przed głosowaniem
  • Po każdej większej zmianie
  • Na środowisku identycznym z produkcją

Co testować:

  • Logowanie/weryfikacja
  • Oddawanie głosu
  • Przeglądanie projektów
  • Wyniki na żywo

Narzędzia:

  • JMeter (open source)
  • Gatling
  • k6
  • Locust

Scenariusze:

  1. Normalny ruch - 100% planowanego
  2. Szczyt - 300% planowanego
  3. Viral - 1000% planowanego
  4. Atak DDoS - symulacja

Architektura odporna na obciążenie

1. CDN (Content Delivery Network)

  • Statyczne zasoby (CSS, JS, obrazy)
  • Cache stron publicznych
  • Ochrona przed DDoS

2. Load Balancer

  • Rozkładanie ruchu na serwery
  • Health checks
  • Automatyczne wyłączanie awarii

3. Auto-scaling

  • Automatyczne dodawanie serwerów
  • Skalowanie w górę przy obciążeniu
  • Skalowanie w dół po szczycie

4. Optymalizacja kodu

  • Cache odpowiedzi (Redis)
  • Optymalizacja zapytań DB
  • Lazy loading
  • Kompresja

5. Kolejkowanie

  • Asynchroniczne przetwarzanie głosów
  • Kolejki dla maili/SMS
  • Graceful degradation

Procedury awaryjne

Poziom 1: Spowolnienie

Objawy: Strony ładują się >5s Akcje:

  • Włącz dodatkowe serwery
  • Zwiększ cache
  • Ogranicz funkcje non-essential

Poziom 2: Częściowa niedostępność

Objawy: Błędy dla części użytkowników Akcje:

  • Włącz tryb “ratunkowy” (tylko głosowanie)
  • Wyłącz statystyki na żywo
  • Komunikat dla użytkowników

Poziom 3: Całkowita awaria

Objawy: System nie odpowiada Akcje:

  • Przekieruj na stronę informacyjną
  • Komunikacja kryzysowa (social media)
  • Eskalacja do dostawcy
  • Decyzja o przedłużeniu głosowania

Komunikacja kryzysowa

Przygotuj wcześniej:

  • Szablon komunikatu o awarii
  • Lista kontaktów (media, koordynatorzy)
  • Procedura przedłużenia głosowania
  • FAQ dla mieszkańców

W trakcie awarii:

  • Szybka informacja (w ciągu minut)
  • Szczera komunikacja (nie ukrywaj)
  • Aktualizacje co 15-30 min
  • Info o rekompensacie (przedłużenie)

Checklist przed głosowaniem

2 tygodnie przed:

  • Testy obciążeniowe wykonane
  • Auto-scaling skonfigurowane
  • CDN włączone
  • Procedury awaryjne spisane
  • Kontakty dyżurne ustalone

1 dzień przed:

  • Monitoring włączony
  • Alerty skonfigurowane
  • Dyżur techniczny obsadzony
  • Backup wykonany
  • Komunikacja kryzysowa gotowa

Podsumowanie

Zabezpieczenie przed przeciążeniem:

  • Planowanie wydajności (×5-10 od szacowanego)
  • Testy obciążeniowe obowiązkowe
  • Architektura skalowalna (cloud, auto-scaling)
  • Procedury awaryjne przygotowane

Poznaj infrastrukturę ARDVote →

Powiązane artykuły