Klient napisał krótko: zainstalujcie captchę na rejestracji, dostajemy kilka fałszywych kont dziennie. Wyceniliśmy to na kilkaset złotych i trzy dni robocze. Standardowe zadanie, robione dziesiątki razy. Skończyło się na kilkunastu godzinach dochodzenia, dlaczego nic nie działa tak, jak powinno, i jednej awarii całej strony po drodze. Poniżej opisujemy, co się właściwie stało, bez zdradzania, o którego klienta chodziło, bo to nie jest historia o wstydzeniu kogoś, tylko o tym, jak wygląda utrzymanie starych systemów w praktyce.
Zlecenie wygląda prosto, dopóki nie zajrzysz pod maskę
Sklep internetowy działał od kilku lat na popularnym systemie do prowadzenia e-commerce. Klient miał gotowe klucze do usługi captcha, mieliśmy dostęp do plików, zadanie brzmiało jak jedno popołudnie pracy: wgrać moduł, skonfigurować, sprawdzić. W teorii wystarczy zainstalować gotowy, sprawdzony moduł zabezpieczający formularz rejestracji i podpiąć klucze klienta.
W praktyce moduł już leżał na serwerze. Ktoś go tam kiedyś wgrał i na tym poprzestał. Nigdy nie został prawidłowo zainstalowany w systemie, nigdy nie trafił do żadnego formularza, więc mimo że pliki istniały, funkcjonalnie nie robił absolutnie nic. Pierwsza lekcja: obecność plików na serwerze nie znaczy, że coś działa.
Instalacja na sucho, bo produkcji się nie testuje na żywo
Zamiast eksperymentować na działającym sklepie klienta, postawiliśmy lokalną kopię środowiska, dopasowaną do tej samej, dość wiekowej wersji systemu i PHP co na produkcji. To kluczowa zasada przy każdej pracy na cudzym, żywym biznesie: najpierw testujesz u siebie, dopiero potem wgrywasz dalej. Na kopii lokalnej wszystko poszło gładko. Moduł się zainstalował, captcha się wyświetliła, formularz działał jak należy.
Przenieśliśmy dokładnie te same kroki na serwer produkcyjny i moduł odmówił współpracy. Okazało się, że instalacja klienta przez lata była na tyle mocno modyfikowana ręcznie, że brakowało jej części standardowych plików, na których opierał się mechanizm instalacji modułów. Coś, co w świeżej instalacji działa od ręki, na mocno wysłużonym, wielokrotnie łatanym sklepie po prostu się wykrzacza.
Cudza, niedokończona robota, która czekała jak mina
Grzebiąc głębiej w szablonie strony, znaleźliśmy fragment kodu, który nie miał prawa tam być: niedokończoną, zepsutą próbę wdrożenia zabezpieczenia od poprzedniego wykonawcy. Inny dostawca usługi, inny klucz dostępu, kod z błędem składniowym, który uniemożliwiał poprawne przetworzenie szablonu strony.
Dlaczego strona wcześniej działała pomimo błędu w kodzie? Bo serwer trzymał w pamięci podręcznej starą, poprawną wersję strony i nigdy nie próbował przeliczyć jej na nowo. Błąd spał cicho, aż my, próbując wgrać własną poprawkę, odświeżyliśmy tę pamięć podręczną. W tym momencie system spróbował przeliczyć wszystko od nowa, natrafił na zepsuty fragment sprzed lat i cała strona przestała działać. Nie u klienta z naszej winy w sensie wprowadzenia błędu, ale z naszej winy w sensie: powinniśmy byli sprawdzić dokładniej, zanim ruszyliśmy coś, co nie było ruszane od dawna.
Tu przypominamy sobie o zasadzie, którą znamy z dużych wdrożeń, a o której łatwo zapomnieć przy „drobnym" zleceniu: przed każdą zmianą robisz kopię zapasową dokładnie tych elementów, które zamierzasz ruszyć. Mieliśmy taką kopię. Przywrócenie strony do stanu sprzed naszej ingerencji zajęło kilka minut, nie kilka godzin.
Naprawiliśmy cudzy błąd, zanim naprawiliśmy własne zadanie
Zanim mogliśmy w ogóle wrócić do captchy, trzeba było posprzątać po poprzednikach: usunąć martwy, zepsuty kod, przywrócić stronie stabilność. Efekt uboczny: sklep klienta po naszej wizycie jest odporniejszy niż był przed nią, bo ta mina już tam nie leży i nie czeka na kolejne przypadkowe odświeżenie pamięci podręcznej.
Dopiero na tak oczyszczonym gruncie mogliśmy wrócić do właściwego zadania. Kolejna przeszkoda: gotowy moduł zabezpieczający sprawdzał inny sygnał wysyłania formularza niż ten, którego faktycznie używał szablon sklepu klienta. Krótko mówiąc, gdyby udało się wcisnąć sam wygląd captchy bez naprawienia tego niedopasowania, klient dostałby ładny checkbox, który nie blokuje absolutnie żadnego bota. Estetyczna atrapa zamiast zabezpieczenia, gorsza niż brak zabezpieczenia w ogóle, bo daje fałszywe poczucie bezpieczeństwa.
Jak to ostatecznie przetestowaliśmy
Zamiast wierzyć, że kod „powinien" działać, przeprowadziliśmy realny test. Wysłaliśmy do formularza rejestracji dokładnie taki zestaw danych, jaki wysłałby automat: bez zaznaczonej captchy, z kompletem pozostałych pól. Wynik: formularz odrzucił próbę, użytkownik zostaje na stronie z czytelnym komunikatem, żadne konto się nie tworzy. Dopiero po takim teście, a nie po samym wgraniu kodu, uznaliśmy zadanie za wykonane.
Osobno sprawdziliśmy scenariusz odwrotny: prawdziwa osoba, zaznaczona captcha, rejestracja przechodzi bez przeszkód. Oba scenariusze musiały się zgadzać, zanim cokolwiek zgłosiliśmy klientowi jako gotowe.
Czego to uczy właściciela starszej strony lub sklepu
Nie każda strona z pozoru „po prostu działająca" jest w dobrym stanie w środku. Lata poprawek, zmian wykonawców i doraźnych łatek zostawiają ślady, które nie są widoczne na pierwszy rzut oka, ale ujawniają się przy pierwszej poważniejszej ingerencji. Im starsza strona i im więcej osób po niej wcześniej „poprawiało", tym większe ryzyko, że pod spodem czeka coś w rodzaju archeologicznego wykopaliska.
To nie znaczy, że trzeba się bać dotykać starych systemów. Znaczy to, że wyceniając taką pracę, warto zakładać margines na niespodzianki, testować zmiany poza produkcją, robić kopie zapasowe przed każdym ruchem i weryfikować efekt realnym testem, a nie samym brakiem błędu na ekranie.
Najczęstsze pytania
Czy to normalne, że proste zlecenie się komplikuje?
Przy nowych, dobrze utrzymanych stronach rzadko. Przy systemach, które od lat przechodziły przez ręce różnych wykonawców, zdarza się częściej, niż klienci by się spodziewali.
Czy klient płaci za takie niespodzianki więcej, niż było ustalone?
Zależy od umowy i skali odkrycia. W tym przypadku zmieścliśmy się w pierwotnej wycenie, bo dodatkowa praca dotyczyła tego samego obszaru kodu, który i tak trzeba było ruszyć. Przy większych odkryciach informujemy klienta i ustalamy dalsze kroki, zanim przekroczymy zakres.
Jak sprawdzić, czy moja stara strona ma podobne problemy?
Najprościej zlecić audyt techniczny przed planowaną zmianą, zwłaszcza jeśli strona nie była aktualizowana od dłuższego czasu lub przechodziła przez wielu wykonawców.
Czy nie prościej było postawić stronę od nowa?
Czasem tak, ale to zupełnie inna, znacznie droższa decyzja biznesowa. Naszym zadaniem było zrealizować konkretne zlecenie na istniejącym systemie, nie przebudowywać całego sklepu.
Jak upewnić się, że wykonawca faktycznie przetestował zmianę, a nie tylko ją wgrał?
Poproście o opis testu, nie tylko informację „gotowe". Prawdziwy test to próba oszukania własnego zabezpieczenia, nie samo sprawdzenie, czy strona się otwiera.
Podsumowanie
Zlecenie, które w wycenie wyglądało na kilka godzin pracy, zamieniło się w dochodzenie przez warstwy lat zaniedbań i cudzych, niedokończonych poprawek. Skończyło się dobrze: captcha działa, przetestowana na realnym scenariuszu bota i realnym scenariuszu człowieka, a strona klienta wyszła z tego stabilniejsza, niż była na starcie. Jeśli Twoja strona lub sklep internetowy działa od lat bez większego audytu i planujesz w nią ingerować, warto zrobić to z kimś, kto potrafi się cofnąć, gdy coś pójdzie nie tak, zanim ruszy dalej. Napisz do nas, sprawdzimy stan Twojej strony przed zmianami.
