Import グループ

Import グループはマイグレーションを支援します。

概要

Import グループは Create ステージの一部です。 このグループは GitLab インスタンス間および他のプロバイダーからの移行によってプロダクトをサポートします。

このページは Import グループに固有のプロセスと情報を扱います。また、 グループ方針ページと カテゴリごとにサポートする機能も参照してください。

連絡方法

Import グループに連絡するには、関連プロジェクト（通常は GitLab）に Issue を作成し、 ~"group::import" ラベルと適切なラベルを追加するのが最善です。その後、 関連するプロダクトマネージャーおよび/またはエンジニアリングマネージャーに ping してください。

緊急の案件については、Slack チャンネル（内部）：#g_import をご利用ください。

チームメンバー

以下の人物がグループの恒久的なメンバーです：

チームメンバー情報は 原文 (英語) を参照してください。

メトリクス

エンジニアリングメトリクスダッシュボードはこちらで確認できます。

作業

プロダクトマネージャーはマイルストーンの優先度ラベルを使用し、チーム、エンジニアリングマネージャー、その他のステークホルダーからのインプットを受けて、プロダクト優先順位付けプロセスに従ってデリバラブルおよびストレッチ Issue のリストをまとめます。 イテレーションサイクルはある月の18日から翌月の17日まで続き、リリース予定の GitLab バージョンで識別されます。

Issue 開発ワークフロー

一般的に、標準の GitLab エンジニアリングワークフローを使用します。

エンジニアリングマネージャー、プロダクトマネージャー、その他のステークホルダーが現在のマイルストーンにある全 Issue のステータス、または特定の人に割り当てられた全 Issue の概要を把握する最も簡単な方法は、現在のマイルストーンボードです。このボードにはワークフローラベルごとのカラムがあります。

割り当てられた Issue のオーナーとして、エンジニアは Issue のワークフローラベルを最新の状態に保つことが期待されます。新しいラベルを手動で割り当てるか、ボード上で Issue を次のカラムにドラッグして更新します。

エンジニアが Issue に取り組み始めたら、workflow::in dev ラベルを出発点としてマークし、開発全体を通じて Issue を更新し続けます。プロセスは主に以下のガイドラインに従います：

graph LR

  classDef workflowLabel fill:#428BCA,color:#fff;

  A(workflow::in dev):::workflowLabel
  B(workflow::in review):::workflowLabel
  C(workflow::verification):::workflowLabel
  F(workflow::complete):::workflowLabel

  A -- Push an MR --> B
  B -- Merged --> C
  C --> D{Works on production?}
  D -- YES --> F
  F --> CLOSE
  D -- NO --> E[New MR]
  E --> A

誰かが Issue に取り組み始めたが、1週間同じワークフローラベルのままになっている場合、担当者は Issue の状況を説明するコメントを残す必要があります。Issue が進んでいない間は、少なくとも毎週1件のコメントを書く必要があります。

Issue ボード

Import グループの作業は以下の Issue ボードで追跡できます：

Issue ラベル

良いラベルの管理を維持するために、Issue を作成またはトリアージする際は正しいラベルを適用してください。

すべての Issue に必要なもの：

  • ~"group::import"（ボットがステージとセクションのラベルを適宜適用します）
  • 1つ以上のカテゴリラベル：
    • ~"Category:Importers"（FIXME: 現時点でボットはすべての Issue にこのカテゴリを強制します）
    • ~"Category:Webhooks"
  • タイプラベル
  • ワークフローラベル
  • 必要に応じて ~"backend" または ~"frontend"

インポーターに関連する Issue には、Importer: ラベルも適用してください。例：~"Importer:GitHub" または ~"Importer:Direct Transfer"。

キャパシティプランニング

私たちはキャパシティプランニングを支援するために Issue ウェイトの軽量なシステムを使用しています。 これらのウェイトにより、サイクルでスケジュールされた作業量が、チーム全体として、また各個人にとっても合理的であることを確認できます。特定のサイクルの「ウェイト予算」は、チームの最近のアウトプットと、各エンジニアの今後の稼働可能日数に基づいて決定されます。

