OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ)

Transkrypt

1 Załącznik nr 1 SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA (OPZ) Wyposażenie centrum utrzymania systemu epuap

2 Spis treści 1. Wprowadzenie Zastosowane skróty i pojęcia Przedmiot zamówienia Cel zamówienia Etapy realizacji Wymagania Wymagania ogólne Wymagania funkcjonalne dla Systemu Monitorowania Wymagania funkcjonalne dla Systemu Monitorowania Bezpieczeństwa Wymagania dla systemu klasy Service Desk Wymagania w zakresie Systemu Wspomagania Zarządzaniem kontami uprzywilejowanymi Wymagania w zakresie urządzeń mobilnych wspomagających użytkowane systemy Wymagania w zakresie odbioru produktu Wymagania w zakresie zarządzania projektem Wymagania w zakresie gwarancji oraz wsparcia na produkty Zakres wdrożenia Wymagania w zakresie dokumentacji str. 2 z 63

3 1. Wprowadzenie 1.1. Zastosowane skróty i pojęcia Pojęcie/skrót Znaczenie.NET Platforma programistyczna opracowana przez Microsoft, 24/7/ godz. na dobę, 7 dni w tygodniu, 365 dni w roku AMOLED Rodzaj matrycy ekranowej. Baza konfiguracji urządzeń lub ich elementów wchodzących w skład Baza CMDB epuap. (analityka biznesowa) jest pojęciem o bardzo szerokim znaczeniu. Najbardziej ogólnie można przedstawić je jako proces przekształcania Business Intelligence danych w informacje, a informacji w wiedzę, która może być wykorzystana do zwiększenia konkurencyjności przedsiębiorstwa. Column Oriented Kolumnowy system zarządzania bazą danych. DBMS Dokument Wiedzowy Dokument Wiedzy zawarty w Bazie Wiedzy Systemu SD. Technologia zapewniająca komunikację pomiędzy obiektami CORBA-Java pracującymi w heterogenicznych (różnorodnych) systemach komputerowych. (ang. Central Processing Unit) urządzenie cyfrowe sekwencyjne, które CPU pobiera dane z pamięci, interpretuje je i wykonuje jako rozkazy. DB2 DB Relacyjna baza danych firmy IBM. (ang. system nazw domenowych) system serwerów, protokół DNS komunikacyjny oraz usługa obsługująca rozproszoną bazę danych adresów sieciowych. Uszczegółowienie, oznacza przejście od obiektów ogólnych do drill down szczegółowych. Każdy zasób logiczny oraz jego właściwości zawarty w ramach epuap Element konfiguracji oraz jego stan zapisany w Bazie konfiguracji. epuap Elektroniczna Platforma Usług Administracji Publicznej platforma, na której za pomocą określonych podstawowych elementów (usług wspólnych platformy), instytucje publiczne udostępniają usługi oparte na elektronicznych kanałach komunikacji ze swoim otoczeniem (w szczególności przedsiębiorcami i obywatelami, ale również z innymi instytucjami publicznymi) poprzez pojedynczy punkt dostępowy w str. 3 z 63

4 Internecie. Flex FTP http HTTPS I/O ICMP IMAP Incydent IP IPS JDBC JMS Zestaw technologi (The Fast Lexical Analyzer). Protokół transferu plików (ang. File Transfer Protocol) protokół komunikacyjny typu klient-serwer. (ang. Hypertext Transfer Protocol protokół przesyłania dokumentów hipertekstowych) protokół sieci WWW (ang. World Wide Web). (ang. HyperText Transfer Protocol Secure) - szyfrowana wersja protokołu HTTP. W przeciwieństwie do komunikacji niezaszyfrowanego tekstu w HTTP klient-serwer, szyfruje go za pomocą protokołu SSL. Urządzenie wejścia-wyjścia. (ang. Internet Control Message Protocol, internetowy protokół komunikatów kontrolnych) opisany w RFC 792 protokół warstwy sieciowej OSI/TCP/IP wykorzystywany w diagnostyce sieci. Pełni przede wszystkim funkcję kontroli transmisji w sieci. To internetowy protokół pocztowy zaprojektowany jako następca POP3. Incydent to każde zdarzenie, które nie jest częścią normalnego działania usługi, które powoduje, lub może powodować przerwę w dostarczaniu usługi, względnie obniżenie jej jakości. Incydent jest spowodowany uszkodzeniem elementu infrastruktury informatycznej. Incydentem jest więc, np. przerwa w działaniu poczty elektronicznej lub spadek wydajności tej usługi poniżej poziomu zagwarantowanego. (ang.: Internet Protocol) protokół komunikacyjny warstwy sieciowej modelu OSI. Rodzaj matrycy ekranowej. (ang. Java DataBase Connectivity - łącze do baz danych w języku Java) - interfejs programowania opracowany w 1996 r. przez Sun Microsystems, umożliwiający niezależnym od platformy aplikacjom napisanym w języku Java porozumiewać się z bazami danych za pomocą języka SQL. Interfejs ten jest odpowiednikiem standardu ODBC opracowanego przez SQL Access Group. Standardowy zestaw interfejsów i modeli przesyłania komunikatów w str. 4 z 63

