Content last updated 2026-09-17

ハンドブック エスカレーション

チームメンバーの役割と責任については、コンテンツウェブサイトのページをご覧ください。

はじめに

ハンドブックは、チームメンバーが効果的に業務を遂行できるようにするための重要な要素です。そのため、すべてのチームメンバーに影響を与える問題の解決を支援するグループが存在します。

問題の報告

一般的なヘルプについては、ハンドブック編集ページをご覧ください。

業務を停止させる問題は、Slack の #handbook-escalation チャンネルに報告してください。 それ以外の場合は、関連するコンテンツサイトリポジトリで Issue を作成し、#handbook Slack チャンネルに投稿することを検討してください。

問題をエスカレーションするタイミング

問題のエスカレーションは、以下に関連する場合にのみ行ってください:

  1. デフォルトブランチが壊れている場合
  2. インフラが壊れている場合
  3. 更新作業に問題が発生している、期限が迫ったハンドブックの更新

「main をグリーンに保つ」グループ

#handbook-escalation に投稿しても応答が得られない場合は、ハンドブック DRIの勤務時間内であれば ping してください。

DRI が対応できない場合、「main をグリーンに保つ」グループのメンバーが可能な範囲で支援するためにボランティアとして参加しています。チームメンバーのタイムゾーン、Slack プロフィールに記載の勤務時間、および Slack のステータスで不在かどうかを確認してから連絡してください。

また、GitLab のすべてのチームメンバーは #handbook-escalation チャンネルに参加し、サポートするボランティアになることができます。

グループに参加したい場合は、グループのメンバーに追加を依頼してください。同様に、チームメンバーはいつでも GitLab グループを離れることでグループから脱退できます。

グループへの期待事項

  1. #handbook-escalation チャンネルに参加し、ミュートしないようにしてください。
  2. 問題が報告された場合:
    1. チームメンバーに応答し、確認中であることを伝えてください。
    2. #production、#incidents-dotcom、#is-this-known を確認して、インフラやその他の問題で既知の問題がないか確認できます。
    3. 問題を確認できたらできる限り早く更新情報を提供してください。
    4. 必要に応じて #mr-buddies や #handbook にも更新情報を投稿できます。
    5. 問題が複雑な場合は、問題の再現や解決を支援するために Zoom コールを提案してください。
    6. 問題を解決するか、チームメンバーが自分で解決できるようにフィードバックを提供してください。
    7. 解決できないと判断し、さらなる支援が必要な場合は、以下のいずれかまたはすべてを検討してください:
      1. 「main をグリーンに保つ」グループの別のメンバーに ping する。
      2. ハンドブック DRI、またはコードメンテナーグループのメンバーに ping する。
      3. 詳細を記載したバグ Issue を作成する。

Reliability Engineering にエスカレーションするタイミング

ハンドブックのエスカレーションは、content-sites プロジェクトに関連する問題を専門的に扱います。 報告された問題が GitLab 製品やハンドブックのインフラに関連している場合は、Reliability Engineering チームにエスカレーションする必要があります。 インシデントを報告するには、インシデント管理ページの指示に従ってください:https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident

よくあるインシデントとヒント

パイプラインの失敗

ガイダンスと例については、パイプラインのトラブルシューティングガイドをご覧ください。

#handbook-escalation での壊れた main アラートの管理

handbook リポジトリの main ブランチで失敗した CI パイプラインはすべて、自動的に Slack チャンネルに投稿されます。 これらのレポートは調査し、必要に応じて対処する必要があります。

レポートを確認したら、問題の性質、実施した対応を記載したコメントを残し、処理済みであることを示すために ✅ リアクションを追加してください。

何らかの理由で大量の失敗が発生してチャンネルへのスパムが発生している場合は、リポジトリ設定でエラーレポートをオフにすることができます:https://gitlab.com/gitlab-com/content-sites/handbook/-/settings/integrations

スタックしたマージトレイン

マージトレインのステータスを確認するには(チームメンバーが MR がトレインで「スタック」しているように見えると報告している場合に役立ちます)、この Issue でステータスを確認し、必要であれば回避策を実施してください。

回避策の要約:FIFO リスト (ID 順の sort=asc) の最初/最古の MR iid がパイプラインを実際に実行していてやがてマージされれば、処理は進んでいます(ただしゆっくりです)。リストの最初の MR が現在パイプラインを実行していない場合は、トレインから削除して再追加してください(末尾に移動します)。

about.gitlab.com のランブック

ハンドブックはもはや about.gitlab.com 上にありませんが、about.gitlab.com のインシデント対応ランブックの情報の一部が役立つ場合があります。