Paradoks prewencji. Kiedy wszystko działa, nikt nie pyta dlaczego

Jest 23:40. Na biurku stygnie herbata, a ja trzeci raz sprawdzam, czy nowa reguła na firewallu robi dokładnie to, co powinna. Nikt mnie o to nie prosił. Nikt się też o tym nie dowie, bo jeśli wszystko zadziała, jutro po prostu nic się nie wydarzy.

I o to właśnie chodzi.

Następnego dnia o 8:15 dzwoni telefon. Nie działa drukarka.

Czym jest paradoks prewencji

Paradoks prewencji to sytuacja, w której skuteczne zapobieganie problemowi sprawia, że problem wygląda na wydumany. Skoro nic złego się nie stało, to może wcale nie było zagrożenia? A może ktoś po prostu przesadzał?

Najlepszym przykładem jest problem roku 2000. Przez kilka lat tysiące informatyków na całym świecie przeglądały kod, łatały systemy bankowe, energetyczne i lotnicze. Nadszedł 1 stycznia 2000 roku i nic się nie stało. Samoloty latały, bankomaty wypłacały pieniądze, światło się paliło. Bardzo szybko pojawiły się głosy, że cała afera była rozdmuchana.

Nie była. Nic się nie stało właśnie dlatego, że ktoś wcześniej wykonał ogromną pracę. Tylko że tej pracy nie było widać. Widać było jedynie brak katastrofy, a brak katastrofy trudno pokazać na zdjęciu.

Praca, której nie widać

W codziennej pracy informatyka jest to samo, tylko w mniejszej skali. Większość tego, co robię, z definicji nie zostawia śladu. Kiedy jest zrobione dobrze, nikt tego nie zauważa.

To są rzeczy takie jak:

• aktualizacje systemów i oprogramowania, wykonywane często wieczorem, żeby nikomu nie przeszkadzać,
• kopie zapasowe, których nikt nigdy nie potrzebował, bo nic się nie zepsuło,
• monitoring, który wyłapuje problem, zanim ktokolwiek go odczuje,
• reguły bezpieczeństwa, które codziennie zatrzymują próby ataków, o których nikt nawet nie wie,
• dokumentacja i procedury wymagane przez przepisy o cyberbezpieczeństwie, takie jak NIS2 i krajowy system cyberbezpieczeństwa,
• dbanie o dostępność cyfrową, żeby strona czy dokument dało się odczytać także osobie niewidomej,
• planowanie infrastruktury na kilka lat do przodu, zanim stara po prostu przestanie wystarczać.

Żadna z tych rzeczy nie robi wrażenia. Nie ma przecięcia wstęgi, nie ma zdjęcia do gazetki. Jest tylko dzień, w którym wszystko działa tak jak wczoraj.

Najciekawsze jest jednak to, że niewidoczne bywają nawet duże projekty. Zbudowanie od podstaw rozbudowanego portalu, który obsługuje mieszkańców i działa bez przerwy, to miesiące projektowania, programowania, testów i poprawek. Z zewnątrz widać tylko gotową stronę. Nikt nie widzi setek godzin, które w nią włożono, ani decyzji, które sprawiły, że jest bezpieczna, szybka i dostępna dla każdego.

Podobnie jest z wdrażaniem nowych rozwiązań. Zastąpienie drogiego oprogramowania komercyjnego rozwiązaniem open source oznacza realne oszczędności, często liczone w tysiącach złotych rocznie, które nie muszą już iść na licencje. Ale żeby to się udało, trzeba najpierw znaleźć właściwe narzędzie, przetestować je, przenieść dane, nauczyć ludzi i wziąć na siebie odpowiedzialność za to, że wszystko będzie działać. Kiedy się uda, efekt jest jeden: wszystko działa jak wcześniej, tylko taniej. Czyli znowu nic się nie wydarzyło.

Po godzinach

Tej pracy nie da się zamknąć o 15:30. Technologia nie czeka, aż skończy się dzień roboczy. Nowe zagrożenia pojawiają się co tydzień, sprzęt się starzeje, a rozwiązania, które dziś są nowością, za dwa lata będą standardem.

Dlatego wielu informatyków uczy się w swoim czasie i często za swoje pieniądze. Wieczorem testują coś w domowym laboratorium, w weekend czytają dokumentację, budują serwer z używanych części tylko po to, żeby sprawdzić, czy dany pomysł w ogóle ma sens. Potem przenoszą tę wiedzę do pracy, gotową i sprawdzoną.

Przy dużych projektach skala tego czasu robi się ogromna. Portal, nowy system, migracja z komercyjnego programu na otwarte rozwiązanie: to wszystko w dużej części powstaje wieczorami i w weekendy, bo w ciągu dnia trzeba zajmować się bieżącymi sprawami, zgłoszeniami i tą nieszczęsną drukarką. Gdyby policzyć wszystkie te godziny, wyszedłby z tego niejeden dodatkowy etat.

Nie robię tego, bo muszę. Robię to, bo to lubię. Szukanie nowych dróg, kombinowanie, jak coś zrobić lepiej, taniej albo bezpieczniej, to dla mnie przyjemność, a nie obowiązek. Ale pasja nie zmienia faktu, że to są godziny, których nikt nie liczy. I efekty, o których mało kto wie, skąd się wzięły.

