Kwestia skali

Z mieszaniną fascynacji i rezygnacji czytam wiadomości dotyczące problemów z (nie)działaniem serwisu wyborczego PKW w dniu wyborów i jeszcze dzień później.

Z mieszaniną fascynacji i rezygnacji czytam wiadomości dotyczące problemów z (nie)działaniem serwisu wyborczego PKW w dniu wyborów i jeszcze dzień później.

Tym razem, inaczej niż 4 lata temu, nie odmówiło posłuszeństwa oprogramowanie zbierające dane z komisji wyborczych. Zawiódł natomiast - i to na całej linii - serwis internetowy.

Nie wiem, czy doczekamy się gruntownej analizy w postaci "białej księgi". Z niejasnych dla mnie względów takie działania nie są rutynowo przeprowadzane ani przez władzę publiczną (choć dysponuje ona kilkoma instytucjami kontrolnymi, z NIK na czele), ani przez instytucje niezależne. A przecież wypadałoby odpowiedzieć podatnikowi na kilka prostych pytań: co się stało, dlaczego tak się stało, kto zawinił i w jaki sposób, a także co trzeba zrobić, żeby sytuacja się nie powtórzyła w przyszłości. W końcu wydano po raz kolejny jego pieniądze na system, który nie osiągnął celu, dla którego powstał.

Jednak żadna władza ani kontrola nie odpowie informatykom, jak powinni konstruować swoje aplikacje, aby uniknąć wpadki takiej, jaką "zaliczyła" PKW wraz z Eo Networks, wykonawcą serwisu. Nie chcę rozsądzać, czy zawiniła zła specyfikacja (SIWZ), czy wykonanie. Ale pozwolę sobie przytoczyć kilka rad. Może nie uważam się za "starego wyjadacza", ale w skalowalnych aplikacji internetowych trochę w życiu widziałem, a i parę zbudowałem.

Po pierwsze, wydobądź od swojego klienta szacunki dotyczące ruchu oraz dystrybucji tego ruchu w czasie (czy nie mamy do czynienia z chwilowymi skokami obciążenia, jak właśnie w przypadku wyborów). Następnie zweryfikuj je w oparciu o dostępne źródła (np. dane historyczne, inne kraje albo inne firmy) i przemnóż przez 10. I z takim założeniem przeprowadzaj dalsze prace inżynierskie.

Po drugie, w przypadku serwisu, do którego dostęp może być masowy, w miarę możliwości korzystaj ze statycznych stron w czystym HTML i obrazków JPEG. Generowanie zawartości przy każdym odwołaniu do serwisu, z przejściem przez wszystkie trzy jego warstwy, może być dla niego zabójcze. HTML-e i JPEG-i można generować w oparciu o dane z aplikacji np. raz na 10 minut.

Po trzecie, przeprowadź analizę SPoF (Single Point of Failure) - twój serwis jest tak dobry jak jego najsłabszy element. Wyeliminuj wszystkie SPoF-y, a te, które nie mogą być wyeliminowane (z racji kosztów), powinny być ściśle monitorowane, a na wypadek ich awarii powinny być gotowe procedury. Błąd w SIWZ opublikowanych przez PKW na system wizualizacji polegał m.in. na tym, że zażądano od wykonawcy eliminacji konkretnych słabości (np. przez zapasowe łącze internetowe) zamiast przedstawienia gruntownej analizy ryzyk i planu awaryjnego.

Po czwarte, gotowe rozwiązanie przetestuj. Ten element, choć pozornie oczywisty, realnie jest najtrudniejszy do wykonania. Nikt nie jest w stanie zasymulować działania kilku czy nawet kilkunastu tysięcy rzeczywistych, autonomicznych użytkowników; jeśli nawet jest to technicznie możliwe, to przeprowadzenie takich testów może być nieuzasadnione ekonomicznie. Ale przynajmniej spróbuj.

Po piąte, przygotuj rozwiązanie B na wypadek gdyby rozwiązanie A jednak nie zadziałało. Gdyby serwis wyborczy pokazywał statyczną stronę "Przepraszamy, serwer jest zbyt mocno obciążony, czekaj na swoją kolejkę lub spróbuj w innym czasie", ton komentarzy byłby bardziej merytoryczny, a furia internautów mniejsza.

I najważniejsze. Pamiętaj, że nawet jeśli spełniłeś warunki zamówienia i funkcjonalnie nie można nic zarzucić, ale klienci są niezadowoleni, to nie odniosłeś sukcesu.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200