Skip to content

調査依頼時のヒアリングテンプレート

基本情報

依頼者情報

  • 依頼者:
  • 所属チーム:
  • 連絡先: (Slack ID / Email)
  • 依頼日時:
  • 緊急度: [ ] 緊急 [ ] 高 [ ] 中 [ ] 低

調査対象

  • 対象システム/サービス:
  • 対象環境: [ ] production [ ] staging [ ] develop [ ] infra-dev
  • 対象期間:
  • 関連するAWSアカウント:

現象・課題

発生している問題

問題の詳細説明をここに記載

記載の参考例:

【パフォーマンス問題の例】
fd-system のレスポンス時間が通常の500msから3000ms以上に悪化している。
特に /api/medical_examinations エンドポイントで顕著で、ユーザーからの苦情が増加中。

【エラー・障害の例】  
consultation-service で HTTP 500 エラーが大量発生している。
エラーログには "Database connection timeout" が記録されており、
診療予約の新規作成が失敗している状況。

【機能不全の例】
決済処理(payment-service)で特定のクレジットカード(VISA)での決済が
すべて失敗する現象が発生。Mastercard は正常に処理されている。
GMO Paymentからのエラーレスポンスは「Invalid card」だが、有効なカードでも同様。

【リソース不足の例】
EC2インスタンス(i-0123456789abcdef0)のCPU使用率が継続的に90%超えとなり、
アプリケーションの動作が不安定になっている。メモリ使用率も80%超え。

【外部サービス連携問題の例】
SMS Links経由のSMS送信が全て失敗している。
API呼び出しは正常だがSMSが患者に届かず、認証コードの送信に影響。

影響範囲

  • ユーザーへの影響: [ ] あり [ ] なし
    • 詳細:
  • システムへの影響: [ ] あり [ ] なし
    • 詳細:
  • 影響を受けているサービス:

発生頻度・再現性

  • 発生頻度: [ ] 常時発生 [ ] 断続的 [ ] 一時的 [ ] 不明
  • 再現手順:
1. 
2. 
3.

技術的詳細

エラー情報

エラーメッセージ、ログ、スタックトレースなど

関連リソース

  • AWS リソース:
    • EC2インスタンス:
    • RDS:
    • Lambda関数:
    • CloudWatch ロググループ:
    • その他:

モニタリング情報

  • CloudWatch メトリクス:
  • Datadog ダッシュボード:
  • 関連アラート:

調査観点

調べてほしいこと

具体的な調査内容を記載

記載の参考例:

【原因調査の例】
/api/medical_examinations のレスポンス時間悪化の根本原因を特定したい。
- データベースのスロークエリが関連しているか
- アプリケーションコードの処理に問題があるか  
- インフラリソース(CPU/メモリ)の制約が原因か

【パフォーマンス分析の例】
EC2インスタンス i-0123456789abcdef0 の高CPU使用率について:
- どのプロセスが最もCPUを消費しているか
- メモリ使用量の推移とスワップの発生状況
- ディスクI/O待機時間の影響度
- スケーリング(インスタンスサイズ変更)の必要性

【エラー分析の例】
consultation-service の HTTP 500 エラーについて:
- エラー発生のパターン(時間帯、頻度、トリガー条件)
- データベース接続プールの設定と使用状況
- アプリケーションログでのスタックトレース分析
- 同時接続数の上限に達していないか

【外部サービス連携調査の例】
SMS Links API の送信失敗について:
- API呼び出し時のレスポンス詳細(ステータスコード、エラーメッセージ)
- 認証トークンの有効性
- API利用制限(レート制限)への抵触状況
- 代替手段(他のSMSプロバイダ)の検討

【セキュリティ調査の例】
不正アクセスの可能性について:
- CloudTrail ログでの異常なAPI呼び出しパターン
- WAF ログでのブロックされたリクエスト分析
- 認証失敗の頻度と発信元IPの調査
- IAMロールの権限設定の妥当性確認

【容量計画の例】
RDS の性能劣化について:
- 現在のデータベース使用容量と増加傾向
- 接続数の推移と上限値との比較
- インデックスの使用状況と最適化の必要性
- Read Replica の負荷分散効果の検証

期待する成果物

  • [ ] 問題の原因特定
  • [ ] 解決策の提案
  • [ ] 改善案の提示
  • [ ] 運用手順の作成
  • [ ] その他:

調査期限

  • 希望回答期限:
  • 理由:

既に実施した調査・対応

確認済み項目

  • [ ] CloudWatch メトリクス確認
  • [ ] Datadog ダッシュボード確認
  • [ ] アプリケーションログ確認
  • [ ] AWS コンソール確認
  • [ ] 関連チームへのヒアリング
  • [ ] その他:

実施した対応

既に実施した対応内容を記載

補足情報

関連する変更

  • 最近のデプロイ:
  • 設定変更:
  • インフラ変更:

関連チケット・Issue

  • Jira チケット:
  • GitHub Issue:
  • 過去の類似事象:

添付資料

  • [ ] スクリーンショット
  • [ ] ログファイル
  • [ ] 設定ファイル
  • [ ] その他:

調査担当者記入欄

受付情報

  • 受付担当者:
  • 受付日時:
  • 調査担当者:
  • 着手予定日:

初期診断

初期調査結果・方針を記載

調査結果・対応

調査結果と実施した対応を記載

フォローアップ

  • 追加調査の必要性: [ ] あり [ ] なし
  • 継続監視: [ ] 要 [ ] 不要
  • 改善提案:

使用方法

  1. 依頼者: このテンプレートに必要事項を記入してSlack/Jiraで依頼
  2. SREチーム: 受付後、調査担当者記入欄を更新
  3. 調査完了後: 結果を記載し、依頼者に報告
  4. 必要に応じて: ナレッジベースやRunbookに反映

テンプレートの更新

このテンプレートは以下の場合に更新を検討してください:

  • よくある質問項目の追加
  • 調査効率化のための項目追加
  • 新しいツール・システム導入時
  • 過去の調査で不足していた情報の特定