Modernizacja systemu bilingowego w Play

Transkrypt

1 ROZMOWA Modernizacja systemu bilingowego w Play, Marcin Kozal (Play), Andrzej Syta (Comparex) 1

2 - W 2017 roku firma firma P4 Sp. z o.o. (Play) przeprowadziła bardzo szeroką modernizację infrastruktury systemu bilingowego. Dlaczego wtedy właśnie musiało dojść do tak skomplikowanej operacji? Marcin Kozal (Play) Stało się tak dlatego, że okres wsparcia poprzedniej produkcyjnej platformy, dobiegał końca. Platforma była objęta wsparciem do początku 2018 roku, a my - mając doświadczenia z poprzednich tego typu projektów - stwierdziliśmy, że na całą operację będziemy potrzebowali około roku. Dlatego pod koniec 2016 roku zdecydowaliśmy się przygotować zapytanie ofertowe na wymianę ówczesnej platformy i wysłaliśmy je do potencjalnych dostawców. W ramach procesu wymiany platformy, obok modernizacji sprzętu, planowaliśmy także podniesienie wersji systemów operacyjnych, baz danych oraz samego systemu bilingowego, którego używamy w Play. 2

3 Czy chodziło tylko o terminy, czy też o wydajność sprzętu? Jak ówczesny stan systemu przekładał się na funkcjonowanie firmy? Wymiana hardware u odbywa się w 5-letnim cyklu. Jest to podyktowane polityką dostawców i tym, jaki jest okres wsparcia. Ten regularny cykl przyświeca nam już od wielu lat. Przy samej wymianie systemu billingowego nie zmienialiśmy dostawcy aplikacji, chociaż oczywiście wymieniliśmy pewne jej komponenty. Zdecydowaliśmy się natomiast na nowsze wersje baz danych, a część aplikacyjną zmigrowaliśmy na platformę Intel, ale rewolucyjnych zmian, jeśli chodzi o sam system bilingowy, nie było. Zatem była to zmiana podyktowana stricte upływającym terminem wsparcia oraz zwiększeniem wydajności platformy (możliwość obsługi większej liczby klientów). Modernizacja platformy umożliwiła również skorzystanie z oferowanych nowości. My zdecydowaliśmy się na flaszowe macierze IBM DS8880. Taki moment to zawsze okazja, żeby przemyśleć, co możemy poprawić w architekturze rozwiązania, w celu poprawy wydajności aplikacji i baz danych, co przekłada się na korzyści dla klientów zewnętrznych i wewnętrznych. 3

4 Wraz z nowymi macierzami wdrożyliśmy również nowe serwery, z wydajniejszymi procesorami oraz wymieniliśmy system backupowy. Nasze potrzeby dokładnie opisaliśmy w zapytaniu skierowanym do dostawców. jedną z warstw aplikacyjnych na platformę Intel. Ta decyzja była w pewnym stopniu powiązana z road-mapą dostawcy systemu billingowego. Natomiast z warstwą middleware i bazami danych pozostaliśmy na platformie IBM Power. Jeżeli chodzi o pozostałe oferty, to rozwiązania w większości spełniały nasze oczekiwania. - Jak wyglądała odpowiedź rynku? Czy było z czego wybierać? Marcin Kozal (Play) - Dlaczego zatem wybrane zostały macierze dyskowe IBM DS 8000 i nowe serwery IBM Power 8? Co zdecydowało o tym, że było to najlepsze rozwiązanie? Owszem, było z czego wybierać. Nasze zapytanie było dość obszerne, w związku z tym główni dostawcy sprzętu na rynku polskim byli zainteresowani tym postępowaniem. Co istotne, rozważaliśmy migrację całego rozwiązania na platformę Intel. Pomimo tego, iż poprzednia platforma była oparta o procesory IBM Power 7, to dawaliśmy możliwość także innym dostawcom zmierzenia się z pełnym zakresem tego zapytania. Oferty były zróżnicowane, a niektóre z nich były bardzo nowatorskie. Finalnie zdecydowaliśmy się zmigrować tylko Andrzej Syta (Comparex) Chodzi głównie o wydajność tych serwerów i ich wysoką dostępność. To znaczy, że pomimo awarii środowiska, np. w jednej lokalizacji, bądź pojedynczego elementu, cały system bilingowy ciągle działa i w stu procentach jest wydajny. Są oczywiście rozwiązania konkurencyjnych firm, ale np. serwery 4

