Mimo wysiłków ponad tysiąca ludzi i niemałych kosztów, pilotażowy system obsługi wyborów samorządowych w krytycznym momencie odmówił posłuszeństwa.

System wprowadzony po to, aby przyspieszyć zbieranie wyników głosowań, paradoksalnie najpierw działał nazbyt wolno, by wkrótce potem przestał działać w ogóle. W efekcie pracownicy większości obwodowych komisji wyborczych nie mogli przekazać danych do działającej w Krajowym Biurze Wyborczym (KBW) centralnej bazy danych, co z kolei uniemożliwiało ich pobranie w celu weryfikacji przez regionalne przedstawicielstwa KBW. Wiele osób spędziło w lokalach wyborczych całą noc, czekając na usunięcie awarii. Okazało się jednak, że na próżno. System bowiem nie zadziałał prawidłowo ani w poniedziałek, ani nawet we wtorek.

Wkrótce po wystąpieniu kłopotów w mediach pojawiły się spekulacje na temat ich przyczyn. Najpierw był to "wyjątkowo silny wiatr, który w tych dniach nawiedził Polskę". Gdy łączność z serwerem centralnym została zerwana, pojawiła się wersja, jakoby wystąpiła awaria serwera w centrali KBW w Warszawie. Problem w tym, że centralna część systemu składała się z sześciu serwerów głównych dostarczonych przez IBM Polska i 5 serwerów zapasowych. W tym czasie pojawiła się informacja, że wszystkiemu winne są działające w terenowych komisjach wyborczych aplikacje klienckie łódzkiej firmy Pixel.

Walka o dostęp

Co tak naprawdę się stało? Z uzyskanych przez nas informacji wynika, że powodem problemów były działające na serwerach w KBW komponenty odpowiedzialne za wymianę danych między aplikacjami funkcjonującymi w obwodowych komisjach wyborczych (autorstwa Prokom Software), centralną bazą danych i aplikacjami klienckimi działającymi w terenowych komisjach wyborczych (autorstwa firmy Pixel). W celu zaoszczędzenia cennego czasu struktury centralnej bazy danych i lokalnej bazy aplikacji klienckiej Prokomu oparto na strukturze wewnętrznej bazy danych programu opracowanego przez Pixel. Niejako naturalnie, to jej właśnie przypadła rola stworzenia komponentów zarządzających wymianą danych między wszystkimi elementami systemu.

Choć komponenty komunikacyjne były testowane w środowisku prawie produkcyjnym przez kilka miesięcy, dopiero w krytycznym momencie ujawniły się ich zasadnicze mankamenty. Podczas operacji zapisu do bazy danych komponenty komunikacyjne wywoływały komponenty robocze (tzw. session beans), które nakładały na bazę danych zbyt wiele blokad (locks) jednocześnie, co znacznie wydłużało czas transakcji.

Gdy w tym czasie kolejni użytkownicy próbowali zapisać informacje w bazie, a istniejąca pula komponentów roboczych była zajęta oczekiwaniem na odpowiedź bazy, system wywoływał kolejną ich partię. Nowe komponenty - podobnie jak poprzednie - nadmiernie obciążały bazę blokadami, co jeszcze bardziej wydłużało czas transakcji. Gdy po zamknięciu komisji wyborczych do systemu centralnego zaczęło dobijać się kilkuset użytkowników jednocześnie, baza została praktycznie unieruchomiona. Z kolei serwer generujący komponenty robocze po przekroczeniu ok. 30 tys. jednoczesnych połączeń z serwerem bazy danych odmówił posłuszeństwa. W nocy po zamknięciu lokali wyborczych sytuacja ta powtórzyła się kilkakrotnie.

Nie tylko technologia

Słaba wydajność była zaskoczeniem dla wszystkich, komponenty komunikacyjne były bowiem testowane i poprawiane przez kilka miesięcy. Terenowe komisje wyborcze rejestrowały kandydatów i pobierały dane o okręgach wyborczych. Trwały szkolenia użytkowników. W poprzedzający wybory piątek ostateczna wersja komponentów została przetestowana przez specjalistów z firmy Infovide, odpowiedzialnej w projekcie za kontrolę jakości.

Niestety ostatecznych testów nie przeprowadzono w środowisku produkcyjnym pod pełnym, przewidywanym obciążeniem. Dlatego, choć bezpośrednią przyczyną problemów była technologia, w projektach tej klasy problemy technologiczne można uznać za niedociągnięcia organizacyjne. Od firm utrzymujących się z produkcji i wdrażania oprogramowania można i trzeba oczekiwać, że znają się na wszystkich aspektach swojego rzemiosła.