GitLab サポートとの連携

概要

このページの目的は、サポート以外の GitLab チームメンバーに対して、GitLab サポートが何を行うか、私たちにどのように連絡するか、そして私たちの関与が必要な一般的な依頼をどこに向けるべきかを案内することです。技術サポートを求めているお客様ですか？その場合は、代わりに サポートページ をご覧ください。

クイックリファレンス

このページに記載されていない場合、それはおそらくカスタマーサポートの対象ではありません。

詳細については、次の GitLab サポートの目的 と GitLab サポートに連絡すべきか？セクション をお読みください。

これは網羅的なリストではありません。サポートチームが対応すると思われるその他のものについては、目次を確認するか、このページを検索してください。

GitLab サポートの目的

GitLab サポートは、GitLab.com およびセルフマネージド GitLab の顧客に対して技術サポートを提供します。IT（1Password、Slack、Mac など）の問題を抱えている GitLab チームメンバーにサポートを 提供しません。そういった性質の問題で支援が必要な場合は、Team Member Enablement に連絡してください。

GitLab サポートに連絡すべきか？

GitLab に関する一般的な質問（「GitLab で x はできるか？」「GitLab で y を行う方法は？」）については、#questions で質問してください。あるいは、GitLab を使用中にバグまたは正しく動作していない何かに遭遇したと思った場合は、#is-this-known で質問してみてください。そうすることで、誰もが回答に貢献できる ようになります。

GitLab サポートの Slack チャンネルは、GitLab サポートのさまざまな チーム 専用であり、GitLab 製品に関する質問用ではありません。技術サポートを必要とする顧客と作業している場合は、その顧客に GitLab サポートへの連絡 を案内してください。

Support Team Meta プロジェクト

長期的または広範な質問をしたい、GitLab サポートにアイデアを提案したい、何かについて議論したい、ワークフローへの改善や変更を提案したい場合は、Support Team Meta プロジェクトの Issue トラッカー にアクセスして Issue を作成してください。コミュニティに対して公開されているため、機密情報を含めるべきではない ことに注意してください。Zendesk へのリンクや他の参照は推奨されています。

サポートチケットと顧客情報

顧客のためのサポートを依頼する

顧客が技術サポートを必要としてあなたに連絡してきた場合、以下のオプションが利用可能です。

1. （推奨）多くの場合、サポートポータル経由でチケットを開く ように案内してください。私たちの顧客に技術サポートを提供することがサポートの主要な機能であり、有料ユーザーとして顧客は私たちにアクセスする権利があります。このオプションは、顧客が自分自身の Issue とニーズを最もよく説明できる立場にあるため推奨されます。サポートに直接連絡することがほぼ常に最も早い回答への道であることを顧客が理解していることを確認してください。

2. 顧客を GitLab サポートポータル に案内する際、サポート連絡先として追加されている ことを確認するように知らせてください。そうしないと、チケットが自動的にクローズされる可能性があります（ライセンスと更新のチケットを除く）。これに関連して、顧客の同僚もサポートチケットを送信できるようにしたい場合、管理対象連絡先のリストも提供する必要があります。顧客は 連絡先の管理 の手順に従ってサポート連絡先を追加または管理できます。有効なサポートポータルアカウントを持つことを顧客に促すことで、サポートプロセスが合理化され、顧客と私たちのサポートチームの双方にとってよりスムーズな体験が保証されることに注意してください。

3. ライセンス、サブスクリプション、更新、トライアル、トライアル延長、一時ライセンスなどの調整を依頼するには、LnR 社内リクエストを開く ことができます（詳細は下記）。

   • 注: 顧客がすでにライセンス/サブスクリプションを所有しており、それを適用する際にエラーが発生している場合は、顧客が直接私たちにサポートチケットを開くのが最善です。
   • 注: フォームを送信するには、Zendesk Light エージェントアカウント が必要です。すべての GitLab チームメンバーがリクエストできます。このアカウントにより、チームメンバーは Zendesk で顧客チケットを表示し、サポートチームにメモを残すこともできます。

4. 顧客にチケットを開くよう依頼することが状況を悪化させるような繊細なケースでは、Zendesk グローバル社内リクエストフォーム を介して顧客の代理でサポートチケットを開くことができます。これを行うには、Customer Support Internal Requests を選択し、次に What is this request concerning? ドロップダウンで Create a support ticket on behalf of a prospect or customer を選択します。提供できる情報を可能な限り使ってすべての必須フィールドを埋めてください。

   • 注: このプロセスは以下には 使用しないでください:
     • 組織のサポート連絡先の追加。この場合、顧客は自分でサポートチームに直接連絡する必要があります。
     • L&R 社内リクエスト。