5 języku programowania Java. JSR168 KPI Kluczowe Wskaźniki Efektywności Linux LogFile MAC MAPI MIB MSSQL OLA Oracle DB Paszportyzacja POP3 PZP RAM RCA RDP, Microsoft Remote Desktop RETINA RFC Specyfikacja portletów jest opracowywana przez Java Community Process i nosi numery JSR-168 i JSR-286. Portlet jest to niezależny komponent stworzony najczęściej w języku Java do umieszczenia na stronie www. (ang. Key Performance Indicators, KPI) finansowe i niefinansowe wskaźniki stosowane jako mierniki w procesach pomiaru stopnia realizacji celów organizacji. Rodzina uniksopodobnych systemów operacyjnych opartych na jądrze Linux. Plik dziennika systemowego, plik zawierający listę występujących zdarzeń. Sprzętowy adres karty sieciowej Ethernet, unikatowy w skali światowej, nadawany przez producenta danej karty podczas produkcji. API opracowane przez Microsoft umożliwiające programom na wysyłanie i odbieranie poczty elektronicznej. (ang. Management Information Base) rodzaj bazy danych wykorzystywanej do zarządzania sprzętem w sieci komunikacyjnej. Relacyjna baza danych firmy Microsoft. Umowa OLA (Operational Level Agreement) opisujących parametry usług wewnętrznych dostarczanych przez jednostki operacyjne. Relacyjna baza danych firmy Oracle. System inwentaryzacji obiektów, opisuje parametry danego elementu między innymi wersja komponentu, nazwa i adres sieciowy, konfiguracja sprzętowa, wersja oprogramowania. Protokół internetowy z warstwy aplikacji pozwalający na odbiór poczty elektronicznej ze zdalnego serwera do lokalnego komputera poprzez połączenie TCP/IP. Ustawa Prawo Zamówień Publicznych (ang. Random Access Memory pamięć o dostępie swobodnym) podstawowy rodzaj pamięci cyfrowej. (ang. Root cause analysis) Jedna z metod rozwiązania problemu. Protokół pozwalający na komunikacje z usługą Terminala Graficznego w Microsoft Windows (Terminal Services). Rodzaj matrycy ekranowej. Zbiór technicznych oraz organizacyjnych dokumentów mających formę memorandum związanych z Internetem oraz sieciami komputerowymi. Każdy z nich ma przypisany unikatowy numer identyfikacyjny, zwykle str. 5 z 63

6 używany przy wszelkich odniesieniach. RMI-Java SD Service Desk SLA SM System Monitorowania SMB System Monitorowania Bezpieczeństwa SMTP SNMP SNMPv1 SNMPv2 SNMPv3 SQLPlus SSH To mechanizm umożliwiający zdalne wywołanie metod obiektów. Obiekty te mogą znajdować się w innych maszynach wirtualnych Javy, które mogą znajdować się na innych komputerach. System klasy Service Desk (IT Service Support Management) wraz z modułami w zakresie: zarządzania incydentami, zarządzania problemami, zarządzania Wiedzą, zarządzania konfiguracją, zarządzanie zmianą, zarządzanie katalogiem usług, zarządzanie poziomem usług IT, zarządzanie dostępnością, zarządzanie realizacją wniosków, zarządzanie portfelem usług, zarządzanie zdarzeniami, zarządzanie Wydaniami i Wdrożeniami. Umowa (Service Level Agreement) opisujących parametry usług pomiędzy klientem i dostawcą. Nazwa na wyspecyfikowany poniżej system monitorowania parametrów ilościowych i jakościowych środowiska. (SIEM - Security Information and Event Management) System monitorujący i raportujący zdarzenia dotyczące naruszenia bezpieczeństwa urządzeń i aplikacji działających w sieci teleinformatycznej. Protokół komunikacyjny opisujący sposób przekazywania poczty elektronicznej w Internecie. (ang. Simple Network Management Protocol) rodzina protokołów sieciowych wykorzystywanych do zarządzania urządzeniami sieciowymi, takimi jak routery, przełączniki, komputery czy centrale telefoniczne. Protokół SNMP w wersji 1, pierwsza wersja, która została opublikowana w 1988 roku; opisany w RFC W tej wersji protokołu bezpieczeństwo oparte jest na tak zwanych communities, które są pewnego rodzaju nieszyfrowanymi hasłami umożliwiającymi zarządzanie urządzeniem. Protokół SNMP w wersji 2, eksperymentalna wersja protokołu, określana także SNMPv2c, opisana w dokumencie RFC 1901 Protokół SNMP w wersji 3 wspierający uwierzytelnianie oraz szyfrowaną komunikację. Terminalowy klient bazy danych Oracle, stanowi on interaktywne narzędzie służące do wykonywania określonych zadań lub zapytań SQL/PL/SQL oraz administracji serwerem baz danych Oracle. (ang. secure shell) to standard protokołów komunikacyjnych używanych w sieciach komputerowych TCP/IP, w architekturze klient-serwer. str. 6 z 63

