rfc1297.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Johnson                                                         [Page 4]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


   communication between operators, then fixed fields may tend to be a
   hindrance.  One reasonable guideline would be that fixed fields are
   used ONLY where they are automatically filled in by the larger
   system, or where the information in that field is explicitly used in
   a report or standard search procedure.

   Because of this close relationship between the structure of the
   ticket and the problem to be solved, it is very very useful to be
   able to define different ticket types for different classes of
   problems.  This becomes even more true for those many NOCs whose
   staff are responsible for other types of operations: mainframe
   operations, workstation administration, help desk functions, or any
   of the other real-time response functions.  Network operations to
   justify the expense of an operations center.  This kind of operation
   makes economic sense, and is becoming more prevalent.  In these kinds
   of situations it is vital that the same tools that are used for
   network operations also be available for the other operations.  This
   means that the trouble ticket configurations need to be modifiable by
   local staff.  Commercial RDBMS forms builder and report generator
   packages and "fourth-generation languages" offer a good start at
   this, although it is sometimes difficult to integrate full trouble
   ticket functionality through these systems.

TROUBLE TICKET STRUCTURE

   1) HEADERS.  Inevitably, a trouble ticket begins with a number of
   fixed fields.  These generally include:

      Time and Date of problem start.
      Initials or signon of the operator opening the ticket.
      Severity of the problem  (possibly separating the "customer
      severity" and the "NOC priority", since these could be different).
      A one-line description of the problem for use in reports.

   There can be many other fixed fields for specific purposes.  There
   may also be different kinds of tickets for different problems, where
   the ticket format differs mainly in fixed fields.  These include:

      Who reported the problem?  (Name, organization, phone,
                                                      email address)
      Machine(s) involved.
      Network involved (for multi-network NOCs).
      User's machine address.
      Destination machine address.
      Next Action.
      Time and date for alarm on this ticket.
      Who should the ticket be dispatched to?
      Ticket "owner" (one person designated to be responsible overall).



Johnson                                                         [Page 5]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


   2) INCIDENT UPDATES.  The main body of trouble tickets is usually a
   series of freeform text fields.  Optimally, each of these fields is
   automatically marked with the time and date of the update, and with
   the signon of the operator making the update.  Since updates are
   frequently recorded sometime after the problem is fixed, however, it
   is useful to allow the operators to override the current time stamp
   with the time the update was actually made.  (In some
   implementations, both times will be kept internally).

   The first incident update usually is a description of the problem.
   Since the exact nature of the problem is usually not known when the
   ticket is first opened, this description may be complex and
   imprecise.  For problems that are reported by electronic mail, it is
   useful to be able to paste the original message in the ticket,
   particularly if it contains cryptic or extensive information (such as
   a user's traceroute output).  At least one such arbitrarily-long
   freeform field seems necessary to contain this kind of output,
   although it is better to allow arbitrarily long messages at any stage
   (e.g., so future complex messages can also be archived in the
   ticket).

   Subsequent update fields may be as simple as "Called site;  no
   answer".  Some systems allow these kinds of updates to be coded in
   fixed fields; most use freeform text.

   There should always be an indication of what the next action for this
   ticket ought to be.  Again, this may be implemented as a special
   fixed field, or by convention of using the last line of text.

   Advanced systems may also need a facility to allocate the amount of
   time a ticket is open between multiple sources.  A serious NOC will
   want to use its trouble ticket system to statistically track its
   performance on responding to problems. (e.g., Mean Time Between
   Failure and Mean Time To Repair reports).  Frequently, though,
   repairs are stopped at the customer's request.  ("It's not that
   important a machine and I don't feel like coming in--can you defer it
   until Monday Morning?").  In these cases the ticket needs to remain
   open, but there needs to be a notation that the ticket is now in
   "customer time" rather than "NOC time".  The durations of "customer
   time" need to be excluded from MTBF and MTTR reports.  Complicated
   repairs could move back and forth between "NOC time" "customer time"
   repeatedly.  This probably implies that each Incident Update may have
   a time and date of status change, and that these status changes can
   be read and aggregated by by reporting programs.

   3) RESOLUTION DATA.  Once a problem is resolved, it is useful to
   summarize the problem for future statistical analysis.  The following
   fields have been found to be useful:



