Content last updated 2026-05-26

データベース関連の問題でヘルプを得る

データベース関連の問題で適切なヘルプを見つけるためのデシジョンツリー

このガイドは、データベース関連の問題に対して適切なヘルプを見つけるための手順を示します。Step 1 から始め、ご自身の状況に合うパスをたどってください。

Step 1: どのようなヘルプが必要ですか?

Step 2: 顧客のデータベース問題

まずはサポートの stable counterparts に連絡してください — 彼らは一般的な顧客のデータベース問題に関するコンテキストを持っており、エンジニアリングにエスカレーションする前にトリアージを支援できます。

最初に: #spt_pod_database に投稿し、Database Pod チーム (データベースサポートの stable counterparts) に連絡します。彼らは適切なパスを判断し、エンジニアリングの関与が必要かどうかを判定できます。

次に、これがどのような種類の問題かを判断します:

問題が特定の機能、マイグレーション、クエリ、エンドポイントに関連していますか?

問題がバックアップやリストアに関連していますか?

問題が Omnibus または Charts における Postgres のパッケージングや設定に関連していますか?

  • はい -> セルフマネージドのパッケージングと設定を管理している #s_gitlab_delivery の GitLab Delivery セクション に連絡します。

これは一般的なデータベースの問題ですか (単一の機能に限定されないパフォーマンス劣化、運用に関する質問、アップグレード失敗、設定ガイダンス)?

  • はい -> サポートの Request for Help を起票します:

    1. Issue が #spt_pod_database で stable counterparts に既に提起されていることを確認します
    2. データベースサポートテンプレートを使って Request for Help Issue を起票します
    3. 可能であれば、顧客に database SOS dump をリクエストします
    4. Issue で @gitlab-org/database-team/triage をメンションします

    RFH には次の情報を含めます:

    • 顧客のインストールサイズとアーキテクチャ情報
    • PostgreSQL のバージョン、レプリカ数、pgbouncer の設定、ホスティングの詳細 (マネージドサービスか VM か、クラウドプロバイダー)
    • 可能であれば db:sos ダンプを追加
    • 再現手順
    • 関連するログと観察された監視メトリクス
    • 顧客への影響 (商談保留中、エスカレーション中、ショウストッパーなど)

顧客の Issue が緊急で、より迅速な対応が必要ですか?

Step 3: GitLab.com または Dedicated のインシデント

データベースの問題によって、アプリケーション (または Sidekiq などの主要コンポーネント) がダウンしている、または広範囲に応答不能になっていますか?

  • はい、広範囲な障害 -> これは総力戦の状況です。
    1. #s_database_excellence に投稿し、@db-team と @dbo-oncall をタグ付け
    2. インシデントチャンネルで /inc escalate を使用し、incident.io 経由でオンコールのデータベースエンジニアを呼び出していることを確認

インシデントがデータベースの設定または運用に関連していますか (例: 接続エラー、レプリケーションエラー、SSL エラー、Postgres の運用)?

インシデントがアプリケーションの動作に関連していますか (例: PG タイムアウトエラー、スロークエリ、長時間実行されるトランザクション、失敗するマイグレーション)?

Step 4: Database Excellence にエスカレーションする

エスカレーションする際は、できるだけ具体的に伝えてください。コミュニケーションガイドライン に従い、可能な限り略語を避けます。常に次を含めます:

  • Issue、Sentry エラー、インシデント、Zendesk チケットへのリンク
  • エラーメッセージのテキスト
  • 該当するチャートやダッシュボードへのリンク
  • クエリ、マイグレーション、Issue の詳細

進行中の GitLab.com または Dedicated のインシデントの場合:

  1. #s_database_excellence に投稿
  2. 15 分以内に応答がない、またはリクエストが緊急の場合、元のメッセージのスレッドで @db-team と @dbo-oncall をタグ付け
  3. さらに 15 分待っても応答がなく、リクエストが緊急の場合、Slack で Database Excellence ステージリードの電話番号を見つけてテキストまたは電話する

緊急の Self-Managed エスカレーションの場合:

  1. 詳細、Zendesk チケットへのリンク、RFH Issue を添えて #s_database_excellence に投稿
  2. スレッドで @db-team をタグ付け

インシデントエスカレーションの詳細

データベースインシデントのエスカレーションでは、オンコールルーティングに incident.io を使用します。

  • スコープ: Incident Manager On Call、Engineer On Call、セキュリティチームによって提起された GitLab.com S1 および S2 のプロダクションインシデント。GitLab Dedicated のサポートはコンサルティングベース。セルフマネージドのサポートは裁量制で、ケースごとに評価されます。
  • エスカレーション方法: インシデントの Slack チャンネルで /inc escalate を使用します。緊急でない Issue の場合は、トリアージローテーション を使用するか、#s_database_excellence に投稿してください。
  • 対応: ベストエフォート、現地のタイムゾーン、平日のみのカバレッジ (24/5)。オンコールエンジニアはコンサルティング能力としてサブジェクトマターエキスパートとして参加します。オンコールエンジニアがエスカレーションの解決に単独で責任を負うべきという期待は持つべきではありません — 他のサブジェクトマターエキスパートを呼び込む必要があるかもしれません。
  • ウォームハンドオフ: オンコールエンジニアは、シフト交代時、特に進行中のアクティブなインシデントがある場合に、ウォームハンドオフを調整する責任を負います。

