開発におけるプロダクション炎上 — 意味、原因、アクション手順

“プロダクション炎上”の意味と障害の種類

“プロダクションが炎上している”（すべてダウン）という表現は、プロダクション環境が正しく動作しておらず、ユーザーに影響が出ている状況を表します。障害は、アプリケーションの完全な利用不可（空白画面、502エラー）、部分的な利用不可（支払いモジュールは動作しないが他の機能は利用可能）、またはパフォーマンス低下（極端に遅い読み込み）として現れることがあります。インシデントの深刻度は、影響を受けるユーザーの割合と障害の期間によって決定されます。

Atlassian Statuspage（2025）によると、2024年のモバイルアプリケーションの平均ダウンタイムはインシデントあたり27分でした。最も一般的な原因：デプロイ後のコード回帰（34%）、クラウドプロバイダーの障害（22%）、データベース問題（18%）、設定ミス（15%）、DDoS攻撃（11%）。重要な教訓：ほとんどの障害は外部要因ではなく、チーム自身が行った変更によって引き起こされます。

クラッシュ（クライアント側のアプリケーション障害）とバックエンド障害（サーバー利用不可）を区別することが重要です。クラッシュは通常、クライアントコードのホットフィックスで修正されますが、バックエンド障害はインフラストラクチャの変更またはサービスの再デプロイが必要です。監視メトリクス：クライアントの場合 — クラッシュフリーレート、サーバーの場合 — 5xxエラーレートとp95レイテンシ。APM（アプリケーションパフォーマンス監視） — Sentry、New Relic、Datadog — 障害の種類を迅速に特定するのに役立ちます。

インシデントの深刻度：P0、P1、P2と分類基準

統一された深刻度分類は迅速な対応の基盤です。それがなければ、チームは行動する代わりに「これがどれほど緊急か」を議論する時間を無駄にします。古典的なスケール：P0（重大）— アプリケーションが完全に利用不可、またはユーザーデータが漏洩している、応答時間 — 即時；P1（高）— 50%以上のユーザーで重要な機能が動作しない、応答時間 — 15分；P2（中）— 一部のユーザーで重要でない機能が利用不可、応答時間 — 1時間。

P0は即時のエスカレーションが必要です。オンコールエンジニアは現在の作業をすべて中断し、インシデントに集中します。10分以内に問題が解決しない場合 — テックリードが参加します。30分後 — エンジニアリングマネージャーへのエスカレーション。P0インシデントでは、完全なコードレビューなしでのホットフィックス、本番への直接デプロイ、ブランチ保護ルールの無視など、あらゆるプロセスを破ることが許容されます。緊急オーバーライドはチームレベルで事前に合意されている必要があります。

深刻度テーブル

深刻度を過小評価しないことが極めて重要です。P2と分類されたP0およびP1インシデントは、対応の遅れとダウンタイムの増加につながります。ルール：疑わしい場合はP0を設定してください。過大分類は過小分類よりも優れています。復旧に1時間を失うよりも、余分なミーティングを開くほうが良いのです。

最初の10分間：障害時のアクション手順

タイマースタート：アラートまたはユーザーからのメッセージが届いた瞬間からです。最初の10分間が最も重要です。手順：1）問題を確認する — 問題が本物であることを確認する（誤警報ではない）；2）止血する — 直ちに影響を減らす（ロールバック、フィーチャートグル、エンドポイントブロック）；3）コミュニケーション — 共通の#incidentチャンネルに状況を投稿する：何が起こったか、深刻度、何をしているか。最初の10分間は根本原因分析に費やされません。

止血と並行して、一人のエンジニアが診断を開始し、もう一人がコミュニケーションを担当します。コミュニケーションチャンネル：Slack #incidentチャンネル（チーム向け）、ステータスページ（ユーザー向け）、エスカレーション用メール/SMS（管理職向け）。15分ごとに — 情報を含むステータス更新：何がわかっているか、何をしているか、復旧予定時間。ステータスページ（StatusPage、Statuspal）は外部ユーザー向けにアップタイムとインシデント履歴を表示します。

止血方法：ロールバック、フィーチャートグル、ホットフィックス

最初で最も重要なルール：本番環境で問題を修正しようとしないでください。新しいリリースが障害を引き起こした場合 — 以前の安定バージョンにロールバックします。特定の機能がフィーチャートグルの背後にあって障害を引き起こしている場合 — トグルをオフにするだけです。ロールバックもトグルも利用できない場合 — 最小限の差分でホットフィックスを適用します。ロールバックは、すでに動作していた状態に戻すため、最も安全なオプションです。

