数多くの障害を起こしてきたPMが思う障害対応で大事なこと3選

ブログを読むと良さそうな人

• webサービスの障害対応しているが合っているかわからない

• 障害対応のフローを改善したいがどうしたら良いかわからない

障害について

webサービスを運営していると障害って起こりますよね。

設定ミスであったり、考慮漏れだったり、サーバー落ちたりなど大なり小なりユーザーからすると障害にあたります。

障害を起こさないことは前提ですが、起こってしまったら素早く対応する必要があります。

自分が障害が起こった際のフローを改善する機会があったので、障害対応で大事だと思うことをまとめてみました。

組織の障害対応で変えたこと

障害対応のフローを3つ大きく変えました。

IC(インシデントコマンダー)を立てる

変更前

変更後

自分の属している組織はサービスを自分ごと化する人が多く、障害が起これば連絡ツール上で顔を出す人が多いです。
ただ、取りまとめる人とフローが曖昧でした。

今は自分ごと化する人が多いですが、組織の人が変わっていくと障害に対して反応されないこともあるかもしれません。
障害対応に顔を出しいる人が少なければ、情報が揃わず、迅速に正しい判断ができないかもしれません。

そこで、障害が起こった要因ごとにIC(インシデントコマンダー)を立てるようにしました。
ICを立てることで、障害事象・要因・影響範囲が迅速に正確に把握できるような仕組みに近づきました。

障害を組織に可視化する

変更前

変更後

障害が起こっていることを組織へ伝えるフローを整えました。

今までは障害の規模感に応じて各個人の判断で組織へ@hereなどで障害報告をしていました。

全員へ告知するレベル感が人に寄ってしまう点、迅速に組織へ障害が報告されない点に課題を感じて、Slackのワークフローで組織全体へ適切な情報を共有できるフローを作成しました。

障害時は数秒でも早く障害収束をさせることが大事になります。

障害を収束させるためのコミュニケーション工数をなくすためにも、障害事象をまとめて適切なメンバーへ伝えるフローがあることが大事です。

振り返りMTG

変更前

変更後

障害がひと段落して、再発防止を考えるフローもIC主体にするようにしました。
ICの責任範囲が
障害把握→収束→再発防止
までと広いため、IC担当をチームリーダーや役職リーダーにすると責任範囲やミッション的に適切になると思っています。

障害が起こると通常の業務を止めながら最優先で対応しないといけず、緊張から心もすり減ります。
誠実に対応することで、組織からの信頼も少しずつ増えていくと思います。

ピンチはチャンスという気持ちで、いざ障害が起こったら踏ん張って誠実に取り組んでいきましょう！