Załącznik nr 2 do zapytania ofertowego nr 1/2017 z dnia 23.02.2017 SPECYFIKACJA TECHNICZNA W związku z realizacją projektu pn.: Wprowadzenie produktu nowego na rynku w celu ekspansji oraz poprawa efektywności dzięki wykorzystaniu technologii informacyjno komunikacyjnych w Aiton Caldwell S.A. współfinansowanego w ramach Regionalnego Programu Operacyjnego dla Województwa Pomorskiego na lata 2014-2020 (Oś priorytetowa: 02. Przedsiębiorstwa, Działanie 02.02. Inwestycje profilowane, Poddziałanie 02.02.01. Inwestycje profilowane - wsparcie dotacyjne), Aiton Caldwell S.A. ogłasza zgodnie z zasadą konkurencyjności postępowanie w trybie zapytania ofertowego na realizację następującego zadania: Zakup wartości niematerialnej i prawnej związanej z wytworzeniem serwera telekomunikacyjnego Call-eX poprzez zastosowanie innowacyjnych rozwiązań Przedmiotem zamówienia jest dostarczenie dedykowanego systemu do nowego produktu rozumianego jako serwer telekomunikacyjny służący do organizacji ruchu telekomunikacyjnego wewnętrznego i zewnętrznego poprzez kanał VoIP, umożliwiający realizację usług dodanych (nagrywanie rozmów, callcenter, IVR itd.), integrowany z innymi systemami teleinformatycznymi (np. bazami danych). W Wyniku realizacji projektu nastąpi znacząca poprawa jakości i funkcjonalności produktu CalleX co przełoży się istotnie na poszerzenie rynków zbytu na rynku krajowym i zagranicznym. Modernizacja ta będzie polegała na wprowadzeniu innowacyjnych rozwiązań technologicznych tj.: a) Nowy motor sytemu oparty o zmienioną architekturę b) System wirtualizacji oparty o rozwiązanie Docker lub równoważny, opisany poniżej c) Moduł implementacji usług realizujących funkcjonalności przeniesione ze wcześniejszej wersji systemu w nowej architekturze d) Moduł połączeń e) Moduł API/CTI f) Moduł monitorujący g) Narzędzia do badania wydajności systemu Poniżej szczegóły dotyczące każdej z funkcjonalności: a) Nowy motor sytemu oparty o zmienioną architekturę Umożliwienie przydzielania zasobów CPU oraz priorytetyzacji dostępu do dysków dla segmentów Telco, NoTelco, Raport, Support. W skład segmentu Telco wchodzą aplikacje Asterisk oraz AGI.
Zwiększenie wydajności systemu poprzez zmniejszenie zapotrzebowania aplikacji na CPU oraz pamięć RAM. Zwiększenie parametrów pojemnościowych(ilość jednoczesnych połączeń, ilość zarejestrowanych użytkowników, ilość aktywnych kolejek Call Center, ilość aktywnych agentów Call Center) dotyczących usług głosowych Umożliwienie dalszego rozwoju aplikacji poprzez implementację nowych modułów, bez potrzeby ingerencji w całość rozwiązania. Podział na moduły ma zapewnić niezależność międzymodułową, dzięki której rozwój poszczególnych modułów odbywać się będzie bez potrzeby modyfikacji innych modułów. Główną korzyścią tej modyfikacji będzie zapewnienie ciągłości działania usług głosowych, a tym samym ograniczenie awarii zgłaszanych przez klientów, spowodowanych obciążeniem maszyny, na której zainstalowana jest aplikacja. Wzrost wydajności pozwoli na dotarcie do klientów z dużymi działami Call Center. Poza korzyściami płynącymi z możliwości zarządzania polityką przydzielania zasobów do poszczególnych segmentów aplikacji dużą wartością będzie podział aplikacji na miniservice y, dzięki którym dalszy rozwój aplikacji będzie lepiej zarządzany od obecnego modelu monolitycznego. Dzięki określeniu styków pomiędzy miniservice ami oraz ich odpowiedzialnościami organizacja będzie w stanie realizować rozwój aplikacji przez zewnętrznych kontraktorów, co przyśpieszy proces realizacji nowych funkcjonalności. Architektura systemu zostanie zmieniona z dotychczasowej 32-bitowej na 64-bitową. System zostanie podzielony na segmenty Telco, NoTelco, Raport, Support. W skład segmentu Telco wchodzą aplikacje realizujące usługi głosowe takie jak Asterisk, AGI, tcpdump, menadżer zdarzeń oraz baza danych wymagana do działania tych aplikacji. W skład segmentu NoTelco wchodzą aplikacje nie realizujące usług głosowych i raportowych, a służą do zarządzania konfiguracją systemu. Te aplikacje to : panele WWW, monitor stanu połączeń, provisioning urządzeń, składarka nagrań, API, książka adresowa LDAP, menadżer zdarzeń oraz baza danych wymagana do działania tych aplikacji. W skład segmentu Raport wchodzą : system raportowy, API wewnętrzne systemu raportowego, API zewnętrzne systemu raportowego oraz baza danych wymagana do działania tych aplikacji. W skład segmentu Support wchodzą aplikacje monitorujące stan systemu oraz aplikacje związane z centralizacją logów takie jak logstash, elasticsearch, kibana, zabix, fail2ban. Innowacyjność Nowa architektura systemu zakłada wykorzystywanie najnowszych dostępnych rozwiązań, które będą zastosowane zarówno w nawiązywaniu połączeń pomiędzy poszczególnymi komponentami, jak i w budowaniu tych komponentów. Wykorzystanie mechanizmów Server SentEvents (SSE) oraz Websocket to rozwiązania dostępne od niedawna i niewiele systemów teleinformatycznych zdążyło zaadoptować te mechanizmy. b) System wirtualizacji oparty o rozwiązanie Docker lub równoważny Uniezależnienie aplikacji od maszyny fizycznej oraz systemu operacyjnego, na którym jest zainstalowana.
Wdrożenie środowiska Continous Integration, umożliwiające automatyczne testowanie aplikacji oraz dystrybucję zaimplementowanych funkcjonalności na środowiska developerskie, testowe oraz produkcyjne. Umożliwienie przydzielania zasobów CPU oraz priorytetyzacji dostępu do dysków dla segmentów Telco, NoTelco, Raport, Support. W skład segmentu Telco wchodzą aplikacje Asterisk oraz AGI. Ograniczenie czasu pobierania najnowszych wersji aplikacji poprzez zastosowanie obrazów przyrostowych(zawierające tylko różnice pomiędzy poprzednią wersją obrazu a wersją do której chcemy zaktualizować obraz). Użycie technologii Docker lub równoważnej jest konieczne, aby w prosty sposób uniezależnić warstwę aplikacyjną od warstwy systemowej, co pozwala na migrowanie rozwiązań osadzonych w tzw. kontenerach między różnymi maszynami fizycznymi i pomiędzy różnymi systemami operacyjnymi. Kontenery zastosowane jako środowisko developerskie, testowe oraz produkcyjne pozwalają również na integrację systemu ze środowiskami CI (Continuous Integration), co znacząco przyśpieszy proces implementacji nowych funkcjonalności poprzez możliwość dystrybucji obrazów na wskazane środowiska. Wykorzystanie tej technologii tj. mechanizmu obrazów przyrostowych przyśpieszy proces aktualizacji systemu. Obecnie proces aktualizacji wymaga przesłania na system produkcyjny całej aplikacji, co w zależności od łącza może potrwać ponad godzinę. Obrazy przyrostowe zawierają mniej informacji przez co są dużo mniejsze co w sumie przełoży się na czas przesyłania obrazów na system produkcyjny. Zmiana dotyczy wszystkich modułów wymienionych w pkt a). Każda z aplikacji zostanie osadzona w osobnym kontenerze w postaci obrazu, a kontener ją zawierający dzięki zastosowaniu mechanizmu CGROUPS otrzyma odpowiednią dla danego segmentu politykę przydzielania zasobów CPU oraz IO dysków. Polityka przydzielania zasobów zakłada trzy poziomy dostępu: HIGH kontenery, które otrzymają dostęp do wszystkich dostępnych rdzeni procesora/ów oraz maksymalny priorytet w dostępie do dysku. NORMAL kontenery, które otrzymają ograniczony o 50% (parametr konfigurowalny) dostęp do wszystkich dostępnych rdzeni procesora/ów oraz maksymalny priorytet w dostępie do dysku.\ LOW kontenery, które otrzymają ograniczony o połowę 80% (parametr konfigurowalny) dostęp do wszystkich dostępnych rdzeni procesora/ów oraz maksymalny priorytet w dostępie do dysku. Aktualizacja wersji poszczególnych aplikacji będzie obywała się poprzez mechanizm dockerpull, który wykorzystuje obrazy przyrostowe (zawierające tylko różnice pomiędzy poprzednią a obecną wersją obrazu). Innowacyjność Technologia Docker lub taka, która spełnia jej założenia, powinna być oparta na oprogramowaniu otwartym (darmowym) służącym jako platforma dla programistów i administratorów do tworzenia, wdrażania i uruchamiania aplikacji rozproszonych. Beneficjent nie przewiduje zakupów licencji na tego typu oprogramowanie ze względów ekonomicznych
projektu (projekty współfinansowane ze środków publicznych charakteryzują się ponoszeniem wydatków jedynie koniecznych do poniesienia). Technologię równoważną do Docker określamy jako narzędzie, które pozwala umieścić program oraz jego zależności w lekkim, przenośnym, wirtualnym kontenerze, który można uruchomić na prawie każdym serwerze z systemem Linux. c) Moduł implementacji usług realizujących funkcjonalności przeniesione ze wcześniejszej wersji systemu w nowej architekturze Umożliwienie migracji klientów ze starej wersji systemu do nowej bez negatywnego wpływu na świadczone usługi Główną korzyścią tej modyfikacji jest możliwość przeniesienia obecnych aplikacji na nowe rozwiązanie bez utraty przez nich jakiejkolwiek funkcjonalności systemu. Nowa architektura i podział na moduły wymaga również stworzenia nowych aplikacji realizujących funkcjonalności wcześniej zaimplementowane w monolitycznej aplikacji, a obecnie znajdujących się w segmencie NoTelco. Takie zmiany wymagają przeniesienia części logiki obecnej aplikacji oraz bazy danych do osobnej aplikacji. Takie rozdzielenie wymaga również zapewnienia odpowiedniej komunikacji pomiędzy rozdzielonymi elementami. Aplikacje, które zostaną wydzielone to: Składarka nagrań aplikacja realizująca, składanie nagrań z poszczególnych kanałów SIP rozmowy w jedno nagranie. Dostosowanie aplikacji polega na odpowiednim przekazaniu nagrań z kanałów z aplikacji Asterisk do nowej aplikacji i złączenie ich w jedno nagranie w zależności od ustawionych w systemie parametrów zapisanych w bazie danych. Manager Zdarzeń aplikacja musi zostać stworzona od nowa. Odpowiada ona za przekazanie informacji wysyłanych z segmentu Telco do odpowiednich aplikacji segmentu NoTelco oraz segmentu Raportowego. Panele WWW z racji rozproszenia systemu na moduły, należy zmodyfikować panele tak, aby zamiast korzystać z jednego źródła danych, korzystała z danych udostępnionych przez odpowiednie kontenery. Fail2ban aplikacja odpowiadająca za blokowanie adresów IP podejrzanych o próbę ataku na system. Wydzielenie jej do segmentu Support wymaga udostępnienie przez aplikację Asterisk informacji o nieudanych rejestracjach użytkowników. Wszystkie aplikacje działające w kontenerach będą logować do centralnego systemu logów co wymaga modyfikacji ścieżek plików z logami w każdej z nich. d) Moduł połączeń Umożliwienie reagowania komponentów systemu na zdarzenia telekomunikacyjne takie jak odebranie połączenia przez agenta Call Center Umożliwienie tworzenia raportów bazujących na zdarzeniach telekomunikacyjnych
Uniezależnienie się od działania wykorzystanych aplikacji opensource Asterisk oraz skomplikowanego mechanizmu składania CDR (Call DetailRecord dane dotyczące połączeń, które bazują na wielu źródłach danych) Wyeliminowanie rozbieżności w prezentacji danych dotyczących połączeń pomiędzy aplikacjami Panele Online, API/CTI, Raporty Obecne rozwiązanie składa się z wielu modułów, które w specyficzny dla siebie sposób informują o zdarzeniach dotyczących połączeń. Pozostałe aplikacje muszą więc rozumieć jak działa każdy z modułów informujących o zdarzeniach i przetwarzać je na swoje potrzeby. Nowy moduł połączeń pozwoli pozbyć się logiki przetwarzania zdarzeń z wielu modułów i przenieść ją w jedno miejsce, co znacząco uprości proces rozwoju aplikacji zależnych od danych dotyczących połączeń. Wydzielenie funkcji agregujących informacje o połączeniach pozwoli też na wyeliminowanie rozbieżności w interpretowaniu tych informacji przez aplikacje, które obecnie korzystają z tych informacji, co wyeliminuje rozbieżności w prezentowaniu informacji o połączeniach pomiędzy różnymi punktami styku z aktorami systemu. (Panele Online, API/CTI, Raporty). Nowy moduł połączeń będzie posiadał informacje o aktualnym stanie połączeń głosowych. Będzie agregował informacje przesyłane z aplikacji Asterisk oraz AGI i na ich podstawie informował pozostałe moduły (panele online informujące o pracy kolejek Call Center w czasie rzeczywistym; API/CTI interfejsy pozwalające na integrację z systemami zewnętrznymi takimi jak systemy CRM klientów) poprzez ustandaryzowane obiekty zdarzeń. Zdarzenia będą również trafiać do systemu raportowego, który na ich podstawie będzie tworzył raporty historyczne dotyczące połączeń głosowych w systemie, dlatego zmianie podlegać będzie również mechanizm generowania raportów. Wyniesienie przetwarzania logiki dotyczącej połączeń do jednej aplikacji poprawi też wydajność aplikacji, które wcześniej przetwarzały dane o połączeniach. e) Moduł API/CTI Udostępnienie klientom intuicyjnego narzędzia do integracji systemów zewnętrznych z systemem Call-eX Możliwość wielopoziomowego zarządzania parametrami dostępności API zarówno jako ograniczenia dotyczące przydzielania uprawnień do korzystania z metod API konkretnym użytkownikom, jak i zabezpieczenie systemu przed nadużywaniem API poprzez zbyt częste odpytywanie się systemu o dane Narzędzie w postaci intuicyjnego API pozwoli na zaspokojenie potrzeb klientów poprzez integrację z zewnętrznymi aplikacjami np. CRM. Zastosowane mechanizmy reverseproxy oraz throttling pozwolą na wykorzystanie API przez wiele systemów zewnętrznych jednocześnie bez negatywnego wpływu na wydajność systemu. Zastosowanie modułu uprawnień pozwoli na elastyczną konfiguracje punktów styku. Np. styk z systemem zewnętrznym CRM pozwala tylko na wykorzystanie funkcji pobierających dane. Gdy system CRM będzie chciał skorzystać z funkcji zmiany konfiguracji sytemu zostanie poinformowany o braku uprawnień do wywołanej funkcji.
Elastyczne i intuicyjne punkty styku z systemem Call-eX pozwolą również na rozszerzanie funkcjonalności systemu poprzez aplikacje zewnętrzne tworzone przez klientów lub zewnętrznych kontraktorów, co pozwoli organizacji na skupienie się nad rozwojem kluczowych modułów systemu jednocześnie dając możliwość dostosowania się do potrzeb indywidualnych klientów. Nowe API wykonane w technologii RESTful będzie posiadało funkcję niezbędne do zarządzania konfiguracją usługi Call Center oraz funkcje raportowe, które pozwolą na pobranie informacji o aktualnym stanie kolejek i agentów. Styk CTI to moduł działający w trybie publish-subscribe. Aplikacje zewnętrzne, które zapiszą się na otrzymywanie informacji od systemu będą informowane na bieżąco o zdarzeniach, na które się zapisały. Wdrożenie mechanizmu reverse-proxy, które cache uje (zapamiętuje) wyniki odpytań API i w sytuacji gdy zapytania powtarzają się, w krótkim okresie czasu zwraca zapamiętane wyniki bez angażowania API w ponowne pobranie danych i przetworzenie ich na potrzeby wykorzystanej funkcji API. Nowe rozwiązanie będzie korzystać z mechanizmów throttling u, czyli ograniczania dostępu systemów zewnętrznych na wykorzystanie API poprzez parametr maksymalnej ilości odpytań API w okresie czasu (parametry konfigurowalne). Wprowadzenie modułu uprawnień, na podstawie których systemu zewnętrzne będą uwierzytelniane. f) Moduł monitorujący Możliwość szybkiego reagowania na wystąpienie awarii i sytuacje niepożądanych Przyśpieszenie weryfikacji problemów z poprawnym działaniem usług Główną korzyścią płynącą z centralnego systemu logów jest możliwość analizy logów aplikacji, które mogą być rozproszone po różnych maszynach fizycznych bez konieczności udzielania dostępów do wszystkich maszyn. Przyśpiesza to znacząco analizę logów i zabezpiecza system przed niepowołanym dostępem. Dzięki indekserowi logów oraz narzędziu do prezentacji logów proces wyszukiwania, filtrowania logów ograniczy się do wyklikania odpowiednich filtrów zamiast przeszukiwania plików w celu znalezienia odpowiednich wpisów. Możliwe będzie również prześledzenie akcji systemu w logach wszystkich aplikacji bez potrzeby ręcznego wyszukiwania i łączenia wielu plików logów. Wdrożony zostanie centralny system logów logstash z indekseremelasticsearch oraz narzędziem Kibana służącym do prezentacji i wyszukiwania logów. Wdrożony zostanie system monitoringu zabbix, który będzie monitorował krytyczne parametry systemu. System monitoringu dołączony do systemu pozwoli na bardzo dokładne monitorowanie działania aplikacji i reagowanie na sytuacje niepożądane. Dzięki odpowiednim regułom, będzie możliwe powiadomienie administratorów o wykrytej nieprawidłowości, a nawet wykonanie akcji służących do przywrócenia środowiska do stanu prawidłowego.
g) narzędzia do badania wydajności systemu Umożliwianie określania parametrów pojemnościowych systemu (ilość jednoczesnych połączeń, ilość zarejestrowanych użytkowników, ilość aktywnych kolejek Call Center, ilość aktywnych agentów Call Center) po wykonaniu zmian w systemie Monitorowanie zmian parametrów pojemnościowych w zależności od zastosowanej konfiguracji systemu (nagrywanie połączeń, zastosowanie konkretnych kodeków) Umożliwienie przypisania parametrów pojemnościowych do konkretnych parametrów maszyny fizycznej, na której system jest zainstalowany. Główną korzyścią tego narzędzia jest dokładne określenie parametrów maszyny fizycznej(cpu, RAM, dyski) dla pojemności(ilość jednoczesnych połączeń, ilość zarejestrowanych użytkowników, ilość aktywnych kolejek Call Center, ilość aktywnych agentów Call Center) oferowanych klientom. Dodatkowo, monitorowanie wydajności po wprowadzonych zmianach w systemie pozwoli na określenie wąskich gardeł, czyli miejsc w systemie, które powodują największe obciążenie systemu. Możliwość przeprowadzenia testów obciążenia maszyny przez długi okres czasu(24 godziny, tydzień, miesiąc) pozwoli zidentyfikować błędy związane z wyciekami pamięci i określić parametry podzespołów takich jak np. dyski. Do monitorowania wydajności systemu wytworzone zostaną: Nadajnik SIP aplikacja generująca połączenia o określonych parametrach (odstęp pomiędzy nowymi połączeniami, czas rozmów, ilość jednoczesnych połączeń). Odbiornik SIP aplikacja rejestrująca się do systemu i odbierająca połączenia. Połączenie Nadajnika, Odbiornika oraz systemu monitoringu wykorzystania zasobów pozwoli na określenie wartości granicznych dla maszyny fizycznej oraz zastosowanej konfiguracji systemu.