フィーチャートグル（別名フィーチャーフラグ）は、デプロイなしで止血するための強力なツールです。支払いモジュールがトグルで無効になっている場合 — ユーザーはエラー画面を受け取る代わりに、単に支払いボタンを見ません。トグルはビルドを必要とせず、ストアレビューも不要で、数秒で有効になります。重要な機能はすべて、サーバーレベル（リモート設定）で無効にできるフィーチャートグルの背後にあるべきです。フィーチャーフラグ — 防御の第一線。

ロールバックが不可能な場合（例：不可逆的なデータベースマイグレーションのため）でトグルもない場合 — 最後の手段は最小限の変更によるホットフィックスです。ホットフィックスは最新のリリースタグから作成され、障害修正に必要な行のみを含み、高速トラックでデプロイされます（記事「ホットフィックス — 緊急修正」を参照）。黄金のルール：安定化後は、原因が明白に思えても、常に根本原因分析を実施してください。

原因診断：ログ、メトリクス、アラート

止血後（またはエンジニアの人数が許せば並行して）診断を開始します。最初の情報源はログです。集中ログ管理（ELK、Grafana Loki、Datadog Logs）により、タイムスタンプ、ユーザーID、リクエストIDでエラーを見つけることができます。重要：grepが高速に機能するよう、ログは構造化（JSON）されている必要があります。構造化ログはすべてのサービスに必須の要件です。

2番目の情報源はメトリクスです。Grafana、Datadog、New Relicは、エラースパイクがいつ発生したか、どのエンドポイントで、どのステータスコードで発生したかを示します。デプロイ前後のメトリクスを比較することで、問題を特定のサービスやエンドポイントに特定できます。REDメトリクス（Rate、Errors、Duration）— マイクロサービス監視の標準です。

3番目の情報源は分散トレーシングです。Jaeger、Zipkin、Datadog APMは、マイクロサービスを通るリクエストのパスを表示し、遅延やエラーが正確にどこで発生したかを特定します。トレーシングは、あるサービスの障害が依存するすべてのサービスにエラーを引き起こすカスケード障害で特に有用です。トレースIDはクライアントからすべてのバックエンドサービスに渡される必要があります。

# kubectlとログを使ったクイック診断例
# エラーのあるPodを一覧表示
kubectl get pods --field-selector=status.phase!=Running

# クラッシュしたPodのログを確認
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# 過去30分間のサービスのエラーを検索
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

重要：止血前に原因の診断を試みないでください。50%のユーザーがクラッシュを見ている場合 — 最初にロールバックし、その後調査します。例外：ロールバックが直接ホットフィックスよりも時間がかかる場合（例：データの非互換性のため）。この場合、直ちにホットフィックスを適用し、安定化後にポストモーテムを実施します。修正前の診断はダウンタイムを増加させる危険なパターンです。

ポストモーテム：非難なしでインシデントをレビューする方法

ポストモーテム（インシデントレビューとも呼ばれる）は、解決後24〜72時間後に実施される構造化されたインシデント分析です。その目的：障害がなぜ発生したか、監視とテストが本番前にそれをなぜ捕捉できなかったか、再発を防ぐためにプロセスを何を変更すべきかを理解することです。ブレームレス文化は基本原則です。ポストモーテムはプロセス、ツール、コミュニケーションについて議論し、特定の個人の過ちについては議論しません。

ポストモーテム文書の構成：タイムライン（タイムスタンプ付きのイベント時系列）、影響（影響を受けたユーザー、期間、財務的損失）、根本原因（技術的な根本原因）、検出（どのように発見されたか、なぜ早期に捕捉できなかったか）、対応（何を行ったか、より迅速に何ができたか）、アクション項目（責任者と期限付きの具体的なタスク）。アクション項目はS.M.A.R.T.である必要があります：具体的、測定可能、割り当て可能、現実的、期限付き。

本番障害後の典型的なアクション項目：沈黙していたメトリクスに監視とアラートを追加する；見逃したケースのテストカバレッジを拡大する；同様の状況のためのステップバイステップ手順を含むページをランブックに追加する；誤って使用されたツールについてチームトレーニングを実施する。各アクション項目は、インシデントの再発可能性を減らす具体的な変更です。