hledat:

5.7  Systém podpory řešení provozních problémů a konfiguračních požadavků

Cílem projektu je vytvoření systému, který bude podporovat řešení provozních problémů, resp. konfiguračních požadavků. Systém bude oficiálním prostředníkem zabezpečujícím výměnu informací jak mezi řešiteli, tak i skupinami a v neposlední fázi rovněž s uživateli sítě TEN-155 CZ.

V současné době je již funkční systém instalován na zkušebních PC a bylo připraveno prostředí pro jeho chod nenarušující vývoj. Upravujeme vzhled a chování uživatelského rozhraní včetně přípravy metodik.

Postup a průběh řešení

Postup řešení byl rozdělen do dvou po sobě následujících fází.

První fáze

• pořízení a instalace první ostré/vývojové stanice - stanovení vhodné konfigurace stanic (resp. serverů) a systému
• příprava dokumentace systému (návod k používání)
• testování první beta verze systému po dokončení instalace
• zajištění zálohování dat systému včetně konfigurace serveru
• vyladění běžného provozu/chování na základě ohlasů od řešitelů
• případné úpravy rozhraní
• příprava statistik a jejich grafických on-line prezentací na WWW
• automatické generování FAQ

Pořízení stanic bylo jinými okolnostmi opožděno. S využitím momentálně dostupné techniky jsme mohli instalovat pouze jednu neostrou stanici v Praze (stroj diana.ten34.ces.net) a shodou okolností druhou v Plzni (stroj lupus.zcu.cz). Na obou strojích typu PC byl instalován operační systém Linux (distribuce Debian) s mírnými odlišnostmi, neboť plzeňský stroj plní primárně jiné funkce.

Na obou strojích byla zprovozněna databázová podpora MySQL včetně příslušných Perl modulů požadovaných k provozu systému Request Tracker (vlastní adaptace systému, který jsme zvolili za nejvhodnější pro daný účel). Následovalo zprovoznění jednotlivých rozhraní (http/apache, e-mail/sendmail/smail, přístup k databázi, ssh atp.) a testování rozličných funkcí systémů.

Po ověření funkčnosti zálohovacího postupu jsme zajistili pravidelné automatické zálohování prostřednictvím služby cron, která vyvolává příslušné zálohovací skripty. Tyto ukládají aktuální transakce a stav databáze včetně důležitých konfiguračních souborů jednotlivých služeb systému na vzdálenou stanici/AFS.

Protože ostrý provoz nemohl začít, nebylo možné jej vyladit ani monitorovat. Přesto již začal vznikat nezávislý modul pro tvorbu statistik na základě údajů dostupných z databáze RT systému. Vývojáři (zatím převážně teoreticky) připravují i možnost určité formy účtování za některé druhy služeb/podpory. Generování FAQ bylo rovněž odloženo, neboť úzce souvisí se změnami rozhraní a metodik, které budou stanoveny až při ostrém náběhu systému.

Později musel být plzeňský stroj uvolněn a tak jsme systém pokusně přenesli na jiný systém (opět starší PC Intel Pentium), kde je nadále provozován a přístupný například prostřednictvím adresy http://rt.zcu.cz/rt.cgi, či základní brána prostřednictvím elektronické pošty na adrese rt@service.zcu.cz. V systému již bylo provedeno mnoho drobných úprav specifických zdejšímu prostředí, které jsou zaznamenány v systému správy verzí CVS, takže lze jednoduše tyto změny aplikovat do budoucích verzí (jak se již několikrát během tohoto roku stalo).

Druhá fáze

• sledování toků dat a návrh distribuce částí systému
• ladění instalace na dalších navržený místech
• zabudování bezpečnějšího ověřování přístupu k systému
• vazba na adresářové služby LDAP
• průběžná aktualizace dokumentace a komplexní prezentace systému

Všechny úkoly druhé fáze zůstávají dosud nedotčeny - budou následovat po dokončení první fáze. Výjimkou je vazba na adresářové služby, která není příliš časově vázána na stav vývoje tohoto projektu (může ovlivnit pouze způsob práce se systémem/dokumentaci), ale je vázána na další projekty TEN-155 CZ. S tím úzce souvisí případné silnější zabezpečení komunikace se systémem včetně maximálního zjednodušení pro uživatele.

