メインコンテンツまでスキップ

障害対応手順

Bazbiiシステムのインシデント対応とトラブルシューティング手順を説明します。

インシデント対応の概要​

インシデントの定義​

  • サービス停止: ユーザーがサービスを利用できない状態
  • パフォーマンス劣化: レスポンスタイムが大幅に増加
  • データ不整合: データの整合性が損なわれた状態
  • セキュリティインシデント: 不正アクセス、データ漏洩など

インシデントの分類​

重大度レベル​

  • P0 (Critical): サービス完全停止
  • P1 (High): サービス大幅な機能制限
  • P2 (Medium): 一部機能の不具合
  • P3 (Low): 軽微な不具合、改善要望

インシデント対応フロー​

1. インシデント検知​

検知方法​

  • 監視アラート: Grafana Cloudからのアラート
  • ユーザー報告: サポートチケット、問い合わせ
  • ログ確認: エラーログの急増
  • メトリクス異常: リクエスト数、エラー率の急変

アラート確認​

# Grafanaダッシュボード確認
# - エラー率のグラフ
# - レスポンスタイムのグラフ
# - リソース使用率のグラフ

2. 初期対応​

インシデントの確認​

  1. 影響範囲の把握

    • どのサービスが影響を受けているか
    • どのユーザーが影響を受けているか
    • どの機能が影響を受けているか

  2. ログ確認

# エラーログを確認
kubectl logs -f deployment/gateway | grep error

# 特定のログIDで検索
kubectl logs deployment/api | grep "EVT_POST_003"
  1. メトリクス確認
# Grafana Cloud Prometheus互換エンドポイントへのクエリ（PromQL）
rate(http_requests_total{status=~"5.."}[5m])

緊急対応​

  • サービス停止: 原因不明の場合は一時的にサービスを停止
  • ロールバック: 直近のデプロイが原因の場合はロールバック
  • トラフィック制限: DDoS攻撃の場合はトラフィック制限

3. 原因調査​

調査項目​

  1. 最近の変更

    • デプロイ履歴
    • 設定変更
    • データベースマイグレーション

  2. ログ分析

# エラーログの集計
kubectl logs deployment/api | grep error | wc -l

# 時間帯別のエラー数
kubectl logs deployment/api --since=1h | grep error
  1. メトリクス分析
  • リクエスト数の推移
  • エラー率の推移
  • レスポンスタイムの推移
  • リソース使用率
  1. データベース確認
# 接続数確認
kubectl exec deployment/api -- psql -c "SELECT count(*) FROM pg_stat_activity;"

# ロック確認
kubectl exec deployment/api -- psql -c "SELECT * FROM pg_locks WHERE NOT granted;"

4. 修正・復旧​

修正方法​

  1. 設定変更: 設定の問題の場合は修正
  2. コード修正: バグの場合は修正
  3. リソース追加: リソース不足の場合はスケールアップ
  4. ロールバック: 直近の変更を戻す

復旧確認​

# ヘルスチェック
curl https://api.bazbii.app/healthz

# メトリクス確認
# Grafanaダッシュボードで正常値を確認

5. 事後対応​

インシデント報告書の作成​

  • 発生時刻: いつ発生したか
  • 検知時刻: いつ検知したか
  • 復旧時刻: いつ復旧したか
  • 原因: 何が原因だったか
  • 影響範囲: どのような影響があったか
  • 対応内容: どのような対応をしたか
  • 再発防止策: 再発を防ぐための対策

再発防止策​

  • コード修正: バグ修正
  • 監視強化: 監視項目の追加
  • アラート改善: アラート閾値の調整
  • ドキュメント更新: 手順書の更新

トラブルシューティング手順​

よくある問題と対処法​

1. サービスが起動しない​

# ログ確認
kubectl logs deployment/gateway

# ポッドの状態確認
kubectl get pods

# イベント確認
kubectl describe pod <pod-name>

2. データベース接続エラー​

# 接続数確認
kubectl exec deployment/api -- psql -c "SELECT count(*) FROM pg_stat_activity;"

# 接続プール設定確認
kubectl get configmap api-config -o yaml

# データベースの状態確認
kubectl logs deployment/postgres

3. メモリ不足​

# リソース使用率確認
kubectl top pods

# メモリ使用量確認
kubectl exec deployment/api -- free -h

# メモリリークの可能性がある場合
kubectl logs deployment/api | grep "out of memory"

4. レスポンスタイムの悪化​

# スロークエリ確認
kubectl exec deployment/api -- psql -c "SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;"

# リクエスト数の確認
# Grafanaでリクエスト数のグラフを確認

5. エラー率の増加​

# エラーログの集計
kubectl logs deployment/gateway --since=1h | grep error | wc -l

# エラーの種類を確認
kubectl logs deployment/gateway --since=1h | grep error | sort | uniq -c

# 特定のエラーを調査
kubectl logs deployment/api | grep "EVT_POST_003"

エスカレーション基準​

エスカレーションレベル​

  1. L1 (担当者): 初期対応、基本的なトラブルシューティング
  2. L2 (上級者): 複雑な問題の調査、コード修正
  3. L3 (アーキテクト): アーキテクチャレベルの問題

エスカレーション条件​

  • P0: 15分以内に解決できない場合は即座にエスカレーション
  • P1: 30分以内に解決できない場合はエスカレーション
  • P2/P3: 必要に応じてエスカレーション

インシデント後のレビュー（Post-Mortem）​

Post-Mortemの目的​

  • インシデントの原因を深掘り
  • 対応プロセスの改善点を特定
  • 再発防止策を立案

Post-Mortemの内容​

  1. タイムライン: インシデント発生から復旧までの経緯
  2. 原因分析: 根本原因の特定
  3. 対応の振り返り: 対応プロセスの評価
  4. 改善策: 再発防止策とプロセス改善

Post-Mortemテンプレート​

# インシデント報告書

## 概要
- 発生時刻: YYYY-MM-DD HH:mm
- 検知時刻: YYYY-MM-DD HH:mm
- 復旧時刻: YYYY-MM-DD HH:mm
- 影響時間: X時間Y分

## 影響範囲
- 影響を受けたサービス: Gateway, API
- 影響を受けたユーザー数: 約XX人
- 影響を受けた機能: 投稿作成、フィード取得

## 原因
- 直接原因: データベース接続プールの枯渇
- 根本原因: 接続プールサイズの設定不備

## 対応内容
1. 接続プールサイズを増加
2. 既存接続の確認・切断
3. サービス再起動

## 再発防止策
- [ ] 接続プールサイズの適切な設定
- [ ] 接続数の監視アラート追加
- [ ] ドキュメント更新

関連ドキュメント​