調査依頼時のヒアリングテンプレート
基本情報
依頼者情報
- 依頼者:
- 所属チーム:
- 連絡先: (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:
- 過去の類似事象:
添付資料
- [ ] スクリーンショット
- [ ] ログファイル
- [ ] 設定ファイル
- [ ] その他:
調査担当者記入欄
受付情報
- 受付担当者:
- 受付日時:
- 調査担当者:
- 着手予定日:
初期診断
初期調査結果・方針を記載調査結果・対応
調査結果と実施した対応を記載フォローアップ
- 追加調査の必要性: [ ] あり [ ] なし
- 継続監視: [ ] 要 [ ] 不要
- 改善提案:
使用方法
- 依頼者: このテンプレートに必要事項を記入してSlack/Jiraで依頼
- SREチーム: 受付後、調査担当者記入欄を更新
- 調査完了後: 結果を記載し、依頼者に報告
- 必要に応じて: ナレッジベースやRunbookに反映
テンプレートの更新
このテンプレートは以下の場合に更新を検討してください:
- よくある質問項目の追加
- 調査効率化のための項目追加
- 新しいツール・システム導入時
- 過去の調査で不足していた情報の特定