Content last updated 2026-09-18

CMOC 業務の遂行方法

Support Engineering における Incident CMOC ローテーションの役割と責任について説明します

はじめに

GitLab SaaS Incident Communications Manager on Call (CMOC) として、あなたはインシデント中、ユーザーおよびステークホルダーに対する GitLab の声となります。これを効果的に行うため、主に Incident Manager (IM) と Engineer on Call (EOC) と協力し、ステータスページ（Status.io で動作）、Slack、Zendesk、incident.io、および GitLab 自体の組み合わせを使用します。CMOC ローテーションは、GitLab Support On-call を構成するローテーションの 1 つです。

他のページでこの用語を区別するため、頭字語 ICMOC を目にしたり、この役割が「Incident CMOC」と呼ばれているのを目にすることがあります。このページではこの役割のみを対象としているため、CMOC、Incident CMOC、ICMOC を同じ意味で使用しています。

私たちの Slack ボット Woodhouse は、Status.io でインシデントを素早く立ち上げるためのコマンド（/woodhouse incident post-statuspage）を提供しています。それ以降、Status.io でインシデントを更新・クローズする基本的な方法は、Status.io の Incident Overview ドキュメントでカバーされています。このドキュメントでは、GitLab がそれらのタスクを遂行するために Status.io をどのように具体的に使用するかを説明します。

CMOC PagerDuty ローテーションへの追加方法

CMOC ローテーションに追加されるには:

  1. まず、GitLab-com CMOC トレーニングモジュール を完了します。
  2. マネージャーと話し合い合意した後、新しい PagerDuty Issue を作成し、適切なリージョンの CMOC ローテーションへの追加をリクエストします。

知っておくべきこと

開始する前に、以下のセクションを参照するか、ワークフローに直接進む場合は インシデント管理 から始めてください。

インシデントについて

このセクションでは、インシデントがどのように開始されるか、PagerDuty の各種ステータスメッセージの意味、およびインシデント中の EOC と IM の違いに固有の情報を扱います。

インシデントの宣言方法

Infrastructure チームは incident.io を使って Slack からインシデントを宣言 します。これにより、次のことが行われます:

  1. EOC、IM、CMOC に自動的にページが送信されます。
  2. Production Issue トラッカーにインシデント用の Issue が作成されます。
  3. インシデント専用の Slack チャンネルが作成されます。また、インシデントの Zoom 通話および incident.io のホームページが生成され、プライベートコメントとタイムラインが追跡されます。詳細は こちら を参照してください。

この情報はすべて、incident.io によって #incidents チャンネルに Slack で投稿され、次の例のような形で表示されます。

incident.io によるインシデント宣言

GitLab のチームメンバーは、GitLab.com がインシデントに直面しそうだと疑った場合、この方法でインシデントを報告することが推奨されています。

PagerDuty ステータスの定義

  • Triggered -「CMOC の注意を必要とするインシデントが存在する。」
  • Acknowledged -「ページを確認し、インシデント Slack チャンネルと Zoom 通話に参加するプロセスにある。」
  • Resolved -「インシデント専用の Slack チャンネルと Zoom 通話に参加し、Status.io でインシデントを作成し、社内のステークホルダーに通知し、インシデント Issue にラベルを付け、現在インシデントに対応している。」

注: PagerDuty の「Resolved」は、根本的な問題が解決されたことを意味するわけではありません。

ステータスページの通信を開始するかの判断: EOC vs. IM

ステータスページを介して公開コミュニケーションを開始するかどうかの決定の DRI は IM です。CMOC としてインシデントに参加する際は、現時点でコミュニケーションが必要かどうかを尋ねるべきです。まれにインシデントに IM がいない場合、EOC がこの責任を引き受けるため、代わりに EOC に尋ねることもできます。

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

現在のインシデントの詳細を記入するための例やインスピレーションが必要な場合は、いつでも 過去のインシデントを確認 できます。

Status.io について

Current Status と Current State の更新

インシデントへの正式な更新を行うことなしに、影響を受けるインフラの Current Status やその Current State を変更することはできません。最後の更新が公開されてからどれだけ時間が経過していなくても、Current Status または Current State のいずれかを変更するために、インシデントへの新しい更新を公開することは認められています。

