自動化サービスの制限
メンテナンス期間中は、一部の自動化ルールが正常に実行されず、意図したとおりに機能しない場合があります。
インスタンスのパフォーマンスを保つために、以下の自動化サービスの制限が適用されています。
要約 | limit | 制限に違反する場合 |
|---|---|---|
ルールのコンポーネント数 | 65 | 1 つのルールには、65 を超える条件、ブランチ、アクションが含まれます。 |
高度なルールあたりのコンポーネント数 | 500 | 高度なルールには、500 を超える条件、ブランチ、アクションが含まれます。 |
ルール グループあたりのコンポーネント数 | 65 | ルール グループには、65 を超える条件、ブランチ、アクションが含まれます。 |
クラウド サイトあたりのルール ラベルの数 | 600 | クラウド サイトのルール ラベルの総数が 600 を超えています。 |
アクションごとの新規サブタスクの数 | 50 | ルールは 50 を超えるサブタスクの作成を実行します。 |
検索された作業項目 | 1000 | 最適化が不十分な、スケジュールされた JQL 検索で、1,000 件を超える作業項目を返すもの。 |
同時に実行できるスケジュール済みのルール | 1 | 実行に 5 分以上かかるアクションが、5 分おきにスケジュールされたルール。このルールの同時実行は 1 つのみ許可します。 |
ルールの関連項目 | 5,000 | ルールを 1 件実行して取得できる項目数を定義します。 たとえば、スケジュールされたトリガーが 100 件の作業項目を取得し、続いて関連ブランチが作業項目あたり 10 件のサブタスクを取得する場合、100 ｘ 10 = 1000 件の関連項目がこの制限に追加されます。 この上限に達したルールは無効化され、今後は実行できなくなります。 |
グローバル レベルでキューに入れられているアイテム数 | 50000 | ルールによってキューに入れられたアイテムと同様ですが、グローバル レベルの Jira インスタンスで進行中のルールに適用されます。 |
*日次の処理時間 | 12 時間あたり 60 分 | たとえば、ルールで動作の遅い外部システムと通信する場合はこのケースに当てはまる可能性があります |
ループ検知 | 10 | 実行が停止されループとしてマークされるまでに、ルール自体 (または他のルール) をどれだけ速く連続でトリガーできるかを制御します。 |
24 時間でメール 100 通。 この制限は Jira Cloud の Free プランとトライアル ライセンスにのみ適用されます。 |
| |
作業項目検索アクション | 100 件の作業項目 | 作業項目検索アクションに JQL クエリを入力すると、最初の 100 件の作業項目のみが使用されます。 |
ブランチがルール実行ごとに取得できるアイテムの数。 |
| たとえば、ルール ブランチに 150 を超える項目を返す CQL クエリが含まれている場合、ルールは最初の 150 項目に対してのみアクションを実行します。 |
同時に実行できるルールの数 |
異なるプランで複数のアプリを利用している場合は、上限のみがカウントされます。 | たとえば、Jira Service Management Enterprise と Jira Cloud Free をご利用の場合、サイトで最大 30 個のルールを同時に実行できます。 |
AI アクション | AI アクション アイテムを生成すると AI で要約を 12 時間あたり 1,000 回使用 |
|
自動化ルールで処理される作業項目のフィールド制限 | 2,000 フィールド | これは次のアクションに適用されます。
|
*[サービス制限違反時] トリガーを使用して、日次または毎時の処理制限に近づいた際に通知を送信する自動化ルールを作成できます。
制限違反
監査ログに次のエラーが含まれている場合は、サービス制限に違反している可能性があります。
監査項目のステータスは "
THROTTLED" です。監査項目には以下が含まれます。
Automation for Jira has exceeded the allowed total processing time for this rule. Maximum allowed processing time over 12 hours is (in seconds):A JQL search in this automation rule has exceeded the allowed maximum number of work items to retrieve per search. Only the first work items up to the following limit where processed:
ルールがそのサービス制限を超過した場合、エラーについての詳細は監査ログで確認できます。
監査ログの情報を使用すると、ルールが許容可能制限内に収まるようにいくつかの手順を講じることができます。一般的な注意事項は次のとおりです。
スケジュールされたルールの実行間隔を短くします。たとえば、5 分ではなく 1 時間おきにのみルールを実行します。
JQL クエリを制限して関心のある作業項目のみ検索する。たとえば、作業項目の更新された時間が一定の範囲内であることを確認します (更新済み > -1 週間として、先週の作業項目のみ含める)。
各ルールに複数のコンポーネントが必要な場合、自動化ルールを複数のルールに分割します。
数千の作業項目を編集する必要のある、非常に大きな 1 度限りの操作に対しては、Jira の一括変更機能を使用する。
キューのアイテム数のサービス制限
自動化では、ルール処理用のキューによって、インスタンスのルールの実行が管理されます。パフォーマンスを維持するため、ルールの実行はキューに入れられ、同時に処理されるアイテムの数には上限が設けられています。
自動化ルール ビルダーは強力なため複雑なルール構造を構築できますが、キューに並ぶ項目数が急増する可能性があります。
アプリのすべてのルールでこの上限に達すると、自動化ルールは実行されなくなります。
キューが急増する原因となるルールはどのようなものですか?
多数の関連作業項目ブランチを伴い、これらの各作業項目ブランチが多数の作業項目とマッチしているルールです。
以下の例では、約 13,000 件のアイテムがキューに入れられることになります。
100 個の作業項目にマッチするスケジュールされたトリガー
関連作業項目ブランチが 50 件の作業項目にマッチする
80 個の作業項目と一致する別の関連作業項目ブランチ
If 条件をシミュレーションする多くの関連作業項目ブランチを含むルールでも、多数のキュー アイテムが発生します。以下の例では、ブランチの数によっては、結果として 3,500 個以上のアイテムとなります。
トリガー: 作業項目の更新時
関連作業項目ブランチの JQL が「type = Bug」であり、作業項目 1,000 件にマッチする
関連作業項目ブランチの JQL が「type = Task」であり、作業項目 500 件にマッチする
関連作業項目ブランチの JQL が「type = Feature」であり、作業項目 2000 件にマッチする
対策
トリガーまたは関連作業項目ブランチを使用し、1 つのルールが取得する作業項目の総数を減らすことをおすすめします。
キューのアイテム数のサービス制限を超えないために、以下のガイドラインを参考にしてください。
実行対象が最小限の作業項目セットに抑えられるように JQL を使用します。そのための方法は、次のとおりいくつかあります。
JQL 検索の内容をできるだけ具体的にする。現在、「進行中」の作業項目にのみ関心がある場合、単純に
type = Taskに一致する作業項目を検索しないでください。このケースでより良い JQL はtype = Taskandstatus = "In Progress"です。[このルールが最後に実行されてから変更された作業項目のみを含める] オプションを使用する。ルールの多くは、この小さいサブセットで運用するだけでも問題ありません。
関連作業項目ブランチを条件付きの確認用に作成しない。上の例では、作業項目のタイプに基づいてマッチを探すために、If/else ブロック条件が使えます。
この内容はお役に立ちましたか?