5 innej znanej marki już tak dobrze się nie skalują i taki system nie jest optymalny. Natomiast IBM Power ma bardzo dobrą wydajność i nawet przy obciążeniu rzędu ponad 90 procent ten system ciągle pracuje. A w podobnym środowisku konkurencyjnym proc. to maksymalny poziom obciążenia procesora, przy którym system ciągle stabilnie działa. Warto zaznaczyć w tym miejscu, że to już jest nasza druga migracja w Play. Poprzednią robiliśmy 6 lat temu i było to też środowisko IBM Power. Po 5 latach klient ponownie zdecydował się wymienić maszyny na nowe, także na rozwiązanie Power, bo ma to sprawdzone. Poza tym w tych rozwiązaniach można wirtualizować środowiska, czyli możn na jednym serwerze uruchomić kilkanaście systemów i instancji baz danych. I to środowisko dalej działa wydajnie. Przy takim systemie jak biling, który musi naliczać opłaty abonamentowe, jest to niezwykle ważne. Już na etapie rozważania naszej decyzji cały projekt rozdzieliliśmy na część storage i serwerową. Jeśli chodzi o storage, to zgłosili się różni dostawcy, którzy prezentowali swoje rozwiązania, na których nam zależało. Nasze wymagania były konkretnie sprecyzowane. Wiedzieliśmy, że na rynku działa już technologia flaszowa i takiej oczekiwaliśmy. Częściowo dlatego, że mieliśmy wcześniej okazję przetestować ją w konkretnym rozwiązaniu i sprawdzić, czy nasza aplikacja skorzysta z tego, że mamy szybkie macierze. Wiedzieliśmy, że chcemy tego w warstwie, w której bardzo mocno przetwarzamy dane. Wiedzieliśmy, że możemy na tym skorzystać i np. skrócić czas potrzebny na przetwarzanie dużych ilości danych. Chodziło też o to, żeby rozwiązanie było wielowarstwowe, czyli miało te stosunkowo drogie obszary typu flasz, na które my będziemy potrafili podstawić sobie dane dla nas ważne. Ale dodatkowo żeby były również te warstwy tańsze (dyskowe), na których będziemy mogli trzymać inne komponenty aplikacyjne, czy chociażby dane historyczne, których nie ma potrzeby trzymać na stosunkowo drogim storage fleszowym. Takich rozwiązań wielowarstwowych poszukiwaliśmy i jednym z nich było rozwiązanie IBM. 5

6 A jakie były główne założenia, jeżeli chodzi o część serwerową? Jedną z rozważanych opcji była migracja bazy danych na platformę Intel, albo pozostanie przy rozwiązaniach IBM. Wybraliśmy opcję IBM Power, nie mieliśmy w związku z tym migracji dużych baz danych pomiędzy różnymi architekturami procesora. Serwerową część aplikacyjną zdecydowaliśmy się zainstalować na technologii Intel. W związku z tym cała platforma wykorzystuje rozwiązania dwóch dostawców. Za jej wsparcie odpowiada firma Comparex. Marcin Kozal (Play) W ten sposób zminimalizowaliśmy potencjalne tarcia pomiędzy vendorami w przypadku wystąpienie problemów. Wiadomo było, że główne komponenty są dostarczone razem, przez jednego dostawcę, są sprawdzone i nawet gdyby wyszły jakieś 6

