チーム
2018.05.09

正しいアラートの上げ方 – インシデント対応と報告の処方箋 1 連載9回目

前回までは、チームリーダー向けの内容でお送りいたしましたが、今回は少し観点を変えて、チームメンバー向けの内容を書いてみたいと思います。

バグを出してしまった、オペミスをしてしまったときの正しいアラートの上げ方

本番リリースにおいてテストをすり抜けてしまったバグがあった、オペミスをしてしまったという経験は誰しもあると思います。常日頃からこうした事態に備えているつもりでも、いざやってしまった時に冷静に行動できるとは限りませんが、こうしたインシデント発生時には、できるだけ落ち着いた行動が取れるようにしたいものです。先に絶対守るべき大原則を書いておきますと、決して1人で解決しようとせず、必ずチームメンバーへアラートを上げましょう。

まず事実から報告する

何をどうやらかしたところで、時計の針をもとに戻すことはできません。現実の世界は残念ながら不可逆です。ほとんどのケースにおいて、自分で何とかしようとするよりも、まず上席者に報告しましょう。
報告の際には、まず事実を簡潔に報告し、これから対処する旨も伝えましょう。ただし、対処方法が曖昧な場合は、無理に自分で火消しをしようとせず、上席者の判断を仰ぎましょう。
一方で、上席者への報告より前に対処に着手したほうがよいケースもあります。それは

  • 見えてはいけないコンテンツを見せてしまったことが明確にわかっている
  • ファイルの上書きや該当SQLのupdate、ダンプファイルからのリストアなどの復旧手順を理解している
  • WEBサイトをメンテナンスモードにするなどの一時的な対応手順を理解している

これらの条件が揃っていれば、チームメンバーに代わりに上席者へエスカレーションしてもらい、自ら対応するのもありです。何故ならば、

  • 自らおこしたわけでもないミスを尻拭いさせられるのは大抵において嫌がられる
  • チームメンバーへの状況説明と対処方法説明をしている時間と自ら初動をとる時間を考えると、圧倒的に後者のほうがリードタイムを短くすることが可能である
  • インシデントの対処と報告は、複数人で並行したほうが早く、かつ事実の客観性が担保されやすい


このように、初動と報告の役割を分離するメリットがあるからです。ただし、先にも述べたように、いきなり初動を他のチームメンバーへ押し付けるのは非常に嫌われます。また、後述するように、自ら初動をとる自信がない場合、まずチームメンバーに相談して役割分担を柔軟に決めるのは、被害拡大防止という観点から有効です。どちらのケースがよいか瞬時に判断できない場合は、まずチームメンバーに相談しましょう。

時系列を把握する

最終的に顧客へ障害報告するために、時系列で何をしたのかを記録しましょう。少なくとも、当事者ともう1人の最低2人で対処することが理想です。インシデント当事者が自らリカバリ対処することが可能であれば、チームメンバーは時系列の記録を行います。逆に、当事者が自ら対処することが困難である場合は、この役割が逆転することになります。

証跡を残す(隠蔽しない)

どのようなリカバリを行うにせよ、必ずファイルのバックアップを取るなど、容易に手戻りができるように心がけ、証跡を残すようにしましょう。特に、性能系のパラメーターなどのようにトライアンドエラーを繰り返す場合は尚のことです。そして、「どういう思考過程を経て最終的なパラメーターに行き着いたのか」という過程を残すことは、チームにとって大きなナレッジとなります。

以上が、インシデント発生時のスキルセットの骨子になります。次に、インシデント発生時のマインドセットについて踏み込んでみたいと思います。

インシデント発生時におけるマインドセットのありかた

インシデント発生時、その当事者はどうしても自己防衛本能がはたらきます。これ自体は否定しようのない事実ですが、本質的な解決を行なうには、ドライな処理を行なうしかありません。しかし、1人で解決しようとするあまり、意図せずまたは悪意をもって事実とは異なる報告をしたり、事実そのものを隠蔽しようとしたりするのは、自己防衛本能がネガティブに働いた結果おきるものです。
こうした行動は本質的な解決を遅らせるばかりでなく、結局のところはインシデント当事者がチームでの信頼を失うことにも繋がりかねません。ではどうすればよいのか、について考察してみたいと思います。

1人で抱えこまない

どんなにベテランのエンジニアであっても、インシデント対応を1人で抱えこんではいけません。また、非熟練エンジニアの場合は、ベテランエンジニアとは違う理由で、1人で抱えこんではいけません。
ベテランエンジニアの場合、「自分としたことが」というプライドがはたらき1人で抱え込んでしまうことで、解決までの道のりがややこしくなってしまいがちです。一方で、非熟練エンジニアの場合は、単純にパニックに陥りやすいためです。

転ばぬ先のメンター

インシデントを起こさないに越したことはありませんが、リスクを恐れるあまり及び腰になるのは、自らの成長を阻害し、責任を回避する態度はチームメンバーの信頼を失うことに繋がります。
また、先に述べたように、逆に1人で抱えこんでしまうことは「何がなんでもインシデントに立ち向かう」ことで視野狭窄をおこしてしまいます。
そこで「転ばぬ先のメンター」です。普段から「この人になら話しやすい」というメンターをチーム内に見つけ、上司に直接報告しにくいことも、最初にメンターへ話せるようにすることで、1人で抱えこむことを防ぎます。ただし、上司への報告を丸投げするようではいけません。

チームでインシデントに立ち向かうために

そもそも論として、どんなインシデントであれ、個人に責任を押し付けるのはチームとして不健全です。また、インシデントが発生する余地があるということは、改善の伸びしろがあるということも意味しています。
チームでインシデントに立ち向かうにあたり、決して「誰が」という観点ではなく「何が」という観点をもってください。人依存の解決を試みるということは、単に人を置き換えればおしまい、臭いものに蓋という考えです。しかし、これでは本質的な改善に繋がりません。
また、チームリーダーは、公平な観点で、かつ主体的にメンバーのフォローにまわり、まず解決を最優先、メンバーの資質を問うのは解決後にしましょう。インシデント発生時におけるリーダーの振る舞いについては、次回取り上げる予定です。

まとめ

  • インシデントをおこした当事者は多少なりともパニックに陥るものである。
  • まず事実から報告する。初動と同時に初報を行うのが望ましいので、チームメンバーの協力を仰ぐ。
  • 顧客への障害報告のため、時系列を把握する。1人での対応を行うと時系列把握が困難であり、最低でも2人以上で対応すること。
  • インシデント対応の証跡は必ず残すこと。途中の思考過程は財産となる。
  • 上席者へ直接報告しにくい場合、メンターに相談することは有効である。ただし、インシデント発生報告を丸投げしないこと。
  • チームでインシデントに立ち向かうには、「誰が」いけないのかではなく、「何が」いけなかったのか、人ではなく原因となる行為や結果にフォーカスして改善をはかること。

間違いないチームマネジメント

競争的な市場の中でビジネスを加速させていくためには、強力なチームの存在が欠かせません。効果的なチームビルディング術や、チームでの共同作業に役立つツールやポイントを押さえることで、最高のチームを作り出しましょう。

詳細を確認する

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事