7 SSL SUDO SZKU System Zarządzania Kontami Uprzywilejowanymi Telnet Testy syntetyczne TruClient Unix URL VMware VNC Web 2.0-Ajax Web Services WebService (ang. Secure Socket Layer), rozwiązanie bezpieczeństwa zaprojektowane pierwotnie przez Netscape Communications, zapewnia poufność i integralność transmisji danych, a także uwierzytelnienie serwera, a niekiedy również klienta. Opiera się na szyfrowaniu asymetrycznym oraz certyfikatach X.509. (ang. switch user do) program stosowany w systemach operacyjnych GNU/Linux, Unix i podobnych, w celu umożliwienia użytkownikom uruchomienia aplikacji, jako inny użytkownik systemu. System Wspomagania Zarządzania Kontami Uprzywilejowanymi w systemach teleinformatycznych. Standard protokołu komunikacyjnego używanego w sieciach komputerowych do obsługi odległego terminala w architekturze klientserwer. Są to takie Testy, których wyniki nie przekładają się w stu procentach na rzeczywiste odczucia wobec badanego urządzenia. Testy takie mają za zadanie ukazać zachowanie systemu w środowisku stricte laboratoryjnym. Uzyskane wyniki są, jak najbardziej zbliżone do maksymalnych (idealnych). Zestaw technologia do testowania. System operacyjny rozwijany od 1969 r. w Bell Labs (UNIX System Laboratories, USL). (ang. Uniform Resource Locator) oznacza ujednolicony format adresowania zasobów (informacji, danych, usług) stosowany w Internecie i w sieciach lokalnych. Firma produkująca oprogramowanie do wirtualizacji, w tym VMware ESX Server - oprogramowanie klasy enterprise dla przedsiębiorstw do tworzenia wirtualnej infrastruktury, opiera się na własnym kernelu oraz konsoli serwisowej. (ang. Virtual Network Computing) system przekazywania obrazu z wirtualnego, bądź fizycznego środowiska graficznego. Technika tworzenia aplikacji internetowych, w której interakcja użytkownika z serwerem odbywa się bez przeładowywania całego dokumentu, w sposób asynchroniczny. Usługa świadczona poprzez sieć telekomunikacyjną, a w tym sieć komputerową, w szczególności przez Internet. Usługa świadczona poprzez sieć telekomunikacyjną, a w tym sieć komputerową, w szczególności przez Internet. str. 7 z 63

8 WebSphere Windows WMI Wniosek WSRP Wykonawca x3270 x5250 Zamawiający Zgłoszenie IBM WebSphere Application Server (WAS) serwer aplikacji JEE oferowany przez firmę IBM. Jest platformą, na której uruchamiane są aplikacje Javy zgodne ze specyfikacją JEE (Java Enterprise Edition) / J2EE. WebSphere Application Server zapewnia szereg usług. Przykładowo połączenia z bazami danych, obsługa wątków, rozkład obciążenia (workload management), które mogą być wykorzystywane przez aplikacje. Rodzina systemów operacyjnych wyprodukowanych przez firmę Microsoft. (ang. Windows Management Instrumentation) zestaw protokołów i rozszerzeń systemu Windows umożliwiających zarządzanie i dostęp do zasobów komputera, takich jak adaptery sieciowe, aktualnie otwarte programy, lista procesów. Formalna propozycja zmiany, która ma być przeprowadzona. Specyfikacja portletów, zdalnych usług web zorientowanych na użytkownika. Podmiot wybrany w wyniku przetargu na systemy Utrzymania epuap, któremu powierzono przygotowanie i wdrożenie systemów wsparcia. Terminalowy klient. Terminalowy klient dla X Windows. Podmiot przygotowujący wdrożenie systemów wspomagania utrzymanie epuap oraz odbiorca przedmiotu dostawy. Rozmowa telefoniczna, , WWW relacja zachodząca pomiędzy użytkownikiem a centrum obsługi użytkowników. Po przez jeden ze zdefiniowanych kanałów komunikacyjnych relacja może zakończyć się zarejestrowaniem wniosku o usługę lub incydentem. str. 8 z 63

