RFC1297 日本語訳
1297 NOC Internal Integrated Trouble Ticket System FunctionalSpecification Wishlist ("NOC TT REQUIREMENTS"). D. Johnson. January 1992. (Format: TXT=32964 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Johnson
Request for Comments: 1297 Merit Network, Inc.
January 1992
コメントを求めるワーキンググループD.ペニス要求をネットワークでつないでください: 1297は1992年1月にネットワークInc.に値します。
NOC Internal Integrated Trouble Ticket System
Functional Specification Wishlist
("NOC TT REQUIREMENTS")
内部の統合NOCの問題チケットシステム機能的な仕様の欲しい物のリスト(「NOC TT要件」)
Status of the Memo
メモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
Professional quality handling of network problems requires some kind of problem tracking system, herein referred to as a "trouble ticket" system. A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on the problem.
ネットワーク問題のプロの上質の取り扱いはここに「問題チケット」システムと呼ばれたある種の問題トラッキング・システムを必要とします。 そうするかもしれない複数人の仕事を調整する病院のチャートのような行為が問題に働く必要がある基本的な問題チケットシステム。
Once the basic trouble ticket system is in place, however, there are many extensions that can aid Network Operations efficiency. Information in the tickets can be used to produce statistical reports. Operator efficiency and accuracy may be increased by automating trouble ticket entry with information from the network Alert system. The Alert system may be used to monitor trouble ticket progress. Trouble tickets may be also used to communicate network health information between NOCs, to telcom vendors, and to other internal sales and engineering audiences.
一度、基本的な問題チケットシステムが適所にあって、しかしながら、ネットワークオペレーション効率を支援できる多くの拡大があります。 統計報告を製作するのにチケットの中の情報を使用できます。 オペレータ効率と精度は、ネットワークAlertシステムからの情報で問題チケットエントリーを自動化することによって、増強されるかもしれません。 Alertシステムは、問題チケット進歩をモニターするのに使用されるかもしれません。 また、問題チケットは、ネットワーク健康情報を伝えるのにNOCsの間と、そして、telcomベンダーと、そして、他の内部の販売と工学聴衆に使用されるかもしれません。
This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers.
このドキュメントはNetworkと他のOperationsセンターズの統合内部の問題チケットシステムの競争している用途、アーキテクチャ、および望ましい地形を探ります。
Introduction
序論
This RFC describes general functions of a Trouble Ticket system that could be designed for Network Operations Centers. The document is being distributed to members of the Internet community in order to stimulate discussions of new production-oriented operator-level application tools for network operations. Hopefully, this will result both in more ideas for improving NOC performance, and in more available tools that incorporate those ideas.
このRFCはネットワークオペレーションセンターズのために設計できたTrouble Ticketシステムの一般的な機能について説明します。 ドキュメントは、ネットワーク操作のために新しい生産指向のオペレータレベルアプリケーションツールの議論を刺激するためにインターネットコミュニティのメンバーに配布されています。 うまくいけば、これはNOC性能を向上させるための、より多くの考え、およびそれらの考えを取り入れるより利用可能なツールに結果として生じるでしょう。
Johnson [Page 1] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[1ページ]RFC1297NOC TT要件1992年1月
PURPOSES OF A NOC TROUBLE TICKET SYSTEM
NOC問題チケットシステムの目的
A good Network Operations Trouble Ticket System should serve many purposes:
良いネットワークオペレーションTrouble Ticket Systemはいろいろな役目を果たすはずです:
1) SHORT-TERM MEMORY AND COMMUNICATION ("Hospital Chart"). The
primary purpose of the trouble ticket system is to act as short-
term memory about specific problems for the NOC as a whole. In a
multi-operator or multi-shift NOC, calls and problem updates come
in without regard to who worked last on a particular problem.
Problems extend over shifts, and problems may be addressed by
several different operators on the same shift. The trouble ticket
(like a hospital chart) provides a complete history of the
problem, so that any operator can come up to speed on a problem
and take the next appropriate step without having to consult with
other operators who are working on something else, or have gone
home, or are on vacation. In single-room NOCs, an operator may
ask out loud if someone else knows about or is working on a
problem, but the system should allow for more formal communication
as well.
1) 短期記憶とコミュニケーション(「病院のチャート」)。 問題チケットシステムのプライマリ目的は全体でNOCのために特定の問題に関する短い用語メモリとして機能することです。 マルチオペレータの、または、マルチシフトしているNOCでは、関係なしでだれが最後に特定の問題に取り組んだかに呼び出しと問題アップデートを入らせます。 問題でシフトに及びます、そして、問題は同じシフトでの数人の異なったオペレータによって扱われるかもしれません。 問題チケット(病院のチャートのような)は問題の全史を提供します、どんなオペレータも他の何かに働いているか、または家に帰った他のオペレータと相談する必要はなくて問題の速度に近づいて、次の適切な方法を採ることができるか、または休みをとるように。 およそまたは、シングルの部屋NOCsでは、オペレータが、他の誰かが知るかどうか声を出して尋ねるかもしれない、aに働くのは、問題ですが、システムはまた、より正式なコミュニケーションを考慮するはずです。
2) SCHEDULING and WORK ASSIGNMENT. NOCs typically work with many
simultaneous problems with different priorities. An on-line
trouble ticket system can provide real time (or even constantly
displayed and updated) lists of open problems, sorted by priority.
This would allow operators to sort their work at the beginning of
a shift, and to pick their next task during the shift. It also
would allow supervisors and operators to keep track of the current
NOC workload, and to call in and assign additional staff as
appropriate.
2) スケジューリングと仕事課題。 NOCsは異なったプライオリティに関する多くの同時の問題で通常働いています。 オンライン問題チケットシステムは優先的に分類された開いている問題のリアルタイム(または、絶えず表示さえして、アップデートする)のリストを提供できます。 これで、オペレータは、シフトの始めに彼らの仕事を分類して、シフトの間、彼らの次のタスクを選ぶでしょう。 それで、また、監督とオペレータは、適宜追加人員を現在のNOCワークロードの動向をおさえて、呼び入れて、選任するでしょう。
It may be useful to allow current priorities of tickets change
according to time of day, or in response to timer alerts.
時刻、またはタイマ警戒に対応してチケット変化の現在のプライオリティを許容するのは役に立つかもしれません。
3) REFERRALS AND DISPATCHING. If the trouble ticket system is
thoroughly enough integrated with a mail system, or if the system
is used by Network Engineers as well as Network Operators, then
some problems can be dispatched simply by placing the appropriate
Engineer or Operator name in an "assigned to" field of the trouble
ticket.
3) 紹介と急ぎ。 問題チケットシステムがメールシステムについて十分すっかり統合しているか、またはシステムがNetwork Operatorsと同様にNetwork Engineersによって使用されるなら単に適切なEngineerかOperator名を中に置くことによっていくつかの問題を派遣できる、「」 問題チケットの分野に割り当てられます。
4) ALARM CLOCK. Typically, most of the time a trouble ticket is
open, it is waiting for something to happen. There should almost
always be a timer associated with every wait. If a ticket is
referred to a phone company, there will be an escalation time
before which the phone company is supposed to call back with an
update on the problem. For tickets referred to remote site
personnel, there may be other more arbitrary timeouts such as
4) 目覚まし時計。 通常と、たいてい、問題チケットが開いている、それは何かが起こるのを待っています。 あらゆる待ちに関連しているタイマがほとんどいつもあるはずです。 チケットは電話会社を参照されると、電話会社がアップデートと共に電話し直すべきである増大時間が問題にあるでしょう。 リモートサイトの人員が参照されたチケットのために、他の、より任意のタイムアウトがそのようであったなら、そこでは、そうするかもしれません。
Johnson [Page 2] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[2ページ]RFC1297NOC TT要件1992年1月
"Monday morning". Tickets referred to local engineers or
programmers should also have timeouts ("Check in a couple of days
if you don't hear back from me"). A good trouble ticket system
will allow a timeout to be set for each ticket. This alarm will
generate an alert for that ticket at the appropriate time.
Preferably, the system should allow text to be attached to that
timer with a shorthand message about what the alert involves
("Remind Site: TT xxx") (The full story can always be found by
checking the trouble ticket). These alerts should feed into the
NOC's standard alert system.
「月曜日の朝。」 プログラマには、チケットは地元の技術者について言及するべきでしたか、またはまた、タイムアウトがあるべきです(「私から連絡をいただかないかどうか一両日中にチェックしてください」)。 良い問題チケットシステムは、タイムアウトが各チケットに設定されるのを許容するでしょう。 このアラームはそのチケットのために適切な時期で警戒を生成するでしょう。 望ましくは、システムは、テキストが警戒がかかわることに関する速記メッセージでそのタイマに取り付けられるのを許容するはずです(「Site: TT xxxに思い出させてください」)(問題チケットをチェックすることによって、全文をいつも見つけることができます)。 これらの警戒はNOCの標準の警告システムに入れられるべきです。
The Alarm Clock can also assist (or enforce!) administrative
escalation. An escalation timer could automatically be set based
on the type of network, severity of the problem, and the time the
outage occurred.
また、Alarm Clockが補助できる、(実施、)!、管理増大。 ネットワークのタイプ、問題の厳しさ、および供給停止が起こった時に基づいて自動的に増大タイマを設定できました。
5) OVERSIGHT BY ENGINEERS AND CUSTOMER/SITE REPRESENTATIVES. NOCs
frequently operate more than one network, or at least have people
(engineers, customer representatives, etc) who are responsible for
subsets of the total network. For these individual
representatives, summaries of trouble tickets can be filtered by
network or by node, and delivered electronically to the various
engineers or site representatives. Each of these reports includes
a summary of the previous day's trouble tickets for those sites, a
listing of older trouble tickets still open, and a section listing
recurrent problems. These reports allow the site reps to keep
aware the current outages and trends for their particular sites.
The trouble ticket system also allows network access to the the
details of individual trouble tickets, so those receiving the
general reports can get more detail on any of their problems by
referencing the trouble ticket number.
5) 技術者と顧客/SITE代表による見落とし。 NOCsには、頻繁に1つ以上のネットワークを経営しているか、または総ネットワークの部分集合に責任がある人々(技術者、顧客担当者など)が少なくともいます。 これらの個々の代表に関しては、問題チケットの概要をネットワークかノードでフィルターにかけて、電子的に様々な技術者かサイト代表に提供できます。 それぞれのこれらのレポートは前の日のそれらのサイトの問題チケットの概要、まだ開いているより古い問題チケットのリスト、および繰り返し起こる問題を記載するセクションを含んでいます。これらのレポートは、サイトレップがそれらの特定のサイトのために現在の供給停止と傾向を意識しているように保つのを許容します。 また、問題チケットシステムが個々の問題チケットの細部へのネットワークアクセスを許すので、一般的なレポートを受け取る人は問題チケット番号に参照をつけることによって、それらの問題のどれかに関するその他の詳細を得ることができます。
6) STATISTICAL ANALYSIS. The fixed-form fields of trouble tickets
allow categorizations of tickets, which are useful for analyzing
equipment and NOC performance. These include, Mean Time Between
Failure and Mean Time to Repair reports for specific equipment.
The fields may also be of use for generating statistical quality
control reports, which allow deteriorating equipment to be
detected and serviced before it fails completely. Ticket
breakdowns by network a NOC costs to be apportioned appropriately,
and help in developing staffing and funding models. A good
trouble ticket system should make this statistical information in
a format suitable for spreadsheets and graphics programs.
6) 統計分析。 問題チケットの書式分野はチケットの分類を許します。(チケットは設備とNOC性能を分析することの役に立ちます)。 特定の設備のためのRepairレポートへのこれらのインクルード、Mean Time Between Failure、およびMean Time。 また、統計的品質管理がレポートであると生成するのにおいて、分野も役に立つかもしれません。(完全に失敗する前にレポートは、悪化している設備が検出されて、調整されるのを許容します)。 NOCが適切に分配されて、モデルを配置して、資金を供給しながら展開するのを手伝うのにかかるネットワークによるチケット故障。 良い問題チケットシステムはスプレッドシートと画像プログラムに適した形式でこの統計情報を作るはずです。
7) FILTERING CURRENT ALERTS. It would be possible to use network
status information from the trouble ticket system to filter the
alerts that are displayed on the alert system. For instance, if
node XXX is known to be down because the trouble ticket is
7) 現在の警戒をフィルターにかけます。 警告システムで表示される警戒をフィルターにかけるのに問題チケットシステムからのネットワーク状態情報を使用するのは可能でしょう。 例えば、問題チケットが知られているので、ノードであるならXXXが下がっているのが知られています。
Johnson [Page 3] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[3ページ]RFC1297NOC TT要件1992年1月
currently open on it, the alert display for that node could
automatically be acknowledged. Trouble tickets could potentially
contain much further information useful for expert system analysis
of current network alert information.
現在、それで開いてください、そして、自動的にそのノードのための注意深いディスプレイは承諾できました。 問題チケットは潜在的に現在のネットワーク警戒情報のエキスパートシステム分析の役に立つ多くの詳細を含むかもしれません。
8) ACCOUNTABILITY ("CYA"), FACILITATING CUSTOMER FOLLOW-THROUGH,
AND NOC IMAGE). Keeping user-complaint tickets facilities the
kind of follow through with end-users that generates happy clients
(and good NOC image) for normal trouble-fixing situations. But
also, by their nature, NOCs deal with crises; they occasionally
find themselves with major outages, and angry users or
administrators. The trouble ticket system documents the NOC's
(and the rest of the organization's) efforts to solve problems in
case of complaints.
8) 責任("CYA") 顧客フォロースルーを容易にするAND NOCイメージ)。 ユーザ苦情チケット施設がエンドユーザを終えた尾行の種類であることを保って、それは正常な問題が修正される状況のために、幸福なクライアント(そして、NOCが像を描く利益)を生成します。 しかし、また、本質的に、NOCsは危機に対処します。 彼らは主要な供給停止と、立腹しているユーザか管理者と共に自分たちを時折見つけます。 問題チケットシステムは、苦情の場合に問題を解決するためにNOC(そして、組織のものの残り)の取り組みを記録します。
FIXED FIELDS, FREE-FORM FIELDS, and TT CONFIGURATION
固定分野、自由形式分野、およびTT構成
Information in trouble tickets can be placed in either fixed or freeform fields. Fixed fields have the advantage that they can be used more easily for searches. A series of fixed fields also acts as a template, either encouraging or requiring the operators to fill in certain standard data. Fixed fields can facilitate data verification (e.g., making sure an entered name is in an attached contacts database, or verifying that a phone number consists of ten numeric characters). Fixed fields are also appropriate for data that is automatically entered by the system, such as the operator's login id, the name of the node that was clicked on if the trouble ticket is opened via an alert tool, or names and phone numbers that are automatically entered into the ticket based on other entries (e.g., filling in a contact name and phone based on a machine name).
問題チケットの中の情報を修理されているか、自由形状分野に置くことができます。 それらは利点であるかもしれませんが、検索により容易に使用されて、固定分野は持っています。 また、一連の固定分野がテンプレートとして機能します、オペレータが、ある標準のデータに記入するのが奨励するか、または必要であることで。 固定分野はデータ検証(例えば、入力された名前が添付の連絡データベースにあるのを確実にするか、または電話番号が10の数字から成ることを確かめる)を容易にすることができます。 また、システムによって自動的に入力されるデータに、固定分野も適切です、自動的に他のエントリー(例えば、マシン名に基づく連絡名と電話に記入する)に基づくチケットの中に入れられるオペレータのログインイドや、問題チケットが注意深いツールで開けられるならクリックされた、ノードの名前や、名前や電話番号などのように。
Unfortunately, fixed fields work best where the problem-debugging environment is uniform, well-understood, and stable; that is, trouble tickets work best when their fields are well tailored to the specific problem at hand. It is easy to set up a large number of fields (or even required fields) that are irrelevant to a given problem; this slows down and confuses the operators. Adding structure and validity checking to a field tends to make the data more consistent and reliable, but it also tends to force the operators into longer procedures like menus to get the get the data accepted by the system. It also forces there to be more maintenance on those verification systems (adding new entries as they become new legal options), and in some ways it reduces the accuracy of the system by forcing operators to choose "canned" or authorized responses that may not always represent the situation accurately. Where statistical operational reports are a primary purpose of the trouble ticket system, several fixed fields may be appropriate. If the primary intent of the system is to keep notes for individual problems and to facilitate
残念ながら、固定野原は問題をデバッグする環境が一定であって、よく理解されていて、安定しているところにうまくいきます。 それらの分野が特定の当面の問題によく適合するとき、すなわち、問題チケットはうまくいきます。 与えられた問題と無関係の多くの分野(または、必須項目さえ)をセットアップするのは簡単です。 これは、オペレータを減速させて、混乱させます。 分野にチェックする構造と正当性を加えるのが、データをより一貫していて信頼できるようにする傾向がありますが、また、得るより長い手順好きメニューにオペレータを力づくで押す傾向がある、システムでデータを受け入れさせてください。 それによって、また、それらの検証制度には、より多くのメインテナンスがやむを得ずあります、そして、(新しい法的なオプションになるので新しいエントリーを加えて)オペレータにいつも正確に状況を表すかもしれないというわけではない「缶詰」の、または、認可された応答を選ばせることによって、ある点ではそれはシステムの精度を低下させます。 統計的な操作上のレポートが問題チケットシステムのプライマリ目的であるところでは、いくつかの固定分野が適切であるかもしれません。 システムのプライマリ意図が個々の問題のための注意を保つことである、容易にします。
Johnson [Page 4] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[4ページ]RFC1297NOC TT要件1992年1月
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.
オペレータのコミュニケーション、当時の固定分野は、妨害である傾向があるかもしれません。 1つの妥当なガイドラインはそれらが、より大きいシステムによって自動的に記入されるか、またはその分野の情報がレポートか標準の調査方法で明らかに使用されるところで固定分野が使用されるだけであるということでしょう。
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.
チケットの構造と解決すべき課題とのこの密接な関係のために、異なったクラスの問題のための異なったチケットタイプを定義できるのは非常に非常に役に立ちます。これはスタッフが他のタイプの操作に責任があるそれらの多くのNOCsにさらに本当になります: もう片方のリアルタイムの応答のメインフレーム操作、ワークステーション管理、ヘルプデスク機能、またはいずれも機能します。 操作をネットワークでつないで、操作センターの費用を正当化してください。 この種類の操作は、経済意味になって、より一般的になっています。 これらの種類の状況で、また、ネットワーク操作に使用されるのと同じツールも他の操作に利用可能であることは、重大です。 これは、問題チケット構成が、現地スタッフが修正できる必要を意味します。 商業RDBMSフォームビルダー、報告書作成ルーチンパッケージ、および「第4世代言語」はこれで好調なスタートを提供します、これらのシステムを通して完全な問題チケットの機能性を統合するのが時々難しいのですが。
TROUBLE TICKET STRUCTURE
問題チケット構造
1) HEADERS. Inevitably, a trouble ticket begins with a number of fixed fields. These generally include:
1) ヘッダー。 必然的に、問題チケットは多くの固定分野で始まります。 一般にこれらは:
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.
問題の時間とDateは始まります。 チケットを開けているオペレータのイニシャルかsignon。 問題(これらが異なるかもしれないので、ことによると「顧客の厳しさ」と「NOC優先権」を切り離す)の厳しさ。 レポートにおける使用のための問題の1系列の記述。
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).
だれが問題を報告しましたか? (名前、組織、電話、Eメールアドレス) かかわる(s)を機械加工してください。 かかわる(マルチネットワークNOCsのために)ネットワーク。 ユーザの機械語アドレス。 目的地機械語アドレス。 次の動作。 このチケットの上のアラームのための日時。 チケットはだれに派遣されるべきですか? チケット「所有者。」(全体的に見て責任があるように任命された1人の人)
Johnson [Page 5] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[5ページ]RFC1297NOC TT要件1992年1月
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).
2) 付随しているアップデート。 通常、問題チケットの本体は一連の自由形状テキストフィールドです。 アップデートの日時、およびオペレータのsignonがアップデートをしていて、最適に、それぞれのこれらの分野は自動的に示されます。 問題が固定されていたいつか後にアップデートが頻繁に記録されるので、しかしながら、オペレータがアップデートが実際にされた時間がある現在のタイムスタンプをくつがえすのを許容するのは役に立ちます。 (いくつかの実装では、両方の回は内部的に保たれるでしょう。)
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).
通常、最初の付随しているアップデートは問題の記述です。 以来、問題の正確な本質はチケットが最初に開けられる場合知られないで、通常、この記述が複雑であって、不正確であるかもしれないということです。 電子メールによって報告される問題に、チケットの中にオリジナルのメッセージを貼ることができるのは役に立ちます、特に不可解であるか大規模な情報(ユーザのトレースルート出力などの)を含んでいるなら。 少なくともそのような分野の任意に長い自由形状1つはこの種類の出力を含むのに必要に見えます、どんな段階にも任意に長いメッセージを許容しているほうがよいのですが(例えば、また、チケットの中に将来の複雑なメッセージを格納できるように)。
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.
また、高度なシステムは、チケットが複数のソースの間で開いている時間を割り当てるために施設を必要とするかもしれません。 重大なNOCは、統計的に問題(例えば、Mean Time Between FailureとMean Time To Repairレポート)に応じることに関する性能を追跡するのに問題チケットシステムを使用したくなるでしょう。 もっとも、頻繁に、修理は顧客の要求によって止められます。 (「マシンと私が、入るような気分でないことは、そんなに重要ではありません--あなたは月曜日のMorningまでそれを延期できますか?」)? 現在チケットがそうである記法が「NOC時間」よりむしろ「顧客時間」であるのが必要です。 「顧客時間」の持続時間は、MTBFとMTTRレポートから除かれる必要があります。 複雑な修理は「NOC時間」「顧客時間」の間で繰り返して前後に移行できました。 これは、各Incident Updateには状態変化と、その日時がプログラムを報告することによってこれらの状態変化を読んで、集めることができるあるかもしれないのをたぶん含意します。
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:
3) 解決データ。 問題がいったん解決されていると、今後の統計分析のために問題をまとめるのは役に立ちます。 以下の分野は役に立つのがわかりました:
Johnson [Page 6] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[6ページ]RFC1297NOC TT要件1992年1月
- 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.
- resulation(供給停止持続時間のための)の時間とDate。 - 持続時間(解決と事故報告「顧客/NOC時間」スタンプの時間から計算できます)。 - 解決(何がレポートのために起こったかに関する記述の1つの系列)。 - 影響を受ける(MTBFと同様のレポートのために)主要なコンポーネント。 - チェックのBy--監督がチケットレビューのときに下に署名する分野。 - いくつの問題が非NOCを必要とするかに関するレポートが助けるので、徐々に拡大されます。 - 派遣社員として働いてください--統計的な調査をしている間、一時的な「チェックマーク」を保存するのに使用できるデータベース分野。
USER, TROUBLE, and ENGINEERING Ticket System(s)
ユーザ、問題、および工学チケットシステム(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.
ネットワークオペレーション問題チケットのプライマリレベルは、「問題」か「問題」です: いつか壊れて、それを修理する様々な取り組みを持って、時間を考えて、結局いくつかで修理されている1誤動作片のハードウェアかソフトウェア。
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.
しかしながら、Networkインフォメーション・センターチケットのプライマリレベルはたぶん「ユーザ苦情」でしょう。 ただ一つのネットワーク失敗はたぶん多くの個々のユーザ電話としたがって、「ユーザ苦情」チケットを起こすでしょう。 NICは、これらの呼び出しのそれぞれを追跡して、例えば各ユーザがただ一つのハードウェア問題の最後の解決に関して知らされて、満足しているのを確実にするのにチケットを使用したがっているかもしれません。
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.
さらに、NOCs(または、Engineering Staffs)は系統的な問題を追跡したがっているかもしれません。例えば、スタッフは、特定のルータが古くて、こわれやすいか、またはそれらのネットワークの特定のセクションには十分な冗長がないのを知るかもしれません。 これらの既知の問題で「工学チケット」を開くのは役に立つかもしれません、問題に関する歴史と注を記録する場所を提供して、さらなる工学か基金議論における使用のために。
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
ジョンソン[7ページ]RFC1297NOC TT要件1992年1月
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).
Expert System技術から非常に複雑な助けか操作指示システムを構築できます。 これはスクリーンを助けてください。さもないと、データベース情報が挿入されている状態で助けが(例えば、サイト連絡名と電話番号)を上映するのと同じくらい簡単であるかもしれません。 または、それは現在のネットワーク状態に基づいてヒントにオペレータにかかわるかもしれません。 または、それは、テストを実行して、結果をタイプするようにオペレータに頼みさえするかもしれません。 (以下のEXPERT SYSTEMSを見ます。)
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:
最高に効率的であって、役に立つように、Trouble Ticketシステムは、NOCツールの残りの大部分とよく統合する必要があります。 これらは:
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.
1) オペレータ窓の環境。 NOC Operatorは同時に多くの情報へのアクセスを必要として、したがって、良いウインドー環境によってよく役立たれています。 Trouble Ticketシステムは、問題チケットに働く間、他の非常時にオペレータがデバッグできるようにこのより大きいウインドーシステムの中で稼働して、データベースに相談して、メールを使用して、警戒をさばいて、目を避ける必要があります。 また、例えば、同時に彼が別のチケットをアップデートする中央にいる間、オペレータが関連するチケットを捜し求めるのを許容するために2つの問題チケットセッションを実行できるのも役に立ちます。 切られて、これらの様々なスクリーンの間のPasteは、問題チケットの中に技術的詳細の簡単な録音を許すために義務的です。
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
2) 監視システムを警告してください。 問題チケットはしばしばマシン警戒に対応して開けられます。 直接注意深いツールから問題チケットを開けるのは簡単であるべきです。 チケットがこのように開けられるとき、警戒とかかわったマシンの情報は自動的にチケットの中にいっぱいにされるべきです。 (問題チケットが開けられるべきであるかどうかに関するいろいろな意見があります。
Johnson [Page 8] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[8ページ]RFC1297NOC TT要件1992年1月
automatically without operator intervention. This operator's
opinion is that an operator acknowledgement should be required,
but this point is debated enough that designers of a new system
probably should support either option).
自動的である、オペレータ介入なしで。 このオペレータの意見がオペレータ承認が必要であるべきであるのにもかかわらずの、このポイントが十分討論されて、新しいシステムのそのデザイナーがたぶんオプションをサポートするべきであるということであるということである、)
The Alarm Clock feature of the trouble ticket system also
generates alerts. These alerts ought to feed gracefully into the
Alert Monitor system, so that the operators will get all of their
alerts from one place.
また、問題チケットシステムのAlarm Clockの特徴は警戒を生成します。 これらの警戒は優雅にAlert Monitorシステムに入れられるべきです、オペレータが1つの場所から彼らの警戒のすべてを得るように。
3) DATABASE CONNECTIONS. A good trouble ticketing system will
query NOC databases to automatically fill out trouble ticket
fields where possible. This can be used for:
3) データベース接続。 良い問題チケット発行システムは、可能であるところに自動的に問題チケット分野に書き込むためにNOCデータベースについて質問するでしょう。 以下にこれを使用できます。
- Filling out Network Operator information (e.g., phone number)
based on the NetOp's signon id.
- Filling in contact information based on machine name.
- Filling in circuit numbers based on link description.
- Filling in alarm clock or escalation time fields based on the
machine or link name and on time of day.
- Filling in machine serial numbers based on configuration database.
- NetOpのsignonイドに基づくNetwork Operator情報(例えば、電話番号)を書き込みます。 - マシン名に基づく問い合わせ先に記入します。 - リンク記述に基づく回路番号に記入します。 - マシンかリンク名に基づいた時刻の上に目覚まし時計か増大時間分野に記入します。 - 構成データベースに基づくマシン通し番号に記入します。
4) MACHINE QUERYABLE INFORMATION. It could also be possible for a
trouble ticket system to make standard queries of the network
itself when a trouble ticket is opened: e.g., the system could
request and store current machine configurations whenever a ticket
was opened for that machine. On some systems, hardware serial
numbers are obtainable by software query directly to the machine.
4) QUERYABLE情報を機械加工してください。 また、問題チケットシステムが問題チケットが開けられるときのネットワーク自体の標準の質問をするのも、可能であるかもしれません: チケットがそのマシンのために開けられたときはいつも、例えば、システムは、現在の機械コンフィギュレーションを要求して、保存するかもしれません。 いくつかのシステムの上では、ハードウェア通し番号は直接マシンへのソフトウェア質問で入手可能です。
5) ELECTRONIC MAIL. Problem notification often comes via
electronic mail; it must be possible to easily open a ticket and
include the original mail message within the ticket as part of the
initial problem description. When extremely technical messages
come in from network engineers, it is useful to allow those
messages to be included verbatim, rather than forcing less
technical network operators to rephrase the messages or to force
them into predefined formats. Later update messages should also
be easily includable. Possibly: tickets could be opened
automatically for mail messages to certain mailboxes. A response
system saying "Your request has been received and assigned ticket
number ####" might be desirable.
5) 電子メール。 問題通知は電子メールを通してしばしば来ます。 初期の問題記述の一部として容易にチケットを開けて、チケットの中にオリジナルのメール・メッセージを含んでいるのは可能であるに違いありません。 非常に技術的なメッセージがネットワーク・デザイナーから入るとき、それらの技術ネットワーク・オペレータにメッセージを言い直すか、または事前に定義された形式にそれらをそれほど力づくで押させないというよりむしろ逐語的に含まれるべきメッセージを許容するのは役に立ちます。 また、後のアップデートメッセージも容易に包含可能であるはずです。 ことによると: メール・メッセージのために自動的に、あるメールボックスにチケットを開けることができました。 「あなたの要求は、受け取られていて、チケット数の####、を割り当てました」と言う応答システムは望ましいかもしれません。
Information within trouble tickets must also be easily available
(possibly just via the windowing system) for inclusion in Email
messages to engineers and others.
また、メールメッセージの包含について、問題チケットの中の情報が技術者と他のものにとって容易にあるに違いありません(ことによるとすぐウインドーシステムを通した)。
Scheduled (e.g., daily) reports must also be easily generated into
the Email system.
また、容易に予定されている(例えば、日刊誌)レポートをメールシステムに作らなければなりません。
Johnson [Page 9] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[9ページ]RFC1297NOC TT要件1992年1月
6) DISPATCHING AND NOTIFICATION SYSTEMS. An important real-time
aspect of Network Operations is notifying users, technical
contacts, and administrators of various classes of problems. The
rules for who gets notified of what can be very arbitrary and
complex, and can involve electronic mail, notices in computer
conferences, automatic beeper pages, and synthesized voice
announcements. It would be good for a trouble ticket system to
provide for automatic (or operator initiated) notification of the
appropriate channels for the current ticket (based on network,
machine, severity of problem, duration of the problem, escalation
guidelines, etc).
6) DISPATCHING AND NOTIFICATION SYSTEMSネットワークオペレーションの重要なリアルタイムの局面は、何が非常に任意であって、複雑である場合があり、電子メールにかかわることができるかについてだれが通知されるかために問題規則の様々なクラスについてユーザ、技術連絡担当者、および管理者に通知して、コンピュータ会議における通知と、自動ポケベルページと、合成音声発表です。 問題チケットシステムが当日券(ネットワーク、マシン、問題の厳しさ、問題の持続時間、増大ガイドラインなどに基づいている)のために適切なチャンネルの自動(または、開始されたオペレータ)である通知に備えるのは、十分でしょう。
Databases associated with the trouble ticket system may also have
lists of specific people to contact about outages for particular
machines. These "who to inform" lists can facilitate customized
notification messages directly from the trouble ticket system.
また、問題チケットシステムに関連しているデータベースには、特定のマシンのための供給停止に関して連絡する特定の人々のリストがあるかもしれません。 「だれに知らせるか」は記載します。これら、直接問題チケットシステムからのカスタム設計された通知メッセージを容易にすることができます。
It may also be possible to dispatch experts directly from the
trouble tickets system. IBM's ECCO system allows allows customers
to directly dispatch Service Engineers from machine interactions.
Many NOCs also use computer hooked to modems to automatically page
engineers. This kind of dispatching should be available from
within the trouble ticket system (along with an automatic note
into the trouble ticket that the engineer has been dispatched).
また、直接問題チケットシステムから専門家を急派するのも可能であるかもしれません。 システムが許容するIBMのECCOは顧客にマシン相互作用からService Engineersを直接派遣させます。 また、多くのNOCsがモデムが自動的にページ技術者に接続されたコンピュータを使用します。 この種類の急ぎは問題チケットシステム(技術者が急派されたという問題チケットの中への自動メモに伴う)から利用可能であるべきです。
7) OTHER TROUBLE TICKET SYSTEMS. When the NOC generates a trouble
ticket, it often immediately calls up a telco or another Internet
NOC, who proceed to open their own ticket. The Internet
Engineering Task Force User Connectivity Working Group is also
proposing a national trouble ticket tracking system, which would
need updating from individual NOC trouble ticket systems. A
state-of-the-art trouble ticket system could have provisions for
transferring tickets and ticket information in and out of other
such systems.
7) OTHER TROUBLE TICKET SYSTEMS NOCが問題チケットを生成すると、それはすぐに、しばしば通信業者か別のインターネットNOCを呼び出します。(NOCはそれら自身のチケットを開けかけます)。 また、インターネット・エンジニアリング・タスク・フォースUser Connectivity作業部会は国家の問題チケットトラッキング・システムを提案しています。(トラッキング・システムは個々のNOC問題チケットシステムからアップデートする必要があるでしょう)。最先端の問題チケットシステムでは、チケットを移すための条項とチケット情報はシステムと他のそのようなシステムを使い果たされたかもしれません。
8) NETWORK ACCESS. Some older trouble ticket systems assumed that
anyone with a need to access the information would obtain a signon
and learn to use that system. The range of people with a need for
trouble ticket information is now too great to allow this
assumption. A good system now needs to be able to support network
query for tickets and summary reports, as well as Email delivery
of scheduled reports.
8) ネットワークアクセサリー いくつかの、より古い問題チケットシステムが、情報にアクセスする必要性をもっているだれでも、signonを入手して、そのシステムを使用することを学ぶと仮定しました。 問題チケット情報の必要性をもっている人々の範囲は現在、この仮定を許容できないくらい大きいです。 良いシステムは、現在チケットと概略報告のためのネットワーク質問をサポートすることができる必要があります、予定されているレポートのメール配送と同様に。
9) SUBROUTINE INTERFACE. To allow for ad-hoc and currently
unanticipated needs, the trouble ticket system needs to support a
full-function set of subroutine calls. These subroutines will
allow construction of further trouble ticket functionality not yet
specified.
9) サブルーチンインタフェース。 臨時で現在思いがけない必要性を考慮するために、問題チケットシステムは、完全な関数集合のサブルーチン呼出しをサポートする必要があります。 これらのサブルーチンはまだ指定されていなかったさらなる問題チケットの機能性の工事を許すでしょう。
Johnson [Page 10] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[10ページ]RFC1297NOC TT要件1992年1月
10) EXPERT SYSTEMS. Network debugging is a very promising area
for expert system and artificial intelligence applications. But
such an algorithm should require access to the alert monitoring
system, configuration and change control systems, to the network
itself, and also to the information in the trouble ticket system.
A good future system then needs to make this information available
(probably via the subroutine interface mentioned above), and to
also allow the Network Operators to invoke the artificially
intelligent debugging from within a trouble ticket (including its
output as part of the ticket dialogue).
10) EXPERT SYSTEMSネットワークデバッグはエキスパートシステムと人工知能アプリケーションのための非常に有望な領域です。 しかし、そのようなアルゴリズムは問題チケットシステムで警告監視システム、構成、および変化制御システムと、そして、ネットワーク自体と、そして、情報にもアクセスを必要とするべきです。 そして、良い将来のシステムは、この情報を利用可能に(たぶん前記のようにサブルーチンインタフェースを通した)して、また、Network Operatorsが問題チケットから人工的に知的なデバッグを呼び出すのを許容する必要があります(チケット対話の一部として出力を含んでいて)。
11) GRAPHICS/REPORT Capability. Statistical and graphical
displays about trouble ticket data need to be compatible with
tools used to generate reports, news letters, etc.
11) グラフィックス/レポート能力。 問題チケットデータに関する統計的でグラフィカルなディスプレイは、レポート、ニュース手紙などを生成するのに使用されるツールと互換性がある必要があります。
OTHER CONSIDERATIONS:
他の問題:
1) INTERACTIVE SPEED. The system must be fast enough to be used
interactively. NetOps need to answer questions over the phone in
real time; good answers cannot be given if every query takes a
couple of minutes. More importantly, the NetOps need the trouble
ticket system in order to get information necessary to fix the
network. If looking for old or currently-open tickets takes more
than a few seconds, it won't be done. If updates take very long
to make, then updates won't be recorded, or they will be recorded
long after the event (with corresponding loss of accuracy). (Our
Operators have asked for a single-line "update this ticket with
this message" utility that would let them avoid even retrieving
the ticket for simple updates!) Any time spent waiting reduces
NetOp productivity and Network reliability.
1) 対話的な速度。 システムはインタラクティブに使用されているほど速くなければなりません。 NetOpsは、リアルタイムで電話で質問に答える必要があります。 あらゆる質問が2、3分かかるなら、適切な答を与えることができません。 より重要に、NetOpsは、ネットワークを修理するために必要情報を得るために問題チケットシステムを必要とします。 古いか現在のオープン・チケットを探すのがかなり多くの秒取ると、それをしないでしょう。 アップデートが作るために非常に長い状態で取ると、アップデートが記録されないだろうか、またはそれらはイベント(精度の対応する損失を伴う)のずっと後に記録されるでしょう。 (私たちのOperatorsは「このメッセージでこのチケットをアップデートしてください」という彼らが簡単なアップデートのチケットを検索さえするのを避ける単線ユーティリティを求めました!) いつでも、費やされた待ちはNetOpの生産性とNetworkの信頼性を減少させます。
2) BACKUPS AND RELIABILITY. The trouble ticket system is
absolutely crucial to both immediate and long-term operation of
the NOC. Good systems could back up all data several times an
hour to an auxiliary processor. That processor should be
accessible for immediate use in case of failure of the primary
system.
2) バックアップと信頼性。 問題チケットシステムは即座のものとNOCの同様に長期の操作に絶対に重要です。 良いシステムは1時間何度か補助のプロセッサにすべてのデータを支援するかもしれません。 即座の使用に、そのプロセッサはプライマリシステムの失敗の場合にアクセスしやすいはずです。
3) HISTORY AND ARCHIVING. A trouble ticket system is a
constantly-growing database system. Old tickets need to be
removed from the system at some interval (a year? several years?)
and archived. These archives should also be restorable for long-
term history processing.
3) 歴史と格納。 問題チケットシステムは絶えず成長しているデータベース・システムです。 古いチケットは、システムからいくつかの間隔(1年--数年?)を置いて取り除かれて、格納される必要があります。 また、長い用語歴史処理において、これらのアーカイブも復元できるべきです。
4) PRIVACY AND SECURITY. The ability to enter, append, and modify
tickets should be controlled by id and password. Permissions
should be specifiable on a per-field basis. General read access
to tickets (or portions of tickets) also needs to be restricted,
4) プライバシーとセキュリティ。 チケットに入って、追加して、変更する能力はイドとパスワードによって制御されるべきです。 許容は1分野あたり1個のベースで明記できるべきです。 また、チケット(または、チケットの一部)へのアクセスが読まれた一般は、制限される必要があります。
Johnson [Page 11] RFC 1297 NOC TT REQUIREMENTS January 1992
ジョンソン[11ページ]RFC1297NOC TT要件1992年1月
or else NetOps will be reluctant to be full and candid in their
reporting.
または、NetOpsは彼らが報告するのに、完全であって、率直であるのに気が重いでしょう。
UTILITY
ユーティリティ
There are quite a few ideas in this "Wishlist". Ultimately, what an Operations Center needs is a totally integrated set of tools which completely model all of its activities, and which integrates cleanly with all backup, peer, and vendor NOCs. It is hard to imagine that this whole system could come out of a shrinkwrapped box, even without the local configuration. But most of these facilities do exist, now, in some system. Hopefully, this document will foster an ongoing discussion of ways in which NOC operator-level tools are used in real operations, and will encourage systems implementors and vendors to bring some of this functionality to the aid of real operations. It might even inspire current Operations Centers to add useful features to their current operations.
この「欲しい物のリスト」にはかなり多くの考えがあります。 結局、Operationsセンターが必要とするものは活動のすべてを完全にモデル化して、清潔にすべてのバックアップ、同輩、およびベンダーNOCsと統合される完全に統合しているセットのツールです。 この全体のシステムがshrinkwrapped箱から出て来るかもしれないと想像しにくいです、地方の構成がなくても。 しかし、これらの施設の大部分は現在、何らかのシステムに存在します。 うまくいけば、このドキュメントは、システム作成者とベンダーがこの機能性のいくつかを本当の操作の援助にもたらすようNOCオペレータレベルツールが本当の操作に使用される方法の現在行われている議論を伸ばして、奨励するでしょう。 それは、彼らの現在の操作に役に立つ特徴を加えるために現在のOperationsセンターズを奮い立たせさえするかもしれません。
Security Considerations
セキュリティ問題
This paper does not pose specific new security issues. The systems described herein would be host database applications, however, or even distributed host database applications. All of the normal security considerations for that kind of system would apply. Multiple classes of user access need to be specified for classes of ticket data. Possible security threats include disclosure of network information, disclosure of confidential material (e.g., circuit numbers or home phone numbers), and denial of service to the Network Operations Center leading to degradation of network service.
この紙は特定の新しい安全保障問題を引き起こしません。 しかしながら、ここに説明されたシステムはホストデータベースアプリケーションであるだろうか分配されたホストさえデータベースアプリケーションです。 その種類のシステムのための正常なセキュリティ問題のすべてが適用されるでしょう。 ユーザアクセスの複数のクラスが、チケットデータのクラスに指定される必要があります。 可能な軍事的脅威はネットワーク情報の公開、機密資料(例えば、回路番号か自宅電話番号)の公開、およびネットワーク・サービスの退行に通じるネットワーク運営センターに対するサービスの否定を含んでいます。
Author's Address
作者のアドレス
Dale S. Johnson Merit NOC 1075 Beal Avenue Ann Arbor, MI 48109-2112
ビール・Avenueアナーバー、デールS.ペニス長所NOC1075MI48109-2112
Phone: (313) 936-2270
以下に電話をしてください。 (313) 936-2270
Email: dsj@merit.edu
メール: dsj@merit.edu
Discussion/comments may be sent to noc-tt-req@merit.edu. The list is maintained by noc-tt-req-request@merit.edu.
議論/コメントを noc-tt-req@merit.edu に送るかもしれません。 リストは noc-tt-req-request@merit.edu によって維持されます。
Johnson [Page 12]
ジョンソン[12ページ]
一覧
スポンサーリンク
