#ibrokeshit, czyli krótka historia fuckupu

Na konferencji WrocLove.rb jedną z prelekcji prowadził Sebastian Sogamoso. Opowiedział o jednym z najgorszych dni w swoim życiu, gdy w firmie, w której pracował, wyszedł na jaw potężny fuckup.

Płatności były ściągane nie raz, ale wielokrotnie za każdą transakcję, co doprowadziło do wyczyszczenia kont wielu klientów. Puenta historii była taka, że wszyscy popełniamy błędy, ale rzadko się o nich mówi. Wstydzimy się przyznawać do porażek i, jak zauważył Jan Filipowski we wpisie Blamelessness, staramy się nie obwiniać innych, choć to często trudne. Skutek jest taki, że mamy swego rodzaju zmowę milczenia.

Moja historia

To było kilka ładnych lat temu, w pierwszym tygodniu zaraz po zmianie pracy z pierwszego stanowiska jako „junior”. Czułem się jak młody bóg, wszystko szło gładko. Fajni ludzie, nowe wyzwania, za największy sukces w karierze uznałem przyspieszenie kluczowego zapytania do bazy danych w poprzedniej aplikacji z 3 sekund do 20 milisekund. 😄 Ale też bardzo szybko wyszły na jaw braki w doświadczeniu.

W poprzednim projekcie cała produkcyjna baza danych w MySQL zajmowała 100MB i wydawała się duża. Tymczasem w nowej firmie jej wielkość była liczona w dziesiątkach gigabajtów. Dlatego przez mój brak ostrożności do kodu trafiło takie oto zapytanie:

SELECT * FROM products;

Bez limitu, ani nawet offsetu, na tabeli z kilkoma milionami rekordów. Owszem, tamta aplikacja miała architekturę master/slave (choć teraz to dość niepopularne słowa i częściej używa się nomenklatury leader/follower lub primary/secondary), więc poza główną bazą do zapisów były dwa dodatkowe serwery. Jednak wystarczyło kilkukrotne odświeżenie strony (bo długo się ładuje) i wszystkie serwery zaczęły wczytywać kilka GB do pamięci.

Co było później, pamiętam do dzisiaj. Pamiętam podniesione głosy dochodzące z pokoju administratorów (odpowiedzialnych za infrastrukturę i utrzymanie aplikacji) i CTO wbiegającego po schodach z pytaniem, dlaczego strona nie działa. Bo przecież dziesiątki tysięcy klientów zostało właśnie odciętych. Główna tabela wykorzystywana na każdej podstronie została zablokowana, a wraz z nią wszystkie serwery bazy danych. Na szczęście szybkie „ubicie” zapytań na wszystkich serwerach rozwiązało problem, ale ja zostałem sam z poczuciem porażki i wstydu. Bałem się, że ten incydent zaważy na mojej przyszłości w tamtej firmie, że wylecę z niej prędzej, niż się dostałem. Że to będzie mój koniec.

Ale stało się zupełnie inaczej. Chwile grozy zmieniły się w śmiech i anegdoty, jak to innym zdarzyło się uruchomić DROP DATABASE na produkcji zamiast na serwerze deweloperskim. I zostałem w tej firmie jeszcze przez dłuższy czas. A konsekwencje? Lepszy proces przeglądu kodu przed umieszczeniem na produkcji i lekcja ostrożności na całe życie.

Dlaczego podzieliłem się z wami tą historią? Aby przełamać tabu, do czego zachęcał w swojej prezentacji Sebastian, i abyśmy wszyscy mogli się uczyć z naszych porażek. A jaka jest Twoja historia?

Ten wpis powstał w ramach konkursu “Daj się poznać”. Publikuję tu dwa wpisy tygodniowo, jeden o moim projekcie aplikacji na iOS “Domowa apteczka” i drugi luźno związany z branżą IT.