Mniej oczywiste przyczyny katastrof w projektach

Przyczyny katastrof w projektach

Praca nad projektem ma to do siebie, że zdarzają się katastrofy. Katastrofa, po której przez kogoś ważnego zostałeś publicznie przed zespołem pochwalony słowami: “Your project is  very, very, very spectacular nuclear meltdown” jest zaliczana do tych wartych zapamiętania.

Gdyby kogokolwiek zapytać jakie są przyczyny porażek projektów albo co spowodowało, że w projekcie nastąpiła spektakularna katastrofa, odpowiedzi byłyby pewnie powtarzające się – niska jakość (albo w zasadzie jej brak), napięte i niedotrzymane terminy, brak kluczowych zasobów, brak zaangażowania klienta, niekończące się zmiany itd. Ja dziś przedstawię przyczyny katastrof w projektach wynikające z (braku) jakości oraz różnic kulturowych.

Historia nr 1 (zasłyszana od kolegi z jednej krakowskich firm IT pracujących w sektorze telko)

Pewna firma IT specjalizująca się w projektach telco robiła oprogramowanie dla BTS’ów¹.

Klientem była japońska sieć komórkowa. Stworzono nową wersję oprogramowania dla BTS. Dokładnie (tak się wydawało) przetestowano. Wszystkie możliwe scenariusze. Przyjechali klienci z Japonii. Uroczyście wręczono wypaloną płytkę z nową wersją. Klienci zjedli kolację (w drogiej restauracji) i wrócili do swojego kraju ojczystego, gdzie technik wsunął płytkę do czytnika w master BTS-ie i uruchomił procedurę aktualizacji.

W środku nocy mało kto korzysta z sieci. Rezultat? Sieć komórkowa leży. Trzeba udać się fizycznie do każdego BTS-a oddzielnie i wcisnąć reset. Do jednej z wysepek należy udać się łódką i zajmuje to parę godzin. Oczywiście eskalacja, awantura itd. Uzasadniona. Sieć nie może sobie pozwolić na takie przestoje. Po pierwsze, jeśli z sieci nie można korzystać, to sieć nie zarabia. Kary w kontrakcie? Proszę bardzo. A co, jeśli ktoś potrzebuje zadzwonić na telefon alarmowy? Teraz robi się poważnie.

No cóż, porażkę trzeba przyjąć na klatę. Project manager posypuje głowę popiołem. Sprzedawcy ruszyli do ciężkiego boju, obiecali jakieś upusty. No dobra, zdarza się, jedziemy dalej. Kolejna wersja. Sprawdzona i przetestowana na milion sposobów. Scenariusz, który zawiódł, został naprawiony i również przetestowany na wszystkie możliwe sposoby. Ma działać. Przylatują klienci, witani tym razem już prawie na czerwonym dywanie. Kolejna wypalona płytka ponownie i przy dźwięku niemal fanfar jest wręczana uroczyście.

Klienci po zjedzeniu kolacji (w jeszcze droższej restauracji) powrócili do swojego kraju. Ponownie technik wsuwa płytkę i uruchamia procedurę aktualizacji. Okazuje się, że sieć ponownie leży. Ale jak to? Dlaczego? Okazuje się, że student, wypalając płytkę, pomylił ścieżki i została wypalona poprzednia wersja. Project Manager zalicza zawał serca.

Zawsze katastrofa może się wydarzyć. Zawsze. Nieważne jak dokładne testy zrobisz, nie zagwarantują 100% powodzenia. Taki mamy klimat i taka jest nasza profesja.

Historia nr 2 (własna)

Duży bank inwestycyjny. Kluczowe serwisy backendowe dla platformy wykonującej transakcje na giełdzie (uwaga: gruuuba kasa). Serwis napisany w Javie musi dostarczać metadane dla instrumentów finansowych. Wymaganie główne to czas odpowiedzi liczony poniżej milisekund. Zawsze. Kod napisany w Javie ma to do siebie, że maszyna wirtualna dowolnie jak chce może uruchomić odśmiecanie pamięci², dlatego napisany kod nie tworzy obiektów na stercie³. Wszystko na start jest prealokowane.

