Aktualizace v r. 2022
Původní odpověď vznikala v době, kdy ještě nebyly standardem virtuální servery, cloudy a samozřejmostí vzdálená správa. K serverům se chodilo a to nejenom, když zkolaboval nějaký HW.
V roce 2022 už je pohled na infrastrukturu velmi odlišný. Pokud nejste skutečně velká organizace, nedává plnohodnotný server smysl. Náklady na jeho provoz jsou výrazně vyšší, než pronájem serveru i se službami jeho správy.
Původní otázka na provozní deník se proto dnes týká takřka výhradně specializovaných firem. A pohled na potřeby dokumentace zásadně ovlivnily i automatické aktualizace a monitoring přímo v Linxu (příp. Windows serveru.)
Efektivní provozní deník by aktuálně měl mít formu systému hlídajícího plánované úkony (typicky kontroly), sledující rizika a vyhodnocující data z provozu (event monitoring), na které budou reagovat upozornění, co zkontrolovat mimo plán. Dokumentace všech zásahů bude vznikat ve formě záznamů přímo v systému.
Větší společnosti na to používají specializované dohledové systémy, které výše popsanou logiku implementují.
Jednou z možností, jak si hlídat všechny kroky správy, je systém AyMINE, který není zaměřen výhradně na IT, takže stejný přístup správy aplikuje na veškerou techniku firmy. Jeho logika sledování ukazuje, kam směřují i doporučení současných standardů, zejména ISO 20000 a ITIL.
- Plánované úkony – stanovené na základě metodiky i analýzy rizik
- Plánované kontroly – definovat na základě potřeby zajistit spolehlivost a dostupnost služby
- Řízení rizik – evidence a sledování rizik, které se sledovaným zařízením souvisí
- Řešení problémů – zaznamenání problému a řízení jeho vyhodnocení
Jak ukazuje příklad z AyMINE, tradiční provozní deník nahrazuje systém řízení, který klade důraz na to, aby se práce věnovala předcházení problémů a jejich řešení. Deník, který by zaznamenával úkony, sice existuje v sytému také, ale je automatickým produktem činností, které jsou systémem řízeny.
Proč je ISO 20000 relevantní
Server ale obecně jakákoli technika ve firmě je nástrojem pro poskytování služby. Péče o techniku musí být proto v souladu s potřebami služby samotné. Standard ISO 20000 definuje pravidla, jak požadavky na službu stanovit, a od nich se budou odvíjet i požadavky na zajištění dostupnosti, spolehlivosti a dalších záruk pro každou užívanou techniku.
Díky standardu ISO 20000 by organizace měla mít systém řízení služeb, které umožní i definovat, jaká rizika hrozí z výpadku techniky, a kolik se vyplatí investovat do předcházení riziku.
Původní odpověď
Standardy samozřejmě můžeme využít (třeba ITIL, CobIT), ale za podstatný považuji účel provozního deníku. Jako každá evidence, má provozní deník smysl pouze pokud je jasné, k čemu slouží. Od toho se také musí odvíjet kým je vytvářena a jaké obsahuje informace. Teprve na třetím místě se bavme o formě evidence.
Účel provozního deníku
Typickým účelem evidence je protokolování, co se se serverem stalo proto, aby se v případě vzniklých problémů dalo snadno dohledat, co může být příčinou a snadněji tuto příčinu odstranit. Často uváděný bezpečnostní důvod („aby se vědělo, kdo tam co udělal“) má smysl pouze pro automaticky generované logy, které nelze vypnout a obejít. Pro ručně vytvářený deník je tento bezpečnostní důvod nesmyslný – nikdo přece nezaznamená, že vymazal či změnil databázi, když to dělat neměl.
Druhým, pravděpodobně ještě častějším důvodem deníku je audit. Firma (interní auditor) vedoucí příslušného oddělení (např. CIO) potřebuje mít nástroj, jak kontrolovat, jestli jsou dodržovány dohodnuté pracovní postupy typu kontrol, zálohování, aktualizací atd. Někdy to dělá díky vlastní pečlivosti, častěji proto, že nemá úplně důvěru k administrátorům, někdy i z obav, jestli je všechno v pořádku. Úplně nejčastěji to ale dělá proto, že to požadují zákazníci nebo externí pravidla jako např. standard SOX. Pokud je toto důvodem vedení deníku, je pochopitelně třeba formu i obsah přizpůsobit externím požadavkům, které jeho vedení určují.
Obsah deníku
Obsah deníku je pochopitelně určen jeho účelem. Vycházím z předpokladu, že deník musí být co nejjednodušší, aby zbytečně nezdržoval, ale současně musí plnit svůj účel, za který považuji poskytování přehledu, kdo, kdy kde, s čím, co a proč dělal:
Kdo – osoba (administrátor), vzdálený skript apod.
Kdy – datum a čas, často se hodí čas začátku i konce
Kde – pokud se deník vede společně pro více serverů, tak samozřejmě evidence serveru (např. virtuálního, apod.)
S čím – Aplikace, modul, knihovna, aplikační server – prostě jednotka, která byla předmětem administračního zásahu. Důležité je pamatovat na to, že zvláště produkční servery obsahují často řadu stejných instancí (např. web servery různých zákazníků, více print serverů apod.) a je třeba identifikovat, jestli byl zásah prováděn se všemi nebo pouze s jedním s tedy s kterým
Co – Prováděná aktivita. Mnohé z aktivit jsou anebo by alespoň měly být administrátorskými zásahy definovanými nějakými pracovními postupy. V položce Co pak je pouze odkaz na daný postup. Pak samozřejmě přibude ještě nepovinné pole poznámka, kam se píšou proměnné daného procesu, pokud jsou (parametry, instance apod.) nebo výjimky, pokud nastaly.
Je třeba ale pamatovat na to, že vždy se vyskytnou případy, kdy je třeba dělat i činnosti žádným procesem nepopsané. Je třeba mí možnost zaznamenat i tyto činnosti a záznam to musí podporovat. Míra podrobnosti popisu takové mimořádné činnosti samozřejmě plně závisí na požadavcích, které jsou na evidenci kladené.
Proč – Velmi důležitá a kupodivu často zapomínaná položka, která identifikuje, z jakého důvodu vůbec byl administrátorský zásah prováděn. Šlo o chybu, upgrade, pravidelnou činnost nebo něco jiného? Pokud má firma jiný systém pro sledování tasků (úkolů), chyb nebo požadavků, většinou postačí odkaz do této evidence.
Forma
Forma deníku bývá různá a závisí na možnostech a vybavení příslušné organizace. Někde postačí jednoduchý deník ve formě tabulky v tabulkovém editoru, jinde mají webovou aplikaci, větší firmy mívají některou z aplikací pro System Maanagement, které deníky podporují. Pokud organizace provozuje některé z řešení pro dálkovou správu a monitoring svých systémů, je vždy vhodné, aby byl deník veden podle pravidel daného systému, protože jinak by vznikala duplicitní, neprovázaná a tedy vzájemně nevyužitelná evidence. Ale popravdě řečeno, firmy s takovými systémy už mají své evidence dávno zavedené, ale potřebují mnohem detailnější pomoc.
Příklady provozního deníku
Příklad provozního deníku si lze stáhnout ve formátu OpenOffice.