障害対応フローを定めてから1年の現在地 / One Year Mark: Progress in Incident Management

マイベストで障害対応フローを定めてから1年が経ちました。
フローの詳細、成果、課題をまとめた資料です。

Transcript

1. October 30, 2025 @FukutomiQA 障害対応フローを定めてから 1年の現在地
2. 01 自己紹介
3. 福富 はじめ（ふくとみ はじめ） • 1991年　静岡県生まれ • 2014.04 - 地元の制作会社でSWEになる • 2017.11 - 上京、赤い第三者検証会社で QAエンジニアになる • （なんやかんやあって） • 2024.02 - 株式会社マイベスト(現職) スポーツをTV観戦するのが好きです（海外サッカー、野球が中心です が、最近NBAにも目覚めてしまいました） @FukutomiQA 自己紹介 FukutomiQA
4. 02 マイベストの紹介
5. 月間利用者 数 3,000 ユーザーの “選択”を サポートするサービス 万人以 上 （2025年9月時点）
6. 選択に資するデータベースを作るために、 ユーザーニーズや利用シーンに合わせて 各領域で専門性を持ったメンバーが徹底検 証を行い、唯一無二のデータベースを制作しています。 商品を自社で購入し、専門性を持ったメンバーが徹底検証 雨傘の検証。送風機を使って「耐風性」を比較 防水カメラの検証。プールを貸し切り、実際に潜って撮影 縦型洗濯機の検証。主要メーカー 7社の中から人気 18商品を購入して検証 ヘアアイロンの検証。全商品を実際に使用して違いを検証 チェーンソーの検証。片道 2時間ほどかけて、山奥にこもって検証 電子レンジの検証。実際の使い勝手などをリアルに検証
7. ユーザーは私たちのコンテンツを信頼してくれている
8. システム障害で信頼を損なうわけにはいかない
9. ちゃんと管理して、再発防止に努めよう
10. そんなマイベストで運用している 障害対応フロー、再発防止策の運用フローについて お話しします
11. 03 マイベストの開発組織
12. 特定のミッション（プロジェクトチームのこと）には所属せず、品質観点からスループットの向上を目指す QAエンジニアはイネーブリングチームに所属 参照：開発のボトルネックを取り除きスループットを向上させるイネーブリングチームの立ち上げについて
13. マイベストの開発組織はリリース数が非常に多い デプロイ周りの仕組みが整っていて、できたものからどんどん出しているので 1日10件前後のリリースが実施される 参照：Findy Team+ DevOps分析
14. 04 マイベストの障害対応フロー [Before・~2024/9/30]
15. 基本的には誰かが善意で対応していた • 障害に気づいたメンバーが連絡 ◦ 大きな障害であれば全社的に連絡するが、小さい障害だとごく一部の関係者にしか通知されないこと もあり、基準が曖昧になっている • 障害履歴はNotionDBを利用してまとめているが、小さい障害だと記入されないこともある ◦ 再発防止策はエンジニアで議論されるが、その進捗は追われていない
16. 05 マイベストの障害対応フロー [after・2024/10/1~]
17. 全体フロー
18. めちゃ長くてすみません
19. 障害発生から連絡まで
20. 障害発生から連絡まで Point! • 障害重要度を明確に定義して、優先度判断を誰でもできるようにしている • Zapierを利用して、関係各所への連絡を自動化している
21. Appendix：障害重要度判断基準
22. Appendix：障害連絡の自動化イメージ 障害に気づいたらSlackスタンプ 障害に気づいたら、その重要度に応じてSlackのリ アクションを付与する Zapierが重要度に応じて各所に連絡 Zapierを利用し、付与されたリアクションの重要度 に応じて各所に連絡を行う リリース連絡を行うチャンネルにも通知 リリース連絡を行うチャンネルでも @channel をつけて周 知し、障害が解消されるまではリリースを避けてもらうよ うにしている
23. 修正対応からリリースまで
24. 修正完了から再発防止策実装まで
25. 修正完了から再発防止策実装まで Point! • 事前にオーナーを選定して、再発防止策実装まで責任を持って行う人を決める • 障害報告は Notion DBで管理 • 障害報告には影響を受けたコンテンツ数や該当期間の PV数まで詳細に記入してもらう • 再発防止策は仕組み化できることを条件とし、場合によっては防止策がないこともある • 振り返りで出た再発防止策案は、テックリードや CTOのレビューを通して最終決定される • 障害内容や再発防止策実装状況は、隔週で実施するエンジニア相談会で共有する
26. Appendix：障害をまとめている NotionDB
27. 06 運用してみて
28. リリースに対する障害は間違いなく減ってきている 変更障害率：hotfixブランチ数 / マージしたブランチ総数 × 100 で、5％以下ならEliteとされる 参照：Findy Team+ DevOps分析 障害対応フロー運用開始(2024/10/1~)
29. • そもそも、実装完了までトラッキングできるようになったことが収穫 ◦ 今までは実装完了まで追えていなかった • 障害を記録に残すことでナレッジ化することができている • 「〇〇しないことを意識する」みたいな再発防止策が生まれない • ステップ数が多すぎて、対応者がドキュメントを見ながらじゃないと対応できない ◦ 仕組み管理者である Fukutomiがフォローしないとまわらない部分がある • 再発防止策は事業課題に優先度で敵わないことがある ◦ 再発防止策の実装は放置されがち。。。 よかったところ、まだまだ課題なところ 運用を始めたからこそわかる課題がたくさん More... Good!
30. 07 これからの展望
31. 運用を始めてから 1年あまり、、、まだまだ改善したい！ やりたいことはたくさんある • まだまだバッチリフィットしたフローにはなっていない ◦ 前のスライドで挙げた通り、改善点はいっぱいある • 実装済みの防止策を棚卸ししたい ◦ 時間が経てば運用も変わる　不要になる再発防止策もあるはずだ • 再発防止策の実装優先度を定義して、期日も簡単に決められるようにしたい ◦ 現状は障害重要度によって決められているが、それだと違和感があることもある • 再発防止策の実装状況管理を各ミッションにお願いするようにしたい ◦ ミッションで起こした障害はミッションで再発防止までちゃんとやりたいね • etc…
32. Appendix：障害再発防止策実装優先度（検討中）
33. 障害を減らすことで、 メンバーが事業に向き合う時間が増える そうすれば会社のビジョン達成にも早く近づけるはず
34. これからもイネーブリングチームの一員として 障害に向き合っていきます
35. Thank You!