外部の顧客は社内リクエストの cc に含めるべきではありません。顧客とのコミュニケーションは、顧客自身が開始した サポートチケット、または顧客の代理で開かれたチケットを通じてのみ提供されます。

サポートは Slack ではアクションを実行しません

特定の顧客状況に関する質問には、サポートチケット（顧客から）または 社内リクエスト チケット（GitLab チームメンバーから）が必要です。

サポートが Slack を介して行われた顧客固有のリクエストに対応できない理由はいくつかあります。

• 私たちは顧客を支援するたびに サービスレベルアグリーメント（SLA）を満たすことを目指しており、SLA コンプライアンスは Zendesk 経由でのみ追跡しています。
• Zendesk にはチケットアサインシステムがあり、これは私たちのワークフローにとって不可欠です。Slack でチケットを割り当てるシステムはありません。
• 私たちが現在の顧客の問題を解決しようとしているとき、Zendesk で解決済みのチケットを頻繁に検索します。Slack のコンテンツは 90 日後に削除されるため、顧客の問題やその解決策が Zendesk チケットの代わりに Slack で議論されると、貴重な情報が失われる可能性があります。
• 私たちは顧客の技術サポート問題とその解決策のすべての記録を一箇所（Zendesk）に保管したいと考えています。

既存の チケットまたは社内リクエストに追加の注意を向けるよう依頼したい場合は、Support Ticket Attention Request フォーム（ハンドブックエントリー）を使用してください。

アカウントまたはログインの問題のある GitLab.com ユーザーのサポートを依頼する

アカウントまたはログインの問題のある GitLab.com ユーザーは、新しいチケットを開いて ください。 リクエストの理由として「GitLab.com (SaaS) User Accounts and Login Issues」を選択する必要があります。

顧客が GitLab サポート Zendesk / 顧客ポータルにログインできない場合

Zendesk 顧客ポータルへのログインに困難がある顧客は、まず 文書化されたトラブルシューティング手順 を試す必要があります。これらの手順でほぼ常に困難が解決されます。

これらのヒントで問題が解決しない場合は、顧客の代理で 社内リクエスト > その他 を開けます。

顧客情報の閲覧をリクエストする

プライバシーポリシー に従い、サポートは公開されていない顧客、グループ、プロジェクトなどに関する情報をあなたに提供しません。これは、顧客が自分自身のプロジェクト、グループなどについての情報をリクエストしている状況も含みます。認証できない場合、私たちはその人が本人であると仮定できません。ロックアウトされた場合は、サポートチケットを送信してもらってください。

Zendesk「Light エージェント」アカウントを依頼する

サポートチケットを表示するには Zendesk Light エージェントアカウントが必要で、マネージャーの承認なしに取得できます。Zendesk グローバル Light エージェントアカウントをリクエストするには、Lumos 経由でリクエストしてください。

Light エージェントアカウントでは、顧客への公開返信を送信できないことに注意してください。これを行う必要がある場合は、フルエージェントアカウントの新しいアクセスリクエスト Issue を提出 し、予算承認のためにマネージャーをタグ付けしてください。必要に応じて、Zendesk から Light エージェントアカウントに関する 詳細情報を読むこと ができます。

一般的なリクエスト

GitLab サポート、プラン、ネームスペースについて

チームメンバー向け self-managed / GDK での Premium/Ultimate 機能のアンロック

ローカルまたはサンドボックステストの目的では、GitLab チームメンバーは独自のエンタープライズエディションサブスクリプションをプロビジョニングできます。これを行う手順:

1. Continue with GitLab.com account ボタンを選択して ステージング Customers Portal にサインインします。既存のアカウントがない場合、作成するように促されます。
2. 選択したいサブスクリプションの購入ページにアクセスします。ステージング Customers Portal のリンクは価格ページにリダイレクトされるので、購入 URL に直接ナビゲートする必要があります。ステージングサブスクリプションの URL の完全なリストは こちら にドキュメント化されています。どのサブスクリプションが必要かわからない場合は、Self-Managed Ultimate が良いデフォルトです。
3. テストクレジットカード を使用してサブスクリプションを購入します。

これは ステージングサブスクリプション であるため、GitLab インスタンスをステージング Customers Portal を使用するように設定する必要があることに注意してください。Omnibus インストールの場合、ステージング Customers Portal を指す方法は こちら です。GDK の場合、環境は デフォルト でステージング Customers Portal を指しているため、アクションは必要ありません。