物事は思っているより時間がかかるため、Issue がウェイトの示す時間よりも長くかかっても問題ありません。ウェイトは集計的に使用されることを意図しており、ある人が1日でできることが別の人には1週間かかることもあります。それはその Issue に関するバックグラウンドの知識量によります。これは明示的に問題なく、予期されています。 正確であるよう努めますが、それらはあくまで見積もりであることを理解してください！ウェイトが正確でない場合、または Issue が当初予想より難しくなった場合はウェイトを変更してください。ウェイトが変更された理由を示すコメントを残し、EM にタグ付けして、ウェイト設定をより深く理解し改善を続けられるようにしてください。

ウェイト

使用するウェイトは以下のとおりです：

ウェイト説明
1: 些細問題は非常によく理解されており、追加の調査は不要で、正確な解決策はすでにわかっていてあとは実装するだけです。予期せぬ問題はなく、他のチームや人々との調整も不要です。

例：ドキュメントの更新、すでに調査・検討済みで数行のコードで修正できる単純なリグレッションやバグ、またはまだ時間が見つかっていないだけで正確な対処方法がわかっているテクニカルデット。
2: 小問題はよく理解されており解決策の概要が描かれていますが、解決策を実現するためにもう少し追加の調査が必要な可能性があります。あったとしても少数の予期せぬ問題があり、他のチームや人々との調整は不要です。

例：既存のデータや機能を公開する新しい API エンドポイントのようなシンプルな機能、またはすでに調査が始まっている通常のバグやパフォーマンス Issue。
3: 中よく理解されており比較的簡単な機能。解決策の概要が描かれ、ほとんどのエッジケースが考慮されていますが、解決策を実現するためにある程度の追加調査が必要です。いくつかの予期せぬ問題が予想され、他のチームや人々との調整が必要な場合があります。

比較的よく理解されておらず、まだ提案された解決策がないかもしれないバグ。重大な調査が確実に必要ですが、問題が見つかれば比較的簡単に解決できるはずです。

例：バックエンドとフロントエンドのコンポーネントを持つ通常の機能、またはほとんどのバグやパフォーマンス Issue。
5: 大よく理解されているが、難しいことがわかっている機能。解決策の概要が描かれ、主要なエッジケースが考慮されていますが、解決策を実現するためにはかなりの追加調査が確実に必要です。多くの予期せぬ問題が予想され、他のチームや人々との調整が必要なことが多いです。

非常によく理解されておらず、提案された解決策がないバグ。重大な調査が必要で、問題が見つかっても解決策が簡単でない可能性があります。

例：バックエンドとフロントエンドのコンポーネントを持つ大きな機能、またはある程度の初期調査が行われたが再現されていないか「解明」されていないバグやパフォーマンス Issue。

5より大きいものはできれば分解する必要があります。

ウェイトは開発とレビューの両方の時間を考慮すべきです。

セキュリティ Issue は通常、上記の表から通常考えられるよりも1レベル高くウェイト付けされます。これはパッチリリースプロセスの厳格さを考慮したものです。特に、修正はより慎重な検討が必要で、複数のリリースにバックポートする必要があります。

バックログリファインメント

エンジニアは通常、取り組む予定の Issue を自分でリファインします。ただし、特にコミュニティコントリビューターが担当する可能性のある Issue については、誰でも開発の準備が整うようにリファインできます。

Issue が Epic の一部の場合、DRI がリファインするか、その Epic に割り当てられたエンジニアにリファインメントを委任することがあります。誰がリファインするかに関係なく、マイルストーン開始前にリファインメントを完了することを目指してください。

遅くても、エンジニアリングマネージャーが次のマイルストーンの計画 Issue を共有する時点でリファインメントを始めるべきです。これは現在のマイルストーン終了の1週間前に行われます。

リファインメント対象 Issue の特定

エンジニアリングマネージャーが Issue をスケジュールし、それがマイルストーン計画 Issue に含まれます。

各エンジニアのマイルストーン割り当てに基づいて、Ready for Development ステータスでない Issue を特定してください。これらは通常 Refinement または Planning breakdown ステータスを持ちますが、任意のプロダクト開発フローステータスを持つ場合もあります。

Ready for Development だが何ヶ月も前にリファインされた Issue は、コードベース、プロダクト、アーキテクチャ方向の変化に焦点を当てて再度リファインする必要があります。

Issue のリファインメント

Create ステージのクロスチームプランニングとリファインメントガイドライン、特にリファインメントと実装計画のセクションに従ってください。

