重複した報告と大規模障害

チケット一覧で行にチェックを入れ、「Multiple report」をクリックします。ボタンは、2行以上にチェックを入れると使えるようになります。

ダイアログは、まず尋ねます。「Which ticket stays?」いちばん古いチケットが、あらかじめ選ばれています。期限が2回目の連絡ではなく、依頼者の最初の連絡から進むようにするためです。別のものを選ぶこともできます。

その下に、両方の番号とともに向きが示されます。「#11 will be closed and moved into #10.」クリックの前に、どちらのチケットが残るかがはっきりします。

すべてが移ります。コメント、添付ファイル、そして2件目の説明です。説明は元のチケットのコメントになり、書いた本人の名前と日付を保ちます。件数は、ダイアログが先に示します。

記録された時間は、複製ではなく移動します。そうでなければ、同じ工数が2件のチケットに残り、二重に請求されてしまいます。

2件目の報告は削除されません。閉じられ、以降は元のチケットを指すようになります。その番号も、有効なままです。

依頼者に別のメールは届きません。依頼者は元のチケットの側にいて、そこですべてを見られます。閉じられた報告には、元のチケットを示すコメントが残り、依頼者もそれを読めます。

取り消しはできません。だからこそ、「Merge」を押す前に、すべてがダイアログに表示されます。

実行後は、両方のチケットの履歴に、誰が何をいつ統合したかが記録されます。

依頼者のメールボックスには、古いチケット番号が残っています。2件の報告が統合されたことは知らず、手元のメールに返信します。

その返信は、元のチケットに届きます。システムは、閉じられた報告が持つ参照をたどります。

だからこそ、統合された報告は削除されません。削除すれば参照がなくなり、返信はどこにも届かなくなります。

古い報告に関わっていた人は、元のチケットにも書き込めます。確認は、メールに書かれたチケットに対して行われます。

別々の人のチケットを選ぶと、ダイアログはそれを含めません。クリックの前に、対象外になる行と、その理由をすべて示します。

理由はこう表示されます。「Different requester — this is an incident, not a multiple report.」代わりにどこへ行けばよいかも示されます。

これが、この機能でいちばん大事な安全装置です。30人からの30件の報告を統合すれば、29人はチケットを失い、その後は何の連絡も受け取れません。

誰が依頼者かは、まずチケットのメールアドレスで決まります。アドレスがない場合は、「User」の欄にある外部の名前で決まり、同じ名前は同じ人と見なされます。それもなければ、チケットを作ったアカウントが依頼者と見なされます。

そのため、この安全装置は電話での受け付けにも効きます。エージェントが2件の電話を記録した場合、どちらのチケットも作成者はそのエージェントです。それでも、別々の相手は別々の相手のままです。名前が欄に入っているためです。

どちらか一方で依頼者を特定できない場合も、対象外になります。不明であることは、同じ人であることとは違います。

同じ枠に、ほかの理由も並びます。大規模障害チケットは統合できません。閉じられた元のチケットは、もう何も受け取りません。すでに自分に報告がひも付いている報告も対象外です。連鎖ができないようにするためです。

ファイルサーバーが止まると、20人がそれを報告します。この報告はどれも、それぞれの依頼者を持つ独立した案件です。ここで統合するのは誤りです。19人がチケットを失うことになります。

報告にチェックを入れ、「Group into incident」をクリックします。ダイアログは3つの道を示します。すでに開いている大規模障害チケットに追加する、選んだチケットの1つを大規模障害チケットにする、独自の件名で新しい大規模障害チケットを作る、の3つです。

そのチームにすでに開いている大規模障害チケットがあれば、その道があらかじめ選ばれています。そちらのほうが、よくある場面です。障害はとうに分かっていて、新しい報告だけが届き続けます。

ひも付いたチケットはどれも、依頼者、ステータス、それぞれの期限を保ちます。消えるものはありません。大規模障害チケットがまとめるのは、返事だけです。

1つの大規模障害チケットに付く報告は、すべて同じチームのものである必要があります。障害が2つのチームに及ぶ場合は、それぞれに大規模障害チケットを作ります。そうしなければ、一方のチームの解決が、もう一方のチームの待ち行列を空にしてしまいます。

あとから届いた報告は、1件のチケットの側で付けることもできます。チームに開いている大規模障害チケットがあると、上部に案内が出て、「Assign」と「Not related」が並びます。システムが自分でひも付けることはありません。誤ってひも付いたチケットは、関係のない解決の文を受け取り、そのまま閉じられてしまうからです。

大規模障害チケットには、何件の報告がひも付いているかが表示されます。ひも付いたチケットの側にも、大規模障害チケットの番号が、一覧と右のカードに表示されます。

「Resolve incident」で大規模障害チケットを閉じ、すべての報告にまとめて答えます。解決の文は必須です。それが影響を受けた全員に届くという点が、この機能のすべてだからです。

ひも付いたチケットはどれも、その文を公開のコメントとして受け取り、選んだステータスになり、依頼者それぞれに個別のメールが届きます。同報のメールは使いません。影響を受けた全員のアドレスが見えてしまうためです。

実行後のメッセージが、何件のチケットを閉じ、何人の依頼者に知らせたかを示します。2つの数値は別々に並びます。連絡先のアドレスがないチケットは、コメントとステータスは受け取りますが、メールは受け取らないためです。

その間に自分で答えて閉じたチケットは、そのままです。二度目に閉じられることも、もう一度書き込まれることもありません。

未処理の報告がひも付いている間は、大規模障害チケットを通常のステータスの変更で閉じることはできません。そうでなければ、20人が黙って答えのないまま残されてしまいます。

ダイアログにも大規模障害チケットにも、「Also show as a banner on the sign-in page」のチェックボックスがあります。これを使えば、次のチケットを書く前に、全員が障害を知ることができます。

バナーはサインイン画面と、サインインしたあとのシステム内に表示されます。「Known incident」と大規模障害チケットの件名が出ます。つまり、その件名は顧客が読む文になります。

複数のお知らせが有効な場合は、上下に並びます。土曜に予定されたメンテナンスが今日の障害を押しのけることも、その逆もありません。

それでも新しいチケットを作る人がいれば、自動返信が大規模障害チケットに触れます。すでにひも付いたチケットでも、そのチームの新しいチケットでも同じで、大規模障害チケットが開いていて告知されている限り有効です。これにはメールの送信が必要です。

大規模障害チケットが解決すると、バナーは自動的に消えます。オフに戻すことを覚えておく必要はありません。

「Maintenance and incident notices」のページで、今どの大規模障害チケットがバナーとして出ているかを確認できます。そのページのスイッチは計画したメンテナンス用で、大規模障害チケットには効きません。