9 1.2. Przedmiot zamówienia Przedmiotem zamówienia jest: Dostawa: Przedmiotem dostawy są zarówno elementy sprzętowe, jak i programowe niezbędne do realizacji Przedmiotu Zamówienia: wyposażenie systemu epuap w narzędzie wspomagające proces zarządzania klasy Service Desk zgodnie z ITIL v. 3 lub równoważnym ; dostarczenie tabletów; uzbrojenie epuap w systemy zarządzania oraz monitorowania pod względem parametrów ilościowych i jakościowych oraz pod kątem bezpieczeństwa epuap: o System Monitorowania; o System Monitorowania Bezpieczeństwa; o System Zarządzania Kontami Uprzywilejowanymi. Usługa: Wdrożenie i konfiguracja wyspecyfikowanych systemów w środowisku epuap oraz szkolenia: System klasy Service Desk System Monitorowania; System Monitorowania Bezpieczeństwa; System Zarządzania Kontami Uprzywilejowanymi Cel zamówienia Celem przedmiotu zamówienia jest automatyzacja i optymalizacja procesów wchodzący w zakres utrzymania platformy epuap oraz monitorowanie ich. str. 9 z 63

10 2. Etapy realizacji Zakres prac związanych z przedmiotem zamówienia obejmuje: Etap I: wykonanie Projektu Technicznego implementacji elementów zamówienia do akceptacji Zamawiającego. Etap II: dostarczenie elementów programowych oraz sprzętowych niezbędnych do realizacji Zamówienia; wdrożenie rozwiązań wspierających utrzymanie platformy epuap; testy rozwiązania oraz strojenie. Etap III: przeprowadzenie szkoleń lub dostawa voucherów; wykonanie dokumentacji powykonawczej. str. 10 z 63

11 Uszczegóławiając etapy realizacji, poniżej przedstawiono harmonogram z podziałem na etapy: Ilość Dni Ilość Dni Etap Kamień Milowy Realiza Realizacji Kryterium odbioru cji Kamienia Milowego Etapu 1 MS-1: Zakończenie analizy systemu SM, SMB, SZKU, SD z Wykonawcą oraz dobór urządzeń wsparcia mobilnego. MS-2: Uruchomienie na wybranych źródłach danych SMB, SM. Uruchomienie SZKU dla jednej z grup rodzajowych składowych systemu np. systemy operacyjne. Uruchomienie podstawowych funkcjonalności SD. 30 dni 30 dni 45 dni Zatwierdzenie dokumentu Projekt Techniczny Systemów SM, SMB, SZKU, SD. Zatwierdzony ew. podział projektu na Etapy wdrożenia. Harmonogram w sposób spójny przedstawia zadania wymagane do realizacji Projektu, wraz z przypisaniem odpowiedzialności za ich realizację. Dostarczenie urządzeń wsparcia mobilnego. Systemy dostarczony i wdrożony dla wybranych źródeł danych. System SD wdrożony dla wybranych procesów biznesowych. 2 MS-3: Odbiór Systemów - Faza 1 - Wybrane źródła danych 119 dni 14 dni Zaplanowane podczas analizy funkcjonalności zostały poprawnie wdrożone. Szkolenia przeprowadzone. Odbiór wykonanych prac. MS-4: Odbiór Systemów - Faza 2 - Pozostałe źródła wskazane w projekcie oraz zakres dla SD. 30 dni Zadania/czynności zaplanowane podczas analizy funkcjonalności zostały poprawnie wykonane. Wykonane prace odebrane. MS-5: Strojenie systemów monitorowania oraz SD na potrzeby Zespołu utrzymaniowego 30 dni Zadania/czynności zaplanowane podczas analizy funkcjonalności zostały poprawnie wdrożone. Szkolenia przeprowadzone. Wykonane prace odebrane. MS-6: Rozpoczęcie świadczenia usługi wsparcia Systemu 14 dni Zespół utrzymaniowy przejął opiekę nad systemami. Rozpoczęcie fazy Eksploatacji. 3 MS-7: Odbiór systemów wskazanych w OPZ. 19 dni 5 dni Zadania/czynności zaplanowane podczas analizy funkcjonalności zostały poprawnie wdrożone. Szkolenia przeprowadzone. Wykonane prace odebrane. str. 11 z 63

12 Suma 168 dni Zakończenie wdrożenia oraz odbiór Przedmiotu Zamówienia, nie może się odbyć później niż po 24 tygodniach (168 dniach) od podpisania umowy z Wykonawcą. 3. Wymagania 3.1. Wymagania ogólne ID wymagania WW.01. WW.02. Opis wymagania Wykonawca ma za zadanie przeszkolenie z administracji i utrzymania oraz użytkowania przedmiotu zamówienia. Ilość szkoleń dookreślono w podpunkcie 3.10 Zakres wdrożenia. Dopuszczalne jest przekazanie przez wykonawcę voucherów szkoleniowych do wykorzystania przez zamawiającego w późniejszym terminie. Ważność voucherów nie krótsza niż do 1 roku od podpisania umowy. Wymagane jest dostarczenie przez Wykonawcę sprzętu, nośników oprogramowania, oraz wszystkich licencji niezbędnych do realizacji przedmiotu zamówienia. Przedmiot zamówienia wymieniony w punktach 3.2, 3.3, 3.4 oraz 3.5 a co najmniej, jego centralny komponent musi być rozwiązaniem sprawdzonym globalnie w postaci umieszczenia go np. w raporcie Gartnera Magic Quadrant odpowiednio dla podpunktu: WW for IT Event Correlation and Analysis (lub równoważnym); 3.3 for Security Information and Event Management (lub równoważnym); 3.4 for IT Service Support Management Tools (lub równoważnym); 3.5 for User Administration and Provisioning (lub równoważnym); str. 12 z 63

