Druga okoliczność, która wpływa na jakość oprogramowania to nieprzewidziane sytuacje. To mogą być incydenty, wpadki albo wypadki przy pracy. Jesteśmy tylko ludźmi i mamy słabsze dni, niedoskonałe procesy i wadliwą komunikację. To wszystko zwiększa ryzyko wystąpienia problemów. Słynne już zdanie “Houston, we've had a problem” było już cytowane tysiące razy, bo takie sytuacje zdarzają się w każdym projekcie. Jeśli nie pracujemy nad systemem od którego zależy życie i zdrowie ludzi, możemy podejść do tego na spokojnie i wykorzystać każdą taką sytuację do nauki i uszczelniania naszego produktu. Grunt to nie zawijać problemów pod dywan i wyciągać wnioski.

Historią, którą mam z tyłu głowy w przypadku wpadki jest GitLab2. 31 stycznia 2017 roku z powodu serii niefortunnych wypadków setki zespołów czekała niemiła niespodzianka. Wszystko dlatego, że inżynierowie GitLaba chcieli zwiększyć stabilność i bezpieczeństwo. Żeby właściwie przetestować nowe rozwiązanie na środowisku testowym, konieczne było wykonanie kopii danych z produkcji. W czasie kiedy dane były kopiowane na środowisku produkcyjnym pojawiła się wzmożona aktywność. To najpierw spowalnia, a potem zupełnie zatrzymało kopiowanie. Dobrze znamy zasadę wyłącz i włącz i kiedy coś przestaje działać, często próbujemy zrobić restart. Taka była intuicja i w tym przypadku. Niestety inżynier, który przeprowadzał migrację omyłkowo usunął produkcyjną bazę zamiast testowej. Niestety okazało się, że nie tylko backupy nie zostały poprawnie wykonane, ale cały system odzyskiwania danych szwankował. Naturalną reakcją w takiej sytuacji jest chęć szybkiej i cichej naprawy. Na szczęście zespół GitLaba postanowili podzielić się ze światem nie tylko szczegółami samej wpadki, ale również procesem przywracania serwisu. Przez 18 godzin transmitowali na żywo jak naprawiają system, a tysiące osób na całym świecie śledziło ich postępy. To dzięki transparentności GitLab wyszedł z tej wpadki obronną ręką i nie stracił zaufania całej branży. Kiedy wszystko się uspokoiło, przeprowadzili analizę post incident używając techniki 5 Whys i opisali ją na swojej stronie, żeby podzielić się nauką wyciągniętą z tej sytuacji3. 

 

Sama mam na swoim koncie niejedną wpadkę, ale najlepiej zapamiętałam jeden moment pracy z bazą danych. Przed wypuszczeniem funkcjonalności na produkcję, chciałam sprawdzić ją na środowisku testowym. Pracowałam w małej firmie gdzie nie mieliśmy do pomocy zespołu testerskiego, po prostu każda osoba, która dostarczała nową funkcjonalność była odpowiedzialna za upewnienie się, że wszystko działa jak należy. Mieliśmy sporo testów automatycznych i niejednokrotnie wykonywaliśmy testy manualne, czasem z pomocą zanonimizowanych danych z produkcji. Przeważnie wystarczały dane z poprzedniego dnia, ale w tym przypadku musiałam ręcznie skopiować i zanonimizować dane z produkcji. Otworzyłam w jednym okienku tabelę produkcyjną, w drugim testową, skopiowałam, po czym stworzyłam zapytanie SQL (jak mówią dobre praktyki, najpierw SELECT, dopiero potem UPDATE) i uruchomiłam skrypt. Na chwilę czas się zatrzymał. Poczułam jak po plecach biegnie mi mała iskierka i jak włosy na ciele stają na baczność. W głowie miałam jedno pytanie: “W którym okienku uruchomiłam skrypt?”. Trochę bałam się sprawdzić, ale na szczęście okazało się, że było to jednak środowisko testowe. Mimo wszystko długo towarzyszyło mi to uczucie, więc do mojej listy dobrych praktyk dodałam używanie okienka produkcyjnego wyłącznie wtedy kiedy jest ono potrzebne i zamknięcie go zaraz po tym. Na listę TODO dla mojego zespołu trafiło natomiast utworzenie skryptu na potrzeby manualnych kopii danych opakowanego w transakcję (którą można w razie potrzeby wycofać).

 

Wpadki będą się zdarzać. Jesteśmy ludźmi, nie maszynami. Poza tym nawet maszyny muszą być odpowiednio oprogramowane i w tym oprogramowaniu mogą być błędy lub nieprzetestowane ścieżki. W poprzedniej części pisałam o wpadce londyńskiego pogotowia, gdzie system nie przewidywał niektórych zdarzeń. O naszej klasie nie świadczy brak wpadek, ale to jak sobie z nimi radzimy i jakie wyciągamy wnioski. W branży IT ważna jest transparentność. Większość osób nie do końca rozumie nad czym pracujemy w projektach. Nieważne, czy wytwarzamy system bankowy dla całego społeczeństwa, czy bardzo wyspecjalizowane narzędzie do obsługi projektów. Nasza ekspertyza polega właśnie na tym, że potrafimy robić rzeczy, które dla innych są czarną magią. Ale to rodzi też odpowiedzialność. Jeśli coś idzie nie tak, nie możemy powiedzieć po prostu “przepraszamy, coś poszło nie tak”, bo wiele osób poczuje się oszukanych i straci do nas zaufanie. Powinniśmy podzielić się szczegółami na tyle na ile jest to bezpieczne, a potem jak najszybciej rozwiązać problem. Zaraz po tym następuje czas wyciągania wniosków i podejmowania działań, które pomogą nam ograniczyć podobne sytuacje w przyszłości. Nie wyobrażam sobie naprawienia błędu na produkcji bez napisania choćby jednego testu. W przypadku poważnych sytuacji powinniśmy jako zespół popracować nad zmianami w procesach i wdrożyć usprawnienia. W ten sposób uczymy się i wykorzystujemy nieprzyjemne sytuacje na naszą korzyść.

 

1 Zdanie wypowiedziane przez załogę Apollo 13

2 GitLab to internetowe narzędzie do zarządzania kodem projektu, razem z jego dokumentacją, procesem budowania i wdrażania na produkcję.

3 Historia wpadki GitLab’a jest dokładnie opisana w książce „Kierunek Jakość. Jak Unikać błędów w projekcie” 

 

Przeczytaj także pierwszą część artykułu: Co może pójść nie tak? Część pierwsza: Wielki Dzień