Praga, 1998 r.: historia przełomowej technologii

W czym tkwi tajemnica sukcesu firmy?

Od czasu do czasu słyszę to pytanie. Oczywiście nie ma na nie prostej odpowiedzi, bo to niemożliwe. Zasada „zrobić jak najwięcej i zrobić to dobrze” nie jest prosta (może poza wygraną na loterii czy niespodziewanym spadkiem w milionach). Ale w moim przypadku tak nie było. Nasz sukces zależał od wielu czynników, głównie technologicznych. Dziś opowiem Wam o jednym z kluczowych z nich: fundamentalnej technologii, która od wielu lat pomagała nam tworzyć przełomowe produkty we wszystkich kategoriach, gwarantując jednocześnie maksymalną ochronę przed wszystkimi możliwymi cyberzagrożeniami.

Technologia ta nosi nazwę „Praga”.

Dlaczego akurat tak się nazywa? Bo została wynaleziona w Pradze!

Wiosną 1998 roku kilka osób postanowiło spotkać się w celu wypicia piwa i zjedzenia czeskich specjałów wymyślenia architektury do naszych przyszłych produktów. Zebranie Praga było niezwykle owocne: utworzyliśmy na nim nową technologię — Unified Component Architecture (UCA), która powiązała szeroką gamę produktów na wszystkich możliwych platformach (systemach operacyjnych). UCA nadal ewoluuje i stanowi szkielet niemal wszystkich naszych produktów.

Co więcej, technologii UCA przyglądają się inne firmy, które mają problem z projektami i wdrożeniami wielojęzycznymi, co dosyć często się zdarza, zwłaszcza przy skomplikowanych projektach, w których zaangażowane jest wiele działów lub gdy łączą się firmy.

Nasze zebranie w Pradze odbyło się dwadzieścia lat temu. Zdałem sobie z tego sprawę, gdy przeglądałem archiwa i znalazłem Prague Technology Documentation — dokument z datą 22 czerwca 1998 r. Wówczas byliśmy zaabsorbowani walką z jakimiś „innowacyjnymi” wirusami i rozwiązywaliśmy pewne czysto techniczne problemy z silnikiem antywirusowym. Wynalezione przez nas rozwiązanie miało znacznie więcej możliwości, dzięki czemu stosowaliśmy je jako podstawową technologię w naszych produktach przez ponad dziesięć lat.

Jak to wszystko się zaczęło?

Wtedy nasza firma była gdzieś między etapem garażowym — w naszym przypadku było to drugie piętro przedszkola w moskiewskiej dzielnicy Strogino — a etapem szklanego biura. Licencji na nasz silnik użyczaliśmy wielu zagranicznym partnerom. Mieliśmy już na rynku niesamowicie udaną wersję o nazwie Antiviral Toolkit Pro 3.0. Jednak technologiczna przyszłość to nie tylko same przyjemności.

Pozostały nam dwa duże wyzwania: coś, co było absolutnie potrzebne i wydawało się bardzo trudne w implementacji, czyli możliwość przetwarzania podejrzanych obiektów bez względu na sposób ich przechowywania (typowym przykładem są tutaj „matrioszki” z osadzonymi obiektami, w których szkodliwy plik znajdował się w archiwum spakowanym w inne archiwum). Drugim wyzwaniem było utworzenie silnika antywirusowego, którym mógłby aktualizować się tak szybko, jak to możliwe, przy minimalnych (a idealnie zerowych) zmianach portów między platformami.

Przypomnę, że pod koniec lat 90 autorzy wirusów byli bardzo pomysłowi, a niektóre nowe wirusy wymagały aktualizacji nie tylko baz danych, ale także samego silnika. W tamtych czasach użytkownicy albo mieli bardzo wolny internet, albo nie mieli go wcale, więc dostarczanie aktualizacji kilku megabajtów stanowiło poważny problem. Zawszywszy na to, że Windows 98 właśnie rozpoczął swoje podboje na naszej planecie, ale jeszcze nie zastąpił całkowicie systemu DOS, wszelkie innowacje w wykrywaniu musiały działać natychmiast w obu systemach operacyjnych.

Przez ten tydzień w Pradze Aleksiej De-Monderik, Andriej Kriukow, Andriej Nikiszin, Wadim Bogdanow, Larisa Gruzdeva i ja musieliśmy omówić naprawdę wiele rzeczy. W hotelu wynajęliśmy salę konferencyjną i codziennie od godziny 9 do 17 szkicowaliśmy i dyskutowaliśmy, a następnie przenosiliśmy się do restauracji, aby pograć w biliarda i spróbować czeskiego piwa, układając sobie w głowie świeże pomysły.

Pracowaliśmy tak produktywnie, że do Moskwy wróciliśmy z pomysłem. De-Monderik spisał nasze propozycje, a dokument ten zainspirował mnie do napisania dzisiejszego posta. Oto on:

Kriukow i Nikiszin długo omawiali silnik Prague, jednak został on utworzony w 1999 r., gdy do zespołu dołączył Andriej Dukwalow. Jego doświadczenie w tworzeniu systemów pomogło przekuć naszą ideę w coś więcej niż tylko system wtyczek do silnika antywirusowego.