13 3.2. Wymagania funkcjonalne dla Systemu Monitorowania ID wymagania WSM.01. WSM.02. WSM.03. WSM.04. WSM.05. WSM.06. WSM.07. WSM.08. WSM.09. WSM.10. Opis wymagania SM musi być wyposażony w centralną konsolę, która umożliwi śledzenie bieżącego i historycznego stanu systemów IT Zamawiającego i będzie stanowić warstwę prezentacji. SM musi mieć modułową budowę, która zapewni skalowalność systemu monitorowania bez zmiany jego centralnej architektury. SM musi posiadać konfigurowalne i interaktywne obszary robocze użytkownika, w których możliwe będzie osadzenie portletów wyświetlających dane z monitoringu. Nawigacja pomiędzy obszarami roboczymi ma odbywać się w sposób manualny jak również automatyczny ( pokaz slajdów ). Musi być możliwe wyświetlenie danych z systemu monitorowania w systemie zewnętrznym za pomocą osadzenia specjalnie spreparowanego adresu URL. SM musi oferować geograficzne zobrazowanie elementów monitorowanych. Musi być możliwe osadzenie na mapach Google Earth oraz MS Virtual Earth lub równoważnych, a także na własnym pliku graficznym monitorowanych elementów. SM musi mieć wbudowany silnik raportowy umożliwiający prezentowanie danych z monitoringu w postaci graficznej oraz tabelarycznej. Silnik ma zawierać zestaw predefiniowanych raportów, jak również pozwalać na utworzenie raportów niestandardowych. SM ma oferować zestaw predefiniowanych kluczowych wskaźników wydajności (KPI) a także możliwość tworzenia własnych KPI. SM ma być wyposażony w mechanizm zautomatyzowanej dystrybucji raportów. SM musi posiadać konsolę z widokiem stanu komponentów systemu monitorowanego, prezentującą kluczowe wskaźniki wydajności. Sposób prezentacji danych ma oferować grupowanie wyświetlanych obiektów według ich typu a także warstw, minimum: warstwy logicznej/biznesowej, warstwy aplikacyjnej, warstwy infrastrukturalnej. SM musi zapewniać komunikację do centralnej konsoli, zabezpieczoną za str. 13 z 63

14 pomocą SSL. WSM.11. WSM.12. WSM.13. WSM.14. WSM.15. WSM.16. WSM.17. WSM.18. SM musi zapewniać automatyczną paszportyzację elementów podlegających monitorowaniu (np. serwery) a także automatyczne tworzenie się relacji między nimi. SM musi mieć możliwość generowania alarmów (w tym wywołania sparametryzowanych adresów URL i wysłania trapa SNMP) i powiadomień e- mail a także wykonywania automatycznych akcji w wyniku wygenerowania alarmu (np. uruchomienie skryptu). SM musi mieć możliwość konfigurowania retencji danych dotyczących monitoringu. SM (w szczególności centralna konsola systemu monitorowania) ma pozwolić na oddelegowanie procesu autentykacji do zewnętrznego źródła (np. LDAP) i pozostawienia procesu autoryzacji (zarządzania rolami i uprawnieniami biznesowymi) w systemie monitorowania. SM ma mieć możliwość analizowania ruchu sieciowego związanego z wykorzystaniem aplikacji zamawiającego i monitorowania na tej podstawie rzeczywistego doświadczenia użytkownika końcowego, z uwzględnieniem czasów wykonania transakcji logicznych/biznesowych (np. logowanie, wykonanie funkcji X w module Y) przez danego użytkownika (użytkownicy zewnętrzni jak i wewnętrzni). SM powinien mieć możliwość kontekstowego przełączania się z raportu analizy ruchu doświadczenia rzeczywistego użytkownika, bazującego na analizie ruchu sieciowego, do konkretnego urządzenia sieciowego i wyświetlenia jego stanu. SM musi mieć możliwość monitorowania symulowania syntetycznego użytkownika aplikacji zamawiającego, z uwzględnieniem czasów wykonania transakcji logicznych/biznesowych. Zachowanie syntetycznego użytkownika powinno być nagrane poprzez przechwycenie protokołu komunikacji klientserwer (w tym HTTP, HTTPS, RDP, i inne) i przechowywane w postaci skryptu, który może podlegać dalszej modyfikacji oraz parametryzacji. SM musi zapewniać możliwość bez agentowego monitorowania komponentów logicznych infrastruktury (w tym między innymi: Windows, Linux, Unix, VMware, SNMPv3, baz danych za pomocą JDBC, FTP, WebService, LogFile, WebSphere, DB2 DB, Oracle DB, URL, parametrów środowiskowych udostępnianych przez zdalną konsolę zarządzania serwerem). str. 14 z 63

