Zenn
🦄

LLMで障害事前分析とプレモーテム生成

2025/03/12に公開

はじめに

「顧客データが消失した」「システムが数時間ダウンした」... 想像するだけで恐ろしいですよね? 実際に、過去にはこのような大規模なインシデントが数多く発生し、ビジネスに甚大な影響を与えてきました。

このような事態を未然に防ぐための強力なツールが、プレモーテム(事前分析) です。プレモーテムは、システムやサービスに障害が発生するに、潜在的な問題点やリスクを洗い出し、対策を講じるための事前分析手法です。

しかし、プレモーテムには以下のような課題もありました。

  • 時間と労力がかかる: 障害シナリオを網羅的に洗い出すには、多くの時間と労力が必要です。
  • 属人化しやすい: 経験豊富なエンジニアの知識や勘に頼る部分が大きく、属人化しやすい傾向があります。
  • 網羅性の不足: 人間の思考には限界があり、想定外の障害シナリオを見落としてしまう可能性があります。

これらの課題を解決するために、LLMで プレモーテム生成を生成させてみました。

LLM によるアイデア生成

Meincke らの論文では、LLM が人間のアイデア生成能力を凌駕する可能性が示唆されています。特に、LLM は以下の点で優れています。

  • 質の高いアイデアを効率的に生成できる: LLM は、大量のデータを学習しているため、人間では思いつかないような斬新なアイデアや、質の高いアイデアを効率的に生成することができます。
  • 多様なアイデアを生成できる: LLM は、様々な視点からアイデアを生成することができるため、より多様なアイデアを生み出すことができます。

LLM とプレモーテムの融合

LLM の持つ強力なアイデア生成能力をプレモーテムに活用することで、従来のプレモーテムの課題を解決し、より効果的な障害対策を講じることが可能になります。

具体的には、LLM に以下の情報を入力することで、プレモーテムを生成させることができます。

  • システムの概要: システムの構成、機能、利用技術など
  • 想定される利用者: 利用者の属性、利用シーン、利用頻度など
  • 過去のインシデント: 過去に発生したインシデントの種類、原因、影響など
  • 懸念事項: 現在懸念していること、リスクが高いと考えていることなど

LLM が生成したプレモーテム:

インシデントシナリオ 根本原因 影響範囲 対策 事前チェックリスト インシデント発生時の対応方法
SQL インジェクション攻撃により、顧客情報が漏洩する。 1. Web アプリケーションの入力値検証の不備 2. データベースユーザーの権限設定が不適切 3. エラーメッセージに詳細な情報が含まれている 1. 顧客の個人情報(氏名、住所、クレジットカード番号など)が漏洩する 2. 顧客からの信頼が失墜する 3. 法的責任を問われる可能性がある 4. 企業のレピュテーションが低下する 1. 入力値検証を徹底する(バリデーション、エスケープ処理) 2. データベースユーザーの権限を最小限にする 3. エラーメッセージを一般化し、詳細な情報を表示しない 4. WAF(Web Application Firewall)を導入する 5. 定期的な脆弱性診断を実施する 1. 入力値検証のテストケースが網羅されているか 2. データベースユーザーの権限が適切に設定されているか 3. エラーメッセージが一般化されているか 4. WAF の設定が適切に行われているか 5. 最新の脆弱性診断が実施されているか 1. 攻撃を検知したら、直ちに Web アプリケーションを停止する 2. 影響範囲を特定する(漏洩した可能性のある情報、顧客数など) 3. 関係各所(顧客、監督官庁、セキュリティ専門家など)に報告する 4. 原因を調査し、再発防止策を講じる 5. 漏洩した情報が悪用されないように監視する
大量の SELECT クエリにより、データベースの応答が遅延する。 1. 非効率な SQL クエリ(インデックスが適切に設定されていない、不要なカラムを取得しているなど) 2. データベースサーバーのリソース不足(CPU、メモリ、ディスク I/O) 3. 同時接続数が多すぎる 1. データベースの応答が遅延し、Web アプリケーションのパフォーマンスが低下する 2. 顧客満足度が低下する 3. 最悪の場合、サービスが利用できなくなる 1. SQL クエリを最適化する(インデックスの追加、不要なカラムの削除など) 2. データベースサーバーのリソースを増強する 3. キャッシュを活用する 4. ロードバランサーを導入し、負荷を分散する 5. スロークエリログを監視し、問題のあるクエリを特定する 1. SQL クエリの実行計画を確認し、問題がないか 2. データベースサーバーのリソース使用状況を監視する 3. 負荷テストを実施し、パフォーマンスのボトルネックを特定する 1. スロークエリログを分析し、原因となっているクエリを特定する 2. 該当クエリを修正または停止する 3. 必要に応じてデータベースサーバーのリソースを増強する 4. 状況を監視し、再発しないことを確認する
誤った WHERE 句の指定により、意図しないデータを抽出してしまう。 1. SQL クエリの記述ミス 2. テスト不足 3. レビュー不足 1. 誤ったデータに基づいて分析が行われ、誤った意思決定につながる 2. 誤ったデータが顧客に提供される可能性がある 3. 個人情報や機密情報が含まれていた場合、情報漏洩につながる 1. SQL クエリのレビューを徹底する(複数人でのチェック) 2. テストデータを用いたクエリの動作確認 3. データバリデーション(抽出されたデータの型、範囲などをチェック) 1. SQL クエリの WHERE 句が正しく記述されているか 2. テストデータを用いたクエリの実行結果が期待通りか 3. 抽出されたデータのサンプルチェック(件数、項目など) 1. 誤ったデータが抽出されたことを検知したら、直ちにデータの利用を停止する 2. 正しいクエリを再実行し、データを抽出する 3. 誤ったデータに基づいて行われた分析結果や意思決定の影響を評価し、必要に応じて修正する 4. 原因究明と再発防止策を検討・実施する