更新頻度

Status.io は、ステークホルダーが知るべきアクティブなインシデントに関する新しい情報を得たときに、いつでも更新する必要があります。それ以外の場合は、以下の表に示すインシデントの重大度に応じた一定の頻度で更新する必要があります。

インシデントの Zoom 通話に参加したら、Status.io に加えられた更新内容と更新時刻に注意してください。リマインダー用のタイマーをセットし、次の更新までの時間が示されている場合を除き、以下の時間間隔を厳守してください。たとえば、「monitoring」中であれば、次の更新までに 1 時間と指定するのが適切な場合もあります。

明確なメッセージと進む道を提示する

たとえば、問題の解決過程にあり、そのプロセスにある程度の時間（たとえば 1 時間か 2 時間）かかることがわかっている場合、その旨を説明する更新を提供し、次の更新がいつ投稿されるかを説明することもできます。

インシデントステータスSeverity 1 更新頻度Severity 2 更新頻度Severity 3/4 更新頻度
Investigating10m15m15m
Identified10m30m30m
Monitoring30m60m60m
Resolvedこれ以上の更新は不要

何を言うべきかわからないときは？

  • 持っている最良の情報に基づいて、汎用的な更新を提供します:

  • GitLab.com でエラー率の上昇が見られます。調査はこちらで進めています: リンク

  • 一部のユーザーから GitLab.com への接続の問題が報告されています。こちらで対応しています: リンク

  • 自分が正しいと思うものの草案を作成します。可能な限り、IM や EOC とコミュニケーションするときは 「〜する予定です」という言い方 を使用します:

    • @incident-manager - 次の内容を投稿します: 「ネットワークの問題が APAC リージョンに限定されていることを特定し、解決に向けて Cloudflare サポートと協力しています。
    • 「次の更新でステータスを監視中に変更します」

  • 行動に偏る - 前回の更新に誤りがあった場合は、別の更新を投稿できます。

  • 報告すべき実質的な更新がない場合でも、人々が私たちが気にかけて取り組んでいることを知れるよう、何かを発信してください。以下にいくつかの例文を示します:

    1. 「報告すべき大きな進展はありません。バックアップから復元するか、まずレプリカが追いつくのを待つかを議論していますが、まだ決定していません。」
    2. 「報告すべき大きな進展はありません。Gitaly サーバーの起動を試みましたが、まだ接続できていません。」
    3. 「報告すべき大きな進展はありません。現在の CMOC が 3 時間続けて対応しているため、新しい CMOC に引き継いでいます。」
    4. 「報告すべき大きな進展はありません。#hugops のツイートを送ってくださった Google に感謝します。リンク」

  • 本当にわからないときは、尋ねることは大丈夫です！

Status.io 上の管理タスク

GitLab System Status ページへの管理者アクセスが必要となる ドキュメント化されたインシデント更新以外 のすべての更新は、このテンプレート で開始する必要があります。

このテンプレートは、コンポーネントを更新または追加する必要があるシナリオで CMOC DRI に通知します。コンポーネントを追加または変更する前に、適切な Reliability Team のインフラストラクチャ担当者からのレビューを必ず取得してください。

コンタクトリクエストについて

進行中のインシデントに関連するかどうかにかかわらず、Infrastructure や Security から、異常な使用を検出した場合に 1 人または複数のユーザーに連絡するよう依頼されることがあります。これらのリクエストに対応するには、Sending Notices ワークフローに従ってください。また、コンタクトリクエストの引き継ぎの詳細については シフト終了の引き継ぎ手順 を参照してください。

CMOC にページを送る方法

CMOC には インシデント宣言プロセス 中にページを送信できます。インシデントが作成された後やその他の理由で CMOC にページを送る必要がある場合は、メインのインシデント管理ハンドブックの EOC、IM、CMOC に対応を依頼する方法 セクションを参照してください。

サポート対応の調整について

予期しないお客様への影響をもたらし、Support による非標準のワークフローやコミュニケーションを必要とするインシデントが発生した場合は、Support Response Issue を作成して Support のアクションと対応を調整してください。

この Issue は、コミュニケーションのガイドラインやワークフローが変化するたびに更新し、Support 関連情報の唯一の情報源として保つようにしてください。