Johnson                                                         [Page 6]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


      - Time and Date of resulation (for outage duration).
      - Durations (can be calculated from time of resolution and
        incident report "customer/NOC time" stamps).
      - Resolution (one line of description of what happened, for
        reports).
      - Key component affected (for MTBF and similar reports).
      - Checked By -- a field for supervisors to sign off on ticket
        review.
      - Escalated to -- for reports on how many problems require
        non-NOC help.
      - Temp - a database field that can be used to store temporary
        "check marks" while making statistical investigations.

USER, TROUBLE, and ENGINEERING Ticket System(s)

   The primary level of an Network Operations trouble ticket is the
   "problem" or "trouble": a single malfunctioning piece of hardware or
   software that breaks at some time, has various efforts to fix it, and
   eventually is fixed at some given time.

   The primary level of an Network Information Center ticket, however,
   might well be the "user complaint".  A single network failure might
   well produce a large number of individual user phone calls and hence
   "user complaint" tickets.  A NIC may want to use tickets to track
   each one of these calls, e.g., to make sure each user is informed and
   satisfied about the eventual resolution of the single hardware
   problem.

   In addition, NOCs (or Engineering Staffs) may want to track
   systematic problems.  The staff may know, for instance, that a
   particular router is old and fragile, or that a particular section of
   their network doesn't have enough redundancy.  It may be useful to
   open an "Engineering Ticket" on these known problems, providing a
   place to record history and notes about the problem, for use in
   further engineering or funding discussions.

   Even further "Meta" tickets could be described, having to do with
   such issues as whether the current trouble ticket fields, reports,
   and operation procedures were sufficient to handle current problems.

   It would be very convenient to be able to build all of these systems
   on the same platform, and to allow each type of ticket to easily
   reference other types.  Multiple "user complaint" tickets, then,
   might might explicitly point to a single "trouble" ticket.  Multiple
   trouble tickets representing independent failures would then point to
   a single "engineering" ticket, which described the systematic
   problem.  Multiple engineering tickets could point to a single "meta"
   ticket, if appropriate.



Johnson                                                         [Page 7]

RFC 1297                  NOC TT REQUIREMENTS               January 1992


ASSISTED ENTRY AND DATA VERIFICATION

   Data (particularly in fixed fields) is only useful for searching if
   it is entered in consistent formats.  A trouble ticket system needs
   to help operators fill these fields with the correct format of
   information.  This can be done using assisted entry (menus of
   acceptable choices), verification routines which check against
   internal lists or external databases (see next section), or other
   computer checking.

   Some database systems allow a customized "help" screen to be
   associated with each field, helping new (and experienced) operators
   by making context-sensitive trouble ticket system documentation
   available at every field.

   Very complicated help or operator-guidance systems can be built out
   of Expert System technology.  This could be as simple as help
   screens, or help screens with database information inserted (e.g.,
   site contact names and phone numbers).  Or it could involve hints to
   the operator, based on current network conditions.  Or it might even
   ask the operator to run tests and to type in the results.  (See
   EXPERT SYSTEMS, below).

INTEGRATION

   To be maximally efficient and useful, a Trouble Ticket system needs
   to integrate well with most of the rest of the NOC tools.  These
   include:

      1) OPERATOR WINDOW ENVIRONMENT.  A NOC Operator needs access to
      many pieces of information simultaneously, and therefore is well
      served by a good windowing environment.  The Trouble Ticket system
      needs to run within this larger windowing system, so that the
      operator can debug, consult databases, use Email, field alerts,
      and keep an eye out for other emergencies while working on a
      trouble ticket.  It is also useful to be able to run two trouble
      ticket sessions simultaneously, for example, to allow an operator
      to search for related tickets while he is in the middle of
      updating another ticket.  Cut and Paste between these various
      screens is mandatory, to allow easy recording of technical details
      in the trouble tickets.

      2) ALERT MONITORING SYSTEM.  Trouble tickets are often opened in
      response to machine alerts; it ought to be easy to open a trouble
      ticket directly from the alert tool.  When a ticket is opened this
      way, information about the alert and the machine involved ought to
      be automatically filled into the ticket.  (There are various
      opinions about whether trouble tickets ought to be opened



Johnson                                                         [Page 8]