15 WSM.19. WSM.20. WSM.21. WSM.22. WSM.23. WSM.24. WSM.25. WSM.26. WSM.27. SM musi mieć możliwość definiowania wartości progowych, określania poziomów krytyczności i tworzenia kalendarzy uruchomień dla monitorów. SM musi mieć możliwość skorelowanie wywołań transakcji logicznych/biznesowych, przeprowadzonych przez użytkownika syntetycznego, z wywołaniami poszczególnych funkcji w kodzie aplikacji. SM ma oferować skorelowanie monitoringu infrastruktury z wywołaniami poszczególnych funkcji w kodzie aplikacji. SM musi posiadać centralne repozytorium jednostek konfiguracji, które zawierać będzie wszystkie główne komponenty aplikacji zamawiającego a także relacje między nimi. Repozytorium ma pozwalać na śledzenie zmian w konfiguracji sprzętowo-programowej monitorowanego środowiska. Repozytorium ma być zasilane w sposób automatyczny oraz ręczny (w uzasadnionych przypadkach). SM musi zapewniać możliwość skonfigurowania umów SLA/OLA dla dostępności i wydajności aplikacji zamawiającego. Stan umów ma być wyliczany na podstawie wybranych KPI, reguł propagacji i określonych progów. Okresy śledzenia umów (np. dzień/tydzień/miesiąc) i kalendarze dla umów mają być konfigurowalne (jedna umowa ma mieć możliwość rozliczania według kilku kalendarzy). Wymagana jest możliwość skonfigurowania zaplanowanej cyklicznej oraz jednorazowej przerwy serwisowej dla umowy, która to przerwa nie wpłynie na stan umowy. Wymagana jest także możliwość skonfigurowania przerwy serwisowej po jej faktycznym wystąpieniu i rekalkulacji umowy w celu zmiany jej stanu. SM musi oferować jedną konsolę operacyjną, która będzie udostępniała wszystkie komunikaty o zdarzeniach mających miejsce w środowisku zamawiającego, pochodzących ze wszystkich źródeł monitorowania. SM musi oferować korelację zdarzeń opartą o topologię środowiska zamawiającego i czas wystąpienia zdarzenia, co ma pozwolić na sprawne określenie przyczyny problemu i jego symptomów, a tym samym zmniejszyć liczbę komunikatów w konsoli operacyjnej. SM musi mieć możliwość tworzenia korelacji z poziomu konsoli zdarzeń, na podstawie istniejących zdarzeń w systemie monitorowania. (Zaznaczenie zdarzeń, wybranie modelu i schematu korelacji oraz zapisanie stworzonej zależności do bazy korelacji SM). Korelacje zdarzeń w SM musi obejmować następujące funkcje: str. 15 z 63

16 a) SM musi umożliwiać tworzenie korelacji zdarzeń na bazie zależności istniejących w bazie zarządzania konfiguracją. Działanie tak zdefiniowanych korelacji musi być zależne od relacji, w jakiej są do siebie monitorowane elementy generujące zdarzenia. b) Tworzenie korelacji musi odbywać się za pomocą konsoli graficznej a proces tworzenia zależności korelacyjnych nie może wymagać czynności programistycznych lub pisania skryptów od osób zarządzających narzędziem. WSM.28. WSM.29. WSM.30. Pojedyncza reguła korelacji musi zapewniać korelację zdarzeń z wielu źródeł monitoringu dziedzinowego (np. zdarzenie dotyczące niedostępności serwera oraz usługi jest korelowane ze zdarzeniem dotyczącym niedostępności urządzenia sieciowego). SM musi zapewniać możliwość wersjonowania testów syntetycznych dostępności aplikacji zamawiającego w celu zapewnienia zgodności ze specyfikacją w przypadku wdrażania zmian/nowych wersji. Wszystkie komponenty SM muszą mieć możliwość wykupienia wsparcia danego komponentu (świadczonego w trybie 24/7/365), dającego dostęp do poprawek, uaktualnień, nowych wersji i konsultacji produktowych. Monitorowanie i zarządzanie infrastruktury teleinformatycznej zamawiającego powinno zostać zrealizowane kompleksowo i obejmować warstwy: WSM.31. a) sprzętową; b) aplikacyjną; c) usługową. SM musi obejmować następujące obszary funkcjonalne: WSM.32. a) wizualizację sieci LAN/WAN w warstwie 2 i 3 ISO/OSI, z uwzględnieniem stanu urządzeń, stanu interfejsów i stanu połączeń między urządzeniami; b) stan poszczególnych elementów (urządzeń, połączeń) w sieci LAN/WAN musi być odzwierciedlany w postaci zmiany kolorów tych elementów na mapie oraz w wykazach elementów; str. 16 z 63