何らかの理由でセルフプロビジョニングが機能しない場合は、#s_fulfillment または #gdk に支援を求めてください。

チームメンバー向け GitLab.com での Premium/Ultimate 機能のアンロック

GitLab チームメンバーが GitLab.com の Ultimate ライセンスを希望する場合、2 つのオプションがあります。

1. アクセスリクエスト を介してデモ目的の Ultimate グループライセンスをリクエストします。
2. 個人ネームスペース用の Ultimate ライセンスをリクエスト します。

GitLab のインシデントや変更についてユーザーに連絡する

サポートに依頼して、あなたに代わって GitLab.com ユーザーに連絡してもらうことができます。ユーザーへの連絡を依頼できる場合の例を以下に示します。

• GitLab に対して計画されている本番変更がユーザーに大きな影響を与える、または多数のチケットが発生すると考えられる場合
• 緊急のセキュリティ関連 Issue について顧客に通知する必要がある場合
• GitLab.com 上のユーザーをブロックした場合
• 通常とは異なる使用パターンや行動を示しているため、特定のアカウントにインタビューする必要がある場合
• プロジェクト/グループに影響する重要な変更がある場合
• GitLab.com アカウントの問題がある場合

ご注意ください: これはマーケティングや営業関連の連絡用ではありません。このチャンネルは、GitLab SaaS の使用に影響する可能性のある重要事項に関するユーザーとのコミュニケーション専用です。

社内リクエスト

社内リクエスト（IR）には通常 2 つのタイプがあります。

1. カスタマーサポート社内リクエスト 詳細は Gratis サポート を参照してください。

2. L&R 社内リクエスト ライセンス、サブスクリプション、トライアルに関するすべての社内リクエストは、グローバルサポート または 米国政府サポート のいずれかの GitLab Support Internal Zendesk インスタンスを使用して提出する必要があります。Customer Support Internal Request ではなく、L&R Internal Request フォームを選択していることを確認してください。これらは別々のキューにルーティングされ、そうしないとあなたや顧客、見込み顧客にとって遅延が発生する可能性があります。

顧客は社内リクエストの cc に含めるべきではありません。

社内リクエスト SLO

一般的な社内リクエストシナリオ

U.S. Government Support の社内リクエスト

U.S. Government Support の顧客に関連する機密ライセンス Issue については、GitLab チームメンバーは U.S. Government Support にケースを開く ことができます。

GitLab.com 課金可能メンバーリスト

製品が #27074 と #35454 の最小限の実装可能なバージョンを実装したため、サポートはこのプロセスを非推奨にし始めています。製品が取り組んでいる改善とその進捗については、エピック 4547 も参照できます。

GitLab チームメンバーのセルフサービスオプション

基本的なシート数情報を取得するためのオプションを以下に示します。

1. Plan および Seats Currently in Use:
   • chatops（dev.gitlab.org アカウントが必要）でコマンド: /chatops run namespace find group-path
2. 1 の情報に加えてサブスクリプション（またはトライアル）の End Date
3. 2 の情報に加えて Seats in Subscription、Max Seats Used、Start Date
   • Customers ポータル管理（Okta 経由のアクセスが必要）

注: サポートは請求ページのサブスクリプション情報のスクリーンショットのみを提供します。これには以下が含まれます。

• プラン、トライアルかどうか
• サブスクリプション内のシート、現在使用中、最大使用、未払い
• サブスクリプションの開始日と終了日

顧客向けのセルフサービスオプション

注: この情報のパブリック向けバージョンは、ライセンスとサブスクリプションの FAQ ページ にあります。

顧客は、グループの Billing ページ（グループ Settings 配下）でサブスクリプション情報とシートを使用しているユーザーのリストを取得できます。または Billable members API エンドポイント を使用できます。

チケットをエスカレートしたい

「エスカレーション」という用語を MECEFU に保つため、サポートは「サポートチケット注目リクエスト」（STAR）という用語を使用して、アカウントエスカレーション と区別します。「Escalation」は「Emergency」または「Incident」と混同される可能性もあります。

GitLab グローバルサポート時間 中にのみ、以下のいずれかが該当する場合は サポートチケット注目リクエスト を開いてください。

• チケットの進捗が停滞しており、より多くのサポートエンジニアリングの労力が必要
• チケットの優先度が変更された（Low -> High）
• 顧客の高いレベルの不満に対処するため、チケットに即時の介入が必要
• 状況に構造と焦点をもたらすためにサポートマネジメントの監督が必要

サポートチケット注目リクエストの詳細

以下の場合は アカウントエスカレーション を開いてください。