CMOC のパフォーマンス指標

CMOC としての成功は、以下のパフォーマンス指標によって判断されます:

  • PagerDuty ページの確認時間: すべての PagerDuty 通知を 15 分以内に確認し、インシデントブリッジに参加します。PagerDuty ページを確認する を参照してください。
  • ステータス更新間の頻度: 重大度に応じて、ドキュメントに記載された間隔（または別途連絡された頻度）でステータスページを更新します。更新頻度 を参照してください。
  • インシデントごとに作成されたステークホルダーへのコミュニケーションスレッド: ドキュメント化されたプロセスに従ってインシデントの存在をステークホルダーに伝達します。ステークホルダーに通知する を参照してください。
  • シフト後に作成された引き継ぎ Issue: 各シフトの終わりに、次の CMOC を準備するための引き継ぎ Issue を作成します。シフト終了の引き継ぎ手順 を参照してください。
  • シフト中に開かれたコンタクトリクエストごとの完了済みコンタクトリクエスト Issue: すべての受信したコンタクトリクエストを完了、引き継ぎ、または完了予定の伝達をします。コンタクトリクエストについて を参照してください。
  • 四半期ごとに 1 回のトレーニングイベントへの参加: 少なくとも 1 回のインシデントに参加するか、トレーニングアクティビティに参加（または企画）します。CMOC トレーニングアクティビティ を参照してください。

インシデント管理

CMOC として、以下の段階を通じてインシデントをガイドします。

  1. ステージ 1: 対応開始 - Status.io でインシデントを作成し、インシデント Zoom 通話に参加し、ステークホルダーに通知、インシデント Issue にラベルを付けます。
  2. ステージ 2: 管理 - EOC と支援エンジニアによってインシデントを解決するために行われている作業に従いながら、更新頻度 のスケジュールを遵守して Status.io を更新します。さらに、Zendesk でインシデント用のタグを作成し、チケットにタグ付けして返信します。
  3. ステージ 3: 監視（状況に応じて） - 問題が再発しないことを確認するために、Status.io でインシデントを一定期間 Monitoring に設定します。この段階は IM の要請でスキップされることがあります。
  4. ステージ 4: 解決 - インシデントを Resolved に設定し、Status.io にポストモーテムリンクを追加し、タグ付けと返信が必要な Zendesk チケットが残っていないことを確認します。

以下のセクションでは、これらの段階の各ステップをどのように実行するかを概説しており、順番に実行する必要があります。

ステージ 1: 対応開始

PagerDuty ページを受信した直後に、以下のすべてのステップを順番に実行します。

PagerDuty ページを確認する

ページを acknowledged としてマークします。これは、モバイルアプリ、Web インターフェース、または #support_gitlab-com Slack チャンネルの PagerDuty App を通じて行えます。

インシデントチャンネルと Zoom に参加する

通話へのリンクは、#incidents で incident.io によるインシデント宣言の投稿に記載されています。

通話中のあなたの役割は、インシデントが対応されている間、それに沿って進み、求められたとき、または必要なときに Status.io を更新することです。多くの場合、このルームでのやり取りは活発で、特にインシデントの初期段階で問題の原因が発見されている間はそうです。不適切なタイミングで発言しないよう、いつ発言するのが適切かについて最善の判断を使ってください。状況について緊急ではない質問があれば、Slack で通話の参加者にいつでもメンションを送ることができます。

最初に参加したとき

最初にすべきことは、ルーム内の他の人にあなたの声が聞こえることを確認することです。これを行うには、次のように発言します:

「こんにちは。現在担当の CMOC です。更新を送信する予定ですので、Slack スレッドでレビューをお願いします。」

「こんにちは。現在担当の CMOC です。何かお手伝いできることはありますか？」

何を発言するにせよ、インシデントの他の側面に集中する前に、自分宛の口頭での確認を必ず受け取ってください。

CMOC がアクションを取るよう求められたとき

ときどき、ルーム内で特定のタスクを実行するよう求められることがあります。そのような依頼については、依頼者に対して理解した依頼内容を口頭で繰り返し、必ず確認してください。これは、依頼が聞き取られたことを全員が理解するのに役立ち、また実行されるべきアクションについて全員が同じ理解を持っていることを検証する役割も果たします。

