メンテナンス

健全な環境を維持するには、実施が必要なメンテナンスタスクがいくつかあります。常に自動化することを目指していますが、自動化できず、時折手動で実施する必要があるものもあります。

このガイドでは、GitLab の Zendesk インスタンスに対して実施するさまざまなメンテナンスタスクについて説明します。

自動化されたメンテナンスタスク

不正なタスクチケットを修正する

^{毎時 30 分に実行}

現在時刻より前の Due Date 値が設定された Task タイプのチケットを検出します。この状態のチケットは、Due Date 値を削除し、タイプを Question に設定します。

組織の誤った expired タグを修正する

^{毎時 30 分に実行}

expired タグを持ち、support_level 値が expired ではない組織を検出します。これらの組織については、誤った expired タグを削除する必要があります。スクリプトは次の点を確認した後に削除します。

• expired タグを削除しても、組織のすべての support_level タグが削除されないこと
• expired タグを削除すると、実際の更新が発生すること

削除済みユーザーを完全に削除する

^{毎日 2 回、0045 と 1245 に実行}

ユーザーを削除すると Zendesk ワークスペースからは削除されますが、実際にはユーザーが_完全に_削除されるわけではありません。そのため、これらの削除済みユーザーを定期的に Zendesk から削除する必要があります。

ベース GitLab チケットをクローズする

^{毎時 30 分に実行}

組織 GitLab の配下にあり、承認済みフォームに含まれていないチケットを検出してクローズします。

手動メンテナンスタスク

テーマで今後のバージョン廃止警告を有効にする

メジャーバージョンが間もなくサポート対象外になることを顧客に警告するため、さまざまなフォームやフィールドで GitLab バージョンを入力した際にテーマ上で警告を表示します。

これを変更するには、同期リポジトリで MR を作成し、次を実施する必要があります。

• data/theme/script.js ファイルを更新します
  • ここでは 3 つの変更を行います:

    1. upcoming_unsupported_version_message 関数のバージョン番号と日付を更新します

    2. 次の if ブロックがコメント解除されていることを確認します:

       if ($(this).val().split('.')[0] == xx) {
          $('#gitlab_version_checker_upcoming').show();
        } else {
          $('#gitlab_version_checker_upcoming').hide();
        }
       

       • xx は以前に使用したバージョン番号です

    3. if ブロック内の以前に使用したバージョン番号（ポイント 2 のもの）が更新されていることを確認します

• data/theme/manifest.json ファイルのバージョンを更新します

ピアが MR をレビューして承認した後、MR をマージできます（これにより、次のデプロイ日に変更が有効になります）。

これは、GitLab のメジャーリリースの少なくとも 1 か月前にテーマで有効になるように実施します。今後のリリースの詳細については、GitLab リリースを参照してください。たとえば、リリース日が 2025-05-15 の場合、2025-04-01 のデプロイに間に合うように実施してください。

テーマで今後のバージョン廃止警告を無効にする

メッセージ内のバージョンはサポート対象外になったため、警告を削除する必要があります。これを行うには、同期リポジトリで MR を作成し、次を実施する必要があります。

• data/theme/script.js ファイルを更新します

  • 次の if ブロックがコメントアウトされていることを確認します:

    if ($(this).val().split('.')[0] == xx) {
       $('#gitlab_version_checker_upcoming').show();
     } else {
       $('#gitlab_version_checker_upcoming').hide();
     }
    

    • xx は以前に使用したバージョン番号です
• data/theme/manifest.json ファイルのバージョンを更新します

ピアが MR をレビューして承認した後、MR をマージできます（これにより、次のデプロイ日に変更が有効になります）。

これは GitLab のメジャーリリース当日に実施します。たとえば、リリースが 2025-05-15 の場合、これらの変更はその日に本番稼働します。

テーマでサポート対象バージョンを更新する

サポート対象バージョンの一覧を更新する必要があります。これは、同期リポジトリで MR を作成し、テーマに対して次を実施して行います。

• data/theme/script.js ファイルを更新します
  • supported_versions 変数の定義を見つけ、現在サポートされているバージョンが含まれるように配列を変更します。
• data/theme/manifest.json ファイルのバージョンを更新します

ピアが MR をレビューして承認した後、MR をマージできます。

これは GitLab のメジャーリリース当日に実施します。たとえば、リリースが 2025-05-15 の場合、これらの変更はその日に本番稼働します。そのため、変更を本番稼働させるには、その日に例外デプロイメントを実施する必要があります。

四半期ごとの Zendesk レビュー

私たちは頻繁に変更を行い、継続的にイテレーションするため、Zendesk インスタンスには未使用の項目が蓄積される可能性があります。そのため、保持の必要性を判断するために、未使用のすべての項目を四半期ごとにレビューします。これは、システムとリポジトリをクリーンに保つために実施します。

このタスクでは、1 人の DRI が必要なすべての変更をまとめます。その後、DRI は Customer Support Systems のリーダーシップと協力して、実施が必要なすべてのタスクを委任します。

このプロセスは、主に 5 つのステップに分けられます。

ステップ 1: Issue を作成する

プロセスの中でもより簡単なステップの 1 つとして、Customer Support Systems Issue トラッカーで Administrative Issue を作成する必要があります。

件名には Zendesk INSTANCE Review - FYxxQy の形式を使用し、次を置き換えます。

• INSTANCE は対象の Zendesk インスタンス（Global または US Government）に置き換えます
• xx は 2 桁の会計年度に置き換えます
• y は対象の四半期（1、2、3、または 4）に置き換えます

この時点では Issue の内容は少なくなります。自分自身に（他の誰にもではなく）割り当てられていることを確認してください。

作成したら、ステップ 2に進みます

ステップ 2: 必要な変更を特定する

このステップでは、Zendesk インスタンスでクリーンアップする必要があるすべての項目の一覧を作成します。削除が必要なものの判断は、項目ごとに異なります。

• 記事
  • 6 か月を超えて経過したアーカイブ済み項目がある場合は、削除する必要があります
• 自動化
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• マクロ
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• 組織フィールド
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• チケットフィールド
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
  • 現在チケットフォームで使用されていないフィールドは、無効化する必要があります
• チケットフォーム
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• トリガー
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• ユーザーフィールド
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります
• ビュー
  • 6 か月を超えて経過した無効化済み項目がある場合は、削除する必要があります

変更一覧を用意したら、変更が必要なすべての内容を示すコメントを追加します。他の人がこれを基に作業するため、書式を慎重に検討してください。

コメントを追加したら、ステップ 3に進みます

ステップ 3: Issue をトリアージする

より簡単なステップとして、必要な情報がすべて揃ったため、ここで Issue をトリアージする必要があります。次を実施します。

• トリアージ DRI を Issue の担当者として追加します
• Issue のコメントでトリアージ DRI に連絡し、Issue のトリアージ準備ができたことを知らせます

トリアージ DRI は Issue をレビューし、必要なタグを追加して、Customer Support Systems と話し合い、対象タスクの委任を決定します（その旨を示すコメントを追加します）。

ステップ 4: Issue に対応する

Issue がトリアージされると、対応可能な状態になります。ここで実施する必要がある正確なタスクは、項目自体によって異なります。

• 記事については、Zendesk で直接記事自体を削除する必要があります
• その他の項目については、無効化または削除の詳細は、その項目のドキュメントページを参照してください

委任されたタスクを完了したら、完了したことを Issue の DRI に必ず知らせてください。

ステップ 5: Issue をクローズする

すべてのタスクが完了すると、Issue をクローズできます。

Issue を完了ステージ（ラベル Stage::Completed を追加）に移動し、Issue をクローズします。

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