LLM を活用したプレモーテムの具体的な手順

LLM を活用してプレモーテムを実施するには、以下の手順を踏みます。

  1. プロンプトの準備: LLM に適切な指示を与えるためのプロンプトを準備します。プロンプトには、システムの概要、想定される利用者、過去のインシデント、懸念事項などを含めます。
  2. LLM への入力: 準備したプロンプトを LLM に入力します。
  3. プレモーテムの生成: LLM がプレモーテムを生成します。
  4. プレモーテムの評価: 生成されたプレモーテムを評価し、必要に応じて修正・加筆します。
  5. 対策の実施: プレモーテムで特定された対策を実施します。
  6. 定期的な見直し: 定期的にプレモーテムを見直し、LLM を用いて更新します。

プロンプト例

以下は、LLM にプレモーテムを生成させるためのプロンプト例です。

あなたは経験豊富なSREです。
データベースから顧客の行動ログをSQLで抽出する作業を実施します。

この作業における潜在的なリスクを特定し、対策を事前に検討するため、プレモーテムを3個作成し影響が大きい順に並べてください。
以下の項目を含む形式で出力してください。
またフォーマットはマークダウンです。

1. インシデントシナリオ: (**サービス安定化**を阻害する可能性のあるインシデントを記述)
2. 根本原因: (インシデントの根本原因となりうる技術的、運用的な要因を、**リスク**の観点から列挙)
3. 影響範囲: (インシデントが発生した場合のサービス、顧客、ビジネスへの影響を、**サービス停止時間**、**データ損失**、**顧客への影響**などを具体的に記述)
4. 対策: (インシデントを予防または軽減するための具体的な対策を、**リスク軽減**、**サービス安定化**の観点から記述)
5. 事前チェックリスト: (リリース前に実施すべき具体的なチェック項目を、**リスクを事前に潰し込む**観点でリストアップ)
6. インシデントが発生した時の対応方法: (**サービスを迅速に復旧**させ、**影響を最小限に抑える**ための対応を記述)


まとめ

LLM を活用することで、よりすばやく効果的な障害対策を講じることが可能になります。LLM は、経験豊富な SRE のように、様々な障害シナリオを想定し、それぞれのシナリオに対する具体的な対策を提案してくれました。

Discussion

ログインするとコメントできます