PHPアプリケーション向けインシデントRunbookは、アラートを制御された意思決定の連続へと変換します。これはコマンドの一覧でも、原因を前提とする文書でもありません。検知された症状、収集すべき証拠、許容されるアクション、停止すべきタイミング、次の手順を決定できる担当者を示す必要があります。
これは、Webトラフィック、バックグラウンドPHPプロセス、キュー、cron、外部連携、共有データベースを持つアプリケーションでは特に重要です。コンシューマーの再起動やメッセージの再試行のように一見単純な介入でも、根本原因を隠し、操作を重複させ、すでに劣化しているサービスへの負荷を増大させる可能性があります。
Runbookが解決することと、代替してはならないもの
Runbookは、再現可能または予見可能な状況における即興対応を減らします。確認の順序、介入の限界、復旧を宣言するために必要な証拠を明確にします。また、インシデントに際して開発、運用、ビジネスが共通の言葉を共有できるようにします。
ただし、インシデント前に存在すべき以下の統制に代わるものではありません。
- オブザーバビリティ:理解しやすいしきい値を備えたメトリクス、相関付けられたログ、トレース、アラート。手順では、曖昧なシグナルやコンテキストのないシグナルを補えません。
- トレーニングと権限:実行する人はリスクを理解し、必要なアクセス権だけを持つ必要があります。
- バックアップと検証済みの復元:完全性、対象範囲、復元時間が分からなければ、バックアップは復旧戦略ではありません。
- アーキテクチャ:冪等な再試行、リソース制限、timeout、circuit breaker、依存先の分離により、手動介入の必要性を減らします。
- 変更管理:デプロイはreleaseと同義ではありません。Runbookはどのバージョンがアクティブか、および段階的な露出がロールバックのリスクを低減できるかを把握する必要があります。
目的は、考えられるすべての障害を文書化することではありません。運用上の影響があり、誤った判断がシステムの状態を悪化させうるシグナルへの対応を標準化することです。
アラートに固有の手順が必要となる場合
すべてのアラートに専用文書が必要なわけではありません。頻度、影響、時間的プレッシャー、チーム間の依存関係を組み合わせた状況を優先することが適切です。ストレス下で手順を思い出すことに反応が依存すべきでない場合、そのアラートにはRunbookが必要です。
- 繰り返し発生し、通常は同じ初期確認を必要とする。
- 収益、顧客プロセス、期限遵守、または重要機能の可用性に影響する。
- 是正アクションが可逆であるのは限定された時間枠内のみである。
- PHPアプリケーション、インフラストラクチャ、データベース、またはAPIプロバイダー間の連携を必要とする。
- 手動アクションがデータの損失、重複、または露出を引き起こしうる。
- 具体的な証拠によって除外すべき既知の誤検知がアラームにある。
仮説ではなく、観測可能な症状から始めてください。「保留中のジョブが増加している」「endpointのレイテンシがしきい値を超えている」「5xxエラーが増加している」「連携が無効な応答を返している」は有用な入力です。「データベースが飽和している」は検証すべき仮説であり、手順の出発点ではありません。
実行可能なRunbookの最小構成
有用な運用文書は、インシデント中に読んで実行できるものです。何を探すか、どの時間範囲で確認するか、どの結果が判断を変えるのかを具体化せずに「ログを確認する」といった表現は避けるべきです。
- 目的と範囲:対象とする症状、影響を受けるコンポーネント、対象外となるコンポーネントを説明します。本番環境、特定の環境、またはある種のプロセスに適用されるかを示します。
- 入力シグナル:アラート、しきい値、関連ダッシュボード、エラーメッセージ、実際のアラートとノイズを区別する条件を含めます。
- 初動担当者と権限:インシデントを認知する人、アクションを実行する人、高影響操作を承認する人を明記します。
- リスクと停止条件:実行してはならないアクション、影響を受ける可能性のあるデータ、継続せずにエスカレーションすべきタイミングを明確にします。
- 手順と証拠:各手順で確認を求め、期待される結果を記録し、次の判断分岐を定義する必要があります。
- 終了:インシデントをクローズできる証拠と、その後も未解決として残るフォローアップを定義します。
ダッシュボード、リポジトリ、ツールへの内部リンクは運用版では有用になり得ますが、それだけをコンテキストにしてはなりません。観測するメトリクス、フィルタリングするタグ、使用する時間枠を記載してください。ツールが利用できない場合、チームは収集できる代替の証拠を把握している必要があります。
診断、緩和、復旧を分離する
インシデントが長期化する原因としてよくあるのは、調査と変更を混在させることです。Runbookは、リスクレベルと目的に応じてアクションを分類する必要があります。
安全なアクションと診断
アラートの認知、連携チャネルの開設、メトリクスの取得、エラーログの照会、依存先の状態確認は、通常は低リスクのアクションです。それでも制限は必要です。劣化したデータベースに対する高コストなクエリや、フィルターなしのログ検索も負荷を追加しかねません。
診断では、検証可能な仮説を立てる必要があります。たとえば、接続エラーが増加し、接続プールが枯渇している場合は、上限を変更する前に依存先と利用パターンを調査します。新たに露出されたバージョンだけが失敗している場合は、そのトラフィックとエラーを以前のバージョンと比較します。
緩和と復旧
緩和は、原因が修正されたと断定せずに被害を抑えます。機能の露出を減らす、ジョブ入力を一時停止する、rate limitingを適用することが例です。復旧はサービスを許容可能な状態に戻します。コンシューマーを復元する、バージョンをロールバックする、保留中の作業を制御された方法で処理することが該当します。
各アクションには判断ポイントを組み込む必要があります。どのメトリクスが改善するのか、どれだけの時間観測するのか、悪化した場合に何をするのかを定めます。PHPプロセスの再起動は限定的な緩和として有効な場合がありますが、非冪等なタスク、データベースロック、または説明不能なメモリ消費がある場合、自動的な指示にしてはなりません。
仮想例: PHPキューでのジョブ滞留
通知、同期、またはコマースタスクを処理するコンシューマーを持つPHPアプリケーションを考えます。アラートは、保留中のジョブ数が継続的に増加していることを示します。Runbookは単に「キューを空にする」と指示してはなりません。
- 範囲を確認します。ジョブ種別ごとの保留数、メッセージ経過時間、流入率、処理率を測定します。遅延がすべてのコンシューマーに影響しているか、特定の経路に限られるかを確認します。
- コンシューマーの健全性を確認します。アクティブなプロセス、再起動、メモリ、PHPエラー、timeout、繰り返される例外を確認します。キューとの接続性、およびジョブが呼び出す依存先も確認します。
- 仮説を分類します。異常に高い流入、容量不足、ブロックされたジョブ、コードエラー、低速な外部依存先、無効なデータです。宛先の依存先がすでに飽和している場合は、コンシューマーを増やしてはいけません。
- 再試行の上限を定義します。繰り返し失敗するメッセージは、設計で可能な場合、レビュー経路またはエラーキューへ送る必要があります。無制限に再試行すると、トラフィックを増幅し、効果を重複させる可能性があります。
- 段階的な復旧を適用します。段階を追ってコンシューマーを復元またはスケールし、成功率を観測し、エラー、レイテンシ、データベース負荷を監視します。バックログの増加が速くなったり、障害が増えたりした場合の停止条件を維持します。
- 結果を検証します。古いジョブが減少していること、重複がないこと、関連する操作に整合性があること、定義された時間枠の間にアラートが安定することを確認します。
ジョブが課金、email、在庫変更などの外部効果を生む場合、Runbookはバッチを再処理する前に人によるレビューを必須とする必要があります。冪等性はリスクを低減しますが、設計と影響を受けるデータの証拠なしに前提としてはなりません。
機微なデータと不可逆な操作を保護する
個人データ、認証情報、注文、支払い、規制記録に触れる手順には追加の統制が必要です。コマンドが技術的に正しいだけでは不十分です。
- 最小権限を使用し、読み取り、運用上の介入、管理に別々のアカウントを用います。
- 削除、大規模な再処理、復元、直接的なデータ変更には二重確認を必須とします。
- 誰がアクションを承認・実行したか、どのデータ範囲を対象としたか、どの結果を得たかを記録します。
- 集合全体に対して実行する前に、検証サンプルを定義します。
- 不一致、特定不能なデータ、または当初の範囲外の効果が生じた場合の明示的な停止条件を設けます。
Runbook、ログ、キャプチャにシークレットを含めないでください。文書では一時的な認証情報を取得するための承認済みシステムを示せますが、機微な情報を恒久的なテキストにしてはなりません。
復旧後のエスカレーションと検証
エスカレーションは、アラート対応チームの失敗ではなく、リスク管理の判断です。アプリケーションの不具合、バージョンのリグレッション、非冪等な挙動の可能性がある場合は開発へエスカレーションします。リソース、ネットワーク、ストレージ、実行プラットフォームの枯渇がある場合はインフラストラクチャへエスカレーションします。証拠が外部プロバイダーのAPIまたはサービスを示す場合は、そのプロバイダーを関与させます。緩和に販売の停止、コミュニケーションの遅延、異なる処理順序の受容が必要な場合は、ビジネス判断を求めます。
さらに、各フェーズの最大時間を定義します。初期診断後に十分な証拠がない場合、または想定した間隔で緩和がシグナルを改善しない場合、担当者はアクションを繰り返すのではなくエスカレーションする必要があります。
復旧は、アラートの消失だけでなく、次の事項を検証したときに完了します。
- 初期症状が観測時間枠を通じて制限内にとどまる。
- 保留中の作業、トランザクション、影響を受けたデータに整合性がある。
- ユーザーが顕著な劣化なく関連フローを完了できる。
- 関連アラートが変更後に副作用を示していない。
- 時系列、確認または棄却された仮説、アクション、未対応の改善事項が文書化されている。
使用後にRunbookを見直してください。証拠につながらなかった手順を削除し、必要だった判断を取り入れ、反復する知見をオブザーバビリティ、テスト、アーキテクチャの改善に変換します。これにより、手順は静的な文書ではなく、安全な復旧ツールとなります。