Co widzą inni

Z drugiej strony biurka wygląda to zupełnie inaczej. Widać drukarkę, która się zacięła. Hasło, które trzeba było zmienić. Komputer, który rano uruchamiał się dłużej niż zwykle. Program, który po aktualizacji ma przycisk w innym miejscu.

O serwer, który od trzech lat nie miał ani minuty przestoju, nikt nie pyta. O to, dlaczego w ostatnim roku nie było żadnego poważnego incydentu, też nie. Pytania pojawiają się tylko wtedy, gdy coś przestaje działać.

I to jest naturalne. Nie wynika ze złej woli ani z braku szacunku. Ludzie oceniają to, co rozumieją i co dotyka ich bezpośrednio. Dobrze działająca infrastruktura jest jak prąd w gniazdku. Nikt nie dziękuje elektrowni za to, że czajnik się zagotował. Wszyscy za to zauważą, kiedy zgaśnie światło.

Tyle że po latach takiej pracy łatwo poczuć, że wysiłek trafia w próżnię. Że dobry informatyk to ten, o którym się nie mówi, a jedyny moment, kiedy się o nim mówi, to moment, w którym coś poszło nie tak.

Co z tym zrobić

Można się na to obrazić. Można też uznać, że to część tej pracy, i spróbować trochę zmienić zasady gry. Kilka rzeczy, które moim zdaniem naprawdę pomagają:

1. Pokazywać swoją pracę. Krótkie podsumowanie raz na kwartał: ile aktualizacji, ile zablokowanych ataków, ile godzin bez przestoju. Liczby mówią więcej niż opisy.
2. Mówić językiem efektów, nie technologii. Nikogo nie interesuje nowa konfiguracja klastra. Interesuje to, że dane są bezpieczne, a system nie stanie w środku dnia.
3. Opowiadać o tym, co się nie wydarzyło. Każdy zatrzymany incydent to historia, którą warto czasem opowiedzieć, oczywiście bez zdradzania szczegółów.
4. Szukać uznania także poza miejscem pracy. W środowisku informatyków, na konferencjach, w sieci. Tam ludzie wiedzą, ile kosztuje to, co z zewnątrz wygląda na zwyczajny dzień.
5. Nie mierzyć swojej wartości tylko cudzym zainteresowaniem. Satysfakcja z dobrze rozwiązanego problemu jest prawdziwa, nawet jeśli nikt jej nie zauważył.

A jeśli komuś się to nie spodoba?

Pokazywanie swojej pracy ma też drugą stronę. Ktoś może to odebrać jako przechwalanie się, jako sugestię, że inni robią mniej, albo jako wchodzenie w cudze kompetencje. Czasem ktoś po prostu poczuje się niezręcznie, bo jego praca wypada przy tym skromniej.

Dużo zależy od formy. Rzeczowe podsumowanie dla przełożonego to coś innego niż publiczne ogłaszanie sukcesów. Często radzi się też, żeby mówić o sukcesie całej instytucji, a nie swoim, i dzielić się zasługą z tymi, którzy dali zielone światło.

Tylko że tu pojawia się pytanie, które zadaje sobie wielu informatyków. Co, jeśli to nie był wspólny sukces? Jeśli to ty dawałeś z siebie trzysta procent, ty wychodziłeś przed szereg i ty siedziałeś po nocach? I to nie raz, ale przez cztery lata, siedem, jedenaście. Ile jeszcze można chować się za słowem „my”?

Myślę, że uczciwa odpowiedź jest taka: dzielić się zasługą warto tam, gdzie ktoś naprawdę miał w niej udział. Ale skromność nie może oznaczać znikania. Można mówić o efekcie dla instytucji i jednocześnie jasno powiedzieć, kto go wypracował. Zdanie „przygotowałem i wdrożyłem rozwiązanie, dzięki któremu instytucja oszczędza kilka tysięcy złotych rocznie” to nie przechwałka. To fakt. A jeśli po latach takiej pracy wciąż nie ma miejsca, żeby go wypowiedzieć, to problem nie leży w formie komunikatu.

A jeśli i tak komuś to przeszkadza? Najlepiej po prostu porozmawiać i zapytać, co konkretnie jest problemem. Często chodzi o formę, nie o treść. Jeśli jednak komuś przeszkadza sam fakt, że dobra praca została zauważona, to mówi to więcej o nim niż o tej pracy. Nie da się zadowolić wszystkich, a milczenie też ma swój koszt. Wtedy nikt nie wie, że ta praca w ogóle istnieje.

Czy dobrego informatyka widać?

Wracam do tamtego wieczoru i tamtej reguły na firewallu. Zadziałała. Następnego dnia nikt o niej nie wiedział, a ja odebrałem telefon w sprawie drukarki i poszedłem ją naprawić. Też się cieszę, kiedy drukarka działa.

Więc czy dobrego informatyka widać? Widać. Tylko trzeba wiedzieć, gdzie patrzeć. Nie w dniach, kiedy coś się psuje, ale w tych wszystkich zwyczajnych dniach, kiedy nic się nie dzieje. W systemach, które po prostu działają. W danych, które są tam, gdzie powinny. W ciszy, która wcale nie jest przypadkiem.

Następnym razem, kiedy wszystko będzie działać, warto zadać jedno proste pytanie: dlaczego?