場合によっては、依頼が明示的ではなく暗黙的なこともあります。疑問がある場合は、必ず発言して確認を求めてください。たとえば:

IM: CMOC が参加しています。最初の更新を公開する必要があります。

良い対応は、アクションが要求されたかの確認を求めることでしょう:

CMOC: IM、status.io で最初の更新を送信すればよいですか？

より良い対応は、アクションが要求されたと仮定し、それに対する意図したアクションコースを伝え、依頼者にインプットを提供する機会を与えることです:

CMOC: IM、承知しました。status.io 向けの更新の草案を作成し、意見を伺うために Slack でメンションします。

関連する GitLab Issue を特定する

status.io で共有する場合は、関連するインシデント Issue を特定する必要があるかもしれません。

Issue を特定するには:

  • Slack インシデントチャンネルの上部にある Overview をクリックします

    インシデントチャンネルの概要

  • 関連する incident.io インシデントページを開きます

    incident.io のリンク

  • GitLab Issue はページの右側にあります

    incident.io のページ

インシデントを作成する

status.io の Web サイトを通じて直接インシデントを作成できます。

インシデントが GitLab Duo 機能に関連している場合は、GitLab Duo の特別な取り扱い を確認してください。

Status.io を通じて作成する

Status.io を通じてインシデントを作成するには、メインダッシュボードから New Incident ボタンをクリックします:

新しいインシデント

その後、インシデントのすべての詳細を入力します。以下の値を変更する必要があります:

Title - これは簡潔で要点を押さえたものにします。インシデントタイトルは「シンプルに言うと、何が問題なのか?」という質問に答えるものでなければなりません。

Current State - これはほぼ常に Investigating に設定する必要があります。なぜなら通常、私たちはこの初期段階ではインシデントの原因を知らないからです。そうではなく、IM や EOC から原因が判明していると伝えられている場合は、代わりに Identified に設定します。

Details - 透明性 という私たちの価値観に沿って、聴衆に対して期待を超え、インシデントについてできる限り多くの情報を提供すべきです。このフィールドには、聴衆が情報を追えるよう、Production の Issue トラッカー からのインシデント Issue へのリンクを 常に 含める必要があります。

Incident Status - これはインシデントの 重大度 に応じて、Degraded Performance、Partial Service Disruption、または Service Disruption のいずれかに設定する必要があります。どれを選ぶかわからない場合は、IM に案内を求めてください。

Broadcast - すべてのボックスにチェックが入っていることを確認します。

Message Subject - デフォルト値のままにしておきます。

Affected Infrastructure - これはチェックを入れず、その下にあるインシデントの影響を受ける各特定コンポーネントの横のボックスにチェックを入れます。このボックスにチェックを入れると、上記で設定した Incident Status の値が すべて のインフラコンポーネントに適用されます。

以下は、GitLab.com 上のジョブ処理の遅延に関するインシデントを作成する準備ができている例で、上記のガイドラインに基づくと、送信前の一般的なページの見え方です。

インシデントの詳細

ステークホルダーに通知する

CMOC は、Incident Notifier Slack ワークフローを使用してインシデントを社内のステークホルダーに通知する必要があります。これは、IM によってインシデントの重大度が確認された後に行うべきです。

このワークフローは、使用されると、インシデントの詳細を入力するフォームを求められ、その後、これらの詳細を #developer-advocacy と #customer-success に投稿します。これにより、それらのチームにインシデントを通知します。ワークフローを実行するには:

  1. #support_gitlab-com チャンネル内で、メッセージボックスに / を入力して使用可能なワークフローのリストを表示し、Incident Notifier ワークフローを選択します。
  2. #incidents-dotcom チャンネルで共有される以下の詳細を入力します
    • Summary: 簡潔な要約。CMOC 通知と同じものにできます。
    • Severity: インシデントと同じ重大度 を選択します。
    • Production issue: インシデント Issue へのリンク。例: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/12345
    • Incident Slack Channel: インシデント Slack チャンネルへのリンク。例: #incident-12345
    • Status Page: インシデントをクリックして完全なステータスページ URL を展開します。例: https://status.gitlab.com/pages/incident/xxxxxxxx/xxxxxxxx
  3. Submit をクリックします

