O przewadze jawności nad magią

Pamiętacie jeszcze aferę po pierwszej turze wyborów samorządowych w 2002 roku (to te, po których Lech Kaczyński został prezydentem Warszawy)? Wprowadzono wtedy pilotowy system informatyczny do liczenia i zbierania głosów – zapowiadany przed wyborami z charakterystyczną dla tamtych lat przesadą (tegoroczne wybory samorządowe ze względu na nowatorstwo wykorzystanych rozwiązań, są przedsięwzięciem unikatowym w skali światowej…). A system z hukiem się wywrócił, nie będąc w stanie przyjąć i przetworzyć danych.

Rzecz nie była tak naprawdę ważna, kilkudniowe opóźnienie wyników mało kogo szczególnie obeszło, prawdziwy problem mieli jedynie ludzie z komisji wyborczych – zamiast w parę godzin policzyć głosy, wysłać je i po północy iść do domu, musieli sztafetowo dyżurować przy wynikach (rekordziści bodajże do środy). Ale było tam parę ciekawych elementów.

Przypomnienie sprawy

Na początek parę cytatów z ówczesnych mediów, ot – dla przypomnienia tematu i atmosfery. Pierwszy był taki (onet):

Państwowa Komisja Wyborcza poinformowała , że zawiódł pilotażowy program informatyczny, który miał pomóc przy liczeniu głosów oddanych w wyborach samorządowych.

Zastępca przewodniczącego PKW Jan Kacprzak powiedział, że program nie spełnił oczekiwań w takim zakresie jak przypuszczano. Zdaniem informatyków przyczyną była awaria serwera w Warszawie.

Później zaczęły się nerwowe kombinacje, które dziennikarze uzupełnili interesującymi kwotami:

Zakłócenia w pracy serwera PKW mogą być spowodowane tym, że dwa opracowane przez niezależne firmy systemy informatyczne - centralny dla PKW oraz dla terytorialnych komisji wyborczych - zachowują się w sposób, który może oznaczać iż są niekompatybilne.

Jak wyjaśnił Stanisław Zabłocki z PKW, po podłączeniu dwóch programów: centralnego i terytorialnego do jednego systemu przesyłania danych nastąpił tzw. efekt skali. Przy dużej ilości połączeń z systemem część użytkowników jest z niego wyrzucana.

Zabłocki dodał, że w poniedziałek ok. 14. na dwie-trzy godziny z systemu zostaną odłączone mniejsze ośrodki, a zostanie w nim tylko 45 największych miast. Ma to umożliwić zgromadzenie przez PKW wyników wyborów wójtów, burmistrzów i prezydentów w tych miastach i - jeśli wszystko przebiegnie bez zakłóceń - podanie tych wyników w poniedziałek
wieczorem.

(…)

Jak podała "Rzeczpospolita" z 16 października, obsługa informatyczna wyborów ma kosztować ok. 24,5 mln zł - dwukrotnie więcej niż ostatnich wyborów parlamentarnych. Wartość kontraktu z głównym wykonawcą, Prokomem, wynosi ok. 20 proc. kosztów całej obsługi informatycznej
wyborów.

aż zaczęły się pojawiać informacje rzucające ciekawe światło na organizacyjną stronę projektu:

Prokom Software nie odpowiada za niesprawne działanie systemu informatycznego, który obsługuje wybory samorządowe - poinformowała Beata Stelmach z Prokom Software. "Prokom nie jest odpowiedzialny za cały system informatyczny. Spowolnienie systemu nastąpiło w części transmisyjnej, przygotowanej przez innego wykonawcę" - powiedziała Stelmach.

i szczególnie smakowite:

Zabłocki tłumaczył dziennikarzom, że celem zlecenia dwóm niezależnym firmom opracowania oprogramowania centralnego i terytorialnego było umożliwienie wzajemnego kontrolowania się tych dwóch firm. Były przeprowadzone próby systemu oraz audyt, ale "prawdopodobnie audyt ten był przeprowadzony dla mniejszej skali wejść do systemu".

(...)

Powiedział, że głównym wykonawcą systemu informatycznego obsługującego wybory samorządowe jest firma Prokom Software, która wykonała system centralnej bazy danych, natomiast firma Pixel opracowała program dla terytorialnych komisji wyborczych. Audyt wykonała natomiast firma Infovide.

Bardziej technicznie

Obserwowałem to lekko uśmiechając się pod nosem – obsłużenie jednorazowego uploadu 801 (liczba komisji) prostych plików, sparsowanie ich i trochę sumowania liczb, noż korale-mecyje, ile to roboty i co tu trudnego. A tu wielka firma (nawet dwie - wykonawca i audytor), duże pieniądze, prestiżowy projekt i taka wtopa. Ale przede wszystkim – ciekawiło mnie, czysto zawodowo, co się właściwie stało.

Trochę sarkazmu z tą wielką firmą. Wiadomo, że gros projektów obstawianych przez dużych graczy ostatecznie robią grupki studentów albo niewielcy podwykonawcy, a główny dostawca albo (gdy jest mądry) prowadzi i nadzoruje projekt albo (gdy jest chciwy) ogranicza się do doklejania swojego logo i integrowania faktur. Pomnóżcie mój sarkazm przez lekką urazę chowaną z czasów, gdy nie mogłem się przyznawać do pisanych przez siebie aplikacji.