Import グループでは、これらのガイドラインに加えて以下の Import 固有の要件を満たす場合に Issue がリファインされたとみなします：

  • ウェイト（type::bugs ではオプション）
  • 別のエンジニアによるピアレビュー（ウェイト1の Issue ではオプション）；レビュー済みを示すために、レビュアーはコメントを残すか Issue を Ready for development に移動します
  • Ready for development ステータス

バグの準備

バグは取り組む前に完全に理解されている必要はなく、そのためウェイトは不要です。

バグを完全に理解するための労力は、しばしば修正のための労力のほとんどを占めます。したがって、バグ Issue における提案された解決策は、欠陥の不完全な理解に基づいた提案とみなすことができます。

少なくとも以下を含めるようにしてください：

  • 再現手順
  • 現在の動作
  • 期待される正しい動作

Bug テンプレートにはこれらのフィールドが含まれています。

サポートの要請

サポート組織の一員でない場合は、まず彼らに連絡することをお勧めします。彼らはより高い可用性を持ち、ほとんどの一般的な問題をサポートできます。専用の Slack チャンネル #spt_pod_import に参加してフォローし、そこで質問することができます。ただし、顧客の Issue を解決するために詳細な技術的知識が必要になる場合があり、チームのエンジニアの関与が必要になることがあります。

エンジニアリングチームにサポートを依頼する前に、まず関心のあるトピックの GitLab ドキュメントと以下の追加リソースをご確認ください：

上記のリソースで質問への回答が見つからない場合は、Request for Help (RFH) Issue を開き、SupportRequestTemplate-Import テンプレートを使用してください。チームに連絡する前に必要な情報をすべて提供してください。そうでないとリクエストを処理できません。新しい Issue は内部のトリアージプロセスに従って優先順位が付けられます。現在の GitLab バージョンと直近2つのマイナーバージョン（N-2）に影響する Issue のリクエストのみサポートできます。古いバージョンの修正は提供できません。これはバックポートのメンテナンスポリシーに準拠しています。

マイルストーンドクター

各マイルストーンでは、チームのバックエンドエンジニア2名がマイルストーンドクターの役割を割り当てられ、一方がプライマリ、もう一方がセカンダリとなります。割り当てはマイルストーンドクターローテーションスケジュールにあります。エンジニアは今後のシフトを自由に交換してスケジュールを更新できます。

セカンダリドクターは、プライマリが OOO（オフィス外）またはキャパシティオーバーの場合に介入し、同じ責任を担います。それ以外の場合は、マイルストーンに計画された作業に取り組みます。プライマリドクターは OOO またはキャパシティの問題がある場合はセカンダリに知らせてください。

プライマリドクターのマイルストーンキャパシティは100%役割の責任に割り当てられます。残っていない場合、エンジニアは ~type::maintenance または ~type::bug Issue に取り組み、コードレビューのキャパシティを増やすことを検討してください。

現在のドクターは @gitlab-com/create-team/import/reaction-rotation でタグ付けできます。

責任

  • 新しい RFH Issue でサポートと PS に対応する
  • 長期間オープンしている Issue をフォローアップする
  • 顧客コールでサポートチームをサポートする
  • マイルストーンドクターが問題を正常に診断した方法に関するチームのランブックドキュメントを維持する
  • チームの Slack チャンネル #g_import の質問に回答する
  • シフトからの学びで私たちの FAQ を更新する
  • インポーター依存関係をレビューし、サードパーティ API の変更による必要な変更の Issue を作成する
  • マイルストーン終了時に @gitlab-com/create-team/import/reaction-rotation のメンバーシップを更新する

インポーター依存関係

各マイルストーンで、各インポーターの依存関係の変更履歴を確認し、今後の破壊的変更や API の非推奨化がないかをチェックしてください。GitLab Duo Chat を使って影響を評価し、更新が必要な変更には関連する ~"Importer:" ラベルを付けた Issue を作成してください。

レビュー後、計画 Issue にサマリーと作成した Issue へのリンクを含むコメントを残してください。EM にタグ付けして注意を促してください。

推奨プロンプト

[START_DATE] を依存関係が最後に確認された日付に置き換えてください。

You are helping an engineer on the GitLab Import team perform a periodic review of third-party API dependencies. Our importers integrate with external services and we need to check their changelogs for any breaking changes, deprecations, or required migrations announced since [START_DATE].

