🐡

開発における障害対応フローの運用をはじめた話

FukutomiQA

2025/02/07に公開

障害対応

idea

 ごあいさつこんにちは。マイベストでひとりQAをしているfukutomiです。

早いものでマイベストに来て1年が経ちました。
…いや、早くないですか？

30歳を超えてから月日が経過するのが加速度的に早くなっている気がします。

令和がもう7年目であることが信じられません。
さてさて、今回は障害対応フローを整備して運用を始めてみたよという話です。

障害、、、それはエンジニアとしては最も聞きたくない言葉のひとつだと思いますが、起こってしまったからにはちゃんと振り返って今後発生しないようにしなければなりません。

その過程をフローとして整備することで、過去の障害情報をしっかり蓄積するとともに、全員が障害発生時に自然と体と頭が動く状態にしておくことを目的としています。

それではよろしくお願いします。

 障害対応フローをまとめる目的
 なぜフローを整備するのか改めて、障害対応フローをまとめる目的は以下です。
障害が発生したときの対応フローを明確にすることで、誰でも対応できるようにする
過去の障害をDB化しておくことで今後の糧にしやすくする
再発防止策が実装されるまでをしっかり追えるようにする
障害が発生したときのコミュニケーションを一部自動化し、伝達漏れ等が発生しないようにする
フローを整備することで、みんなが自然と障害対応に集中することができ、情報伝達も滞りなく行われる状態を目指します。

 今までの障害対応フローはどんな感じだったのかでは今までがどうだったかというと、下記の感じでまわっていました。
障害に気づいたメンバーが連絡
大きな障害であれば全社的に連絡するが、小さい障害だとごく一部の関係者にしか通知されないこともあり、基準が曖昧になっている

障害履歴はNotionDBを利用してまとめているが、小さい障害だと記入されないこともある
再発防止策はエンジニアで議論されるが、その進捗は追われていない
上記のように、ルールが定まっていないので障害発生の周知が適正に行われなかったり、振り返りをしても再発防止策まで実装されないケースが散見されていました。

善意による障害連絡の例

 こんな感じでまとめましたということで本題。実際に作ったフローはこんな感じです。

まずは全体フロー図をご覧いただければ。

めっちゃ縦長で恐縮ですが、、、

 障害対応フロー全体図各項目の詳細は次項で！

 もう少し詳細に
 障害発生〜重要度判断〜情報伝達障害が発生したことに気づいたら、下記の通り策定した基準に基づき重要度を判断します。

重要度が決まったら、Slackの第一報ポストにリアクションをつけます。

すると、Zapierが作動し重要度に応じた情報伝達を行います。
添付した画像の場合はP0障害（一番重要度が高い障害）なので、全社向けのチャンネルに @channel をつけて周知しています。

また、リリース連絡を行うチャンネルでも @channel をつけて周知し、障害が解消されるまではリリースを避けてもらうようにしています。

 全力で修正対応ひとまず関係者への周知が終わったので、全力で修正対応を行いリリースします。

リリースが終わったら対応完了連絡を行います。

 障害振り返りの準備修正対応が完了したら振り返りの準備を行います。

下記基準に沿ってオーナーを決め、障害報告やミッション内振り返りのセッティングを行なっていただきます。

 ミッション内で振り返りを実施、再発防止策の考案ミッション関係者を集めて振り返りを行います。

オーナーより障害の概要を説明してもらい、再発防止策を考案します。

再発防止策は基本的に仕組み化していただくようルールを定めています。

「〇〇を意識する」「〇〇を徹底する」というような防止策は結局忘れられてしまうし、ルールに意識が引っ張られて開発生産性が下がってしまう恐れもあります。
その代わり、影響範囲や頻度が低い障害への対応コストが大きくなりすぎないよう場合によっては防止策がないこともある、ということを明記しています。

 再発防止策のエンジニアレビューミッション内で再発防止策を策定したらエンジニアレビューを通します。

Slackでワークフローを作成したので、そちらから入力していただく感じです。

また、ミッション振り返りで悩んだ時はこのステップでエンジニアに相談することも可能です。

 再発防止策の共有、実装状況確認再発防止策が確定したら共有・見守りフェーズに入ります。

隔週で行われるエンジニア相談会および、月1で行われるプロダクト全体会（PdM、エンジニア、プロダクトデザイナーが全員参加する会）で障害内容の共有と、再発防止策の実装状況を共有します。

 実際に運用してみての感想、これから前半部分、情報伝達までは2024年10月に運用を開始しましたが、今のところうまくまわっています。

第一報の投稿に対してスタンプをつけるだけで他部署への連絡ができるので、この部分はまさに仕組み化することで連絡不足や連絡コストを解決することができたと言えそうです。
対して後半部分、振り返りフローはまだ2025年1月に運用を開始したばかり。

現時点で数回振り返りを実施していますが、まだまだブラッシュアップが必要だなと感じます。

ほぼほぼ仕組み化できている前半部分と違い、こちらはまだまだルールが多く運用していくのにフォローが必要な状態です。

もちろん月日が経つにつれルールは浸透していくと思いますが、仕組みで自動化できることに越したことはないので、これからも隙あらば改善施策を進めていきたいと思います。
ひとまずこれで過去の障害データ蓄積がスタートしました。

障害データが蓄積されていけば、どの機能や工程で障害が起きやすいのかが自ずとわかるようになっていくはずです。

そうすれば開発プロセスも改善され、開発体験も生産性も向上していくことでしょう。

実現するのはまだ先の話となりそうですが、これからも頑張ります！
それではまたどこかで！