Na wszelki wypadek ustawiamy na maszynie wirtualnej bardzo duży obszar pamięci dla sterty. Rezultat jest taki, że jednak gdzieś tam, w jakimś miejscu malutki obiekt na stercie był tworzony. Po wielu dniach bezbłędnej i niezakłóconej przez maszynę wirtualną pracy, odśmiecarka zdecydowała, że jednak już trzeba się uruchomić, żeby zwolnić pamięć, bo już zaczyna jej brakować. Na nasze nieszczęście ktoś ustawił odśmiecarkę w trybie “serial”, wychodząc z założenia, że przecież i tak się nigdy nie uruchomi. Dlaczego? Nie wiem. Efekt? Zamrożone działanie niemal całego banku na dobrych kilka sekund. Tryb “serial” działa tak, że odśmiecarka zatrzymuje działanie programu i w jednym wątku usuwa nieużywane obiekty ze sterty. Straty? W tej skali, w której operuje ten jeden z największych na świecie banków – olbrzymie. Project manager przerażony.

Teoretycznie kod był poprawny. Zawiodła technika dostarczana wtedy przez Sun Microsystems (obecnie Oracle). Tak naprawdę to zawiodły niepoprawne założenia. W tej sytuacji po części można było temu zapobiec i domyśleć się, że taki scenariusz może się wydarzyć, są jednak przypadki, które naprawdę ciężko czasem przewidzieć.

A teraz mały quiz. 

mailbox

Źrdóło: https://www.grandinroad.com/

Drogi Czytelniku, co to jest?

Oczywiście, to skrzynka na pocztę. No dobrze, ale skąd to wiesz? Przecież, jeśli nie byłeś w “Juesej”, to raczej nie było szans na obserwację czegoś takiego w naturze. Aaa, już wiem! Widziałeś na filmach. Zgadza się. Nasze skrzynki pocztowe wyglądają inaczej. Czemu? Bo są różnice kulturowe. Tak, dobrze się domyślasz Drogi Czytelniku, że w projekcie może zdarzyć się katastrofa również z takiego powodu.

Historyjka nr 3 (zasłyszana)

Znowu projekt dla Japończyków. Tak, wiemy, ten kraj jest dziwny. Okres – lata “wczesnej Javy”, czyli okolice roku 2000. Jeszcze nie ma jakichś frameworków, rzeźbimy, używając JDBC bezpośrednio po bazce. Autentykacja i autoryzacja prymitywna, bazująca na tabeli w bazie z użytkownikiem i hasłem (oczywiście nie hashowane). Projekt tym razem do jakichś rozliczeń, faktur i tak dalej. Aplikacja online składa się z kilku modułów: logowanie, gdzie zapisujemy początek czasu pracy pracownika, moduł do “wklepywania” faktur, moduł administracyjny i oczywiście największy moduł z raportami dla szefów.

Z projektu ma korzystać około 2000 osób równolegle. Estymaty na “wklepanie” całej faktury to 5 minut, co oznacza, że w ciągu 5 minut, czyli 300 sekund mamy średnio do 2000 transakcji. Daje to nam około 7 transakcji na sekundę. No ok, ale część ludzi będzie w ubikacji, część w kuchni, część chora, część na urlopie. Nie wszyscy będą też w tym jednym module, część będzie w jakimś innym. No to będzie mniej. Kurcze, no ale musimy wziąć margines bezpieczeństwa i zrobić odpowiednie load i stress testy. Dobra, mnożymy przez dwa. Albo lepiej przez trzy. Będzie bezpieczniej. System działa, jest przetestowany.