これにより、#developer-advocacy と #customer-success の両方のチャンネルに送信されます。

PagerDuty ページを解決する

この段階の他のすべてのタスクが完了したら、PagerDuty ページを resolved としてマークします。モバイルアプリ、Web インターフェース、または #support_gitlab-com Slack チャンネルの PagerDuty App を通じてページを解決します。

ステージ 2: 管理

すべての ステージ 1 タスクが完了したら、インシデントに更新を加え、Zendesk でタグを作成し、関連する Zendesk のチケットに返信することで、インシデントを管理します。

インシデントを更新する

公開コミュニケーションでの注意と進捗を伝えるため、インシデントは インシデント更新頻度の表 に従って更新する必要があります（別途連絡されている場合を除く）。

アクティブなインシデントを更新するには、ダッシュボードからインシデントアイコンをクリックします。

アクティブなインシデントのダッシュボードアイコン

次に、インシデントの横にある編集ボタンをクリックします。

インシデントの編集ボタン

以下の値を変更します:

Current State - IM または EOC からインシデントの原因が特定されたと伝えられた場合は Identified に変更します。そうでない場合は Investigating のままにします。インシデントに対する修正を展開し、監視期間に入る場合は、Monitoring に設定し、ステージ 3 に進みます。

Details - 前回の更新からインシデントに関して何が変わったかを、できる限り簡潔かつ要点を押さえて記述します。文字数制限内に収まるなら、インシデント Issue へのリンクを再度含めることも検討してください。

Broadcast - すべてのボックスにチェックが入っていることを確認します。

Message Subject - デフォルト値のままにしておきます。

Current Status - インシデントの範囲が拡大または縮小していない限り、インシデントを作成したときに以前設定した値のままにします。不明な場合は IM に相談してください。

Set Status Level - チェックを入れたままにします。インシデントの範囲が拡大し、当初選択されたコンポーネントに加えて追加のコンポーネントが影響を受けるようになった場合は、更新を公開した後に 影響を受けるインフラの更新 に進みます。

公開準備が整った更新は、次のように見えるはずです。

インシデントの更新

X（旧 Twitter）には 280 文字の制限がありますが、いくつかのツイートは 230 文字に切り詰められることが確認されています。たとえば このツイート です。これは、X が任意の URL を 23 文字の URL に変換する URL 短縮サービスによる場合があります。

公開する前に 更新の長さを確認 し、メッセージの本文（最終的な Issue への URL の前）を 220 文字に収めるようにしてください。これにより、最終的な URL が切り詰められた場合でも、それを表示する約 10 文字を残せます。

更新が公開された後、ライブステータスページ にアクセスして公開されたことを確認します。

影響を受けるインフラまたはタイトルの更新（状況に応じて）

タイトル または 影響を受けるインフラ のいずれかに進み、それぞれを変更する方法を学んでください。

Title

インシデントのタイトルを更新するには、ナビゲーションバーの Incidents をクリックし、対象のインシデントの横の View Incident ボタンをクリックします:

インシデントタイトルの更新 - 1

現在のインシデントタイトルの横にある鉛筆アイコンをクリックして変更し、Save をクリックします。

Affected Infrastructure

インシデントの影響を受けるインフラを更新するには、ナビゲーションバーから Incidents をクリックし、対象のインシデントの横の View Incident ボタンをクリックします:

影響を受けるインフラの更新 - 1

Affected Infrastructure の横にある鉛筆をクリックし、追加で影響を受けるインフラの横のボックスにチェックを入れ、Save をクリックします。次に、ナビゲーションメニューから Dashboard をクリックし、Current Status メニューから追加で影響を受けるインフラをクリックして、それらのステータスを変更します:

影響を受けるインフラの変更

Zendesk タグ

インシデントに関連して Zendesk 経由で送信されたチケットを追跡するため、インシデント Issue に言及するすべてのチケットに Zendesk タグが自動的に追加されます。

このタグは他のチケットでも使用できます。インシデントに関連するすべてのタグは、gitlab-com_gl-infra_production_issues_##### の形式で、##### の部分はインシデント番号で、インシデント Issue で確認できます。

