bug-analysis

バグ分析

概要

このスキルでは、根本原因の特定、影響の評価、重大度の分類、実行可能な修正案の作成を行うための、体系的なバグ分析を提供します。バグのトリアージを効率化し、開発チーム向けに構造化された分析を提供します。

中核となる分析ワークフロー

ステップ 1：初期トリアージと情報収集

重要な情報を収集します：

• バグの説明と症状
• 再現手順（正しく動作することを確認します）
• 期待される動作と実際の動作
• 環境の詳細（OS、ブラウザー、バージョン、設定）
• エラーメッセージ、スタックトレース、ログ
• スクリーンショットまたは動画
• ユーザーへの影響と発生頻度

簡易評価：

• 重大度：重大／高／中／低
• 種類：機能／パフォーマンス／セキュリティ／UI／データ／統合／設定／リグレッション
• 優先度：重大度とビジネスへの影響に基づいて決定
• 重複の可能性：既存の問題を検索

ステップ 2：バグの分類

重大度の分類（詳細な基準については、severity-guidelines.mdを参照してください）：

重大（P0） - 対応：直ちに（1 時間未満）

• システム停止、データ損失、セキュリティ侵害、回避策なし

高（P1） - 対応：当日中

• 主要機能の故障、重大なユーザーへの影響（25％超）、回避策が困難

中（P2） - 対応：1 週間以内

• 機能の一部が故障、中程度の影響、回避策あり

低（P3） - 対応：バックログ

• 軽微な問題、見た目上の問題、影響は最小限

バグの種類：

• 機能：仕様どおりに機能が動作しない
• パフォーマンス：応答が遅い、タイムアウト、リソースの問題
• セキュリティ：脆弱性、不正アクセス
• UI/UX：表示上の不具合、使いやすさの問題
• データ：破損、損失、不正な処理
• 統合：API の障害、サードパーティの問題
• 設定：環境またはデプロイの問題
• リグレッション：以前は動作していた機能の故障

ステップ 3：根本原因分析

調査プロセス：

1. エラーの証拠を確認する

   • スタックトレースを解析して障害箇所を特定する
   • エラーコードを既知の問題と照合する
   • 最近のコード変更を確認する（git blame、コミット履歴）

2. 問題を再現する

   • 再現手順を検証する
   • 異なる環境でテストする
   • 入力を変えて境界条件を特定する
   • 一貫して再現できる方法を記録する

3. 実行フローを追跡する

   • エントリーポイントから障害箇所までのコードパスをたどる
   • 実際の動作が期待される動作と異なる箇所を特定する
   • データ変換と制御フローを確認する
   • 関連するコード箇所を確認する

4. 依存関係を分析する

   • ライブラリとフレームワークのバージョンを確認する
   • 依存関係に既知の問題がないか確認する
   • 統合ポイントを確認する
   • 異なるバージョンの依存関係でテストする

よくある根本原因のパターン：

• ロジックエラー（条件や計算の誤り）
• null／undefined 参照エラー
• 競合状態とタイミングの問題
• メモリリーク
• 境界条件（オフバイワン、オーバーフロー）
• 設定の問題
• 依存関係の問題
• 統合の失敗

詳細な分析手法については、analysis-techniques.mdを参照してください。内容は次のとおりです。

• 5 つのなぜの手法
• スタックトレース分析
• 差分分析
• データフローの追跡
• 仮説検証
• 証拠の収集方法

ステップ 4：影響評価

複数の側面から影響を評価します：

ユーザーへの影響：

• 影響を受けるユーザーの数／割合
• 中断されるユーザーワークフロー
• 影響を受けるユーザーセグメント

ビジネスへの影響：

• 収益の損失またはリスク
• SLA 違反
• 顧客満足度への影響
• 評判へのリスク

システムへの影響：

• パフォーマンスの低下
• リソース消費
• 連鎖的な障害
• データ整合性のリスク

セキュリティへの影響（該当する場合）：

• 機密性：データの露出レベル
• 完全性：不正な変更
• 可用性：サービスの中断
• 悪用される可能性

範囲の定義：

• 影響を受けるバージョン／リリース
• 影響を受けるプラットフォーム／ブラウザー
• 影響を受ける機能／ワークフロー
• リグレッションの範囲