7 problemy, to poszukiwanie rozwiązań zamyka się w obszarze firmy IBM. A my nie musimy prowadzić rozmów z różnymi dostawcami i słuchać wymówek typu: a to nie u mnie, tylko na pewno po drugiej stronie jest problem. Oczywiście są klienci, którzy wolą nie uzależniać się od jednego vendora, a są i tacy, którzy właśnie taki model preferują. Moim zdaniem jeden dostawca to plus. Bo wiadomo, że komponenty są ze sobą kompatybilne i zmniejszamy ryzyko tego, że coś nie będzie działało jak trzeba. Jak istotne jest to, aby decydować się na jednego dostawcę i w czym jeszcze to pomaga? A może takie rozwiązanie ma jakieś wady? Ma to duże znaczenie, bo jeśli mamy kilku vendorów i każdy dostarcza inny element, to rozmywa się odpowiedzialność. I jeśli cokolwiek złego dzieje się w systemie, każdy mówi: to nie moja wina. To daje pole do tego, żeby nikt nie brał odpowiedzialności za całość. Andrzej Syta (Comparex) A jeżeli klient bierze zestaw od jednego producenta i od jednego partnera, jakim jest Comparex, tak naprawdę ma jeden kierunek do kontaktu kiedy coś nie działa. Po prostu zgłasza nam problem i my się tym zajmujemy. Marcin Kozal (Play) Nie stosujemy krótkich list dostawców. Zawsze staramy się sprawdzić, co w danym momencie oferuje rynek i jak możemy wykorzystać nowe technologie. Z drugiej strony nie staramy się za wszelką cenę wdrażać wszelkich nowinek i bardzo zwracamy uwagę na dotrzymanie ustalonych terminów wdrożenia. Przy wdrażaniu krytycznych systemów zawsze staramy się minimalizować potencjalne problemy / opóźnienia, już na etapie planowania prac, również te związane z dostawcami. Tak było i w tym przypadku: bazy danych, middleware, infrastruktura SAN i macierze były traktowane jako całość, współpracująca z warstwą aplikacyjną. Zatem miejsc na potencjalne tarcia było zdecydowanie mniej niż przy większym rozdrobnieniu. 7

8 Z pewnością jednak tarć i kłopotów uniknąć się nie dało. W ramach projektu zmierzyliśmy się z niejednym problemem technologicznym. Zwłaszcza, że czas implementacji był tu bardzo krótki. Od momentu dostawy sprzętu na zmigrowanie i przetestowanie go oraz na całą migrację produkcyjną mieliśmy niecały rok. Bazy danych, system operacyjny i sprzęt to elementy, na styku których gdzieś zawsze może powstać problem. I rzeczywiście tak się działo. Do ich rozwiązywania zastosowaliśmy metodę spotkań i burz mózgów z fachowcami ze wszystkich możliwych stron. Szukaliśmy wyjścia nie przerzucając odpowiedzialności na kogoś innego, tylko rozważając różne scenariusze. W gronie ekspertów i specjalistów, podczas dyskusji świetnie potrafiliśmy odnajdywać właściwe rozwiązania. Miało to kluczowe znaczenie ze względu na terminowe zrealizowanie projektu. Harmonogram mieliśmy naprawdę mocno napięty. 8

9 Niecały rok przy tego typu operacjach to dużo czy mało? Żeby sytuacja była zupełnie komfortowa, potrzebowalibyśmy pewnie jeszcze ze dwa miesiące. Głównie na migracje baz danych. Ostatecznie się udało i termin został dotrzymany. Marcin Kozal (Play) Zależy od tego, co wchodzi w zakres takiego projektu. My oprócz całkowicie nowej infrastruktury sprzętowej robiliśmy upgrade systemu operacyjnego. Do tego co bardzo ważne upgrade bazy danych do nowej wersji, która mocno się zmieniała. I jeszcze aktualizację systemu bilingowego po to, żeby wspierał nową bazę danych i nowy system operacyjny. Z jednej strony czekała nas ogromna ilość testów, które musiały być wykonane, poczynając od infrastruktury niskopoziomowej, przez kolejne warstwy aplikacji i testy wydajnościowe. A druga sprawa to same migracje, które trwały blisko trzy miesiące. A przecież nie można robić wszystkiego jednocześnie. Wszystkie zadania zostały podzielone na etapy, co wynikało też z ograniczenia dotyczącego tzw. okien utrzymaniowych. Dodatkowo, prace musiały być niewidoczne z punktu widzenia klientów i procesów biznesowych działających na starej, i w miarę postępu prac, nowej platformie. Z drugiej strony robiąc taką migrację w jakimś stopniu robiliśmy freeze na zmiany w systemie. Więc niektóre prace były po prostu wstrzymane. Dlatego biorąc pod uwagę, że biznes idzie do przodu, nie mogliśmy pozwolić sobie na przedłużanie całego projektu. 9

