Wolfgang Friebel

1
Handling requests with a trouble ticket system at
DESY Zeuthen

• Wolfgang Friebel
• Motivation
• The req/reqng request tracking system
• Enhancements
• Problems left
• Experiences

2
Motivation

• Stimulated by an introductory talk to Remedy
• Remedy license bought by DESY, usage
  straightforward
• Installation at Zeuthen planned for months,
  estimated manpower for installing, configuring
  and administering led to further delays
• Idea to try a quick and dirty interim solution
• (to cope with the requests while several admins
  were abroad)
• Knew only about gnats and req
• Selected req as it did fit best our work model

3
Living without a request tracking system

• Users trained to use email to uco to report
  problems
• Additional problem reports by phone, email to
  individuals
• All admins receive the email and work on some
  problems
• Solutions are posted back to the users and to
  uco
• Works only for small group of admins, obvious
  drawbacks
• Ideally, a trouble ticket system should
• be invisible or transparent to end users
• put as few additional load to admins as possible
• allow for efficient coordination of the work on
  requests

4
The req/reqng request tracking system

• Replaces the mailing list uco by a mail filter
  of the same name
• The email filter
• stores requests as emails in repositories (active
  and resolved)
• adds email headers (user, priority, request date,
  owner, status, )
• sends the modified mail containing a request ID
  to uco-dist
• The administrator
• reviews the request queue and performs actions on
  it
• view a request notify a user change the subject
• take it comment a request change the user
• give it to somebody change its status/priority kil
  l (remove) a request
• merge requests resolve requests search a request

5
The req/reqng request tracking system (2)

• Almost completely written in perl5
• Powerful searching capabilities by indexing
  requests with glimpseindex
• Now maintained at http//scuttlebutt.explore.com/r
  eqng

6
The req/reqng user/admin interfaces

• Email interface
• reply to email, possibly adding X-request-Do
  headers
• inserting actions in the preformatted Subject
  line
• ReZtn 38 my problem becomes Re take Ztn
  38 ...
• Command line interface
• programs q (query) req (do) uco (query for users)
• Graphical interface tkreq
• WWW interface wwwreq

7
Enhancements at DESY

• NFS based access replaced by client/server
  solution
• Interfaces rewritten for client/server solution
• Administrators get defined in a configuration
  file
• Enhanced email interface (subject line actions)
• Search with glimpse integrated in cmdline
  interface

8
Problems left

• Mixture of req and reqng code
• Problem area field defined but not used yet
• Repository not well enough organized
• (many small files in a directory, replace it by
  an archive)
• Interfaces still with bugs
• Command line interface not yet fully implemented
• DESY version not well maintained
• no interface to Remedy Action Request System yet
• No escalation procedures yet

9
Experiences

• In use since May 98, 400 trouble reports up to
  now
• Usage statistics within the last month
• (96 total, 46/33/9/8 resolved same day/lt1 week/gt1
  week/unresolved)

10
Experiences(2)

• Basically no overhead for administrators
• Not even known to users (no automatic
  acknowledgement, not confronted with request
  number)
• Main advantage admins precisely know status of
  request
• Searching/Indexing facility not used (yet)
• (admins get posted all solutions, do still
  remember)
• Admins get much better organized and informed
• Saves lots of (commercial solutions quite
  expensive)