こんにちは、辻村です。
今回は、障害解析を依頼される側から、障害解析の際にこんなことが依頼に含まれているとありがたいと言うことについてお話ししたいと思います。ご参考になれば幸いです。

(a) 障害の内容

障害の内容を書くには、なにが起こったかと、そこへ至るには何がなされたかを知らせるのが大事です。ログの時計がずれていて解析がやり直しになったことは一度や二度ではありません。複数のシステムやインスタンスにまたがるときは、時計が合っているかどうかを確認してください。

・いつ、どこで、何が起こったか?
　・時計がずれているときには何分ずれているかを書いてください。
・障害の前には何か作業をおこなったか?
　・構成や設定の変更、再起動、新規のプログラムなどはありませんか?

(b) どのような支援が必要か?

残念ながら、「大変な状況だとういうことは詳細に書いてあるけれども、読んみると結局何をして欲しいかさっぱりわからない」と言うことがよくあります。何を実現して欲しくて、いつ、どのような支援が必要かを明確にしましょう。

全面復旧が無理なときに、中間目標とか、優先度の高いシステムの部分を示して、当初の目標として掲げるのも良いアイデアです。

大きな障害ではパニックになるもの分かりますが、「大変だ、大変だ！」と大騒ぎして、夜中にアメリカの偉い人をたたき起こせば問題が解決するわけではありません。大障害の時ほど冷静に。

(c) 障害の再現方法

障害を再現する方法があるのであれば、その方法を書いてください。
この場合、詳しい人がテスト環境を作るとは限らないので、できるだけ詳しい手順を書いてください。特に大きな障害の時は手分けして作業することになると思うので、大切です。

(c) 影響の範囲

影響の範囲を知ってもらいましょう。
この障害でどれくらいの影響があるのか?どれくらい大切なシステムなのか?
私個人は「重要」とか「至急」という言葉は毎日のように聞くせいで、正直麻痺してしまっています。

・システムは止まっているのか、性能の劣化なのか?
・1台だけの影響なのか、1000台なのか
・復旧まで猶予があるのか、それとも、1分ごとに札束が消し飛ぶようなシステムなのか?
・復旧が想定時間に間に合わないときなどうして欲しいか?
・業務や自社のビジネスに対してどれくらいの影響があるのか?

自社のビジネスや業務に影響があるならば、その影響を伝えておくことは大事です。復旧に時間制限があるのであれば、間に合わないようならどうしたいかを事前に伝えておくのは大事なことです。それによって、障害対策や調査の方針が変わることすらあるからです。

システムの影響というと台数やインスタンス数を考えがちですが、お金に換算することによって、特にマネージャーと呼ばれる人たちを動かしやすくなると思います。大きなシステムであれば、ここぞと言うときに使ってみるのも一つの方法です。

(d) （あるとうれしい）正常に動いているときのログ

障害やバグを担当する人はほとんどの場合、障害時のログしか目にしません。もし望むことが正常に動いていたならそのときのログを提供してください。もし、存在しないなら、システムが正常であったと判断でする時間帯がいつまであるかを教えてもらえると、正常系と異常系を比べながら調べることができるので、調査の速度と精度が上がります。

(e) 粘り強さ

お客様であるあなたには、今障害を起こしているシステムが一番大事でしょう。でも、部分的にしか伝わっていなかったり、残念ながら時計がずれていたことがあとで分かったり、はたまた、あなたのシステムより大きな障害が起きて担当者がそっちにかかりきりになっていることもあると思います。

とにかく粘り強く、伝え続けることが大事です。お互い違う景色を見ているかもしれないのですから。

粘り強さと言えば、以前あるお客様が説明を動画にしておくってくださいました。言葉で書くと翻訳の過程での誤訳やそもそも担当者間での認識の違いがあると言うことで、動画にしてくださったようです。私の知る限り、世界で唯一バグに動画が添付された件です。

お名前は出せませんが、本当に感謝しかありません。
ありがとうございました。

最後に

「依頼に含まれているとありがたい」と言いながら、あれもこれもとえらそうに書いてしまったかもしれません。あなたの障害が一刻も早く解決することを祈ります。この記事が何かの役に立てば幸いです。