10 Jak konkretnie wyglądało wdrożenie nowego systemu? Czy nowy sprzęt wymagał nowych pomieszczeń? A może potrzebni byli dodatkowi pracownicy? Na szczęście nie musieliśmy dokupować czy wynajmować dodatkowej powierzchni w serwerowni. Jedno z naszych założeń było takie, że sprzęt ma być bardziej upakowany zajmować mniej powierzchni. Udało się to uzyskać w dużym stopniu dzięki zastosowaniu technologii fleszowej, która zajmuje mniej miejsca i potrzebuje mniej prądu. Przyznam też, że jest zauważalnie cichsza. Taki system na początku instaluje się obok tego istniejącego. Następnie uruchamia, potem testuje oraz przeprowadza migracje testowe. I dopiero na migracjach testowych wykonuje się testy funkcjonalne i bada wydajność oraz sprawdza, czy wszystko działa zgodnie z wymaganiami. Dopiero gdy jesteśmy pewni, że wszystkie zaplanowane testy faktycznie zostały prawidłowo wykonane i potwierdziły właściwe działanie platformy, wtedy zaczynamy produkcyjne uruchomienie systemu według przygotowanego harmonogramu, który 10

11 w tym przypadku był bardzo rozbudowany. Zawierał on zarówno migrację wszystkich baz danych, części aplikacyjnej, jak i całego systemu, który umiejscowiony był obok ciągle działającego systemu bilingowego, który miał być stopniowo wygaszany. Zaangażowane były tak naprawdę dziesiątki osób. I wszyscy wiedzieli, co muszą zrobić, co w danej chwili jest ważne, z jakim problemem się zmagamy i kto ma się nim zająć. Wspierał nas w tym wszystkim software do zarządzania takimi projektami. Pozwoliło nam to na przykład nie gubić wątków, których jednocześnie potrafiły toczyć się setki. Jak wyglądało to od strony zaangażowania pracowników? Kiedy już projekt wkroczył w taką fazę, że faktycznie dużo się działo, przez parę miesięcy mieliśmy specjalne poranne spotkania. Robiliśmy wtedy listę rzeczy, które będziemy wykonywać danego dnia. W ciągu dnia były spotkania w różnych grupach w zależności od tematu i zadania, a wieczorem podsumowanie. I to jest schemat, który się sprawdza w takich harmonogramach, gdzie naprawdę dużo się dzieje i komunikacja musi być bardzo dobra. Andrzej Syta (Comparex) My do projektu oddelegowaliśmy zespół z dedykowanym od początku do końca project managerem. Ułożony był ścisły harmonogram wdrożenia, na bieżąco konsultowany z klientem. Ponieważ był to nasz drugi raz, było łatwiej, chociaż ten projekt był o wiele większy od pierwszego, bo baz do migracji było więcej. Zaczynaliśmy dostawami sprzętu na przełomie stycznia i lutego 2017 r. Lipiec i sierpień to były testowe migracje po to, żeby na przełomie sierpnia i września wykonywać już produkcyjne migracje baz. Ostatnie trzy miesiące roku upłynęły na dostrajaniu środowiska, wygrzewaniu go i na różnych korektach ustawień, żeby osiągnąć spodziewane parametry wydajnościowe platformy. Na końcu miały miejsce szkolenia i tak cały projekt zamknął się w ciągu roku. 11

12 Nowy system pracuje już blisko rok. Jak z tej perspektywy oceniacie Panowie cały proces wdrożenia? Coś was szczególnie zaskoczyło? Marcin Kozal (Play) Z perspektywy czasu możemy też próbować ocenić, czy dobrze oszacowaliśmy nasze wymagania i czy nie przestrzeliliśmy w którąkolwiek stronę planując za mało albo za dużo. I tu faktycznie mamy dopasowanie możliwości serwerów i macierzy. Bardzo miło jest stwierdzić po czasie, że nie kupiliśmy czegoś za dużo ani za mało. Kupiliśmy w sam raz, oczywiście z możliwością pewnej rozbudowy. Platforma działa stabilnie i jest w stanie obsłużyć rosnące obciążenie systemu. Proces fakturowania został skrócony, płatności szybciej się wczytują i to są główne korzyści, jakie odnotowaliśmy. Andrzej Syta (Comparex) Jeśli chodzi o problemy, to były one szczególnie na początku, na przykład ze wspomnianą bazą danych, która inaczej się zachowywała niż w poprzednich wersjach. Były też problemy z samym zachowaniem platformy sprzętowej. I nie było to początkowo wcale takie oczywiste do zdiagnozowania. Dlatego potrzebowaliśmy tak naprawdę trochę czasu, żeby docenić zalety nowej platformy. Na rynku są teraz różne koncepcje cloudowe, nastawione na tańsze rozwiązania i szukanie oszczędności. Ale nie wszędzie warto oszczędzać. Są rozwiązania, w których warto zapłacić za niezawodną technologię i mieć sprzęt z górnej półki. Tak naprawdę kupujemy wtedy bezpieczeństwo i wydajność. I to, że śpimy spokojnie. Niestety w przypadku oszczędności bywa, że później coś może nie działać, jak trzeba. Tutaj nie mamy takiego problemu. Klient kupuje system na 5 lat i wie, że przez 5 lat tej wydajności mu wystarczy. A gdyby zaczęło brakować, to bardzo łatwo można sprzęt rozbudować. Bo wcale nie trzeba modernizować 12