ステップ 5：修正の推奨事項

構造化された修正戦略を作成します：

1. 早急な緩和策（まだ実施していない場合）：

• ユーザー向けの回避策
• 影響を軽減する設定変更
• 問題のあるコードを無効にする機能フラグ
• 最近のリグレッションが発生した場合のロールバック方法

2. 恒久的な解決策：

• 必要な具体的なコード変更
• 行番号を含む変更対象ファイル
• 必要な設計変更
• 必要なデータベースのマイグレーションまたはクリーンアップ
• 必要な設定の更新

3. テスト要件：

• 追加するユニットテスト
• 必要なインテグレーションテスト
• 再発防止のためのリグレッションテスト
• 該当する場合のパフォーマンス／セキュリティテスト

4. 予防策：

• コードレビューで重点的に確認する項目
• 追加で必要な検証
• 追加する監視／アラート
• ドキュメントの更新
• プロセスの改善

出力形式

次のテンプレートを使用して、構造化された分析を提示します。

標準的なバグ分析：output-templates.md のテンプレートを使用し、以下を含めます。

• 深刻度と優先度を含むバグの概要
• 環境と再現手順
• 根拠を示した根本原因の分析
• 影響の評価
• テスト計画を含む推奨修正

専門的なレポート（output-templates.md を参照）：

• セキュリティ脆弱性レポート：CVSS スコア、攻撃ベクトル、開示計画
• パフォーマンスバグレポート：メトリクス、プロファイリング結果、最適化戦略
• クラッシュ分析レポート：スタックトレース、メモリ状態、クラッシュのトリガー

特殊な分析シナリオ

セキュリティ脆弱性

セキュリティ上の問題については、次の手順を実施します。

1. CVSS を使用して評価します：攻撃ベクトル、複雑さ、権限、影響
2. 悪用の可能性を特定します：リモートからの悪用、認証の要否
3. 封じ込めを計画します：緊急パッチ、アクセス制限、監視
4. 開示戦略を立てます：タイムライン、通知、コンプライアンス（CVE、GDPR、PCI-DSS）

セキュリティ固有のトリアージについては、severity-guidelines.md を参照してください。

パフォーマンスの問題

パフォーマンスのバグについては、次の手順を実施します。

1. ベースラインを確立します：想定されるメトリクス、SLA のしきい値
2. ボトルネックを特定します：CPU プロファイリング、メモリの傾向、I/O、データベースクエリ
3. 劣化を定量化します：応答時間の増加、スループットの低下
4. 最適化戦略を立てます：コードの最適化、キャッシュ、インデックス作成、アーキテクチャの変更

クラッシュ分析

アプリケーションのクラッシュについては、次の手順を実施します。

1. クラッシュダンプを分析します：例外の種類、スタックトレース、スレッドの状態
2. トリガーを特定します：ユーザー操作、システムの状態、データ入力、タイミング
3. 安定性への影響を評価します：頻度、影響を受けるシナリオ、データ損失のリスク
4. 復旧戦略を立てます：クラッシュ処理、段階的な縮退、監視

調査ツールとコマンド

コマンドの詳細については、investigation-commands.md を参照してください。

バージョン管理：

• git bisect - バグを導入したコミットを特定します
• git blame - コードを最後に変更した人を確認します
• git log -S "text" - コードがいつ変更されたかを特定します

ログ分析：

• grep -A 5 -B 5 "error" app.log - 前後のコンテキストを含めてエラーを検索します
• tail -f app.log | grep ERROR - エラーをリアルタイムで監視します
• awk と分析スクリプトを使用したログの解析

データベースの調査：

• PostgreSQL：遅いクエリの分析、インデックスの使用状況
• MySQL：プロセスリスト、デッドロックの検出
• MongoDB：操作のプロファイリング、コレクションの統計情報

システムの監視：

• プロセスの監視：top、ps、htop
• メモリの分析：free、pmap、valgrind
• ネットワークの分析：netstat、tcpdump、curl -v

アプリケーションのデバッグ：

• Node.js：node --inspect、プロファイリング、ヒープスナップショット
• Python：pdb、cProfile、メモリプロファイリング
• Java：jmap、jstack、フライトレコーダー
• Docker/Kubernetes：コンテナログ、exec、デバッグ