• 単一のチケットまたは複数の Issue の集積によるアカウントレベルのリスクがある。
• 顧客の信頼を回復し Issue を解決するため、複数の部門からの可視性と注意が必要。

アカウントエスカレーションの詳細

以下の場合は 緊急チケット を開いてください。

• 顧客が「緊急」のサポートインパクトについての 私たちの定義 を満たす状況に直面している

サポートエンジニアによる緊急チケットの処理についての詳細

以下の場合は GitLab.com インシデント を宣言してください。

• SaaS 顧客の間で報告された問題の共通パターンに気づいた
• 5 分以上続く機能の喪失 を経験し検証した
• 深刻度の高いバグ が GitLab.com にデプロイされた疑いがある

GitLab.com インシデントの詳細

以下の場合は セキュリティインシデント を宣言してください。

• GitLab サービスやデータの機密性、完全性、または可用性に影響する可能性のあるクリティカルな Issue に関する情報を持っている

セキュリティインシデントの詳細

GitLab.com 管理インターフェイスの設定を変更したい

インフラストラクチャチームが GitLab.com の管理者であり、製品の調整可能項目への変更は 変更リクエストワークフロー を経由します。

トライアルおよび見込み顧客のサポート

優先見込み顧客に関する情報については、 Priority Prospects を参照してください。

顧客が GitLab.com サブスクリプションの適用に困っている

顧客は購入プロセス中に問題に遭遇したか、グループにサブスクリプションを適用する方法を知らない可能性が高いです。次のドキュメントは、GitLab.com にサブスクライブし、GitLab.com アカウントを CustomersDot にリンクし、そのサブスクリプションをグループに適用する方法を説明しています。

• GitLab サブスクリプションを取得する
• サブスクリプションを管理する

自分が所有するアカウントのユーザーが、組織のサポートチケットの可視性を高めたい

場合によっては、特定の組織が組織のすべてのメンバーに、ログされたすべてのサポートチケットを閲覧できるようにしたいことがあります。 他のケースでは、アカウントの特定のユーザーが、組織からのすべてのチケットを閲覧して応答できるようにしたいことがあります。 これを有効にしたい場合は、以下を行ってください。

1. 顧客に Support Ops フォーム を使用してサポートチケットを送信し、Problem type フィールドで Shared organization requests を選択するように依頼します。
2. チケットが作成されると、Support Ops がレビューし、チケットに対応します。

注: 顧客が別のサポートフォームを使用して共有組織リクエストを送信した場合、フォームを Support Ops に変更し、Problem type フィールドで Shared organization requests を選択するだけです。Support Ops はチケットをレビューし、必要に応じてフォローアップの質問をします。

顧客がグループ構造内のすべてのユーザーのレポートを必要としている

グループの課金可能メンバー数を表示するには、グループの Owner 権限を持つメンバーが内訳を見るために Settings -> Billing セクションを訪問できます。課金可能メンバーの数は Seats currently in use の下にリストされる量で、これは有料サブスクリプションにグループをリンクするときに表示される量です。課金可能メンバーは、有料ネームスペース内のグループ、サブグループ、またはプロジェクトに追加された すべてのユーザー で構成されます。例外は、特定のサブスクリプションレベルのネームスペース内のゲストユーザーのみです。

課金可能メンバー API エンドポイント があり、グループのすべての課金可能メンバーのリストを生成します。これは自分の PAT で実行する必要があります。

すべての課金可能メンバーは現在、グループ請求ページにソートされていないリストとしても表示されます。これは最初のイテレーションで、興味があれば、計画されている作業を確認するために エピック を表示できます。課金可能メンバーリストに関するフィードバックや、エピックで計画されていない機能や UI の変更をリクエストしたい場合は、エピックにコメントを残してください。

組織/ユーザーに関する重要な情報を追加したい

Zendesk には組織とユーザーノートを保存する機能があります。Zendesk のトリガーを使用して、これらをその組織またはユーザーが送信した各チケットに入れます。組織またはユーザーのチケットに含めたい重要な情報がある場合は、組織の ID（Zendesk の組織の URL から ID をコピーすることで見つけることができます）を こちら で検索して MR を作成し、関連する組織のファイルに必要な変更を加えてください。 情報が特定の期間のみ有効かどうかを必ず示してください。これによりノートにその事実を含めることができます。

追加したいかもしれないノートの例:

• チケットで使用するために SA の名前をそこに入れたい。
• 顧客が呼びかけ時に特定の称号を使用することを望んでいる。
• 組織が複数のサブスクリプションを持っている。

ページのソースコードを見る - ページの編集 - please contribute.