エスカレーションプロセス

  1. EOC/IM、開発、またはセキュリティが /inc escalate を通じてオンコールデータベースエンジニアを呼び出す
  2. オンコールエンジニアがページを確認し、インシデントチャンネルと Zoom に参加する
  3. オンコールエンジニアが Issue をトリアージし、解決に向けて取り組む
  4. 必要に応じて、オンコールエンジニアがさらなるヘルプやドメインエキスパートを呼ぶ
  5. オンコールが応答しない場合、incident.io 内で定義されているエスカレーションパスが発動する

オンコール対応者向け

対応のガイドライン

インシデントに対応する際は:

  1. インシデント Zoom に参加します — 関連するインシデントの Slack チャンネルにブックマークされています
  2. すべてのテキストベースのコミュニケーション用に、適切なインシデント Slack チャンネル (通常は #inc-<INCIDENT NUMBER>) に参加します
  3. EOC と協力して、既知のコードパスが問題かどうかを判断します
    • Issue があなたのドメインにある場合は、EOC と協力してトラブルシューティングを続けます
    • Issue が馴染みのないものである場合は、チームごとのコードオーナーシップを判断しようとします — これにより、そのチームのエンジニアをインシデントに呼び込めます
  4. Incident Manager と協力して、インシデントの Issue が適切な Engineering Manager にアサインされていることを確認します

シャドーイング

  • インシデントのシャドーイング: #incidents-dotcom でアクティブなインシデントを監視し、同期的なトラブルシューティングのために Situation Room Zoom コールに参加します。シャドーイング体験については このブログ記事 を参照してください。
  • シフトのシャドーイング: 現在のオンコールエンジニアに連絡してシャドーイングすることを伝え、シフト中は #incidents-dotcom を監視します。
  • 過去のインシデントのリプレイ: 過去のインシデントの Situation Room の録画は、Google Drive フォルダ (内部) で利用できます。

トラブルシューティングリソース

  1. Sentry と Kibana を使った 500 エラーの調査方法
  2. GitLab.com の SLO フレームワークのウォークスルー
  3. スケーラビリティのドキュメント
  4. Grafana と Kibana を使って PostgreSQL データを見て根本原因を見つける
  5. Grafana と Prometheus を使って API スローダウンをトラブルシュートする

ダッシュボード

  1. Saturation Component Alert
  2. Service Platform Metrics
  3. SLAs
  4. Web Overview

Step 5: 責任を持つチームを特定する

データベースアプリケーションの Issue の多くは、関連する機能を所有するチームが対応するのが最適です。エラーに「database」という言葉が含まれていても、関係するデータパターンを理解しているのは機能チームのため、通常は機能チームが解決に最も適しています。

エラーに機能カテゴリが含まれていますか (Sentry、Rails コントローラー、Sidekiq ワーカー、API エンドポイント、バックグラウンドマイグレーションから)?

Issue がマイグレーションに関連していますか?

  • はい -> GitLab リポジトリ から次を実行します:

    git log --first-parent {path/to/migration.rb}

    マイグレーションファイルのパスはバックトレースで見つけられます。マイグレーションファイルは日時のタイムスタンプで始まり、db/migrate/ または db/post_migrate/ にあります。顧客のログ出力にタイムスタンプ (例: 20240113071052) を見つけられれば、一意にマイグレーションファイル名と一致します。

    git log の出力にはマージリクエストへのリンクが含まれており、責任を持つチームを特定できます。リンクがある場合は、そのチームに連絡してください。ない場合は、次のオプション (テーブル名による特定) を試してください。

Issue に関係するデータベーステーブルを特定できますか?

  • はい -> データベース辞書 で {table_name}.yml を探します。ファイルには feature_categories がリストされており、これを使って 機能カテゴリのルックアップ からチームを見つけられます。カテゴリが複数ある場合は、1 つを選んでそのチームから開始してください。

Issue がクエリに関連しているが、機能カテゴリがありませんか?

  • はい -> クエリが Rails コントローラー、Sidekiq ワーカー、API エンドポイント、バックグラウンドマイグレーションから来ている場合は、機能カテゴリ化ガイド を使って機能カテゴリを特定し、上記の方法でチームを探してください。発生源を特定できない場合は、クエリで参照されているテーブルを使って、テーブル名でチームを特定してください。

発生源を特定できない、またはオーナーチームが応答しない場合。

Step 6: 緊急でない Issue を起票する

Database Excellence チームから何かを必要としていますか (相談、インフラ変更、stable counterpart、プロジェクト業務)?

  • はい -> database-team/team-tasks で work request を提出します。これは外部からのすべてのリクエストの単一の受付窓口です。ルーティングの詳細については、Database Excellence ステージページ を参照してください。

gitlab-org/gitlab の既存の Issue でデータベースチームの注意が必要ですか?

責任を持つ機能チームがわかっているアプリケーション Issue ですか?

  • はい -> そのチームのグループラベルを Issue に付けます。機能チームが最適な最初の連絡先です。

Omnibus または Charts のパッケージ化された Postgres に関連していますか?

  • はい -> Issue に ~"group::distribution" ラベルを付けます

Issue がブロックされていてエスカレーションが必要ですか?

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License