Review the following changelog pages and identify any changes that could break or require updates to our importers:

**GitHub importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/github_import
- Changelogs: https://docs.github.com/en/rest/about-the-rest-api/breaking-changes, https://github.blog/changelog/, https://github.com/octokit/octokit.rb/releases

**Bitbucket Cloud importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/bitbucket, https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/bitbucket_import
- Changelogs: https://developer.atlassian.com/cloud/bitbucket/changelog/

**Bitbucket Server importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/bitbucket_server, https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/bitbucket_server_import
- Changelogs: https://developer.atlassian.com/server/bitbucket/changelog/

**Gitea importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/import/gitea_controller.rb (uses GitHub import client)
- Changelogs: https://github.com/go-gitea/gitea/blob/main/CHANGELOG.md, https://blog.gitea.com

**Jira importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/jira_import
- Changelogs: https://developer.atlassian.com/cloud/jira/platform/changelog/, https://github.com/sumoheavy/jira-ruby/releases

**FogBugz importer**
- Source: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/fogbugz_import
- Changelogs: https://support.fogbugz.com/section/3113-articles

For each change you find, check the corresponding GitLab implementation to verify whether the change affects us.

Then, for each importer, list:
1. The name of the importer
2. Whether changes are required
2. A summary of the required change (for changes that do not affect us, simply provide a link to
   the announcement)
3. The due date or enforcement date

If no actionable changes are found, confirm that and note the date range you checked.

セキュリティとの連携

グループにはセキュリティへの影響がある可能性のある Issue を特定するための脅威モデルがありますが、他にも考慮すべき事項があります。

アプリケーションセキュリティレビューは、Issue または MR がセキュリティに影響する可能性がある場合に要請すべきです。これには以下が含まれますが、これに限りません：

  • 脅威モデルに該当する場合
  • バイナリファイルの処理（ダウンロード、解凍、展開、移動、削除）
  • ファイル操作サービスの変更または使用
  • Import/Export の CommandLineUtil のメソッドを使用する場合

長期間有効なフィーチャーフラグ

これはフィーチャーフラグの使用に関する GitLab の一般的な開発ガイダンスを補足するものです。ops タイプを除くすべてのフラグタイプに適用されます。

Import 機能への変更はしばしば高トラフィックのコードパスで発生し、過去に GitLab.com で障害を引き起こしました。障害はしばしばリソースの競合に関連しており、コードレビューや QA テストでは事前に気づくことが難しいことがあります。

  • 大規模なインポートは何千ものワーカーをトリガーする可能性があります。
  • インテグレーションとウェブフックは1日に何百万回も実行されます。
  • 競合の問題は即座に表面化せず、大規模な顧客が新しいコードパスをトリガーした時だけ発生することがあります。

このため、フィーチャーフラグを通常よりも長い期間コードベースに残すことを推奨します。 この期間中、フラグはデフォルトで有効になっていますが、インシデントの際には迅速に無効化できます。

過去に、機能を無効化することでいくつかのインシデントを迅速に軽減できました：

インポーター、インテグレーション、またはウェブフック内の変更については、以下を推奨します：

  1. 通常通り /chatops でフラグをロールアウトする。
  2. スケールでの問題を積極的に洗い出すために大規模なデータを使用して変更を QA する。 インポーターについては、ランブックのヒントを参照してください。
  3. 機能をリリースする際は、フィーチャーフラグを削除するのではなく default_enabled: true に変更する。これはフラグロールアウト Issue のオプション的なフラグ付きで機能をリリースのステップです。
  4. この時点で機能はマイルストーン内でリリースされたとみなされ、セルフマネージドの顧客に届くためリリースポストで発表できます。
  5. フラグがコードベースに存在しますがデフォルトで有効な状態で1〜3週間待機する。 競合が多い領域の変更や、何らかの理由で問題の検出に時間がかかると思われる場合は長い期間を使用してください。
  6. その期間後、フラグを削除してフラグロールアウトプロセスを完了する。

リリース中

  • キックオフ後にリリースに Issue が追加された場合、未計画の作業を考慮して等量のウェイトを削除する必要があります。
  • Issue の見積もりとウェイト付けが完了する前に開発を開始すべきではありません。
  • 15日までに、エンジニアリングのマージリクエストをマージする必要があります。言い換えると、15日以降にマージされたコードはリリースに含まれないと想定します。これにより、リリースがファイナライズされる時間と、関連するリリースポストが17日までにマージされる時間が確保されます。（これは13.11 から始まった実験です。）