Silnik Prague okazał się być niezależnym, zorientowanym na obiekty i modułowym systemem, w którym obiekty były tworzone i zarządzane po uruchomieniu aplikacji, hierarchia obiektów była obserwowana, a jądro włączało takie funkcje jak zarządzanie pamięcią czy komunikacja. Wszystko to komunikowało się z systemem operacyjnym i interfejsem, który widział użytkownik, poprzez stosunkowo cienką warstwę, dzięki czemu można było napisać niemal całe jądro antywirusa w postaci „wtyczek do silnika Prague”.

Dukwalow utworzył pierwszą wersję, której użyliśmy w produkcie dla AVP 4.0. Mimo że jeszcze nie był to całkowicie nowy produkt napisany ponownie na podstawie silnika Prague, ale widoczne już były mocne strony tej architektury:

• Całkowicie rozwiązał się problem przetwarzania skomplikowanych obiektów osadzonych. Antywirus na silniku Prague jako pierwszy na rynku z łatwością leczył zainfekowane pliki, np. spakowane w archiwa, czy wykrywał wirusy na granicy objętości archiwum wielowoluminowego. Dla modułów odpowiedzialnych za wykrywanie i leczenie nie miało znaczenia, gdzie pierwotnie znajdował się zainfekowany obiekt — w którym archiwum czy systemie plików.
• Logika silnika antywirusowego można było z łatwością aktualizować wraz z bazami danych, a ponadto nie trzeba było ponownie uruchamiać produktu w celu akceptacji nowej logiki.
• Moduły były niewielkie i z łatwością adaptowały się do różnych platform. W efekcie mogliśmy bez wysiłku przygotować KAV w wersji 6 dla systemu Mac.
• Wszystko działało bardzo szybko i wymagało minimalnej ilości pamięci; silnik Prague pochłaniał wtedy znacznie mniej zasobów niż jakikolwiek inna istniejąca struktura obiektów.

Dzięki wykorzystaniu technologii Prague znaleźliśmy się w czołówce branży IT — podejście modułowe do tworzenia oprogramowania nie było wtedy na zaawansowanym poziomie. Później zdobyliśmy na Prague cztery amerykańskie patenty: 7386885, 7730535, 7418710, 8234656.

Silnik Prague można było również z łatwością integrować z kodem napisanym na innych zasadach; dlatego początkowo był on wbudowany w wersję 4.0, chociaż tylko w celu rozwiązania wąskiego zakresu problemów. Okazał się wtedy tak dobry, że gdy pojawiły się znacznie poważniejsze problemy podczas tworzenia wersji 5.0, Dukwalow wymyślił, aby utworzyć nową wersję w pełni opartą na technologii Prague — tak powstała rewolucyjna wersja Kaspersky Anti-Virus 6.

Aby umieścić „wtyczkę antywirusową” w strukturze do tworzenia całego produktu musieliśmy uogólnić i przeprojektować niektóre założenia. Główną siłą napędową byli tutaj Andriej Dokwalow i Paweł Mieżujew — gdyby nie oni, Prague nie nadawałby się do tak skomplikowanych zadań.

Oczywiście nic nie jest idealne na etapie rozwoju, więc i nasz silnik Prague miał dwie duże wady.

Pierwsza: trudno się go debugowało. Druga: był on trudny w adopcji przez programistów. Ponieważ był to nowo utworzony system obiektów, nakładał dość surowe wymagania odnośnie kodu. Ponadto moduły początkowo musiały być napisane wyłącznie w języku C. Trudno się uczy ludzi w tempie ekspresowym, a my potrzebowaliśmy zatrudniać coraz więcej programistów, gdyż firma się rozwijała, a produkty stawały się coraz bardziej złożone.

A zatem, jak wszędzie indziej w branży IT, priorytetem stała się szybkość programowania, a my stopniowo musieliśmy przechodzić na bardziej znane i bardziej konwencjonalne struktury obiektów. Jednak fragmenty oparte na silniku Prague nadal z powodzeniem działają w naszych produktach.

Oczywiście wtedy wady te były związane z przetwarzaniem i zasobami. Jak najbardziej były one do rozwiązania, a korzyści z implementacji silnika Prague znacząco przeważały potrzebny nakład pracy. Prague rozwiązał jeden z najtrudniejszych (i najdroższych) problemów, które szczególnie zyskały na popularności w ciągu ostatniego dziesięciolecia — mobilność technologii (w tym mobilność binarna) na różne platformy.

Zamiast tworzyć nowy produkt od zera dla każdego systemu operacyjnego i procesora, użyliśmy gotowego silnika debugowania. Ta długoterminowa inwestycja w badania i rozwój silnika debugowania nie tylko w pełni się opłacała, ale utrzymuje nasze technologiczne przywództwo po dziś dzień — Unified Component Architecture, czyli następca technologii Prague, jest używana w maksymalnym stopniu, a my nadal nie widzimy żadnych problemów, których nie można by było z jej pomocą rozwiązać. To kolejny dowód na to, że dobra architektura może służyć wiele lat.

Jak stwierdził Aleksiej De-Monderik, technologia Prague odegrała w naszej firmie bardzo istotną rolę, nie tylko w sensie technologicznym. Skupiła się wokół niej grupa zaangażowanych ludzi, którzy później utworzyli dział „Six”. Bardzo miło to wspominam.

Cieszę się, że nasza najważniejsza technologia wyznaczyła trendy i z radością świętuję rocznicę jej powstania.