13 całego środowiska, tylko rozbudowujemy serwer, macierze i to wszystko dalej nam działa. System ma funkcjonalność capacity on demend i bardzo łatwo można rozszerzyć i rozbudować środowisko bez zmieniania jego architektury. Co to oznacza w praktyce? Czy np. abonenci Play zauważyli różnicę? Marcin Kozal (Play) A czy po roku widać już taką potrzebę rozbudowy? Elementem, który zawsze można poprawić, bo zawsze mógłby być szybszy, jest storage. Natomiast w tym przypadku technologia fleszowa, którą zastosowaliśmy, jest czymś najnowszym i nie pojawiło się nic lepszego. Więc na razie nasze potrzeby są zaspokojone. To się tak prosto nie przekłada, bo np. papierowe faktury i tak drukarnia musi wydrukować. Z kolei faktury elektroniczne, których jest już ponad 90 proc., muszą być odpowiednio przetworzone. A zmodernizowany system to tylko jeden z elementów procesu. Natomiast cała modernizacja przyniosła duże ułatwienia dla naszych klientów wewnętrznych. Konkretne dane są teraz znacznie wcześniej dostępne, więc mogą szybciej robić pewne analizy, czy przygotowywać te dane do dalszej obróbki. Na pewno też wszyscy korzystają na tym, że system jest stabilny. Kiedy składaliśmy zamówienie, braliśmy też pod uwagę dyski SSD, ale one są wolniejsze niż technologia fleszowa. Technologia IBM FlashSystem była o wiele szybsza, ale i dużo droższa, dlatego musiała być rozsądnie wybrana. Dzięki wcześniejszym testom wiedzieliśmy, że wykorzystamy jej moc i że będą to dobrze wydane pieniądze. Opłaciło się i system działa szybciej. 13

14 Czy aktualna wydajność tego systemu wystarczy do kolejnej, planowanej zgodnie z harmonogramem modernizacji? Ta platforma jest skalowalna, co oznacza, że możemy dołożyć do niej trochę nowych serwerów, czyli dołożyć mocy. I możemy zrobić to zawsze, bo tak jest napisana aplikacja. A jeżeli chodzi o storage, to możemy dołożyć więcej warstwy fleszowej i to nam pozwoli na pewno kilka lat spokojnie przeżyć. Marcin Kozal (Play) Teraz jesteśmy w stabilnym okresie. A wymiana czy modernizacja platformy sprzętowej tylko dlatego, że pojawiła się nowsza wersja, raczej nie wchodzi w grę. Będziemy brali pod uwagę różne nowości technologiczne, jak przyjdzie kolejny okres przygotowań do wymiany platformy. 14

15 Jak dużym wyzwaniem jest taka modernizacja? A jak duże wyzwanie było to dla Comparexu? Obaj pracujemy w Play już ponad 10 lat, więc mieliśmy okazję przeżyć już trochę takich różnych migracji aplikacyjnych. Jest to wyzwanie z kategorii ciekawych, także organizacyjnie. Marcin Kozal (Play) Nie mam nic przeciwko wyzwaniom, oby nie za często. Andrzej Syta (Comparex) Wiadomo, że jak pojawia się taki ogromny projekt, to ma on u nas priorytet. Po prostu nie ma nic ważniejszego. Wiedząc, że taka współpraca będzie miała miejsce, alokujemy osoby, żeby były do niej zaangażowane na 100 procent. Ale to też nie jest tak, że firma staje. Taki projekt robi kilku inżynierów i kilku konsultantów, a my jesteśmy na takie wyzwania gotowi. To duże przedsięwzięcie, ale to nic takiego, co by stawiało firmę na głowie. Natomiast z pewnością każdy inżynier lubi angażować się w takie zadanie. Tak, bo czasami trzeba też odpocząć. Po takim gorącym czasie są potrzebne okresy na uporządkowanie wszystkiego i dopracowanie dokumentacji. 15