No i, zanim wszyscy ochłonęli i ustalili, kto ma posypywać głowę popiołem (oczywiście najmniejszy z uczestników, o którym w razie sukcesu projektu pies z kulawą nogą pewnie by nie wspominał) i jakimi słowy wyrażać swój żal, udało mi się wyłapać trochę ciekawych informacji (poniższe cytaty za Onet i ComputerWorld). Na przykład taką fajną decyzję projektową:

Jak wyjaśnił warszawski komisarz, system komputerowy jest tak skonstruowany, że nie podaje cząstkowych wyników - może podać wynik tylko wówczas, gdy do systemu wprowadzi się wszystkie, w 100% bezbłędne protokoły z obwodów.

potwierdzenie, że na pewno problemem nie były braki w konfiguracji sprzętowej:

(...) centralna część systemu składała się z sześciu serwerów głównych dostarczonych przez IBM Polska i pięciu serwerów zapasowych (...)

ale przede wszystkim zupełnie dokładny opis techniczny problemu:

(...) Podczas operacji zapisu do bazy danych komponenty komunikacyjne wywoływały komponenty robocze (tzw. session beans), które nakładały na bazę zbyt wiele blokad (locks) równocześ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 się dobijać kilkuset użytkowników równocześ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. (...)

Ba – znalazło się nawet wyjaśnienie, jakim cudem za pad centralnej części realizowanej przez Prokom odpowiedzialny się okazał robiący aplikację dla komisji Pixel (hmm, co to ja pisałem wyżej o sposobie robienia projektów przez dużych graczy?):

(...) 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.

Wnioski

O różnych rzeczach mógłbym popisać. Choćby o projektach robionych przez kilka firm naraz, zwłaszcza przy niejasnych podziałach kompetencji (PKW czegoś się nauczyła, kombinacji paru wykonawców już więcej nie próbowała), o tym, że samodzielnie popełniony błąd jest więcej wart, niż cudzymi rękami osiągnięty sukces (prasa trzęsła się ze zgrozy, gdy kontrakt na kolejne wybory wygrał Pixel, tymczasem problemów nie było). O reakcjach w sytuacjach nagłych awarii, o robieniu realistycznych testów, o tym jak systemy mające zadziałać raz, w bardzo konkretnym momencie, bywają trudniejsze od aplikacji 365x24 (tak na boku, systemy rakietowe i antyrakietowe też nie mają zbyt wielu okazji do docierania się). Wreszcie – o technologiach, o tym, że agresywnie reklamowane komercyjne narzędzia wcale nie są remedium na wszystko (ot, prześliczny obrazek akurat się trafił).

Do przynajmniej części z tych spraw kiedyś na pewno wrócę.

Dzisiaj podywaguję sobie troszkę, jak w ogóle mogło dojść do tego, że robiona przez grupę łebskich ludzi aplikacja (niezależnie od wszelkich uwarunkowań politycznych paru rozsądnych programistów na pewno tam było) mogła zawierać takie usterki. Oczywiście to tylko luźna hipoteza, informacji mam bardzo mało.

We frameworkach webowych i aplikacyjnych można zauważyć dwa podstawowe podejścia.

Jedno polega na dostarczeniu obszernego zbioru gotowych komponentów (od obsługi sesji czy obiektu żądania po komentarze czy głosowania, od komunikatu i połączenia po serwis nazw czy menedżer transakcji) i porad, jak składać je w całość. Wszystko jest dosyć jawne, wiem jak składam klocki, wiem co, gdzie i po co się dzieje, nawet jeśli nie wchodzę w szczegóły, widzę i rozumiem jak przebiega przetwarzanie od początku do końca.

Drugie dostarcza framework jako działającą, złożoną strukturę, w którą w wybranych miejscach można dopisać jakieś elementy swojego kodu (hook-i, pluginy, podklasy, bean-y … – jak zwał, tak zwał). Dostarcza też złożone, wyrafinowane usługi. Gotowej funkcjonalności jest nieraz bardzo dużo, od niemal samego początku coś działa ale co się dokładnie dzieje, jak dokładnie wszystko przebiega – nie wiadomo (a przynajmniej – można budować aplikacje nie wiedząc).

Ot – Django versus Zope/Plone. Perl versus Smalltalk. Tuxedo versus DCOM. D-Bus versus ActiveX. GTK vs MFC. Nie wszystkie te przykłady są zupełnie ostre i czyste, ale … każdy znajdzie lepsze w swoim ulubionym języku i zastosowaniu.

Oba podejścia mają swoje zalety i wady. Przy budowie z klocków zwykle trzeba się trochę więcej narobić, by uzyskać pierwsze efekty. Przy użyciu złożonych, lekko magicznych frameworków … łatwo oddać narzędziu kontrolę nad projektem. Łatwo uwierzyć, że planowanie wydajności, szukanie wąskich gardeł, analiza zachowań przy rywalizacji o zasoby, dokładne testowanie – nie są potrzebne, bo przecież nasz kod jest taki prosty a narzędzie jest mądre.  

I coś takiego mogło się tu stać.

Sprawa stara ale nauczka jak najbardziej aktualna.

I jeszcze jeden dopisek. Aby zrobić duży system, nie wystarczy wziąć mały system i zapewnić mu dziesięciokrotnie (a niechby, stukrotnie) większe zasoby. Skalowalność trzeba planować. I jest trudna. Tym trudniejsza, im bardziej złożonych narzędzi używamy. To nie jest przypadek, że wiele bardzo dużych serwisów sieciowych to stosunkowe proste, pragmatycznie budowane aplikacje, popisane w Perlu czy PHP.