リリースポスト

詳細な発表が必要な Issue については、Issue を使用してリリースポストを自動的に作成できます。 Issue に取り組む際（計画中、または設計・開発中）に、リリースポストアイテムジェネレーターを使用してリリースポストを作成し、関係者全員に通知することができます。

Issue にリリースポストを作成したくない場合は、Issue にリリースノートセクションがないことを確認するか、release post item:: ラベルを使用しないでください。

概念実証 MR

私たちはイテレーションと小さなインクリメントでの価値提供を強く信じています。イテレーションは難しい場合があります。特に、プロダクトのコンテキストがないときや、コードベースの特にリスクの高い/複雑な部分に取り組んでいるときはそうです。Issue の見積もりや実現可能かどうかの判断に苦労している場合は、最初に概念実証 MR を作成することが適切な場合があります。概念実証 MR の目的は、計画中の主要な仮定を排除し、早期のフィードバックを提供することで、将来の実装からのリスクを軽減することです。

  • PoC: のプレフィックスを付けて MR を作成する。
  • MR の説明に PoC MR が解決しようとしている問題を説明する。
  • タイムボックスを設ける。2〜3日以内に実現可能性や計画を判断できますか？
  • この期間終了時にフィードバックを提供するレビュアーを特定する。
  • MR をクローズする。PoC から学んだこと（プロダクトとパフォーマンスへの影響を含む）の要約を元の Issue に提供する。
    • 実装を進めることができるかどうかを述べる。
    • Issue をクローズしないでください。

概念実証 MR の必要性は、コードベースやプロダクトの一部が過度に複雑になっていることを示すシグナルかもしれません。将来このステップを避ける方法を議論できるよう、振り返りの一部として MR を議論することは常に価値があります。

振り返り

定期的にスケジュールされた「マイルストーンごと」の振り返りが1回あり、「プロジェクトごと」の振り返りは随時行うことができます。

マイルストーンごと

Import グループは GitLab Issue でマイルストーン振り返りを実施しています。これにはエンジニア、UX、PM、そのマイルストーンでチームと協力したすべてのステーブルカウンターパートが含まれます。

チームメンバーの参加はすべてのマイルストーンで強く奨励されています。

これらは最初の議論の間は機密で、毎月の GitLab 振り返りに間に合うように公開されます。詳細については、グループ振り返りを参照してください。

プロジェクトごと

特定の Issue、機能、またはその他のプロジェクトが特に有益な学習経験になった場合、そこから学ぶための同期または非同期の振り返りを行うことがあります。取り組んでいることが振り返りに値すると思う場合は：

  1. 振り返りを行いたい理由を説明し、同期か非同期かを示す Issue を作成する。
  2. EM と関与すべき他の人（PM、カウンターパートなど）を含める。
  3. 該当する場合は同期ミーティングを調整する。

振り返りからのすべてのフィードバックは、参照目的のために最終的に Issue に記録すべきです。

テックリード

私たちのグループはテックリードと協力して、さまざまなトピックに関する作業を整理し、それらの DRI を特定します。

テックリードの特徴

テックリードとは：

  • 追加の責任を持つ個人コントリビューターです。シニアリティに関係なく、すべてのエンジニアがテックリードになる資格があります。
  • 特定のトピック/プロジェクトに結び付いた一時的な役割です。チームが異なるトピック/プロジェクトについて同時に複数のテックリードを持つことができます。
  • マネージャーではありません。
  • 追加のシニアリティレベルではありません。

テックリードの役割は、リーダーシップスキルの習得に関心のあるエンジニアに成長の機会を提供します。

テックリードの責任

テックリードは多くの役割を担います。その責任はプロジェクトによって異なる場合がありますが、以下が含まれることがあります：

  • テクニカルビジョンとアーキテクチャ - 特定のプロジェクトの全体的な技術アーキテクチャを定義・発展させる
  • テクニカルガイダンス - チームの他の開発者に技術的なガイダンスとメンタリングを提供する
  • 作業の計画と優先順位付け - 大きなタスクをより小さな実行可能なアイテムに分解して作業を整理する
  • 進捗の追跡 - コミットメントの進捗を追跡してステータス更新を報告する
  • リスク管理 - 成果物に影響を与える可能性のある技術的リスクを特定、評価、管理する
  • 調整 - 他者の作業を監督してブロッカーの除去を支援する
  • 技術ドキュメント - 他の開発者のために技術アーキテクチャとコード構造のドキュメントを維持する

