実際にシステムトラブルが発生したらその他のテクニックなんでこんな記事書いたの?お金がない!1ITに携わっているとシステムトラブルを避けて通ることはできません。システムトラブルと一言で言ってもハードウェア障害からオペミス、自分が作り出したバグまでその種類は多岐にわたります。障害が発生すると関係者はダウンタイムを極力抑えるために躍起になって対応するわけですが、トラブル対応で最も怖いのはその混乱の中で生み出される二次災害です。二次災害は三次災害を呼び、なんでもなかった小さな障害がユーザサービスに影響する大きな障害に発展してしまうこともあります。二次災害を生み出してしまう原因も色々ありますが、個人的な経験上コミュニケーションミスは上位にランクインし、かつ防ぎようのあるものと感じています。コミュニケーションというものは複雑で、いざトラブルが発生してから「コミュニケーションミスを起こさないぞ!」と思ったとしてもそれはなかなか難しい。災害対策と同じで日頃からトラブルを想定して訓練し、また情報を収集・整理しておく必要があります。コミュニケーションミスを減らしてシステムトラブルを乗り越えるためには、どんなヒューマンスキルを鍛える必要があり、どのように使っていけばいいか、個人的な経験から考えてみたいと思います。実際にシステムトラブルが発生したらまず報告する事実を伝える。ユーザサービスへの影響有無を伝える。found」というエラーが出ていたとします。あなたはそのデータ前の処理で登録されるべきデータであることを知っています。報告を受けた人はきっと前処理のログを調査し、前処理のプログラムを確認し、デバッグを行うでしょう。本当に前処理に問題があったんでしょうか?後続処理のエラーメッセージは適切だという前提があったとしても、そこにある事実は「後続処理実行時にレコードが存在しなかった」というものだけです。前処理以外にも原因は考えられるんじゃないでしょうか。...第3の処理が存在し、後続処理実行前にレコードを消した前処理の書き込み後にDBに障害が発生し、データの欠損が発生したDBがWriteサーバとReadonlyサーバに別れていて、データのレプリケーションが失敗していた前処理の処理時間が極端に長くなり、コミットされたのが後続処理実行後だった本当に前処理に問題がなかったとすると、前述の報告ではこれらの可能性を潰してしまい、原因の特定を困難になってしまうでしょう。そのようなことにならないよう、あなたは「後続処理実行時に前処理が登録するはずのレコードが存在しなかった。そのためにエラーが発生している。」のように、只々事実を伝えるべきなのです。その上で9割方前処理が悪いと思っているなら「まずは前処理のデータ登録に問題がなかったか調査しましょう。」と付け加えればいいんです。いざトラブルが発生した時に「思い込みを排除して考えるぞ!」なんて都合のいいことはできないので、常日頃からバイアスを排除した会話を心がけて癖を付ける必要があります。found』エラーが発生しています!」でも良いんじゃないですかね?同じ仕事に従事している仲間ならこっちのほうが確実かもしれません。found』エラーが発生しています!調査してください!」って言いますか?どれも通じないでしょう。相手や相手の立場によって業務知識量や持っているスキルが違うので、説明を抽象化したり言葉を選ばないといけません。後者の別ベンダーなら握ったインターフェース仕様をベースに会話しないと取り合ってもらえないでしょう。そのためにはあらかじめ「この人にはこういう知識を持っている」「この立場の人にはこういう資料を使って説明する」ということを知っておく必要があります。ないと、あなたはトラブルの説明をするときに、自分のシステムの概要からトラブルの詳細に至る1から10までを説明して「この中であなたに引っかかる言葉を使って理解してください」と言わないといけないでしょう。...実際にはそんなことにはならないですが、相手が報告内容を理解できないと逆に質問攻めにあってしまい、大幅に時間をロスしてしまいます。ユーザサービスに影響を与えるポイントの知識システムトラブルが発生したときに誰でも関心があるのは「サービスへの影響」です。トラブルを検知して直後の第一報であっても絶対に聞かれます。正確なところは後々調査するにしても、「たぶんある(ない)」くらいでもいいので大体のところは空で回答できるようにしたい。サービスへの影響有無によって次の作業が変わります。初動の遅れは後々響きますので、できるなら最短ルートを通っていきたいところ。サービスへの影響が不透明なら、まずは影響調査かな...サービスへの影響が確実なら、復旧作業が先かな...サービスに影響しないことが確実なら、原因調査を優先してもいいかな...データがどんどんぶっ壊れていく状況なら、まずはサービスを止めるしかないかな...システムが出力するエラーの一覧とその原因を記憶しておければそれに越したことはありませんが、エラーメッセージは原因を示唆しているものが多いので、頑張って覚えることにあまり意味はないと思っています。人間の記憶力には限界がありますし。それよりも、エラーが発生したときにどのような挙動をするシステムなのかを把握しておきたい。エラーが発生したのがデータを一括更新するバッチなら...エラーが発生したらすべてロールバックするシステムなのかデータは更新されていないが安全な状態が維持されていると言える?エラーが発生したらそこで処理が止まるシステムなのかエラーが発生したデータは1件のみと言える。入力データに問題があったとすると、逆に更新に成功したデータが正しかったのか不安...エラーが発生したデータのみスキップしてすべて更新しきるシステムなのか全体の何%でエラーが発生したのかしりたい。スキップされたデータはロールバックされてるの?ぶっ壊れた状態なの?また、普段コードを触ってるなら、例外処理に目を向けましょう。例外が握りつぶされてないかエラー情報が丸められていないかエラー対象オブジェクトを識別できる情報が出力されているか(ファイル名とか行番号とかユーザ情報とか)ロールバックされるようになっているかどのような単位でトランザクションを生成しているのか結局のところ、対象のシステムに興味を持とう、ということなのかもしれません。実際にシステムトラブルが発生したらここからは、実際にトラブルが発生したときに気をつける点について書きます。報告するとにもかくにもまず報告しましょう。隠したり、塩漬けにしても何も良いことはありません。直属の上司が捕まらないなら誰でもいいので情報を共有しましょう。上で述べたように、第一報の際にサービスへの影響有無も添えると余計なやりとりを省くことができますが、わからない場合は影響有無を調べるのに時間を使うのはやめて、素直にサービスへの影響はこれから調査する旨を伝えましょう。トラブルを発見した時刻と報告した時刻は記録しておきましょう。(後述)とにかく記録するいつ、何を見て、何をしたかを記録しましょう。ターミナルエミュレータによっては自動ロギングする機能を有しているものがありますので、普段からそういった機能を有効にしておきましょう。Teraterm)設定を変更したり、再起動したりした時間は後々重要になることがあります。作業した時刻を記録するようにしましょう。経過を報告・共有する際は、作業内容とともに作業した時刻も報告するようにします。タスク保持者を明確にする自分の手の届く範囲だけで解決できればいいですが、実際には別の領域や業務部門と連携することがほとんどでしょう。相手に何かを依頼するときは会話のキャッチボールを意識して不明瞭な言い方ではなく、明確に相手のタスクとわかるように伝えましょう。自分に否がある場合はお願いしづらいですし、ぼやかした言い方になりがちですが、後で問題となる方がお互いダメージがでかいので、ここは覚悟を決めましょう。「謝ったら負け」みたいな考えは一文にもならないです。個人的な経験ですが、「謝ったんだからお前の責任だ!」と言ってくる人を見たことないです。気持ちよくタスクを受け取ってもらうためにどんどん謝っていきましょう。自分が保持しているタスクも積極的に公開していきましょう。同じタスクを他の人が重複して作業してしまうリスクが減ります。それに、他の人にタスクを依頼する上で、全体像を見渡せるようにすることは礼儀だと私は考えています。ひとりで対処しないトラブル対応はスピードが物を言うのでパニックになります。どんなに自分では冷静だと思っていても平常時のそれとは異なります。ひとりで対処しないようにしましょう。自分のミスを指摘できるだけの知識を持つ人とダブルチェックしながら作業するのが一番いいと思うんですが、そういう人がいない場合はリーダーや上司などの自分より権限を持っている人にお願いするのがいいでしょう。最悪責任を押し付けることができます。いう人もいない場合でも、とにかく誰かにダブルチェックをお願いしましょう。説明しながら作業をすることで、自分自身の確認になりますし、声に出すことで冷静になれます。最悪声に出せばもう何でもいいので、オフィスに誰もいないときのためにあらかじめコウペンちゃんやブルスコを配備しておくのも手です。その他のテクニック訂正する際は間違いを明示するトラブル対応の混乱の中で間違った情報を伝えてしまうこともあります。訂正報を出すことになりますが、その時に正しい情報「だけ」を再送するのはやめましょう。受け取った相手は誤情報に対してプラスアルファの追加の情報と勘違いしてしまう恐れがあります。メールなら「いつ送ったメールのここが間違っていたのでこう訂正」とか「いついつ送ったメールの情報はすべて忘れて今回のメールを正としてほしい」と誤情報を明示しましょう。みたいなタイトルはやめましょう。「【訂正報】」がいいです。謝りたくない、誤りを認めたくない人がやりがちなイメージがあります。「電話で会話した件です」で牽制する電話や1対1のチャットの会話の続きをオープンなチャットやメーリングリストでやると、横から余計なツッコミが入りがちなので「XXさんと電話で会話した件です」で他を牽制するといいです。あとで情報共有する必要はありますが、現在進行系でトラブルが発生してる状況下では余計な説明作業は入れたくないですし。なんでこんな記事書いたの?しらねー。別に何かの発表に使ったりするわけでもないんですよね。「俺はこんな視点を持ちつつ運用してるよ」って言いたかったのかもしれない。Whiteplain。