その他の社内インシデントや機密インシデント（セキュリティ関連のインシデントなど）の場合、公開チケット返信に公開リンクを共有しないため、手動でタグを作成できます。手動でタグを作成するには:

  1. チケットを作成または編集します。
  2. Tags フィールドに com_incident_### の形式で新しいタグの名前を入力し始めます。
  3. Enter を押します。
  4. 返信を含めるかどうかにかかわらず、チケットを送信します。

これでタグは他のチケットでも使用できるようになります。

Zendesk を監視する

Manage Incident ステージにいる間、インシデントに関連する新規および既存のチケットがないか定期的に Zendesk を監視し、それらにタグを付けて返信します。過去 4 時間以内に作成されたすべての新規チケットを表示するには この Zendesk 検索 を使用します。または、Zendesk の検索バーに以下を貼り付けます。

created>4hours order_by:created_at sort:desc group:none group:"support" -form:billing -form:security

インシデントが 4 時間以上前に始まった場合は、4 を調整します。

ステージ 3: 監視（状況に応じて）

インシデントが緩和された後は、問題が再発しないことを確認するため、しばしば監視期間を開始します。監視は通常 30 分続きますが、変動する場合があり、IM によって特定の監視時間が要請されることもあります。監視ステージを完全にスキップするように要請される場合もあります。 その場合は、直接 ステージ 4 に進みます。

監視を開始するには、インシデントを編集し、以下のフィールドを変更します。

Current State - Monitoring に変更します。

Details - インシデント固有の情報に加えて、すべてのシステムが通常の運用に戻ったこと、問題が再発しないことを確認するために監視中であること、およびインシデントを解決するまでの監視時間の見積もりを必ず記述します。たとえば:

すべてのシステムはオンラインで正常に稼働していますが、万全を期すため、監視中は影響を受けたコンポーネントを性能低下の表示のままにします。今後 30 分間に再発がなければ、このインシデントを解決済みとし、すべてのコンポーネントを正常稼働の表示に変更します。

Broadcast - すべてのボックスにチェックが入っていることを確認します。

Message Subject - デフォルト値のままにしておきます。

Current Status - 以前設定した値のままにします。この時点で、影響を受けるインフラは通常通りに動作するようになっているはずですが、混乱を避けるため、インシデントをクローズする準備が整うまでは、これを Operational に戻しません。

公開準備が整った、インシデントを監視期間に切り替える更新は、次のように見えるはずです。

監視への切り替え

監視期間中のいずれかの時点で問題の再発が見られた場合は、ステージ 2 に戻ります。問題の再発なく監視期間が完了した場合は、ステージ 4 に進みます。

ステージ 4: 解決

監視期間を完了した後、または監視期間がスキップされた場合、インシデントをクローズし、インシデントのポストモーテムセクションへのリンクを追加し、タグ付けと返信が必要な残りのチケットがないか Zendesk を確認します。

インシデントを解決する

問題が解決され、IM から Go 判定が出たら、Status.io のインシデントをクローズします。これらの条件が満たされたら、インシデントを更新し、以下のフィールドを変更します。

Current State - Resolved に変更します。

Details - 問題が解決され、システムが通常通りに動作するようになったことを記述します。前回の更新ですでに行っている場合でも、それを見逃したユーザーが詳細情報を取得できる場所がわかるよう、必ずインシデント Issue へのリンクも含めるようにしてください。

Broadcast - すべてのボックスにチェックが入っていることを確認します。

Message Subject - デフォルト値のままにしておきます。

Current Status - Operational に変更します。

Set Status Level - このボックスにチェックを入れます。

公開準備が整った、インシデントをクローズする更新は、次のように見えるはずです。

インシデントの解決

インシデントをクローズした後、ステータスページが正しく表示されているかをダブルチェックします。

Zendesk を確認する

最後のステップとして、Zendesk をもう一度チェックし、タグ付けと返信が必要な残りのチケットがないことを確認します。これを行う方法については Zendesk を監視する セクションを参照してください。

メンテナンス管理

Infrastructure チームは時折、GitLab.com のスケジュールされたメンテナンスイベントを計画します。その一部はユーザーに直接影響を与えます。新しいメンテナンスイベントは、external_communication.md Issue テンプレートと Scheduled Maintenance ラベルを使って、gl-infra/production Issue トラッカーで作成された Issue として発表されます。