17 c) stan poszczególnych komponentów urządzeń sieciowych LAN/WAN (m.in. interfejsów, kart rozszerzeń, wentylatorów, procesora, pamięci) musi być monitorowany; d) monitorowanie wydajności urządzeń sieciowych LAN/WAN; e) zarządzanie zdarzeniami w sieci LAN/WAN; f) raportowanie wydajności urządzeń sieciowych LAN/WAN. WSM.33. WSM.34. SM musi obsługiwać komunikację z urządzeniami LAN/WAN z wykorzystaniem co najmniej protokołów SNMP v1, SNMP v2, SNMP v3, ICMP. SM musi umożliwiać grupowanie urządzeń sieciowych LAN/WAN na podstawie ich atrybutów i wyświetlanie grupy na oddzielnej mapie. WSM.35. SM musi umożliwiać grupowanie interfejsów urządzeń LAN/WAN podstawie ich atrybutów. na WSM.36. WSM.37. WSM.38. WSM.39. WSM.40. WSM.41. WSM.42. SM musi umożliwiać kolekcjonowanie wartości wybranych przez użytkownika zmiennych z bazy MIB urządzeń sieciowych LAN/WAN w celu monitorowania i raportowania. SM musi mieć możliwość rozbudowy architektury o dodatkowe stacje monitorujące urządzenia sieciowe LAN/WAN i skonfigurowanie jednej ze stacji monitorujących jako nadrzędnej, kolekcjonującej topologię sieci i zdarzenia z podlegających jej stacji. SM musi umożliwiać wizualizację aktualnej ścieżki między dwoma dowolnymi punktami sieci LAN/WAN. Architektura aplikacyjna kluczowych komponentów SM-u musi zapewniać wysoką dostępność i w przypadku awarii pojedynczego komponentu, SM musi kontynuować pracę z wykorzystaniem zapasowego lub nadmiarowego komponentu przy zachowaniu wydajności i funkcjonalności. SM musi posiadać interfejs WWW umożliwiający dostęp do pełnej funkcjonalności SM-u oraz zapewniać możliwość konfiguracji SM-u. SM musi umożliwiać synchronizację wykrytej konfiguracji urządzeń LAN/WAN z centralną bazą konfiguracji oraz umożliwiać przekazywanie zdarzeń i incydentów do centralnej konsoli zdarzeń. SM musi obejmować następujące obszary funkcjonalne z wykorzystaniem dedykowanych modułów monitorujących: str. 17 z 63

18 a) monitorowanie systemów operacyjnych pod kątem wpisów w logach, statusu określonych procesów systemowych i metryk wydajnościowych (m.in. obciążenie CPU, RAM, Filesystemy, SWAP, interfejsy sieciowe); b) monitorowaniem platformy wirtualizacyjnej (Vmware) w tym hostów maszyn wirtualnych jaki i centralnych serwerów zarządzających pod kątem wydajności, dostępności (w przypadku Vmware metryki vma); c) monitorowanie aplikacji działających na serwerach pod kątem wpisów w logach, statusu procesów systemowych oraz zasobów systemowych konsumowanych przez aplikację; d) zakres musi być realizowany zarówno za pomocą metody agentowej jak i bezagentowej; WSM.43. WSM.44. WSM.45. WSM.46. WSM.47. WSM.48. WSM.49. Licencja na monitorowany system musi dawać możliwość wyboru metody monitoringu agentowego bądź bezagentowego zarówno w momencie instalacji jak i w dowolnym momencie eksploatacji SM-u. Zmiana metody monitoringu nie może pociągać za sobą konieczności zmiany, migracji bądź dokupowania dodatkowych licencji. W ramach jednej licencji na monitorowany system musi być możliwość korzystania jednocześnie z monitorowania agentowego i bezagentowego. SM musi przekazywać zdarzenia pochodzące z monitorowanych agentowo systemów, serwerów i aplikacji do centralnej konsoli zdarzeń. SM musi umożliwiać korelację komunikatów zarówno po stronie agenta (przetwarzanie rozproszone, w celu zmniejszenia obciążenia i zabezpieczenia przed sztormem komunikatów komponentów centralnych SM-u) jak i centralnie po stronie zarządcy. SM musi umożliwiać wykonanie polecenia na zarządzanym przez agenta serwerze, które zostało wyzwolone automatyczne lub zainicjowane przez użytkownika SM-u w kontekście określonego zdarzenia. W obszarze systemów MS Windows wykonanie polecenia dotyczy między innymi: instalacje i deinstalacje (poprawek systemowych, komponentów aplikacyjnych oraz systemów operacyjnych) oraz uruchomienie zadań na wielu obiektach (np. serwer, element sieciowy) w ramach jednego polecenia. SM musi umożliwiać przeglądanie zdarzeń aktualnych oraz historycznych z wykorzystaniem tego samego, graficznego interfejsu. str. 18 z 63

