Jak bezpiecznie wdrażać zmiany w sklepie internetowym
Sklep działał w piątek, w sobotę rano nie dało się zapłacić. Programista mówi, że nic nie zmieniał, agencja też. Jeśli zmiany trafiają na serwer bezpośrednio, bez historii i bez testów, nie da się ustalić, kto ma rację, a naprawa zaczyna się od zgadywania.
- Autor
- Wojciech Wawrzyniak
- Aktualizacja
- Czytanie
- 7 min
Ile kosztuje zmiana, która psuje sklep
Błąd we wdrożeniu kosztuje tyle, ile sprzedaży przepada, zanim ktoś go zauważy i cofnie. Poniżej sklep z obrotem 30 000 zł dziennie. Liczy się nie to, czy błąd się zdarzy, bo zdarzy się każdemu, tylko to, jak szybko sklep wraca do działania.
| Czas do wykrycia i cofnięcia | Utracony obrót | Typowa sytuacja |
|---|---|---|
| 15 minut | 469 zł | monitoring zakupu i cofnięcie wersji jednym poleceniem |
| 1 godzina | 1 875 zł | monitoring jest, cofanie ręczne |
| 6 godzin | 11 250 zł | awarię zgłasza klient, programista szuka zmiany |
| Cały dzień | 30 000 zł | wdrożenie w piątek wieczorem, nikt nie ma dyżuru |
Różnica między pierwszym a ostatnim wierszem nie wynika z umiejętności programisty. Wynika z tego, czy sklep ma historię zmian, testy, monitoring i sposób na szybkie cofnięcie wersji.
FTP na produkcję a wdrożenia z repozytorium
W wielu sklepach zmiany wgrywa się przez FTP albo edytor plików w panelu, prosto na działający sklep. Tak jest szybko, dopóki coś się nie zepsuje.
| Pytanie | Pliki wgrywane na serwer | Repozytorium i automatyczne wdrożenia |
|---|---|---|
| Kto, kiedy i co zmienił? | nie wiadomo | widać każdą zmianę z autorem i datą |
| Czy zmiana była testowana? | zależy od dnia | testy uruchamiają się przed każdym wdrożeniem |
| Ile trwa cofnięcie zmiany? | godziny, jeśli jest kopia | minuty, jedno polecenie |
| Co, jeśli programista odejdzie? | wiedza odchodzi z nim | historia i kod zostają w firmie |
| Kto ma dostęp do serwera? | każdy, kto zna hasło do FTP | tylko system wdrożeń |
Pięć elementów bezpiecznego wdrożenia
- Repozytorium kodu (np. GitHub, GitLab) należące do Twojej firmy, nie do wykonawcy. Każda zmiana ma autora, datę i opis.
- Środowisko testowe, czyli kopia sklepu, na której zmiana działa, zanim trafi do klientów. Z kopią bazy, w której dane klientów są zanonimizowane, bo prawdziwe dane osobowe nie powinny krążyć po serwerach testowych.
- Testy ścieżki zakupu. Automat, który przed każdym wdrożeniem dodaje produkt do koszyka, wybiera dostawę i dochodzi do płatności w trybie testowym. Jeśli ścieżka nie przejdzie, zmiana nie trafi na sklep.
- Automatyczne wdrożenie z możliwością cofnięcia (CI/CD, np. GitHub Actions). Nowa wersja wchodzi jednym procesem, a poprzednia zostaje gotowa do przywrócenia w kilka minut.
- Monitoring po wdrożeniu. Zbieranie błędów (np. Sentry) i test syntetyczny, który co kilka minut przechodzi zakup i alarmuje, kiedy się nie uda.
Do tego zasady, które nic nie kosztują: bez wdrożeń w piątek po południu i przed promocją, aktualizacje wtyczek najpierw na środowisku testowym, a większe zmiany w godzinach najmniejszego ruchu, z kimś, kto przez kolejną godzinę patrzy na sklep.
Jak sprawdzić, kto zepsuł stronę
Jeśli sklep ma repozytorium, odpowiedź jest w historii zmian: lista wdrożeń z dnia awarii pokaże, co weszło na sklep i kto to zatwierdził. Jeśli nie ma, zostają ślady pośrednie:
- Daty modyfikacji plików na serwerze: zmienione pliki z dnia awarii wskazują, gdzie szukać.
- Historia aktualizacji wtyczek i platformy w panelu sklepu albo w logach serwera.
- Historia wersji Google Tag Managera: nowe tagi potrafią zepsuć kasę tak samo jak kod.
- Porównanie z kopią zapasową sprzed awarii: różnica w plikach to lista podejrzanych zmian.
Kiedy w sporze uczestniczą agencja i programiści, pomaga oś czasu wszystkich zmian nałożona na wykres sprzedaży. Opisaliśmy ją w tekście Spadek konwersji: agencja czy IT.
Dług technologiczny: kiedy sklep robi się kruchy
Dług technologiczny to skróty, które kiedyś oszczędziły czas, a dziś utrudniają każdą zmianę. Sklep go ma, jeśli:
- Platforma albo PHP są w wersji, której producent już nie wspiera, bo aktualizacja „coś psuje”.
- Ktoś zmieniał pliki samej platformy zamiast pisać rozszerzenie, więc każda aktualizacja kasuje te zmiany.
- Wtyczek jest kilkadziesiąt, część nieużywanych, a nikt nie wie, które można wyłączyć.
- Nie ma dokumentacji i tylko jedna osoba wie, jak coś działa.
- Proste zmiany trwają tygodnie, bo „trzeba uważać, żeby nic nie wysadzić”.
Długu nie spłaca się jednym przepisaniem sklepu. Najpierw audyt i lista ryzyk, potem wprowadzenie repozytorium i testów, dopiero potem porządki w kodzie, po kawałku, z każdą zmianą testowaną. Tak zaczynamy przejęcie projektu po innym wykonawcy.
Co wpisać do umowy o utrzymanie sklepu
Umowa o opiekę nad sklepem powinna odpowiadać na kilka pytań, zanim zdarzy się awaria:
- Czas reakcji i czas naprawy to dwie różne rzeczy. Reakcja to moment, w którym ktoś zaczyna działać, naprawa to moment, w którym sklep znów sprzedaje. Obie powinny być zapisane osobno.
- Definicja awarii krytycznej. Na przykład: nie da się złożyć zamówienia albo zapłacić. Bez definicji każda awaria staje się sporem o to, czy jest krytyczna.
- Godziny. Czas reakcji w dni robocze nie pomoże w sobotę, kiedy wiele sklepów ma najwięcej sprzedaży.
- Kopie zapasowe i test ich odtworzenia, z częstotliwością i miejscem przechowywania.
- Własność kodu, repozytorium i dostępów po stronie Twojej firmy.
- Konsekwencje przekroczenia terminów, na przykład obniżenie abonamentu. Konkretne zapisy o karach umownych warto ustalić z prawnikiem.
W opiece nad sklepem czas reakcji na błąd krytyczny to 4 godziny w dni robocze (10–18), a w pakiecie rozszerzonym także 8 godzin w weekendy i święta. Zapisujemy to w umowie, a do tego monitoring, kopie zapasowe i wdrożenia z repozytorium, które da się cofnąć.
Repozytorium, wdrożenia CI/CD z możliwością cofnięcia, monitoring Sentry, kopie zapasowe i czas reakcji w umowie.
Zobacz, jak utrzymujemy sklepy