Za ścianą

Pracując w branży IT natrafiam na najprzeróżniejsze rodzaje projektów dla klientów wszelakiej maści, wielkości i proweniencji. Zdarzało mi się kasować grubą mamonę za kilka sprytnie umiejscowionych linijek VBA w systemie sprzedażowym niewielkiej sieci sklepów, zdarzało mi się też brać całkiem przeciętną pensję za bycie maleńkim kółeczkiem zębatym w wielgachnych projektach dla gigantów z samej wierchuszki światowego biznesu.

Najciekawsze jednak są zwykle projekty dla organizacji rządowych.

Dlaczego?

A no dlatego, że z jednej strony próbują one być w miarę nowoczesne i "dopasowane" do stale zmieniającego się krajobrazu technologicznego, a z drugiej, tej bardziej mrocznej, obarczone są balastem biurokracji i urzędniczego betonu pod tytułem "ale my zawsze tak robiliśmy i było dobrze, po co zmieniać?". I jest tak wszędzie, nie tylko w Polsce.

Nade wszystko jednak, w dobie jęternetów, większość rządowych komórek jest pozabezpieczana przed dostępem z zewnątrz. A ponieważ hakerzy nie próżnują, komórki rządowe często zamiast instalowania wymyślnych firewalli i innych programowych blokad, po prostu... odcinają, fizycznie odcinają kawałek sieci od świata zewnętrznego. Pracownik w biurze używa komputera podłączonego do tej "wewnętrznej" sieci, ale nikt nie jest w stanie dostać się tam od zewnątrz nie dlatego, że jest trudno, ale dlatego, że się po prostu, technicznie, nie da. Coś jakby zalać system piętnastoma metrami betonu.

W takich to pięknych okolicznościach flory (i, niewykluczone, fauny) przytrafiło mi się swego czasu pracować nad projektem migracji danych, w którego centrum siedziało sobie kilka względnie niedużych (200-300 linii kodu) skryptów w Pythonie oraz kilka nieco większych (po parę tysięcy linii kodu) za to mniej skomplikowanych skryptów w SQL-u. Wszystko zalane symbolicznymi piętnastoma metrami betonu, a więc żeby skopiować jakikolwiek plik z zewnątrz do systemu "wewnętrznego" trzeba znać odpowiedniego człowieka, który ma odpowiednie papiery i pieczątki, i który jest w stanie ów plik umieścić we wskazanym przez nas miejscu pod warunkiem jednakowoż uprzedniego przejrzenia pliku przez speca od security. W zależności od pory dnia oraz dostępności odpowiednich ludzi proces ten potrafił zająć od dwóch godzin do dwóch dni roboczych.

Ponieważ sam nie posiadałem odpowiednich papierów ani pieczątek, nie miałem żadnego dostępu do wewnętrznego systemu. Dostałem do dyspozycji udawaną kopię części systemu, na podstawie której wygenerowałem całkiem sporo rozmaitych kawałków kodu. Następnie przekazałem ów kod koledze z teamu, który zna odpowiednich ludzi po stronie klienta i już nazajutrz kod ów trafił na serwery wewnętrzne. No i tu się zaczęło rodeo, albowiem okazało się, że udawana kopia, którą miałem do dyspozycji, nijak ma się do stanu faktycznego; w szczególności jest nieco przestarzała oraz dużo mniejsza od oryginału. Zamiast setek tysięcy rekordów, w prawdziwej bazie siedzą setki milionów, w dodatku niektóre elementy wyglądają tam nieco inaczej (na przykład sposoby autoryzacji dostępu do baz, struktury niektórych tabel albo obecność pewnych danych itd. itp.). W efekcie moje skrypty, które przechodziły testy w środowisku testowym w stu procentach nagle zaczęły się potykać o różne nieprzewidziane przeszkody.

Na początku próbowałem działać zgodnie z procedurą, czyli wyciągałem (przez łańcuszek dwóch ludzi) zrzuty ekranów z komunikatami błędów, modyfikowałem skrypty, przesyłałem je z powrotem (w ślimaczym tempie, wiadomo), skrypt potykał się o inną przeszkodę i tak dalej. Trwało to, bo ja wiem, ze dwa albo trzy tygodnie, po których stwierdziłem, że w tym tempie to ten projekt nie zamknie się przed kolejnym zlodowaceniem. Udało mi się więc namówić kolegę z teamu, który miał dojścia po stronie klienta, żeby wbił się na kwadrat (na szczęście miał odpowiednie papiery) i sam uruchamiał te skrypty, a następnie raportował mi o błędach w czasie rzeczywistym przez telefon.

Pomogło. Trochę. Informację zwrotną miałem teraz co prawda od razu, ale jak tu dostarczać nowe wersje skryptów? Postanowiłem, że zamiast prosić o transfer za pomocą łańcuszka dobrych serc, po prostu będę dyktował (przez telefon) zmiany w kodzie owemu koledze, ów będzie je aplikował bezpośrednio na maszynie wewnątrz i od razu uruchamiał.

Pomysł zacny (biorąc pod uwagę okoliczności), jednak realizacja nieco kulała, bo kolega, człowiek skądinąd zacny i niegłupi, i ze stażem w branży dłuższym od mojego, o Pythonie słyszał głównie w zoo, a SQL-a znał bardziej z nazwy niż praktyki. Jak można sobie wyobrazić, zdalne edytowanie kodu za pośrednictwem palców i uszu było nieco... kłopotliwe, żeby nie użyć bardziej dosadnego słownictwa (a nuż będzie te słowa kiedyś czytać jakaś grzeczna młodzież?). Końcem końców jednak, po kilku zarwanych długich popołudniach - udało się, a projekt zakończył się sukcesem. To znaczy przynajmniej mój kawałek projektu, czyli samo żonglowanie danymi. Co się tam potem działo to już nie moja filiżanka.

A wydawać by się mogło, że mamy 2022 rok 🙂

2 komentarze

  1. Eh a mnie nawet nie wolno wspomnieć o takich niejasnych detalach w żadnym języku przez X lat ;]

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]