19 WSM.50. WSM.51. WSM.52. WSM.53. WSM.54. WSM.55. WSM.56. SM musi umożliwiać tworzenie własnych i modyfikowanie predefiniowanych dostarczanych przez oprogramowanie mechanizmów i konfiguracji monitorowania realizowanych przez agentów oraz centralną dystrybucję tych mechanizmów i konfiguracji z zarządcy. SM musi zarządzać wersjonowaniem konfiguracji mechanizmów i schematów monitorowania. SM zdarzeń na serwerach i aplikacjach musi umożliwiać integrację z dedykowanymi systemami zarządzania i monitorowania z wykorzystaniem trapów SNMP, plików logów, poleceń linii komend, mechanizmów WebService czy też informacji udostępnianych w bazie danych. SM musi umożliwiać dla wybranych zdarzeń pochodzących z agentów automatyczne otwieranie i zamykanie incydentów w systemie klasy Service Desk. W przypadku pojawienia się określonego zdarzenia w SM musi być otwarty incydent w systemie Servrice Desk zawierający wszystkie informacje ze zdarzenia. W przypadku zamknięcia incydentu w systemie Service Desk bądź zmiany jego stanu, zmiana ta musi być odzwierciedlona w SM i odwrotnie, zmiana stanu zdarzenia w SM wpływa na stan otwartego incydentu. Centralne repozytorium jednostek konfiguracji SM, musi być zintegrowane z systemem klasy Service Desk, w zakresie wykrywania różnic między aktualną konfigurację infrastruktury teleinformatycznej zamawiającego, przetrzymywaną w centralnym repozytorium, a konfiguracją autoryzowaną, znajdującą się w systemie Service Desk. Wykryte różnice muszą być rejestrowane w systemie Service Desk w postaci incydentu lub zgłoszenia zmiany. Integracja musi być zrealizowana z wykorzystaniem gotowego mechanizmu integracji dostarczanego przez producenta oprogramowania. Konfiguracja monitorowanych elementów (dane dot. jakie usługi i komponenty są zainstalowane i monitorowane na danym systemie operacyjnym) oraz ich wzajemne połączenia (np. Na jakich fizycznych maszynach uruchomione są systemy wirtualne, lub na jakim systemie operacyjnym uruchomione są konkretne instancje bazy danych muszą być automatycznie dodawane do używanego przez Zamawiającego repozytorium oraz automatycznie aktualizowane w przypadku zachodzących zmian na w/w komponentach. Dodane komponenty muszą być automatycznie wiązane(muszą być tworzone relacje) z istniejącymi już komponentami w str. 19 z 63

20 posiadanej przez Zamawiającego bazie. WSM.57. WSM.58. WSM.59. WSM.60. WSM.61. WSM.62. WSM.63. WSM.64. WSM.65. WSM.66. WSM.67. WSM.68. WSM.69. SM musi umożliwiać przesyłanie dowolnych plików pomiędzy zarządzanymi serwerami a zarządcą SM z poziomu zarządcy. SM musi umożliwiać definiowanie progów dla monitorowanych metryk oraz treści i parametrów generowanych komunikatów (alarmów) z poziomu interfejsu graficznego systemu zarządzania, również dla zdarzeń pochodzących z autorskich skryptów. SM musi posiadać zbiór gotowych reguł do monitorowania baz danych. Zbiór gotowych reguł do monitorowania baz danych musi być dostarczony przez producenta rozwiązania oraz uaktualniane w ramach kontraktów wsparcia. Zbiór gotowych reguł do monitorowania baz danych musi posiadać instrukcje pomocnicze i podpowiedzi dla operatora dotyczące możliwości rozwiązania problemu. SM musi umożliwiać monitorowanie baz danych, przy czym nie może tworzyć żadnych nowych obiektów w monitorowanej bazie danych. SM musi posiadać zbiór gotowych reguł do monitorowania środowisk wirtualnych. Zbiór gotowych reguł do monitorowania środowisk wirtualnych musi być dostarczony przez producenta rozwiązania oraz uaktualniane w ramach kontraktów wsparcia. Zbiór gotowych reguł do monitorowania środowisk wirtualnych musi posiadać instrukcje pomocnicze i podpowiedzi dla operatora dotyczące możliwości rozwiązania problemu. SM musi posiadać możliwość wykonywania zdalnych poleceń na zarządzanych serwerach i oglądanie ich rezultatu z poziomu zarządcy systemu monitorowania. SM musi posiadać definiowanie dokładnego czasu (co do minuty, godziny, dnia tygodnia) uruchamiania testów i monitorów z poziomu interfejsu graficznego zarządcy. SM musi posiadać interfejs graficzny do korelacji zdarzeń. Niedopuszczalne jest wykorzystanie skryptów i kodowania do obsługi korelacji. Dane zebrane przez agentów (operacyjnych i wydajnościowych) SM str. 20 z 63