こんにちは!すぎのーるです。

2009年に都銀の子会社に入ってから約9年間、おもにインフラ周りのシステムエンジニアをやってきましたが、その後の地銀、フィンテックベンチャーと、通して定評があったのは、 システム障害 への対応でした。

今回は、Twitterで以下のようなやりとりをしたこともあったので、私が障害対応で大切にしていることを書いておこうかと思います。

システム障害 の登場人物

システム障害 の場合、顧客やオペレーション部門、コンプラ、経営者など様々な登場人物がいます。

私はこれまで、開発部門だったり、運用部門だったり、名前はいろいろありました。

しかし、システム障害に関する登場人物は「システムの問題を解決する人」「ビジネスの問題を解決する人」の2種類しかいないと考えています。

私はいつもこの両者の界面の「システム」側で対応をしてきました。

障害復旧の燃料はエンジニアの集中力

システム障害で一番重要なことは「いち早く影響を特定し、復旧させること」に他なりません。私は原因調査は目的ではなく手段だと思っています。

いずれの作業も、エンジニアの手をなくして実現することはできません。

そして、「最も重要なことは、対応にあたるエンジニアが、復旧までいかにして集中力を維持できるかということです。

したがって、私のようなSEなど、障害対応を仕切る立場には、彼らの集中力を切らさないための所作が要求されます。

具体的には、「ノイズの排除」と「必要なものや情報をすぐ準備できる体制づくり」です。

後者は後日時間があればお話するとして、今回は前者について考えましょう。

障害対応へのノイズ

それでは、障害にあたるエンジニアにとっては、どのようなことがノイズになるでしょうか。

私の経験をもとにお話します。

無茶、あいまいな要求

一番わかりやすいのは、無茶、あいまいな要求です。

「早くしろ」や、「責任を取れ」などといった罵声が思いつきがちですが、意外に多いのが「至急」「必須」といった言葉にも要注意です。

現場で作業をしてる人にとっては、全てが「至急」で全てが「必須」です。

彼らはその中で優先度をつけて対応しているので、あいまいな言葉掛けは混乱を招くだけです。

用途が明らかでない質問

障害の規模が大きくなるにつれ、係長、課長、部長と、上役の人が順番に現場や電話会議に現れ、その都度状況説明を求められて、エンジニアの貴重なリソースが失われることはよくあります。

  • 顧客や関連会社、当局などに報告する必要がある場合
  • 以降はその人が窓口になる場合
  • 技術的に見識があり対応方法に責任が持てる場合

概ね上記以外の質問は「私が知りたいだけ」なのではないでしょうか。

完全に時間の浪費です。

根拠のない解決策の提示

今回の中で最も悪質なのが、「根拠のない解決策の提示」です。

たとえば「前はこうやって解決した」や、「~に違いない」などの外野からの無責任な発言や、エンジニアの出した複数の解決策から選ぶ場面のいて、そのどれでもない方法をいきなり提案してきたりする(いわゆる「鶴の一声」)などがあります。

これまでの二つはまだ復旧までの時間を伸ばすだけですが、この場合は、議論を巻き起こし、最悪対応を間違ってしまうことがあります。

「仕切る」立場としてシステム障害をどう乗り越えるか

それでは、仕切る立場として、システム障害を迅速かつ適格に収束させるために、どのようなことをしなければならないのでしょうか。

重要なマインドセット

障害対応の際の重要なマインドセットとしては、「エンジニアを信用する」ことだと思います。というよりも事実としては「信用するしかない」だと思います。

時々「対応を早くしろ」と怒ってきたり、偉い人を連れてきた李しますが、これをやってもやらなくても、時間は一緒です。むしろ話をしている時間遅れます。

「早くしろ」と言ってる時間が一番無駄だと心がけましょう。

1) エンジニアと外部のやりとりをコントロールする

対応にあたっているエンジニアに集中できる環境を整えるため、ビジネスサイドの情報を入れない工夫をしましょう。具体的には、ビジネスサイドがエンジニアにコンタクトできないように工夫しましょう。これは、電話の音声を聞こえないようにしたり、チャットを操作画面から見ないようにはたらきかけることです。

このとき、エンジニアに伝えるべきビジネスサイドの声は以下です。

  • ビジネス上の決断に必要なシステム再度の情報
    • (公式に発表する復旧時間 など)
  • ビジネス上の確定事項

上記以外は臨機応変というしかないですが、だいたいがノイズになると思われます。

ただ、ずっと隔離していると今度はお互いの認識のずれが出てくるリスクもありますので、定期的にチェックポイントを設けるなどして、コントロールをすることが必要です。

2) 発言の理由を確認する

「それは、なぜですか?」ときくようにしましょう。

質問でも、なぜ聞きたいのかによって、答えが変わる場合があります。

また、その重要度がわからなければ、後で「それ先に言ってよ」と言われることになったり、逆に「そんなの別に言ってこなくていいよ」となる場合もあります。

障害は、深夜に発生することもあるため、とても体力を消耗します。そのため、右から左に受け流すような態度になってしまいそうなこともあるのですが、迅速な解決を目指すのであれば、とても重要なプロセスです。

3) 記録し、共有する

新たな参加者に対して、「ここを見てください」といえる仕組みを作っておきましょう。

障害を対応するにあたって、現在の対応状況、判明している原因や影響、復旧の時限や守れなかった場合の影響などをひとつのドキュメントにまとめていきます。

私が銀行にいたころは Notesを使っていましたが、今ではSlackや、GoogleDocs、Office365のWEBなどが使えるのではないかなと思います。

それでもだめなときは印籠を渡す

上記の施策で、できる限りエンジニアが集中できる環境を作ることができます。

しかし、それでも、元のツイートでいう「食い込んでくる馬鹿」がいなくなるわけではありません。意味のない罵声を浴びせてきたり、対応中のオペレーションルームに現れたりします。その際にはどうすればよいでしょうか。

私が思うには、「大きな声」で、その人が「邪魔だと、本人に気づかせる」しかないと思います。

大きな声はいつでも有用です。何より真摯に対応していることを相手に伝えることができます。

声を荒げるのではなく、落ち着いてゆっくり大きな声で話しかけます。

そして、「邪魔だと、本人に気づかせる」方法ですが、一番の方法は「それは一理ありますね。それでは一旦作業止めますか?」や、「私はその方法がわかりませんので、かわりますか?」と聞くことです。

適当にあしらっているとずっと粘着していますが、たいていの場合、彼らは印籠を渡そうとすると引き下がります。

(「どういうつもりで言ってたんだよ」と思い、すごくむかつくのですが、ここで怒っても仕方ありません)

若干リスクを伴うのですが、粘着質に付き合わされるよりも、早く終わらせることのほうが重要だと私は考えます。

まとめ

今回は、すこし本業に関するお話をしてみました。

書いていて思ったのですが、実は同じことが開発でも言えるのではないかなと思います。

たとえば「早くしろと言ってる時間が無駄」なんかはわかりやすいですね。

結局のところ、相手へのリスペクトが重要なんだと思います。そこにエゴやヒエラルキーを持ち込むと、モノづくりは破綻するのではないかと思います。

みなさんの現場はいかがでしょうか?Twitterなどでご意見いただけると嬉しいです。

それではまた後日。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA