Wizja centralnej bazy zarządzającej zgłoszeniami od użytkowników nie musi być tylko wyimaginowanym ideałem, który znamy raczej z opowieści od kolegów z korporacji. Wprowadzając zasadę dotyczącą zgłoszeń, mówiącą o konieczności zgłaszania poprzez telefon wyłącznie sytuacji krytycznych, możemy zdyscyplinować użytkowników tak, aby w pozostałych przypadkach korzystali z formy elektronicznej. Korzyścią dla użytkownika jest przede wszystkim możliwość śledzenia, kto rozwiązuje problem i na jakim etapie jest proces jego usunięcia, a także czy w ogóle ktoś zaczął nad problemem pracować. Ponadto po zgłoszeniu pozostaje ślad po stronie użytkownika, jak i po stronie działu IT.

Jednym z narzędzi, które można zastosować do takich zadań, jest Request Tracker. To chyba najbardziej znany i ceniony system do zarządzania zgłoszeniami typu ticket-tracking (dosłowne tłumaczenie: śledzenie biletów). Śledzi on status zgłoszenia od rejestracji jego wpłynięcia do ostatecznego określenia rozwiązania i zamknięcia. Wszystkie stany zgłoszenia opieczętowuje opisem, sygnaturą czasu, oznaczeniem osoby zgłaszającej i obsługującej, a także czasem rozwiązania poszczególnych etapów. Na koniec administrator ma możliwość prześledzić, ile czasu zajęło rozwiązanie problemu, a także jaki był rzeczywisty koszt działań. Co ważne, użytkownik może również śledzić swoje zgłoszenia i korespondować w ramach poszczególnych "ticketów" z administratorem, a Request Tracker (RT) będzie aktualizował automatycznie zgłoszenie i "podpinał" wymianę wiadomości pod odpowiedni numer zlecenia.

System (nie)wymagający

Request Tracker powstał w 1996 roku w celu koordynacji zadań pomiędzy wieloma użytkownikami. Napisany w Perlu przez Jesse Vincenta, jest rozwijany do dzisiaj. Aplikację dystrybuuje obecnie, na zasadach licencji GNU General Public License (GPL) w wersji 2.0, firma Best Practical Solutions LLC, którą założył twórca.

RT to system webowy, pozwalający na obsługę jednocześnie użytkowników autoryzowanych (nazwanych) oraz publicznych, zgłaszających problemy na zasadzie prawa gościa. Jego głównymi zaletami są prostota obsługi, przejrzystość interfejsu i szybkość działania, jak również otwartość kodu i licencji, przez co może skorzystać z niego praktycznie każda organizacja, bez względu na wielkość i zasobność budżetu na inwestycje IT. Do działania systemu RT potrzebujemy platformy Linux, bazy danych MySQL lub PostgreSQL (konfiguracja portalu RT oraz przechowywanie ticketów wraz z historią), Apache'a (serwer aplikacji WWW), Fetchmaila (będzie pobierał
e-maile z zewnętrznego serwera poczty) oraz Postfiksa (do wysłania e-maili z systemu).

Scenariusz działania systemu jest następujący. Maszyna wirtualna lub fizyczna z Request Trackerem będzie dostępna dla użytkowników sieci wewnętrznej poprzez Apache'a 2. RT może znajdować się w segmencie wraz z innymi serwerami, udostępniającymi aplikacje intranetowe. Jeżeli mamy serwer e-mail, wystarczy wykorzystać wysyłkę maili z maszyny RT za pomocą Postfiksa, a wiadomości przychodzące mogą być pobierane ze skrzynek dedykowanych dla odpowiednich kolejek zgłoszeń na obecnym serwerze poczty (cyklicznie, za pomocą aplikacji Fetchmail). W artykule odnosić się będziemy do dystrybucji Debian 5 Lenny w wersji Netinstall.

Instalujemy RT-eka

W pierwszej kolejności zainstalujmy kilka pakietów, które będą nam potrzebne do uruchomienia całego systemu.

[...]

Autor jest wieloletnim menedżerem Działu Integracji Systemów. Obecnie jest audytorem bezpieczeństwa systemów sieciowych oraz trenerem kadr IT w sektorze administracji publicznej. Specjalizuje się w zabezpieczeniach systemów i aplikacji oraz projektowaniu wielopoziomowych rozwiązań bezpieczeństwa.