ベストプラクティス

調査の原則

• 証拠に基づく：仮定ではなく、具体的なデータに基づいて結論を出します
• 体系的：論理的な調査プロセスに従います
• 仮説主導：仮説を立て、検証し、結果を確認します
• すべてを記録する：調査結果、推論、判断を記録します
• 複数の原因を考慮する：最初に思いついた説に固執しません

効果的なコミュニケーション

• 明確な言葉を使う：技術に詳しくない関係者には専門用語を避けます
• 背景を説明する：バグが重要な理由を説明します
• 期待値を設定する：現実的なスケジュールと複雑さを伝えます
• 回避策を提示する：可能であれば、すぐにユーザーを支援します
• フォローアップする：進捗を関係者に伝えます

予防への注力

バグの修正後：

• パターンを特定する：複数のバグに共通する原因を探します
• テストを改善する：バグのシナリオに対するカバレッジを追加します
• 監視を強化する：類似の問題に対するアラートを追加します
• プロセスを更新する：コードレビューのチェックリストやデプロイ手順を見直します
• 教訓を記録する：ナレッジベースを更新します

クイックリファレンス

よくある根本原因のチェックリスト

• Null／undefined の参照
• 1 つずれるエラーまたは境界条件
• 競合状態またはタイミングの問題
• メモリーリーク
• 検証またはエラーハンドリングの不足
• 設定の問題
• 依存関係のバージョン不一致
• API コントラクトの変更
• データベーススキーマの不一致
• 権限の誤り
• リソースの枯渇
• キャッシュの問題
• タイムゾーン／日付の処理
• 文字エンコーディングの問題

迅速な診断コマンド

# Service status
systemctl status service_name

# Resource usage
top -bn1 | head -20                    # CPU
ps aux --sort=-%mem | head -10         # Memory
du -sh /* | sort -rh | head -10        # Disk

# Recent changes
git log --since="1 day ago" --oneline

# Error analysis
tail -100 /var/log/app.log | grep -i error
grep ERROR /var/log/app.log | wc -l

開発ワークフローとの統合

バグのライフサイクル：

1. 新規 → 報告を受領
2. トリアージ → 分析と優先順位付け（このスキルを使用）
3. 確認済み → 再現し、根本原因を特定
4. 担当者決定 → 開発者を割り当て
5. 進行中 → 修正を実装中
6. コードレビュー → 修正をレビュー中
7. テスト → QA による検証
8. 修正済み → デプロイ済み
9. クローズ → 解決を確認済み

ドキュメントの要件：

• コードへのリンク：ファイルと行番号
• テストへのリンク：修正を検証するテストケース
• 監視へのリンク：ダッシュボードまたはアラート
• 関連する課題へのリンク：重複や関連するバグ
• ドキュメントの更新：ユーザー向けの変更がある場合

参照ファイル

分析の必要に応じて、参照ファイルを読み込みます。

• 重大度のガイドライン：severity-guidelines.md を参照するケース：

  • バグの重大度と優先度を判断するとき
  • トリアージの基準を把握するとき
  • 重大度／優先度マトリックスが必要なとき
  • セキュリティ脆弱性を分類するとき

• 分析手法：analysis-techniques.md を参照するケース：

  • 詳細な RCA 手法が必要なとき
  • 5 Whys またはその他の手法を適用するとき
  • 仮説検証を行うとき
  • 証拠を収集するとき
  • 特定のデバッグ戦略を使用するとき

• 出力テンプレート：output-templates.md を参照するケース：

  • バグレポートを作成するとき
  • RCA ドキュメントを作成するとき
  • セキュリティ脆弱性を記録するとき
  • パフォーマンスの問題を報告するとき
  • クラッシュを分析するとき
  • 重複としてマークするとき

• 調査コマンド：investigation-commands.md を参照するケース：

  • 特定のコマンド構文が必要なとき
  • バージョン管理（git）を扱うとき
  • ログやデータベースを分析するとき
  • システムリソースを監視するとき
  • アプリケーションをデバッグするとき
  • コンテナツール（Docker、Kubernetes）を使用するとき