Слайд 3
Why are they important?
Track all events, failures and
issues
Focal point for help desk communication
Use it to track
all communications
Both internal and external
Events originating from the outside:
customer complaints
Events originating from the inside:
System outages (direct or indirect)
Planned maintenance, upgrades, etc.
Слайд 4
Use ticket system to follow each case, including
internal communication between technicians
Each case is assigned a case
number
Each case goes through a similar life cycle:
New
Open
...
Resolved
Closed
Слайд 5
Help Request with Tickets
Ticket System
Helpdesk Tech
Eqpt
----------------------------------------------------------------
T T T T
query | | | |
from ---->| | | |
customer |--- request --->| | |
<- ack. -- | | | |
| |<-- comm --> | |
| | |- fix issue -> eqpt
| |<- report fix -| |
customer <-|<-- respond ----| | |
| | | |
Слайд 6
RT
Heavily used worldwide.
Can be customized to
your location.
Somewhat difficult to install and configure.
Handles large-scale operations.
trac
A
hybrid system that includes a wiki and project management features.
Ticketing system not as robust as rt, but works well for web-only ticket interface.
Often used for ”trac”king group projects.
Used for this course:
http://noc.ws.nsrc.org/wiki/
Слайд 7
Bugzilla
http://www.bugzilla.org/
Cerberus
http://www.cerberusweb.com/
eTicket
http://www.eticketsupport.com/
itracker
http://www.itracker.org/
Jutda Helpdesk
http://www.jutdahelpdesk.com/
Mystic
http://www.hulihanapplications.com/projects/mystic
OTRS (Open source Ticket
Request System)
http://otrs.org/
osTicket
http://osticket.com/
Simple Ticket
http://www.simpleticket.net/
Trouble Ticket Express
http://www.troubleticketexpress.com/open-source-software.html
Слайд 8
RT: Request Tracker
http://bestpractical.com/rt/
Слайд 10
Why do we use the term “ticket”?
In order
to resolve a problem...
Who wants what?
Who's going to work
on this?
When did they ask, when was it done?
How much time did it take (billing, hours)?
What's left to do?
Everything is summarized and presented in a simple and intuitive manner.
Слайд 11
User support
Security problem management
Issue Tracking / Incident Management
Слайд 12
Several interfaces
Web, CLI, e-mail, etc.
Multiuser
At different levels: admin,
general user, guest
Authentication and authorization
Event history
Handles dependencies
Notifications
Слайд 13
Register an event (i.e., ticket creation)
Assign an owner
Assign
interested parties
Maintain change history
Inform interested parties of each change
Initiative
activities based on status or priority
Слайд 14
Lots of email traffic requesting help, request for
services, etc.
Archived as text without classification
Very difficult to find
current status or problem history.
Sometimes problems were forgotten or never resolved.
Слайд 15
Open source and free
Heavily used and tested
Very active
development
Flexible
Web interface or control via email
Слайд 16
A bit tricky to install the first time...
It's
powerful, so you'll need to spend some time learning
how it works.
Most distributions have packages that make installation a bit easier:
Red Hat, Fedora, SuSE, Debian, Ubuntu, FreeBSD, etc.
Слайд 17
RT allows you to create queues so that
problems are classified by type:
Services: DNS, IP addresses, Radius,
LDAP
Connectivity: Communications infrastructure problems
Security: Attacks, scans, abuse, etc.
Systems: Email accounts, passwords, etc
General help
Слайд 18
Two Options
Virtualhost
http://rt.host.fqdn
Subdirectory
http://host.fqdn/rt/
Root user ('root')
Change the default password on
first login ('password')
Assign the complete email for the root
account
root@host.fqdn
Assign all user rights:
Global -> User Rights
Слайд 19
Create a userid for each member of your
team.
Assign privileges to each user.
Слайд 20
Create groups of users:
Administering privileges by group is
more efficient than doing so for each user.
Слайд 21
Create queues for problem categories
For example
security
accounts
connectivity
Assign users
to each queue
Different between AdminCC and CC
Don't forget to
create email aliases for each queue
Слайд 22
A critical component of RT. The rt-mailgate facility
lets us:
Define virtual users on the RT server that
correspond to ticket queues in RT.
Allow third-party software (Nagios, Cacti, Smokeping, etc.) to automatically generate tickets in specified queues via email.
Provide a simple interface through which end-users can communicate with your support organization via RT.
Слайд 23
For each queue create automatic actions
There is a
group of scrips that apply to all queues.
Possible to
customize per queue or globally
“scrips” are “snippets of Perl code”
Слайд 24
You can extend the functionality of RT. For
example:
Send daily emails to remind users of tickets that
have not been “taken”
Send daily emails to each user reminding them of their pending tickets.
Periodically increment ticket priority
You can execute commands via email
http://wiki.bestpractical.com/index.cgi?Extensions