16 Dlaczego? Andrzej Syta (Comparex) Bo to jest bardzo ciekawe. Macierze, które wdrażaliśmy w Play, to sprzęt klasy enterprise - największe, jakie sprzedaje firma IBM. Wcale nie ma aż tak dużo projektów, przy których można tych macierzy dotknąć i na nich popracować. To rzadkość, żeby dostać nowe urządzenie i od początku do końca móc je skonfigurować. Dlatego inżynierowie chętnie biorą udział w takich wdrożeniach, to dla nich fajna przygoda. Dotykają naprawdę najnowszych, najciekawszych technologii, co nie jest na rynku takie znowu powszechne. Tylko u takich dużych klientów jak właściciel Play - P4, który ma teraz ponad 15 mln abonentów, wymagane są rozwiązania tak bezkompromisowe, wydajne i niezawodne. 16

17 A co jest kluczem do sukcesu przy tak skomplikowanej operacji? Andrzej Syta (Comparex) Przede wszystkim bardzo duże doświadczenie, które my już mieliśmy po wcześniejszym projekcie z P4. Mamy też świetnych specjalistów, którzy tę migrację robili i znamy się z klientem już prawie 12 lat. Zaufanie i partnerskie podejście powoduje, że klient jest spokojny i wie, że wszystko doprowadzimy do końca. Bo i dla nas jest to projekt bardzo prestiżowy. za bazy danych itd. I ważne było, żeby w razie potrzeby mieć ich pod ręką. Wiele z tych osób, oprócz swojej codziennej pracy w innych obszarach, dodatkowo wspomagało nas w tym projekcie. Dlatego uważam, że clue sukcesu wcale nie jest ten hardware, który jest świetny i z którego się cieszymy oczywiście, ale są to ludzie. My mieliśmy wsparcie naszej kadry zarządzającej i ogromne zaangażowanie pracowników Play. Muszę pochwalić też zarówno ekspertów z firmy Comparex jak i IBM. To Ci wszyscy ludzie, ich zaangażowanie i wiedza zdecydowały o tym, że ten projekt się udał. Nam na pewno bardzo pomogła dokładna specyfikacja jeszcze przed zamówieniem tego, czego oczekujemy i co jest nam potrzebne. Wszystkie poprzedzające zapytanie ofertowe spotkania i narady bardzo się opłaciły. Ogromnie istotne było też to, żeby dotrzymywać dat przy samym prowadzeniu projektu, żeby mieć dobrze zgrany zespół rozumiejący, co jest celem projektu. Zarówno od dostawcy, jak i od kierowników projektu, czy ze strony ekspertów odpowiedzialnych chociażby 17

18 Andrzej Syta Pre-Sales & Consulting Manager Comparex Poland Marcin Kozal IT Infrastructure Support Manager Absolwent Wydziału Cybernetyki WAT, od ponad 17 lat wspiera i doradza klientom z branży IT w obszarach Infrastruktury, DataCenter, rozwiązań wysokiej dostępności środowisk aplikacyjnych. Od 10 lat związany z Comparex, gdzie na stanowisku dyrektora działu wsparcia sprzedaży odpowiedzialny jest za doradztwo i konsulting głównie w zakresie technologii IBM i Mircosoft oraz analizę i promowanie nowoczesnych rozwiązań w odpowiedzi transformację cyfrową w świecie IT. Absolwent Wydziału Automatyki, Elektroniki i Informatyki Politechniki Śląskiej, od ponad 20 lat w branży IT. Od 12 lat związany z P4. Odpowiedzialny za rozwój, utrzymanie Infrastruktury IT oraz utrzymanie platformy bilingowej i ratingowej. Piotr Daniszewski Billing Infrastructure Support Team Manager Absolwent Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, od ponad 20 lat w branży IT. Od 11 lat związany z P4 Odpowiedzialny za utrzymanie platformy bilingowej. 18

19 ZAPRASZAMY COMPAREX Poland Sp. z o.o. ul. Równoległa Warszawa tel faks: info@comparex.pl WYDAWCA 19