メンテナンスがユーザーに影響を与える場合、Infrastructure はメンテナンスをステータスページに表示するよう要請できます。メンテナンスイベントには自動化が有効になっており、各イベントが予定された時刻に開始されることが保証されます。CMOC は、メンテナンスイベントを通じて積極的にステータス更新を提供するよう要請される場合があります。これが必要な場合、タスクの自動化は無効になり、メンテナンスウィンドウの最終完了を含むすべての将来の更新は手動で実施する必要があります。このような場合、Infrastructure は Issue に CMOC Required ラベルを適用し、オンコール CMOC にメンションする通知が #support_gitlab-com チャンネルに送信されます。この通知が受信されると、CMOC は Issue 内の詳細を使用して Status.io でメンテナンスを作成します。 これらの通知は現在機能していません。 代わりに、メンテナンス作成者は #support_gitlab-com で @cmoc メンションを使用して、新しいメンテナンスのセットアップが必要であることを CMOC に通知します。

新しいメンテナンスイベントを作成するには、Status.io ダッシュボードから New Maintenance をクリックします。

新しいメンテナンス

メンテナンスの内容は、メンテナンス Issue で提供される詳細に従って入力する必要があります。完了すると、次のように見えるはずです。

メンテナンスの詳細

メンテナンスのタイムゾーンと日付

Status.io のタイムゾーンは UTC に設定されています。

日付形式は 2022-08-12 時点で ISO 形式が選択肢にないため、DD-MM-YYYY となっています。

メンテナンスイベントのリスケジュール

メンテナンスウィンドウのリスケジュールが必要な場合は、status.io > Maintenances タブに移動します。 メンテナンスタブ

リスケジュールが必要なメンテナンスを選択します。 選択されたメンテナンス

Reschedule Maintenance ボタンを押して新しいスケジュール時刻を更新します。更新時に正しいタイムゾーンの詳細が設定されていることを確認してください。 その後 save を押します。

メンテナンスイベントの更新を送信する

自動化されたメンテナンスイベントについての注意: メンテナンスイベントページで、Automation: Running の右に括弧書きの赤い文字で (Disable) が表示される場合があります。 (Disable) をクリックして無効化された後、再有効化することはできません。 Post Update と Finish Maintenance を行うには、自動化されたメンテナンスイベントは (Disable) でなければなりません。 無効化された後、メンテナンスイベントの開始を含むすべての将来の更新は、その時点から手動で実行する必要があります。

メンテナンスイベントについてのリマインダーなどの更新を送信するには、Status.io の Maintenances タブに移動し、更新が必要なものを選択します。メンテナンスの情報ページで、自動メールリマインダーが送信されるよう設定されているかどうかを確認します。「はい」の場合、購読者に重複したリマインダーが送信されないよう、更新のメールブロードキャストは送信しないようにしてください。更新の準備ができたら、Post Update Without Starting ボタンを選択します。

メンテナンスを開始せずに更新を投稿

Infrastructure チームから提供された更新の詳細を入力し、更新を送信する前に適切なブロードキャストチャンネルを確認してもらいます。メンテナンス情報ページで「Send Reminders」が有効になっていた場合は、ブロードキャスト設定で「Notify email subscribers」にチェックを入れないようにしてください。

メンテナンス更新の配信

GitLab Status の Twitter アカウントがメンテナンススケジュールについて投稿したら、ツイートのリンクを #social_media_action チャンネルに送り、GitLab ブランドの Twitter アカウントでの増幅を希望する旨をソーシャルチームに知らせます。これは、選択されたスケジュールメンテナンスのタイムラインで一度だけ、できれば予定されたメンテナンスの前の週半ばに使用してください。

シフト終了の引き継ぎ手順

CMOC ローテーションには、一般的な オンコール - オンコールシフトの終了) セクションの内容を補強する、いくつかの引き継ぎに固有の手順があります。

引き継ぎを行う際には、シフト中に発生した関連するアクティビティや、現在進行中のインシデントがあるかどうかを、後任の CMOC に伝える必要があります。引き継ぎを行うには、Handover テンプレートを使用して CMOC Handover Issue トラッカーで Issue を作成します。シフト中に何も起こらなかった場合でも、すべてが順調であるというシグナルを送ることも有用な情報なので、必ず行ってください。

