Przypominamy ciekawe teksty z Android.com.pl, które są już nieco starsze. Jeśli chcecie powspominać i zobaczyć, jak wyglądał świat IT kilka lat temu – zapraszamy do przeczytania poniższego artykułu. Część wiedzy nadal jest jak najbardziej aktualna, ale w obliczu dynamicznych zmian, pojawienia się AI i innych nowości wynikających z postępu technologicznego – sporo również się zmieniło. Oryginalna treść tekstu opublikowanego w 2019 roku znajduje się poniżej.
Witajcie, dzisiejszy temat będzie dość luźny. Opowiemy sobie o różnych wpadkach, które są związane z programowaniem. Nie jest to lista najbardziej kosztownych wpadek. Postanowiłem wybrać te najciekawsze, z których można wyciągnąć pewną lekcję. Nie sugerujcie się też kolejnością, bo jest ona przypadkowa.
Spis treści
Skąd się biorą błędy?
Już kiedyś wspominałem, że w programowaniu każdy błąd ma swoją przyczynę w człowieku, ponieważ to my tworzymy oprogramowanie. Tutaj jednak chciałbym się skupić nad tym, co tak naprawdę sprawia, że programiści się mylą?
Tak naprawdę pomyłki są czymś powszechnym. Rzadko zdarza się, żeby udało się napisać jakąś skomplikowaną funkcjonalność bez zrobienia żadnego błędu po drodze. Dlatego jest wiele osób oraz narzędzi, które pomagają nam te błędy wychwycić. Najważniejsze jest odpowiednie przetestowanie napisanych przez nas funkcjonalności.
Większość pomyłek wychodzi jeszcze na etapie tworzenia aplikacji i zostają poprawione przed wydaniem jej na świat. Jednak jak dowiecie się w dalszych akapitach, nie zawsze tak się dzieje. Jakie są tego przyczyny? Przeważnie nie możemy wskazać jednej, konkretnej, bo w większości przypadków błąd jest wynikiem połączenia kilku niefortunnych zdarzeń oraz decyzji.
Głównymi czynnikami mogącymi doprowadzić do powstania błędów są pośpiech, wywieranie presji na testerów, nieodpowiednia liczba testerów oraz bagatelizowanie wagi wprowadzanych zmian, czyli po co testować skoro to tylko drobna zmiana…
Czy błędy to coś złego?
Tutaj sprawa nie jest taka prosta. Oczywiście błędy nie powinny wystąpić, bo często prowadzą one do strat finansowych lub co gorsza, ludzkich. Jednak często mimo swoich beznadziejnych skutków, mają też pewien pozytywny oddźwięk, ponieważ często prowadzą do usprawnienia procedur i uniemożliwienia powstania podobnych błędów w przyszłości.
Na pewno każdy z nas zna powiedzenie „uczyć się błędach”. Ważne, żebyśmy minimalizowali prawdopodobieństwo wystąpienia błędów, a jeśli już wystąpią, to wyciągali z nich jak najwięcej wniosków. To tyle słowem wstępu, przejdźmy więc do najbardziej interesujących wpadek programistów.
Katastrofa sondy Mars Climate Orbiter
Ta wpadka jest chyba moją ulubioną. Jest dość zabawna i na szczęście nie doprowadziła do niczyjej śmierci. 11 grudnia 1998 roku rozpoczęła się misja NASA, której celem było wyniesienie sondy badawczej na orbitę Marsa. Początkowo wszystko przebiegało bez żadnego zarzutu, 23 września 1999 roku około godziny 9:00 sonda rozpoczęła manewr osadzania się na orbicie.
Kilka minut później znalazła się ona w cieniu radiowym marsa (docieranie sygnału na ziemię było niemożliwe). Co ciekawe stało się to prawie minutę wcześniej, niż przewidywali naukowcy. Obliczano, że kontakt z sondą będzie możliwy około godziny 9:30, jednak, mimo licznych prób, nigdy się to nie udało. 25 września 1999 roku, czyli dwa dni później NASA poinformowała o zniszczeniu sondy. Jak wykazało późniejsze śledztwo, spłonęła ona w atmosferze marsa.
Sonda zbliżyła się zbyt blisko czerwonej planety (różnica w wysokości wynosiła około 100 km). Skąd tak ogromna różnica w przemyśle, gdzie wszystko jest obliczane z ogromną dokładnością? Przyczyna była dość banalna. Programiści nie ustalili między sobą, czy będą używać systemu imperialnego (używany głównie w Wielkiej Brytanii i USA), czy może jednak metrycznego (praktycznie reszta świata). W rezultacie naukowcy z kontroli naziemnej do określenia siły używali imperialnych funtów na sekundy, a sonda interpretowała jako metryczne niutonosekundy.
Winą takiego zajścia była niedostateczna komunikacja NASA z firmą Lockheed Martin, która była autorem części systemu. NASA wzięła winę w całości na siebie, tłumacząc, że to oni byli odpowiedzialni za przeprowadzenie odpowiednich testów. Koszt sondy był szacowany na 125 milionów dolarów.
Krytyczny błąd w panamskim instytucie onkologicznym
Cała historia działa się pomiędzy sierpniem 2000 a marcem 2001 roku. Pacjenci chorzy na raka prostaty oraz raka szyjki macicy byli poddawani radioterapii. Po pewnym czasie u 28 pacjentów zaobserwowano objawy choroby popromiennej. W przypadku 8 osób choroba zakończyła się śmiercią.
W szpitalu tym podobnie jak w innych do obliczania dawek promieniowania wykorzystywano TPS — treatment planning system. Jest to system komputerowy do planowania terapii. W przypadku leczenia radiologicznego promieniowaniu poddawane są tylko chore tkanki, wobec czego reszta ciała pacjenta jest chroniona przez specjalne bloki osłonne, które nie przepuszczają niebezpiecznego promieniowania. TPS miał pewne ograniczenie. Pozwalał on na uwzględnienie jedynie czterech bloków ochronnych przy obliczaniu czasu terapii oraz dawek promieniowania.
Jeden z radiologów uważał, że w celu zapewnienia odpowiedniego poziomu bezpieczeństwa powinno się stosować pięć bloków ochronnych. Zdecydowano więc, że do TPS dodadzą zsumowane informacje o pięciu blokach, tak jakby to był tylko jeden blok. TPS co prawda przyjął dane, jednak wyniki obliczeń były błędne. Mianowicie obliczony okres trwania radioterapii był znacznie dłuższy, niż powinien. Co naraziło pacjentów na przyjmowanie zbyt dużych dawek promieniowania.
Po śledztwie okazało się, że nikt tak naprawdę nie sprawdził, czy nowa metoda podawania danych o blokach ochronnych jest poprawna. Nie wykonano żadnych testów ani nie skonfrontowano obliczeń TPS z obliczeniami ręcznymi. Winę za całe zajście ponosi więc jedynie personel szpitala, a nie twórcy oprogramowania. Jest to świetny przykład na to, że nie powinniśmy używać tak ważnych systemów komputerowych niezgodnie z ich instrukcjami.
Otwarcie 5 terminalu na lotnisku Heathrow
W 2008 roku wraz z otwarciem nowego terminala na lotnisku Heathrow wprowadzono do użytku nowy system obsługi bagażu. Jak zapewniają osoby odpowiedzialne za całą operację, system został poddany szczegółowym testom przed oddaniem go do użytku. Jednak rzeczywistość zweryfikowała te zapewnienia już pierwszego dnia.
Występowały liczne problemy, system wskazywał mylące komunikaty obsłudze lotnika. Pojawiają się również informacje, że w przypadku ręcznego wyciągnięcia bagażu system całkowicie się wyłączał. W ciągu 10 dni 42 tys. walizek nie mogło zostać nadanych oraz odwołano ponad 500 lotów, co doprowadziło do milionowych strat.
Nie wiadomo do końca, jakie były przyczyny błędów. Pojawiają się wypowiedzi pracowników, którzy już w czasie testów informowali przełożonych o problemach z systemem. Prawdopodobnie z powodu presji świadomie oddano nie do końca przetestowany system, byle by wyrobić się w terminie.
Awaria GitLab
Dla ludzi związanych z programowaniem GitLab jest dość znanym serwisem. Umożliwia on zarządzanie całym projektem w jednym miejscu, wliczając w to przechowywanie kodu źródłowego, budowanie aplikacji, utrzymywanie dokumentacji i wiele innych. Sama awaria jest dość świeżą sprawą, ponieważ wszystko wydarzyło się 31 stycznia 2017 roku.
Oryginalnie GitLab używał tylko jednego serwera bazy danych i właśnie na 31 stycznia zaplanowano testy rozwiązania używającego dwóch serwerów na testowym środowisku. W tym celu rozpoczęto kopiowanie danych ze środowiska produkcyjnego na testowe, co było standardową procedurą.
W międzyczasie administratorzy zobaczyli wzmożoną ilość operacji na produkcyjnej bazie danych, co początkowo zidentyfikowali jako spam. Okazało się, że to automatyczne mechanizmy zaczęły usuwać z bazy konta zidentyfikowane jako niebezpieczne (na przykład spamerzy). W rezultacie wzmożonego ruchu cały proces kopiowania danych zaczął zwalniać, a później zatrzymał się całkowicie w wyniku rozbieżności danych (informacje z bazy produkcyjnej były usuwane w trakcie procesu kopiowania).
Po kilku próbach wznowienia procesu jeden z pracowników postanowił usunąć bazę testową i rozpocząć proces od nowa. Niestety przez przypadek usunął bazę produkcyjną i zorientował się, gdy ponad 300 GB danych było już usunięte.
Takie sytuacje się zdarzają, więc pracownik po prostu zalogował się na zewnętrzny serwer, na który wysyłane były kopie zapasowe baz danych. Z przerażeniem odkrył, że katalog przechowujący kopie jest pusty. W późniejszym śledztwie okazało się, że kopie zapasowe z powodu błędu w konfiguracji nie wykonywały się już od dłuższego czasu.
Normalnie wszystkie błędy wykonywania kopii zapasowych były wysyłane do pracowników na maile. Jednak po sprawdzeniu wyszło na jaw, że konfiguracja skryptów wysyłających maile również była błędna. Na szczęście zespół wykonywał też co 24 godziny zrzuty całych dysków, które uratowały całą firmę. Dodatkowo programista przygotowujący migrację danych również wykonał zrzut dysku przed całą operacją.
Po 18 godzinach udało się przywrócić aplikację, jednak do stanu sprzed 6 godzin od wystąpienia awarii. Firma szacuje, że przez to utracili dane o co najmniej 5000 nowych projektach, 5000 komentarzach oraz 700 użytkownikach. Na pochwałę zasługuje to, w jaki sposób firma podeszła do awarii.
Nie było żadnego zamiatania pod dywan, cała procedura przywracania danych była transmitowana na żywo w serwisie YouTube (w pewnym momencie stream śledziło 5000 osób), po wszystkim wystosowano oświadczenie, w którym szczegółowo wyjaśniono, co się stało. Dodatkowo firma opublikowała listę usprawnień, które wdroży, aby taka sytuacja już nigdy się nie potwierdziła.
Koszmarny pierwszy dzień w pracy
Dość zabawna historia, która przydarzyła się jednemu z użytkowników Reddita. Użytkownik ten został zatrudniony jako młodszy programista. Po przyjściu do pracy dostał mini książkę z poradnikiem jak skonfigurować środowisko programistyczne na swoim komputerze. W pierwszym kroku musiał uruchomić skrypt, który tworzył na jego komputerze bazę danych z testowymi danymi.
Na końcu skrypt pokazywał dane dostępowe do bazy, które należało potem używać przy programowaniu. Niestety pracownik zamiast użyć danych ze skryptu, skonfigurował swoje środowisko, korzystając z danych z książki.
Po skonfigurowaniu wszystkiego przyszła pora na uruchomienie testów. Przeważnie działają one tak, że przed każdym testem baza danych jest czyszczona i wypełniana konkretnymi danymi wymaganymi przez test (tak, aby każdy test był niezależny). Niestety dane wprowadzone przez młodego programistę (te, które znalazł w książce) okazały się danymi bazy produkcyjnej. Z relacji tego pracownika wynika, że firma nie miała prawidłowo skonfigurowanych kopii zapasowych i w rezultacie dane zostały bezpowrotnie utracone.
Bulwersująca jest reakcja szefa przedsiębiorstwa, który całą winę zrzucił na pracownika, straszył go konsekwencjami prawnymi, a na końcu kazał się wynosić i nigdy nie wracać. Oczywiście główną przyczyną tego problemu były wadliwe procedury w firmie. Przede wszystkim początkujący programista nie powinien mieć dostępu do produkcyjnej bazy, dodatkowo mechanizmy wykonywania kopii zapasowej powinny być prawidłowo skonfigurowane.
Na szczęście użytkownicy Reddita słusznie pocieszali autora wątku, ponieważ nie było w tym jego winy. Co ciekawe, wśród pocieszających był również pracownik GitLaba odpowiedzialny za skasowanie bazy danych, o której mówiłem w poprzednim akapicie.
Pozostałe odcinki serii o programowaniu.
Źródło: Wikipedia, Reddit, oprac. własne. Zdjęcie otwierające: Panya_photo / Shutterstock