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

このページについて

このページでは、DBO チームのインシデントエスカレーションポリシーを説明します。

ショートカット

  • DBO incident.io スケジュール
  • Slack 統合: インシデントチャンネルで /inc escalate コマンドを使用（緊急の連絡には必ず incident.io エスカレーションを使用してください）
  • Slack ハンドル: @dbre または @dbo-oncall（非緊急）
  • Slack チャンネル: #g_database_operations
  • group::database operations
  • 本番インシデント

SLO と期待値

  • DBO の対応はベストエフォートベースです

  • 現地タイムゾーンの平日対応のみ

  • S1 / S2 インシデントのみ

    • NB1: AMER タイムゾーンに 1 名しかいないなど、スタッフが限られているため、複数タイムゾーンにおける営業時間内でも対応できる人員がいない場合があります。S1/S2 インシデントへの対応の重要性は理解しており、適切かつタイムリーな対応を確保するよう最善を尽くしますが、現在のスタッフレベルではハード SLO を遵守できていません。この状況を正確に反映するため、スケジュールはアドホックに変更されることも想定されています。

    • NB2: DBRE はインシデントに対し、コンサルティングの立場でドメインエキスパートとして参加します。DBRE がエスカレーションを単独で解決する責任を負うという期待は持たないでください。インシデントを進展させるために、データベースフレームワーク（DBF）チームなどの他のドメインエキスパートにエスカレーションが必要な場合があります。

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

スコープと要件

  1. インシデントマネージャーオンコール、エンジニアオンコール、および セキュリティ チームが発報した GitLab.com の S1 および S2 本番インシデント。

    • NB1: GitLab Dedicated のサポートは現時点ではコンサルティングベースです。DBO チームは現在 Dedicated データベースをサポートするためのアクセス権やトレーニングを持っていないため、対応できていません。今後変更される可能性があります。最新情報はこちらを確認してください。

    • NB2: セルフマネージド のサポートは裁量ベースであり、ケースバイケースで評価します。

    • NB3: このプロセスは、非緊急の Issue で DBO チームに連絡するための経路では ありません。非緊急の Issue については、この Issue テンプレート を使用して Request for Help（RFP）Issue を作成してください。

    • NB4: DBO オンシフトは、進行中のアクティブなインシデントがある場合は特に、シフト交代時のウォームハンドオフの調整に責任を持ちます。

エスカレーション

  1. EOC/IM、開発またはセキュリティが /inc escalate で DBO オンコールにページを送ります。

  2. DBO はページを確認し、インシデントチャンネルおよび Zoom に参加して応答します。

  3. DBO は Issue をトリアージし、解決に向けて取り組みます。

  4. 必要に応じて、DBO はさらなる支援やドメインエキスパートに連絡します。

    • NB1: DBO サポートが応答しない場合、incident.io 内で定義されたエスカレーションパスが実行されます。

リソース

対応ガイドライン

インシデントに対応する際は、以下の手順をガイドラインとして活用し、自分自身および支援を求めているメンバーを助けてください。

  1. インシデント Zoom に参加します — インシデントの Slack チャンネルにブックマークされています
  2. テキストベースのすべてのコミュニケーションのために、適切なインシデント Slack チャンネルに参加します — 通常は #inc-<インシデント番号> です
  3. EOC と協力して、問題となっている既知のコードパスを特定します
  • その知識がお客様のドメイン内にある場合は、EOC と協力して問題のトラブルシューティングを続けます
  • 不慣れな内容である場合は、チームによるコードオーナーシップを特定するよう試みます — これにより、そのチームのエンジニアをインシデントに参加させることができます
  1. インシデントマネージャーと協力して、インシデント Issue が適切なエンジニアリングマネージャーに割り当てられていることを確認します（該当する場合）

インシデントトリアージセッションのシャドウ

インシデントのトリアージが通常どのように行われるかを事前に練習したい場合は、任意のインシデントトリアージコールに参加してください。#incidents-dotcom でアクティブなインシデントを確認し、同期的なトラブルシューティングのために Situation Room Zoom コール（リンクはチャンネルに記載）に参加してください。シャドウイング体験に関する参考ブログ記事もあります。

過去のインシデントのレビュー

過去のインシデントの Situation Room 録画は、この Google Drive フォルダ（内部）で閲覧できます。

シフト全体のシャドウ

オンコール DBO に何が期待されているか、インシデントがどの程度の頻度で発生するかを把握するために、別のシフトをシャドウすることが有効です。そのためには、DBO オンコールを特定し、シャドウすることを事前に連絡してください。シフト中は #incidents-dotcom でインシデントを監視してください。

トラブルシューティングのヒント＆コツ

  1. Sentry と Kibana を使用した 500 エラーの調査方法
  2. GitLab.com の SLO フレームワークのウォークスルー
  3. スケーラビリティドキュメント
  4. Grafana と Kibana を使用して PostgreSQL データを確認し根本原因を特定する
  5. Grafana と Prometheus を使用した API 低速化のトラブルシューティング
  6. 500 エラーをもっと楽しく

エンジニア向けツール

  1. 利用可能なツールのトレーニング動画
    1. ビジュアライゼーションツールプレイリスト
    2. モニタリングツールプレイリスト
    3. パフォーマンス確認用 Kibana ビジュアライゼーションの作成方法
  2. ダッシュボードの例（以下のいずれかのダッシュボードの左上のドロップダウンリストにさらに多くが表示されます）
    1. サチュレーションコンポーネントアラート
    2. サービスプラットフォームメトリクス
    3. SLA
    4. Web 概要
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License