引き継ぎがアクティブなインシデント中に発生し、Issue で提供する簡単な要約では後任の CMOC に状況を適切に準備するのに不十分な場合は、#support_gitlab-com で Zoom 通話を開始し、後任の CMOC を招待して、状況を同期的に把握してもらうことが推奨されます。次のスラッシュコマンドを使用すると、ミーティングのセットアップを迅速に行えます。

/zoom meeting CMOC Handover Briefing

CMOC Handover Issue トラッカーは公開されていますが、機密情報の偶発的な漏洩を防ぐ取り組みとして、テンプレートは デフォルトで機密扱い になっています。

シフト中に CMOC が新規または進行中の SIRT インシデントに参加するよう求められた場合、引き継ぎ時に後任の CMOC を関連する機密 Issue / Slack チャンネルに招待してください。

シフト中に開かれたコンタクトリクエストは、デフォルトでチケットを作成したサポートエンジニアに割り当てられます。次のシフトの認知のためにリクエストに言及することは有用な場合があります。ただし、アクションが必要でない限り、コンタクトリクエストを再割り当てしたり、後続の引き継ぎに含め続ける必要はありません。多くの場合、ユーザーはコンタクトリクエストに応答しません。たとえば、OOO 予定の場合、コンタクトリクエストを再割り当てして別のシフトに引き継ぐことを検討するとよいでしょう。

CMOC トレーニングリソース

CMOC Shadow PagerDuty スケジュール

注: このローテーションに自分を追加する際は、ページ上部の Time Zone フィールドの調整が、自分だけでなくすべてのユーザーに対して調整されることに注意してください。離れる前に、必ずタイムゾーンを UTC にリセットしてください。

CMOC Shadow Schedule は、正式に CMOC として活動する前に CMOC をシャドウして学びたい人なら誰でも使用できます。CMOC になる予定の人は、ローテーションに追加してもらうために、マネージャーに相談する必要があります。または、短期間シャドウする場合は、Schedule an Override をクリックし、Custom duration をクリックしてから、タイムゾーンと開始・終了の日時を選択し、Create Override ボタンをクリックして変更を保存できます。オーバーライドを削除するには、画面右側の Upcoming Overrides リストで削除するオーバーライドの x をクリックします。

CMOC シャドウについての注意: CMOC シャドウ PagerDuty スケジュールがアクティブな場合、エンジニアは CMOC スケジュールにいるときと同じように通知を受け取り、ページ送信されます。CMOC シャドウスケジュールにいるときに、いかなるインシデントも確認済みまたは解決済みにしないでください。これにより、実際の CMOC へのページ送信が停止されてしまうためです！

CMOC トレーニングアクティビティ

CMOC の「トレーニングアクティビティ」とは、CMOC パフォーマンス指標 に対するパフォーマンスを維持または向上させる明示的な目的で、CMOC がワークフローの項目に触れるアクティビティです。

トレーニングアクティビティの例は次のとおりです:

  • 卓上演習
  • リージョン内の CMOC がプロセス改善やヒント・コツを同期的または非同期的に議論する「CMOC Squawk」
  • 実際のインシデントでの CMOC またはシャドウ：実生活でのトレーニングもトレーニングです！
  • 練習イベント

CMOC 練習イベント

練習イベントは、実際のインシデントで CMOC を担当したい人により多くの経験を提供することを目的としています。これらには、ステータスページを更新し、インシデントマネージャーとコミュニケーションし、より多くの自信を提供することを必要とする練習シナリオが含まれています。

CMOC 練習イベントを開始するには、トレーナーまたは任意のサポートエンジニアに Support Team Meta Issue トラッカー に移動して、CMOC Practice Event Issue テンプレートを使って Issue を作成するように依頼してください。

GitLab Duo の特別な取り扱い

GitLab Duo 機能は積極的に開発中であるため、個別の機能の可用性を追跡する専用の Issue を https://gitlab.com/gitlab-com/gl-infra/production/-/issues/18352 に用意しています。

GitLab Duo 機能でインシデントが宣言された場合は、インシデント Issue が https://gitlab.com/gitlab-com/gl-infra/production/-/issues/18352 とクロスリンクされていることを確認してください。

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License