18 Systém podpory řešení provozních problémů a požadavků
Systém Request Tracker (RT) slouží ke koordinaci řešení problémů a požadavků. Umožňuje sledovat vývoj požadavku, zapojit se do jeho řešení a informovat o výsledcích. Jeho základním cílem je informovat skupinu řešící danou problematiku o tom, co její členové pro věc udělali a jaký je aktuální stav. Používáme jej ke koordinaci provozního týmu sítě CESNET2 i k dalším účelům souvisejícím s řešením výzkumného záměru.
18.1 Postup prací
V roce 2002 jsme plánovali přenos databázové části systému na samostatný server. Tento přenos jsme však nemohli uskutečnit pro momentální nedostatek investičních zdrojů. Namísto toho jsme tedy přehodnotili materiálové požadavky projektu a rozhodli se alespoň pro posílení stávajícího serveru.
Konkrétně šlo o doplnění druhého procesoru, resp. o nasazení dvou 800 MHz procesorů namísto jednoho 500 MHz a o doplnění paměti na maximálně možných 512 MB. Původní procesor jsme přidali do vývojové stanice, která by tak mohla v kritickém případě plnit funkci frontendu celého systému a tak znatelně posílit celkový výkon.
Dalšími průběžnými úkoly bylo pokračování v úpravách systému podle požadavků provozu a spolupráce se zahraničními kolegy z této oblasti. Zde se nám například podařilo realizovat převádění veškerého běžně používaného národního kódování zpráv do jednoho interního kódování. Kromě přehlednosti a čitelnosti zasílaných zpráv (jak v poštovním, tak samozřejmě i webovém rozhraní) tak funguje i případné vyhledávání dle obsahu.
Významným krokem na poli mezinárodní spolupráce je naše zapojení do úzkého týmu lokalizátorů systému. V dohledné době se bude možno těšit z češtiny přímo na systémové úrovni RT verze 3 (na WWW rozhraní se příslušný jazyk automaticky volí dle uživatelem nastaveného preferovaného jazyka).
Aktuální vývojová verze systému má drobně pozměněnu správu přístupových práv, má uživatelem definovatelné položky a má pro změnu zastřen stávající systém klíčových slov (tzv. keywords, dříve area). Tato připravovaná změna nám způsobila zpoždění předpokládané migrace starého Trouble Ticket systému. Většinu problémů spjatých s migrací současného provozu jsme nakonec vyřešili (například realizaci operací typu Fix či Description, které se v RT promítnou jako nový typ transakce). Nadále pokračujeme na uzpůsobení potřebného webového rozhraní a vytváření provozních zpráv.
Z provozních důvodů jsme rovněž změnili název serveru na
rt.cesnet.cz a zprovoznili nové certifikáty. Zachovali jsme zpětnou
kompatibilitu odkazů a stará URL, která se vyskytují v dopisech archivního
typu, jsou nadále funkční. Zároveň se podařilo přejít na novější autentizační
subsystém (včetně nalezení problému s nastavováním proměnné
REMOTE_USER, který jsme opravili) a vyzkoušeli jsme získávání
základních autorizačních údajů o uživatelích (včetně správné reprezentace
národního kódování) z LDAP.
Úpravou enhanced_mailgate jsme systém připravili na spolupráci při pokusech s plánovanou autentizovanou e-mailovou korespondencí. Jedním z našich výstupů bylo vypracování nové uživatelské dokumentace RT2. Přínos existence této veřejně dostupné dokumentace používaného systému se rychle zúročil, neboť se nám ozvalo několik dalších zájemců o námi provedené místní úpravy. Obdobná situace nastala ve světě po zveřejnění funkce Forward v novém RT2 v konferenci uživatelů a vývojářů RT.
Následně jsme před vypracováním rozsáhlé a podrobné technické zprávy řešili drobné úkoly, které jsou základními kameny pro finální podobu systému podpory. Především sem patřila konečná implementace automatického zakládání uživatelů při jejich prvotní autentizaci proti CAAS, které dle získaných základních údajů o uživateli z LDAP nastaví příslušné záznamy v RT a definuje novému uživateli alespoň základní přístupová práva. Uživatel tak okamžitě získává možnost vyhledávat a prohlížet v RT veškeré požadavky a komentovat je (či odpovídat žadateli), aniž by nejprve musel požádat správce příslušných front o udělení základních práv. To pochopitelně neznamená, že by se automaticky stal manipulátorem příslušných front.
Otevírá se tak zároveň cesta pro případnou další automatizaci výměny autorizačních informací. Jejich správa zatím závisí na správcích jednotlivých front požadavků (zatím toto řešení postačuje). Vytvořený programový kód jsme rovněž veřejně publikovali, stejně tak jako kód, který nyní umožňuje zobrazovat na výstupní WWW stránce ve výsledcích vyhledávání požadavků klíčová slova (zde je konkrétně nakonfigurována oblast problematiky, resp. Area).
Dalším velmi důležitým krokem bylo úspěšné promítnutí všech našich místních úprav do poslední aktuální stabilní verze RT (konkrétně 2.0.15). Odstranili jsme tak i několik drobných chyb (například dvojí zobrazování požadavků, které jsou již spojeny v jeden) a hlavně jsme získali lepší možnosti aplikace případných oprav chyb nalezených jinými vývojáři v této již dlouhodobě uznávané stabilní verzi. Při slučování verzí jsme zavedli několik nových položek do konfiguračního souboru RT, kterými lze měnit chování vybraných místních úprav.
Při ověřování implementace výše uvedených operací typu Description a Fix jsme přišli na ideální možnost jejich uplatnění při případném požadavku na tvorbu výstupů v podobě FAQ (původně jsme uvažovali o realizaci pomocí klíčových slov, která nenabízela tak jednoduchou možnost úprav a hlavně přehlednost).
Rozhodli jsme nadále stavět na tomto stabilním systému a oddálit přechod na momentálně stále ještě nedokončený systém RT 3 (ačkoli v době psaní tohoto dokumentu již probíhají jeho alfa testy).
S kolegy zabývajícími se bezpečnou infrastrukturou výměny informací mezi řešiteli jsme přehodnotili použití standardu S/MIME ve prospěch standardu PGP (dnes již stejně dobře podporovaného klienty elektronické pošty). Pro volbu tohoto řešení navíc hovoří již zažité používání PGP (popř. GnuPG) mnoha řešiteli, kteří si pravidelně vzájemně podepisují své klíče.
Jako nejvhodnější řešení správy podepsaných klíčů jsme vybrali variantu udržování jejich svazku centrální autentizační autoritou, která tento svazek bude podepsaný předávat systému. RT tak bude moci v konečném důsledku důvěřovat řídicím příkazům vloženým do elektronických zpráv a nepodepsané zprávy bude považovat za prostou uživatelskou korespondenci.
18.2 Dosažené výsledky
Vytvořili jsme technickou zprávu Systém RT v prostředí CESNET, z. s. p. o., která se zabývá současným stavem nasazení systému podpory řešení provozních problémů a konfiguračních požadavků realizovaného pomocí RT, jeho konfigurací a budoucím vývojem. Dokument nejprve zavádí potřebnou oborovou terminologii a popisuje v kapitole Současný stav nasazení RT v síti CESNET2 realizaci a konfiguraci jak serveru, tak klientů. Kapitola Konfigurace systému popisuje úpravy Makefile pro RT a jeho konfiguračního souboru config.pm, úpravy httpd.conf pro WWW rozhraní, úpravy aliases pro rozhraní elektronické pošty a základní služební nastavení crontab. Další část zprávy je malou příručkou do kapsy členěnou podle druhu uživatelů:
- Uživatelská stránka (žadatel)
- Popisuje vznik požadavku, jeho zpracování až po vyřešení.
- Standardní manipulátor (privilegovaný uživatel)
- Podrobně popisuje možnosti zpracování požadavků, jejich vyhledávání, práci se záložkami a vazby mezi požadavky.
- Správce fronty
- Zevrubně dle důležitosti jednotlivých činností popisuje dohled na řešení požadavků, správu manipulátorů fronty a správu klíčových slov.
- Správce systému
- Obsahuje velmi podrobný popis nejdůležitějších a nejčastějších úkonů správce celého systému (vytváření, změny a rušení uživatelských kont, známá omezení uživatelských kont, přidávání nové fronty, rušení nepoužívané fronty, provádění úprav a upgrade).
V nejbližší době dojde k publikaci základních informací o systému RT v internetovém deníku root s možností další spolupráce při detailnějším popisu instalace, konfigurace a provozu této aplikace.
18.3 Plány do budoucna a předpokládaný postup prací
Plánujeme pokračovat v provozu a dalším vývoji tohoto systému. Jako první krok dokončíme migraci trouble ticketů do stávajícího systému podpory a zajistíme možnost tvorby požadovaných zpráv.
Nadále chceme držet krok se světem ve vývoji a testování nového systému RT verze 3 a hodláme vypracovat plán přechodu na tuto verzi.
Chceme rutinně zprovoznit autentizovanou elektronickou poštovní korespondenci s RT systémem prostřednictvím standardu PGP (resp. GnuPG).
Pro zrychlení odezev plánujeme převedení databázové části systému na oddělený databázový server. Ten může zároveň plnit funkci zálohovacího stroje a hot-swap zálohy.
Provedené změny opět promítneme jak do příslušných dokumentací určených pro uživatele, tak v do referenční technické zprávy.
Dovolí-li to naše kapacita, rádi bychom experimentálně otevřeli část systému třetím stranám, což navíc úzce souvisí s výše uvedenou možností generování výstupů typu FAQ.
Rovněž bychom se rádi zabývali otázkami souvisejícími s vyřazováním starých záznamů/požadavků do archivů, aby se urychlilo vyhledávání aktuálních informací.
předchozí |
 obsah |
následující
 |