現在のテックリード

以下は、テックリードが監督しているトピックの概要です：

トピックテックリードトピックリンク備考
Direct Transfer - ユーザーコントリビューションマッピングRodrigo TomonariEpic-
インポーターへの開発者コントリビューションの効率改善James NuttOKR-
Congregatetbdhttps://gitlab.com/gitlab-org/gitlab/-/issues/428657
GitHub Actionstbdhttps://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17652

マージリクエストルーレットレビュー

Import コードベースのエリアが変更された場合、レビュアールーレットはマージリクエストを Import チームメンバーがレビューするよう推奨します。これは、Import チーム外の人がマージリクエストを作成した場合にのみ発生します。レビュー推奨がどのように表示されるかの例を参照してください。

これらの特別な推奨の理由は、他のグループが特定のインテグレーションやウェブフックに一部のオーナーシップを持っているからです。チーム外のメンバーによる変更をレビューすることで、基本コードのオーナーとして行動し、Import コードベースの品質をより良く維持できます。

ルーレットのマッチングの仕組み

マージリクエストの変更のファイルパスは、正規表現のリストと照合されます。 ルーレットはこれらのハッシュ値を使ってレビュアーグループを推奨します。例えば、:import_integrate_be と :import_and_integrate_fe はそれぞれ Import のバックエンドとフロントエンドのレビューを推奨します。正規表現のマッチは最初のマッチが優先であり累積ではないため、:backend や :frontend のような他の関連するレビュアーグループも各ハッシュ値に含める必要があります。

正規表現リストは、インテグレーションやウェブフックのコードが必要に応じて更新されるたびに更新する必要があります。このリストは一般的に名前空間が付いたファイルと一致するため、既存の名前空間内の新しいコードは常にマッチします。

GitLab リポジトリ内のどのファイルがマッチを生成するかを確認するには、Rails コンソールに以下を貼り付けてください：

require Rails.root.join('tooling/danger/project_helper.rb')

ALL_FILES = Dir.glob('**/*');

def category_regexs(category)
  matching_categories = Tooling::Danger::ProjectHelper::CATEGORIES.select do |regexs, categories|
    next if regexs.is_a?(Array)

    Array.wrap(categories).include?(category)
  end

  regexes = matching_categories.map(&:first)
  Regexp.union(*regexes)
end

def print_files(category)
  regex = category_regexs(category)

  puts ALL_FILES.grep(regex).reject { |path| File.directory?(path) }.sort
end

puts "Backend:\n"
print_files(:import_integrate_be)

puts "Frontend:\n"
print_files(:import_integrate_fe)

モニタリング

これは私たちの機能を監視するためのリンクのコレクションです。

Grafana ダッシュボード

Sentry エラー

Kibana ダッシュボード

すべての Import Kibana ダッシュボードのリストを参照してください。

インポーターダッシュボード：

API/Webhooks ダッシュボード：

Kibana ログ

GitLab for Jira Cloud アプリワーカー：

エラーバジェット

GitLab はエラーバジェットを使用して機能の可用性とパフォーマンスを測定しています。 各エンジニアリンググループには独自のバジェット消費があります。Import チームの現在の28日間の消費はGrafana ダッシュボードで確認できます。

エラーバジェットの消費は、以下のいずれかが特定のしきい値を超えた場合に発生します：

  • エンドポイントまたはワーカーのエラーレート
  • エンドポイントの Apdex（レイテンシー）

最も影響の大きい修正の特定

Grafana ダッシュボードで最優先の問題を特定するには：

  1. Error budget パネルに移動する。
  2. Budget spend attribution を展開する。Budget failures パネルは上位の障害順に並んでいます。
  3. Failure log links で対応するリンクをクリックする。

上位の問題を修正することがバジェット消費に最大のインパクトをもたらします。

さらなるリソース

エラーバジェットについてはこれらのリソースで詳しく学べます：

使用状況データダッシュボード

Tableau で機能使用のデータを表示できます。

リンクとリソース

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License