Dosažené výsledky

Byly zkoumány i fyzicky testovány rozličné existujícící imlementace systémů obdobného určení (například Bugzilla, KeyStone, Sun Solstice Enterprise, HP OpenView, GNU GNATS) včetně souvisejících doporučení (např. RFC 1297 či elektronické konference vývojářů výše uvedených systémů).

Výsledkem byl výběr systému Request Tracker, který několik let stabilně funguje a ačkoli je volně dostupný, má díky své modulární otevřené stavbě zajištěn rozvoj a podporu ze strany široké internetovské komunity. Kromě možnosti provádět vlastní úpravy systému samého je hlavní předností před ostatními systémy jeho rozhraní neomezené jen na WWW. Se systémem lze plnohodnotně komunikovat i přes e-mail či příkazovou řádku.

Silná komunita vývojářů rozprostřených po celém světě poskytuje téměř okamžitou odezvu při řešení souvisejících změn či drobných opravách vyvíjených verzí. To se u ostatních komerčních systémů stává prakticky nedosažitelným.

Z důvodů dočasné nedostupnosti finančních zdrojů na pořízení potřebných základních prostředků pro ostrý stabilní provoz systému jsme zvolili alternativní postup, a to zprovoznění prozatímního (testovacího) systému na zapůjčeném zařízení PC Intel Pentium/90MHz. Souběžně byl experimentálně zprovozněn shodný systém v Centru informatizace a výpočetní techniky na Západočeské univerzitě v Plzni na PC Intel Pentium II/300MHz. Získali jsme tak zkušenosti s konfigurováním systému a jeho technickými nároky pro reálný provoz.

Experimentální provoz v Plzni přešel postupně v ostrý (viz obrázek 5.16 znázorňující jednu z pracovních obrazovek).

Přínosy stávajícího provozu:

• vypracování alespoň základní dokumentace v českém jazyce (příklad je dostupný na adrese http://support.zcu.cz/rt/dokumentace/navod.html)
• ověření způsobu zálohování/obnovení systému
• úspěšný rychlý transparentní přenos na jiná zařízení (řádově 4 hodiny)
• z provozu vzešly další podněty k úpravám systému - například změna autentizačních mechanismů WWW rozhraní (nyní se využívá jen jedné cookie s platností 6 měsíců obsahující příslušný MD5 autentifikátor) či zjednodušení e-mail komunikace (vychází se z unikátnosti e-mail adresy, takže není nutné využívat pomocné autentizační příkazy zavedené původním systémem)
• úpravy se díky aktivní spolupráci s návrháři projektu Request Tracker postupně dostávají k ostatním uživatelům a vývojářům doslova na celém světě.

Pro další vývoj jsme připravili testovací vývojové prostředí, aby případné pokusy nemohly narušit ostrý chod systému.

Shrnutí a plán dalších prací v roce 2000

Realizace hlavní části projektu proběhne v následujícím roce s využitím všech dosud získaných podkladů pro zprovoznění. Konkrétnější plán prací je následovný:

Připravíme ostrý rutinní provoz systému podpory (zahrnuje stanovení metodik, sepsání příslušných předpisů/dokumentace, postupné začlenění všech řešitelských skupin) na serveru umístěném v Praze. Rozhraní budeme upravovat na základě praktických zkušeností na vývojové stanici umístěné v Plzni a případně následně pozměníme pracovní postupy. Převážná část komunikace z mail-listů se následně vhodně separuje.

Navrhneme řešení pro distribuovaný provoz systému - zřízení serverů v dalších lokalitách pro případný off-line provoz. Připravíme automatickou tvorbu FAQ pro uživatele a spolupráci s autentizačními autoritami používanými řešiteli (využití LDAP atp.).

Zajistíme zálohování systému i dat prostřednictvím AFS nebo přímo prostřednictvím Networkeru na zálohovací roboty (v návaznosti na projekt MetaCentrum).

Plánujeme provázání stávajících trouble ticket systémů a management stanic s tímto systémem, což zahrnuje i přechod celého síťového operačního centra CESNET, z. s. p. o. na tento systém.

předchozí

obsah

následující