Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
IDENTIFIKACE APLIKACE
Název aplikce
Zkratka názvu aplikace
Jméno projektového managera
správce aplikace
administrátor aplikace
administrátor databáze
administrátor operačního systému
administrátor sítí
administrátor monitoringu
řešitelská skupina SD
Protokol o převzetí aplikace do podpory ICT ZÁVĚREČNÝ KROK Z PROJEKTOVÉ KANCELŘE DO PROVOZU OTP/OKP
Identifikace aplikace Název - zkratka projektu / aplikace
Datum verze předávacího protokolu
Zadavatel IT garant Kontakt na dodavatele, který zajišťuje
Odborný úsek support - dle supportní smlouvy.
Informace o O dborný garant=vlastník
dodavateli V rámci Incident managmentu musí být stanoven způsob podpory se Service Deskem.
Dodavate l
Nutná dokumentace Zástupce dodavatele
pro odbor Smlouva o dílo/Supportní smlouva
Dodatek ke smlouvě
klientské podpory
Uživatelská příručka
Definice podpory z pohledu Service Desku
Nutná dokumentace Administrátorská příručka, provoz ní
pro odbor dok u m e n tace
dle administrátorské osnovy
technické podpory Datový model
Instalační návody
Školení pro Uživatelská školení
odbor klientské podpory pro Lokální správce
Školení pro Administrátorské školení = správci
odbor technické podpory a pl i k a ce
Jiná školení
Datum Bet at est
testování Pilotní provoz
Zátěžový test
O strý provoz
VPN - Oddělení správy sítí provedeno ANO/NE 1 Společné zásady pro povolení a rušení přístupu
provedeno ANO/NE
Zrušení projektových přístupů Kerberos - oddělení správy unixových provedeno ANO/NE 1.1.1 Povolování přístupu
externích pracovníků do produkčního sy st émů NEPŘIDĚLUJÍ SE 1) Účty se zakládají pouze na základě Servisního požadavku.
doména Microsoft Windows - Oddělení provedeno ANO/NE
prostředí aplikací správy Microsoft systémů 2) Založení účtu pro oprávněnou osobu může požadovat:
• Projektový vedoucí – pro externí pracovníky po dobu trvání projektu
Oracle a databázové účty s právy • Manager L3 správy aplikace – pro aplikace převzaté do provozu
administrace dB - administátor databáze • Garant suportové smlouvy – pro externí pracovníky zajišťující support
Servisní účty aplikací - aplikační • Ředitel OTP nebo náměstek ÚICT VZP ČR – ve všech případech
administrátor aplikace
3) V servisním požadavku musí být uvedeno, k jakému účelu bude účet používán.
Žádost o supportní přístupy dodává vlastník supportní smlouvy aplikačního SW = OKP 4) Jedná-li se o přístup pro externího pracovníka, musí být v servisním požadavku uvedeno pro jakou firmu se účet zřizuje a jméno pracovníka externí firmy, který bude účet používat.
5) V servisním požadavku musí být uvedeno po jakou dobu, má být účet platný.
Žádost o supportní přístupy dodává vlastník supportní smlouvy technologických celků = OTP
6) Servisní požadavek musí být odsouhlasen schvalovatelem - pracovníkem zodpovědným za bezpečnost informačních technologií VZP ČR.
VPN - Oddělení správy sítí provedeno ANO/NE 7) Následné fyzické přidělení přístupu a zdokumentování tohoto aktu v provozním deníku OTP provádí vždy přidělovatel za příslušnou oblast (VPN, MS doména, Kerberos).
Kerberos - oddělení správy unixových
sy st émů provedeno ANO/NE
doména Microsoft Windows - Oddělení
Zřízení neaktivních supportních
přístupů externích pracovníků do správy Microsoft systémů provedeno ANO/NE
produkčního prostředí aplikace
Oracle a databázové účty s právy standardně nejsou zakládány. Pouze na vyžádání supportní podpory v rámci řešení
administrace dB - db administátor IM s prio 1
Servisní účty aplikací - aplikační
administrátor aplikace provedeno ANO/NE
Aplikaci předal do provozu, dne: Mgr. Jaroslav Bogač, MBA 1.1.2 Rušení přístupů
Souhlas ředitele odboru architektury, vývoje aplikací a řízení změn, dne: Ctibor Legát 1) Po uplynutí doby platnosti, která byla požadována v servisním požadavku, bude účet zablokován.
Aplikaci převzal do provozu za OKP, dne: Ing. Roman Palkovič 2) V případě, že pomine důvod používání účtu před uplynutím doby jeho platnosti nebo tato situace nastane u účtu s neomezenou dobou platnosti, je povinností žadatele požádat servisním požadavkem o zrušení účtu/přístupu, aby mohl být udržen konzistentní stav, který vyhovuje auditovaným požadavkům na bezpečnost informačního systému.
Aplikaci převzal do provozu za OTP, dne: 3) Při předávání projektu/aplikace do provozu (standardní interní proces VZP ČR mezi ORP a OTP) budou všechny přístupy externích pracovníků do produkčního prostředí této aplikace zablokovány. Budou zároveň změněna všechna hesla „superuživatelských“ účtů. Jedná se zejména o unixový účet oracle a databázové účty s právy administrace dB.
4) Tato operace bude provedena a zaznamenána v provozním deníku příslušným přidělovatelem.
Okruhy informací pro zpracování administrátorské dokumentace
A. Popis systému
1. Přehledový popis architektury aplikace, vč. diagramů a schémat.
2. Popis aplikační logiky, použité objekty (tabulky, fronty) - k čemu slouží, jak jsou procesně navázány, odkud kam co putuje, co se kde loguje - které jsou administrátoři
3. Způsob implementace aplikace do prostředí VZP včetně popisu konkrétního řešení.
B. Popis technologie a infrastruktury
1. Rozbor všech objektů na úrovni technologie a infrastruktury.
2. Specifikace a seznam strojů, na něž byla/má být aplikace implementována.
3. Přesná specifikace operačního systému, v případě implementace do prostředí VZP uvést zdrojový image (včetně data instalace), na němž bylo postaveno (pokud
4. Seznam nasazených/vyžadovaných patchů proti standardnímu image VZP.
5. Seznam všech unixových účtů (dle strojů), jež aplikace vyžaduje.
6. Seznam všech komponent (a systémů), které musí pro správný chod aplikace současně běžet (včetně komponent FailOver). Startovací parametry těchto prostředí pro
7. V případě clusterového řešení seznam nodů, jejich funkce, umístění, postupy pro start a stop clusteru, přepnutí do druhé lokality, popis nutných skriptů, kompletní
8. Specifikace aplikačních komunikačních toků včetně způsobu autentizace/autorizace mezi unix uživateli a stroji, na nichž je aplikace implementována.
9. Seznam doplňkového SW (SW mimo standardní image), jež aplikace vyžaduje (tj. seznam všeho, co bylo instalováno mimo adresáře dedikované aplikaci)
10. Pro doplňkový SW způsob administrace, zálohování, monitoringu funkčnosti, pokud není součástí popisu aplikace.
11. Popis adresářů dedikovaných aplikaci a popis jejich obsahu, přístupová práva.
12. Přehled souborových vstupů/výstupů.
13. Specifikace nároků na datová úložiště – aktuální a s predikcí v horizontu 5 let.
14. Přesná specifikace databázového systému a souvisejícího software (aplikačních serverů…), seznam konfiguračních souborů, jejich proměnných a možných hodnot.
15. Popis a schémata DB instancí (tablespace, tabulky, indexy, uživatelé, role…).
16. Požadované LAN, WAN, SAN spojení.
C. Administrativní nástroje
1. Uvést popis administrativních nástrojů, specifických pro aplikaci. Pokud existuje v aplikaci sekce pro administrátory, podrobný popis funkcionality (je možné nahradit
2. Uvést odkaz na standardní administrativní nástroje určené ke správě aplikace.
3. Uvést popis akcí, prováděných administrátorem (start/stop systému, maintenance aplikace…) včetně nutných omezení s ohledem na vazby na okolí.
D. Diagnostika a monitoring
1. Seznam logových souborů - důležité (klíčové) logy aplikačních činností zdůraznit.
2. Výčet takových kritických objektů, které je potřeba umět zkontrolovat (tj. jak, čím apod.) a umět na nich identifikovat problém (tj. proč).
3. Seznam pracovních oblastí, kde může docházet k nárůstu dat a zaplnění filesystémů.
4. Návod, jak ověřit zdraví aplikace a její funkčnost např. podle následujícího schématu:
i. Podívejte se tam a tam jestli to vypadá tak a tak - definovat co je běžný stav a co indikuje problém.
ii. Sepsat doporučené postupy, jak řešit problémy tj. zastavte to a to, udělejte to a to a zase to nastartujte tak a tak a ověřte, že je to ve stavu
tom a tom
iii. Uvést jaké množství logů, front, generovaných souborů v jednotlivých filesystémech, plnění pracovních oblastí je ještě v normálu a kdy už
je systém přetížen (nestíhá).
iv. Standardní DB a OS procesy – aby se dalo odlišit, jestli je db v klidu nebo na ní někdo pracuje (z pohledu aplikace, ne standardní procesy DB
instance – aby bylo jasné, co je běžná aktivita na pozadí a co je spuštěná akce kterou není radno přerušit).
5. Popis ověření funkčnosti integračních vazeb na ostatní aplikace.
E. Pravidelná údržba a profylaxe, upgrade a nasazování patchů
1. Doporučení profylaktických aktivit a jejich časového režimu (jak sledovat logy apod).
2. Doporučené intervaly/termíny odstávky pro upgrady, patchování systému.
3. Doporučený interval rebootu.
F. Typické chybové stavy a jejich popis nejčastějších nebo nejzávažnějších chybových stavů s výstižným popisem jejich identifikace, doporučený postup řešení.
G. Zálohování a obnovení
1. Požadavky na zálohování a archivaci dat:
i. periodicita
ii. kapacita aktuální a s predikcí v horizontu 5 let.
2. Použité specifické zálohovací nástroje, podrobný popis použití a nastavení.
3. Uvést odkaz na použité standardní zálohovací nástroje.
4. Recovery plán pro kompletní zálohu a obnovu prostředí a dat.
H. Integrace
1. Popis komunikačních a datových toků.
2. Popis integračních vazeb s ostatními aplikacemi, komunikace s integrační platformou, popis souvisejících BPEL procesů…
I. Monitoring
1. Popis monitoringu.
2. Doporučení, které procesy mají být monitorovány a jakým způsobem.
3. Popis vazeb na dohledové nástroje a seznam monitorovaných událostí a stavů.