Kosztowne wpadki na produkcji – czyli historie wpadek, które były bardzo spektakularne. W ramach niniejszego wpisu poruszymy tematykę wpadki na lotnisku Heathrow w Londynie, tragedię w Panamskim instytucie onkologicznym, czy też Londyńskim pogotowiu ratunkowym. Dodatkiem będzie też wpadka GitLaba.
Lotnisko Heathrow i odwołane loty.
Terminal 5, bo o nim będzie niniejszy akapit, powstał za kwotę blisko 4,3 mld funtów. Otwarcie wskazanego terminala było uroczyste i miało być krokiem milowym dla londyńskiego lotniska. Zamiast splendoru i pochwał była ogromna wpadka. Podczas pierwszych pięciu dni zagubiono ponad 23 000 sztuk bagażu, odwołało 500 lotów i przyniosło straty w wysokości 16 milionów funtów. Co było przyczyną takiej ogromnej wpadki?
Willie Walsh – dyrektor generalny British Airways ujawnił, że problemy IT i brak testów odegrały dużą rolę w tym problemie. Powiedział jednak, że linia lotnicza mogłaby sobie poradzić, gdyby to był jedyny problem. Lista problemów związanych z działaniem systemu jest spora. To najważniejszych wymieniony przez W. Walsha należą:
- osoby odpowiadające za załadunek nie mogły automatycznie dodawać bagażu, wszystkie czynności musiały być wykonywanie manualnie – co powodowało opóźnienia lotów;
- terminal 5 miał problemy z siecią bezprzewodową na niektórych stanowiska co utrudniało komunikację pomiędzy poszczególnymi punktami;
- w trakcie testowania systemu bagażowego wdrożono filtry, które zapobiegały wysyłanie wiadomości w inne części Heatrow. Po testach zapomniano wyłączyć filtrów by wiadomości były przesyłane. Efektem tego system Terminalu 5 nie otrzymał informacji o przesyłaniu toreb do British Airways od innych linii lotniczych. Nierozpoznane bagaże zostały automatycznie przesłane do ręcznego sortowania w magazynie terminala.
Po wydarzeniach z marca były kolejne problemy z systemem, który obsługiwał Terminal 5.
- określono ten incydent jako „Nieprawidłowa konfiguracja”, która zatrzymała przesyłanie danych z systemu obsługi bagażu do systemu rozpoznawania bagażu. W sobotę 5 kwietnia 2008 roku – półtora tygodnia po otwarciu – system pojednawczy zawiódł przez cały dzień. Torby spóźniły się na loty, ponieważ wadliwy system wskazał personelowi, że nie przeszły kontroli bezpieczeństwa;
- ponadto wystąpiły błędy w transmisji danych lotu BA między BAA a łącznością i ich wykonawcą IT SITA. W rezultacie system nie rozpoznał części bagaży, które były przechowywane w systemie bagażowym Terminala 5 do ręcznego przetwarzania. Brak pojemności serwera w terminalu zwiększył tylko problemy;
- w miarę narastania tych błędów system nie rozpoznawał większej liczby bagaży, spóźniały się na loty lub musiały zostać ponownie zarezerwowana na nowe loty. System obsługi bagażu zawiesił się po tym, jak nie był w stanie poradzić sobie z liczbą komunikatów generowanych podczas ponownych rezerwacji lotów, co zmusiło menedżerów do wyłączenia automatycznego systemu ponownej rezerwacji.
Wracając do pierwszego dnia otwarcia Terminala 5.
Do godziny 17:00 British Airways nie mógł już przyjmować bagażu rejestrowanego. Wskazano pasażerom w hali odlotów, że wyjadą bez bagażu. Każdy, kto jeszcze się nie odprawił, mógł wybrać między podróżą bez bagażu a zmianą rezerwacji lotu. Personel wyciągał nierozpoznane torby z systemu i sortował je ręcznie – działo się to codziennie do 31 marca.
W podsumowaniu British Airways w raporcie przypisuje brak wykrycia problemów informatycznych nieodpowiednim testom systemu, spowodowanym opóźnieniami w pracach konstrukcyjnych BAA. Zakończenie budowy zaplanowano na 17 września 2007 roku. Opóźnienia oznaczały, że pracownicy BA IT nie mogli rozpocząć testów do 31 października. Kilka prób musiało zostać anulowanych, a BA musiało ograniczyć zakres prób systemowych, ponieważ personel testujący nie mógł uzyskać dostępu do całej witryny Terminalu 5.
„W chwili otwarcia wierzyłem, że posunięcie się powiedzie” – powiedział Walsh. „Żałuję tego, ale tak naprawdę nie spotkałem nikogo, kto byłby w stanie przewidzieć konkretne problemy, jakie moglibyśmy napotkać”.
Panamski instytut onkologiczny.
Historia działa się blisko 20 lat temu pomiędzy sierpniem 2000 a marcem 2001 roku. W tamtym czasie pacjenci chorzy na raka prostaty oraz szyjki macicy byli poddawani radioterapii. Po pewnym czasie wśród 28 pacjentów zaobserwowano objawy choroby popromiennej, na skutek czego 8 pacjentów zmarło. We wskazanym instytucie do obliczania dawek promieniowania wykorzystywano TPS — treatment planning system (system do planowania terapii). W przypadku leczenia radiologicznego promieniowaniu poddawane są tylko chore tkanki, wobec czego reszta ciała pacjenta jest chroniona przed wpływem promieniowania. TPS miał pewne ograniczenie. Pozwalał on na uwzględnienie jedynie czterech bloków ochronnych przy obliczaniu czasu terapii oraz dawek promieniowania. Jeden z medyków uważał, że w celu zapewnienia lepszego poziomu bezpieczeństwa, powinni zastosować pięć bloków ochronnych. W świetle takich zmian zadecydowano, że do systemu TPS dodadzą zsumowane informacje o pięciu blokach. TPS przyjął dane, jednak wyniki jego obliczeń, były błędne. Rezultat wyliczeń systemu – okres trwania radioterapii był dłuższy aniżeli powinien, co skutkowało przyjmowaniem przez pacjentów zbyt dużych dawek promieniowania.
Skutki.
W świetle tych wydarzeń, na skutek których śmierć poniosło 8 pacjentów przeprowadzono śledztwo. W trakcie przeprowadzonych czynności stwierdzono, że nikt nie sprawdził czy nowa metoda podawania danych o blokach ochronnych jest prawidłowa. Nie wykonano też żadnych testów, ani też nie skonfigurowano systemu TPS, czy też nie dokonano przeliczeń ręcznych rezultatów z systemu. Winą za to zajście obarczono personel, który korzystał z systemów w sposób niezgodny z instrukcją.
Zaznaczyć zatem należy, że przy tak ważnych systemach istotnym może być zawężanie możliwości wykorzystania na produkcji, czy też bardziej szczegółowe uzgadnianie aspektów technicznych tworząc dane rozwiązanie. Oczywiście odpowiednie i szczegółowe testy w oparciu o wymagania klienta na pewno mogłyby pomóc zminimalizować ryzyko wystąpienia takiego wydarzenia.
Londyńskie pogotowie ratunkowe – 1992.
Historia
W 1992 roku pogotowie w Londynie zapewniało obsługę blisko 6,8 miliona mieszkańców z obszaru blisko 600 mil kwadratowych. Na swoim stanie posiadano 318 karetek pogotowia ratunkowego, podczas gdy w służbie w jednym czasie było 212. Prócz tego posiada 445 karetek, helikopter i motocykle. Na całą strukturę składało się 70 stacji zatrudniających ponad 2700 pracowników. Całym systemem zarządzano z centrali. Średnio odbierano codziennie 2000-2500 wezwań. 55% swojego personelu i 76% budżetu przeznaczano na reagowanie w sytuacjach kryzysowych.
System ręczny
System manualny był kosztowny i składał się z etapów:
- przyjmowanie połączeń – po odebraniu wezwania pogotowia ratunkowego odbiorca wypełnił papierowy formularz, znalazł lokalizację dzwoniącego na mapie, a następnie umieścił go na przenośniku taśmowym;
- identyfikacja zasobów – przenośnik taśmowy przekazał formularze innemu pracownikowi LAS, który przeanalizował lokalizacje i stany karetek pogotowia w rejonie wezwania. Następnie przydzielił wezwanie do dostępnej jednostki i zapisał zadanie na formularzu;
- mobilizacja zasobów – wreszcie dyspozytor nawiązał kontakt z karetką, do której przypisano wezwanie, i przekazał operatorowi szczegóły wezwania.
Automatyzacja
Rząd przedstawił by reagowano na zdarzenia w przeciągu 3 minut od uzyskania zgłoszenia. Rozpoczęto przygotowania i wdrożono system, który będzie ułatwiał pracę i przyśpieszał czas realizacji. Kierownictwo postawiło cel by większość czynności odbywała się automatycznie. Prostą sekwencją czynności wykonywanych przez osobę byłoby odebranie telefonu, wprowadzenie danych o zdarzeniu do terminala komputerowego. Jeśli system wyświetli komunikaty o wyjątkach wynikające z braku karetek dłużej niż 11 minut operator udzieli odpowiedzi. . Lokalizacje połączeń byłyby mapowane przez oprogramowanie. System wykorzysta następnie dane mapy oraz szczegóły dotyczące lokalizacji i statusu, aby znaleźć i wysłać dostępną karetkę najbliższą miejscu zdarzenia. Na domiar złego system ten byłby wdrażany nie przyrostowo, ale wszystkie naraz
Skutki
Po całej masie problemów, w tym anulowaniu projektu i ponownym zaprojektowaniu, opracowano system oprogramowania i został on wdrożony rano 26 października 1992 r. Jednak już kilka godzin później zaczęły się pojawiać problemy. AVLS nie był w stanie śledzić karetek i ich statusu w systemie. Zaczął wysyłać wiele jednostek do niektórych lokalizacji i żadnych jednostek do innych lokalizacji. Skuteczność, z jaką przydzielał pojazdy do wywoływania lokalizacji, była poniżej standardów. System zaczął generować tak dużą liczbę komunikatów o wyjątkach na terminalach dyspozytorskich, że połączenia zostały utracone. Problem narastał, gdy ludzie dzwonili ponownie, ponieważ oczekiwane przez nich karetki nie przyjechały. Ponieważ do systemu wprowadzano coraz więcej incydentów, system spowalniał coraz bardziej. Następnego dnia przełączono się z powrotem na system częściowo ręczny i całkowicie wyłączono system komputerowy, gdy przestał działać w ogóle osiem dni później.
Ze względu na duży obszar obsługiwany przez pogotowie awaria systemu komputerowego bezpośrednio dotknęła wiele osób. Było aż 46 zgonów, których można byłoby uniknąć, gdyby wezwana karetka przyjechała na czas. Jedna załoga pogotowia przyjechała tylko po to, aby stwierdzić, że pacjent nie tylko zmarł, ale jego ciało zostało zabrane przez pracownika pogotowia.
Bezpośrednie przyczyny
W momencie uruchomienia systemu było 81 znanych problemów z oprogramowaniem i nie przeprowadzono żadnych testów wydajnościowych. Nie przewidziano systemu zapasowego. Podczas gdy 10-miesięczna przerwa między pierwszym szkoleniem dyspozytorów w zakresie korzystania z oprogramowania a jego wdrożeniem odegrała swoją rolę w katastrofie, oprogramowanie miało trzy podstawowe wady, które natychmiast spowodowały awarię.
- Niedoskonałe dane – system oprogramowania nie działał dobrze w przypadku podania nieprawidłowych lub niepełnych danych dotyczących pozycji i stanów karetek.
- Problemy z interfejsem – wdrożony system miał wiele różnych dziwactw w różnych częściach interfejsu użytkownika. Na przykład części ekranów terminali MDT miały czarne punkty, co uniemożliwiało operatorom karetek uzyskanie wszystkich potrzebnych informacji. Gdy załogi karetki próbowały naprawić błędy po naciśnięciu niewłaściwych przycisków, system nie zaakceptował poprawki.
- Wyciek pamięci – główną przyczyną głównej awarii systemu był wyciek pamięci w niewielkiej części kodu. Ta wada zachowała pamięć, w której przechowywane były informacje o incydentach na serwerze plików, nawet gdy nie były już potrzebne. Jak w przypadku każdego wycieku pamięci, po odpowiednim czasie pamięć zapełniła się i spowodowała awarię systemu.
Głębsze problemy
Pierwotny projekt systemu „CAD LAS” został po raz pierwszy zaproponowany w 1987 roku. Został zmodyfikowany w 1989 roku, a następnie, z powodu nadmiernych wydatków o około 300%, projekt został odwołany w 1990 roku. Jednak krajowy mandat do skrócenia czasu reakcji w sytuacjach kryzysowych spowodował by ponownie zająć się systemem. Kiedy projekt został ponownie otwarty, osoby, które nim zarządzały, podeszły do niego z głównym celem, jakim było zaoszczędzenie jak największej ilości czasu i pieniędzy. Chociaż jest to rozsądny cel każdego projektu, miał zbyt duże znaczenie w tym projekcie. W ramach próby zaoszczędzenia pieniędzy zdecydowano się ponownie wykorzystać część sprzętu, który został już zakupiony podczas pracy nad nieudanym projektem, zamiast kupować sprzęt, który był albo bardziej aktualny, albo bardziej odpowiedni dla nowego systemu.
Proces, za pomocą którego zbierano wymagania oraz sporządzano specyfikacje i projekty, miał kilka poważnych wad. Po pierwsze, wydaje się, że zespół odpowiadający za projekt – a nie zespół programistów – przeszedł przez ten proces bez próby konsultacji z operatorami karetek, dyspozytorami i innymi kluczowymi użytkownikami systemu. Podstawowe zrozumienie procesu wymagań oprogramowania sugeruje, że pomijanie kluczowych interesariuszy jest szkodliwe dla projektu i skutkuje niekompletnym zestawem wymagań. Co więcej, dokument wymagań był „bardzo szczegółowy i niezwykle normatywny”, co było bardzo bezpośrednią sprzecznością z koncentracją procesu wymagań na tym, co, a nie na tym, jak.
Wadliwy proces
Kilka innych części procesu tworzenia oprogramowania odegrało dużą rolę w ostatecznej awarii wdrożonego produktu. Nie przeprowadzono kontroli jakości, brakowało zarządzania konfiguracją, nie śledzono uzgodnionych zmian i nie pisano planów testów. W pewnym momencie rozwoju systemu zleceniodawca rozważał zatrudnienie jednego z pozostałych oferentów do wykonania pewnych zadań związanych z zapewnieniem jakości. Ponieważ było to postrzegane jako zadanie rozwijającej się organizacji, pomysł ten został zignorowany. Chociaż każda rozwijająca się organizacja powinna być w stanie zapewnić jakość swoich produktów, testowanie jest niemożliwe, skoro zakodowanie projektu w wyznaczonych 11 miesiącach jest już nieosiągalnym celem.
Konkluzja
Wydaje się, że w tak dużym projekcie popełniono wiele błędów. Problemem wydaje się nastawienie kluczowych osób w projekcie, chęć jak największego zaoszczędzenia środków na sprzęcie, czasie oraz testach. Z góry brak możliwości przeprowadzenia dewelopmentu we wskazanym terminie, nie obejmującego testów wskazywało, że przedsięwzięcie może okazać się nierealne do zrealizowania. Ponadto brak uzgodnienia wymagań z późniejszymi użytkownikami systemu – zespołami ratownictwa medycznego, dyspozytorami itd. również spowodował taki skutek.
Usunięte bazy GitLaba.
Historia tego wydarzenia wiąże się ze strukturami GitLaba. Pierwotnie GitLab używał tylko jednego serwera bazy danych. 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. W tym czasie administracja zauważyła dużą ilość operacji na bazie produkcyjnej. Z początku zidentyfikowali to jako spam. W rezultacie okazało się, że były to automatyczne mechanizmy, które zaczęły usuwać konta z bazy, które zostały zidentyfikowane przez algorytm jako niebezpieczne. W skutek takiego procesu, kopiowanie zostało zwalniać by zatrzymać się całkowicie. Po nieudanych próbach wznowienia jeden z pracowników postanowił usunąć bazę testową i rozpocząć proces od nowa. Takie działanie spowodowało usunięcie bazy produkcyjnej. O swoim błędzie zorientował się gdy ponad 300 GB danych było już usunięte.
Firma posiadała procedury na wypadek takich wydarzeń. Pracownik zalogował się do zewnętrznego serwera na który były wysyłane kopie baz danych. Problemem jednak był fakt, że serwer na które przesyłane były kopie baz danych były puste a późniejsza weryfikacja wykazała, że kopie nie były przesyłane już od dłuższego czasu. System został skonfigurowany w ten sposób, że wszystkie błędy kopii zapasowych miały wysyłać powiadomienia e-mailowe. Weryfikacja wykryła, że skrypty wysyłające maile były błędne. Okoliczności ratujące firmę był fakt, że zespół co 24 godziny wykonywał zrzuty całych dysków, podobnie jak programista przygotowujący całą migrację. Po 18 godzinach udało się przywrócić calą aplikację do stanu sprzed 6 godzin od wystąpienia awarii.
GitLab oszacował, że na skutek tej wpadki utracili dane o co najmniej 5000 nowych projektach, takiej samej ilości komentarzy, oraz 700 użytkownikach. Ważnym faktem jest, że firma miała transperentne podejście i wydała oświadczenie w tym zakresie. Finalnie firma opublikowała listę usprawnień, które wdroży, aby taka awaria już nigdy więcej się nie powtórzyła.
Podsumowanie
Kosztowne wpadki na produkcji to drugi wpis z działu Eksplozje. W tej sekcji bardziej w ramach opowieści, będziemy przedstawiać w jaki sposób błędy w oprogramowaniu, mogą doprowadzić do przykrych, kosztownych a czasami i tragicznych wydarzeń.
