障害が多いWebサービスを改善する優先順位の付け方
本番でエラーが頻発し、顧客から「また落ちてるんですけど」という問い合わせが週に何度も来る。エンジニアは深夜のアラートで疲弊し、直したはずの不具合がまた別の場所で再発する——。障害対応に追われるフェーズのプロダクトからよく相談を受けます。この状態で一番危険なのは、目の前で騒がれた不具合から順に潰していく「もぐら叩き」です。この記事では、闇雲に直す前に踏むべき優先順位のつけ方を整理します。
なぜ「目についた順」に直すと悪化するのか
障害が頻発している現場ほど、対応の順番は「クレームが来た順」「声が大きい人の要望順」になりがちです。これには2つの問題があります。
- 影響度の小さい不具合に時間を取られ、本当に重い障害の再発防止が後回しになる
- その場しのぎの応急処置を繰り返すうちに、コードがさらに複雑になり、次の障害を生む
疲弊している現場ほど「早く鎮火したい」という気持ちが先に立ちますが、順番を間違えると同じ火事を何度も消すことになります。まず必要なのは、勢いで直す前に一度立ち止まって状況を可視化することです。
第一歩は可視化。監視・エラー通知がないと優先順位すら決められない
意外に多いのが、そもそも障害の全体像を把握できる仕組みがない状態です。監視やエラー通知が整っていないと、次のようなことが起きます。
- 顧客から言われて初めて障害に気づく（サイレント障害を見逃している)
- 「体感、最近よく落ちる」という印象論でしか状況を語れない
- 同じエラーが月に何回起きているのか、誰も数字で答えられない
この状態で優先順位をつけようとしても、材料がないので勘に頼るしかありません。最初にやるべきは、次のような低コストで入れられる可視化です。
- エラートラッキング(Sentry等)でアプリケーション例外を自動収集する
- アップタイム監視で外形的な死活監視を入れる(落ちたらSlack通知)
- アクセスログ・エラーログを集計し、頻度と影響範囲が見える状態にする
これだけで「どのエラーが何回起きているか」「どの機能でユーザーが離脱しているか」が数字で見えるようになります。可視化なしに障害対応を始めるのは、レントゲンを撮らずに手術するようなものです。
トリアージの軸は「影響度 × 頻度」
可視化ができたら、集まった障害・不具合を1件ずつ評価します。判断軸はシンプルに2つで十分です。
- 影響度: 決済や申込など収益に直結する機能が止まるか、全ユーザーに影響するか、一部の限定的な機能か
- 頻度: 毎日発生しているか、月に数回か、特定の条件でしか再現しないか
この掛け算で優先順位のマトリクスを作ります。
- 影響度・頻度ともに高い: 最優先。決済失敗が毎日起きている、ログインが度々落ちる、といった類。ここから着手する
- 影響度は高いが頻度は低い: 発生時のダメージが大きいため、応急処置(手動リカバリ手順の整備等)を先に用意しつつ根本対応を計画する
- 影響度は低いが頻度は高い: 顧客体験を地味に削り続けるため軽視できないが、緊急度は1より下
- 影響度・頻度ともに低い: バックログに入れて計画的に対応する
「クレームの声の大きさ」ではなく、この2軸で並べ替えるだけで、対応順序に対する社内の合意も取りやすくなります。
応急処置と根本対応を分けて考える
障害対応でもう一つ重要なのが、「止血」と「治療」を切り分けることです。
- 応急処置: 再起動、手動でのデータ修正、一時的な機能制限など、今の火を消すための対応。速さが正義
- 根本対応: なぜそのエラーが起きたのかを特定し、コード・設計レベルで再発しないようにする対応。時間がかかる
応急処置だけで終わらせてしまうと、同じ障害が形を変えて再発します。逆に、応急処置なしでいきなり根本対応に着手すると、その間ユーザーへの被害が続いてしまいます。「今日中に止血する」「原因調査と修正は今週中に着手する」というように、対応のタイムラインを分けて管理するのが実務的です。
根本原因の多くは「技術的負債」と「テスト不足」
障害の原因を掘り下げていくと、多くのケースで行き着くのは次のどちらかです。
- 技術的負債: 影響範囲が読めないコード構造、同じロジックの重複、古い依存ライブラリなど。小さな変更が予期しない箇所を壊す土壌になっている
- テスト不足: 変更のたびに手動確認頼みで、リグレッション(既存機能の再破壊)を機械的に検知できない
これらは1回のパッチでは解消しません。ただし、障害が起きた箇所から優先的にテストを足していくというアプローチであれば、全面的な書き直しをせずに着実に安定度を上げられます。このあたりの考え方は既存プロダクトの改善、外部チームが最初に見る観点でも詳しく解説しています。
また、障害の原因が「誰がどうデプロイしたか分からない」「デプロイ手順が属人化していて再現できない」ことに起因しているケースも少なくありません。この場合はデプロイの属人化を解消するような運用改善が根本対応になります。
まとめて改善するか、外部に相談するか
障害対応に追われている現場では、社内のエンジニアが目の前の火消しで手一杯になり、可視化や根本対応まで手が回らないことがよくあります。その場合は、外部チームに一時的に入ってもらい、可視化の整備からトリアージ、根本対応までを並走してもらうのも現実的な選択肢です。torcheees では保守・運用やモダナイゼーションのサービスとして、こうした障害多発プロダクトの立て直しを支援しています。
まとめ
- 障害対応は「声が大きい順」ではなく、まず監視・エラー通知で状況を可視化してから「影響度 × 頻度」でトリアージする
- 応急処置(止血)と根本対応(治療)を分けて考え、それぞれ別のタイムラインで管理する
- 根本原因の多くは技術的負債とテスト不足にあり、障害の起きた箇所から優先的に整理・テスト追加していくのが現実的な進め方
障害対応に追われて優先順位が見えなくなっている場合、torcheees では「既存プロダクト改善 診断」として、現状のコード・インフラ・監視体制を確認し、改善の優先順位と概算費用をご提示します。まずはお問い合わせフォームからご相談ください。