Jedziemy bez pilota, od razu produkcja i to na całego. Pierwszy dzień. Jest ósma rano. W potężnej hali, gdzie małe biureczko ciasno styka się z kolejnym małym biureczkiem, przy każdym z nich stoi sobie (na baczność!) mały Japończyk. I tak wygląda cała hala. Po środku jest podwyższenie, na którym stoi kolejny Japończyk. Ten jest ubrany cały na biało. Na głowie biała opaska. Wykrzykuje coś głośno do sali. Nikt nie rozumie, o co mu chodzi ani co się tutaj dzieje. Nagle ten ubrany na biało krzyczy “hai!!!”. Wtedy cała hala również krzyczy “hai!!!” i wszyscy na trzy-cztery uderzają “enter”, próbując się zalogować do systemu. Baza oczywiście uklęknęła i leży. Ciężko wytłumaczyć mi dlaczego pozornie zwyczajne “hai”, które przecież żadną komendą nie jest, wywołuje taką reakcję. Niemniej jednak project manager szuka sobie nowej pracy.

Ktoś może powiedzieć oczywiście, że to nie różnica kulturowa spowodowała katastrofę, tylko brak odpowiedniego testowania. Dobrze, a więc teraz…

Historyjka nr 4 (ponownie zasłyszana od kolegi z jednej krakowskich firm IT pracujących w sektorze telko)

Znowu projekt dla telekomu. Tym razem mamy, projekt który przesyła dane pomiędzy BTS’ami. Przepustowość łączy, czyli ile rozmów równocześnie danym kablem może zostać przesłana, ktoś wyliczył, robiąc założenie, że mniej niż połowę czasu mówi jedna strona, mniej niż połowę czasu mówi druga strona, a pozostałe czas to cisza pomiędzy rozmówcami. Projekt poszedł na produkcję do pierwszego kraju. No, chwile wątpliwości i wahania były. Na szczęście działa doskonale. Drugi kraj. Wątpliwości już niewielkie, w końcu wiemy, co mamy. Trzeci kraj. Z uśmiechem, odważnie i z pewnością siebie. Kolejny kraj. Tym razem gorący i znany z temperamentu ludzi oraz silnych związków rodzinnych. Nie no, co może pójść nie tak? No i katastrofa. Okazało się, że jest częstym przypadkiem, gdy, obie strony mówią 100% czasu i żadna ze stron nie słucha tego, co mówi druga strona. Project manager ma znacznie bielsze włosy na głowie.

Winne są znowu założenia, które okazują się nieprawdziwe w zderzeniu z inną kulturą. W dobie projektów globalnych musimy nauczyć się myśleć multikulturowo.

Czy możemy uniknąć tych wszystkich katastrof? Nie. Możemy się doskonalić, analizować przyczyny katastrof w projektach, wyciągać wnioski z porażek własnych oraz cudzych, możemy uczyć się innych kultur, wciąż jednak galopująca technologia oraz pogłębiające się rozdystrybuowanie zespołów na dwóch półkulach narażać nas będą na tego typu sytuacje. Wybierając ten zawód, pomyśl o tym, a jeśli jesteś już project managerem i nieobce się Ci takie lub inne przyczyny katastrof w projektach, podziel się nimi w komentarzu.

1) BTS – Base Transceiver Station – w systemach łączności bezprzewodowej (w tym GSM) urządzenie (często z wysokim masztem), wyposażone w antenę fal elektromagnetycznych, łączące terminal ruchomy (telefon komórkowy, pager) z częścią stałą cyfrowej sieci telekomunikacyjnej (za wikipedią).

2) Procedura automatycznego usuwania obiektów które już nie są potrzebne. Java jest językiem z automatyczną obsługą pamięci. Programista nie musi ręcznie usuwać obiektów, których już nie potrzebuje. Zrobi to za niego część maszyny wirtualnej zwany potocznie “odśmiecarką” (ang. garbage collector).

3) Obszar pamięci, udostępniony na wyłączność uruchomionemu programowi (procesowi, w tym wypadku maszyny wirtualnej). Przechowuje się tam zmienne dynamiczne (za wWikipedią).

Zdjęcie: http://www.freepik.com / Designed by ijeab

Więcej wpisów autora: Jakub Dudek

O testowaniu przekrojowo i kompletnie – recenzja książki “Testowanie i jakość oprogramowania”

Testowanie oprogramowania jest tak samo stare jak tworzenie oprogramowania. Pierwotnie sądzono, że...
Czytaj dalej

2 komentarze

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *