自動化サービスの制限

インスタンスのパフォーマンスを保つために、以下の自動化サービスの制限が適用されています。

要約

limit

制限に違反する場合

ルールのコンポーネント数

65

1 つのルールに 65 を超える条件、ブランチ、アクションが含まれる

各アクションの新規サブタスクの数

50

ルールによって、50 を超えるサブタスクの作成を実行します。

検索される課題

1,000

スケジュールされた JQL 検索のうち、最適化が不十分で返される課題が1,000 件を超えるもの

同時に実行できるスケジュール済みのルール

1

実行に 5 分以上かかるアクションが、5 分おきにスケジュールされたルール。このルールの同時実行は 1 つのみ許可します。

ルールの関連項目

5,000

ルールを 1 件実行して取得できる項目数を定義します。

For example, a Scheduled trigger fetching 100 issues, followed by a related branch fetching 10 subtasks per issue, would add 100 * 10 = 1000 associated items to this limit.

この上限に達したルールは無効化され、今後は実行できなくなります。

グローバル レベルでキューに入れられているアイテム数

続きを読む

50000

ルールによってキューに入れられたアイテムと同様ですが、グローバル レベルの Jira インスタンスで進行中のルールに適用されます。

*日次の処理時間

12 時間あたり 60 分

たとえば、ルールで動作の遅い外部システムと通信する場合はこのケースに当てはまる可能性があります

ループ検知

10

実行が停止されループとしてマークされるまでに、ルール自体 (または他のルール) をどれだけ速く連続でトリガーできるかを制御します。

[メールを送信] アクション

24 時間でメール 100 通。

この制限は Jira Cloud の Free エディションとトライアル ライセンスにのみ適用されます。

 

Lookup issues action (Jira automation)

100 件の課題

課題検索アクションに JQL クエリを入力すると、最初の 100 件の課題のみが使用されます。

ブランチがルール実行ごとに取得できるアイテムの数。



  • 「ページごと」のブランチ: 150ページ

  • 「タスクごと」のブランチ: 150タスク

  • 「関連エンティティ (CQL) ごと」: 150件の CQL クエリ結果

たとえば、ルール ブランチに 150 を超える項目を返す CQL クエリが含まれている場合、ルールは最初の 150 項目に対してのみアクションを実行します。

同時に実行できるルールの数

  • 無料: 5

  • 標準: 10

  • プレミアム:20

  • エンタープライズ:30

異なるプランで複数の製品を利用している場合は、上限のみがカウントされます。

たとえば、Jira Service Management Enterprise と Jira Cloud Free をご利用の場合、サイトで最大 30 個のルールを同時に実行できます。

Atlassian Intelligence のアクション

1,000 uses of the Generate AI Action items and Summarize with AI actions per 12 hours

 

自動化ルールで処理される課題のフィールド制限

2000フィールド

これは次のアクションに適用されます。

  • 課題の作成

  • 課題のクローンを作成する

*You can use the Service limit breached trigger to create an automation rule to send a notification when you are approaching the daily or hourly processing limit.

制限違反

The following errors in your audit log may indicate that you’re breaching service limits:

  • 監査項目のステータスは "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 issues to retrieve per search. Only the first issues up to the following limit where processed:

ルールがそのサービス制限を超過した場合、エラーについての詳細は監査ログで確認できます。

Jira Automation の [監査ログ] 画面。ルールが制限に違反したことが示されて、その違反に関する詳細が提供されています。

監査ログの情報を使用すると、ルールが許容可能制限内に収まるようにいくつかの手順を講じることができます。一般的な注意事項は次のとおりです。

  • スケジュールされたルールの実行間隔を短くします。たとえば、5 分ではなく 1 時間おきにのみルールを実行します。

  • JQL クエリを制限して関心のある課題のみ検索する。たとえば、課題の更新された時間が一定の範囲内であることを確認します (更新済み > -1 週間として、先週の課題のみ含める)。

  • 各ルールに複数のコンポーネントが必要な場合、自動化ルールを複数のルールに分割します。

  • 数千の課題を編集する必要のある、非常に大きな 1 度限りの操作に対しては、Jira の一括変更機能を使用する。

キューのアイテム数のサービス制限

自動化では、ルール処理用のキューによって、インスタンスのルールの実行が管理されます。パフォーマンスを維持するため、ルールの実行はキューに入れられ、同時に処理されるアイテムの数には上限が設けられています。

自動化ルール ビルダーは強力なため複雑なルール構造を構築できますが、キューに並ぶ項目数が急増する可能性があります。

製品のすべてのルールでこの上限に達すると、自動化ルールは実行されなくなります。

キューが急増する原因となるルールはどのようなものですか?

多数の関連課題ブランチを伴い、これらの各課題ブランチが多数の課題とマッチしているルールです。

以下の例では、約 13,000 件のアイテムがキューに入れられることになります。

  • A Scheduled trigger that matches 100 issues

  • A Related issues branch that matches 50 issues

  • Another Related issues branch that matches 80 issues

Rules with many Related issue branches, to simulate if conditions, can also cause large numbers of queued items. The following examples results in 3,500 items or more, depending on the number of branches.

  • Trigger: Issue updated

  • Related issues branch with JQL: type = Bug that matches 1000 issues

  • Related issues branch with JQL: type = Task that matches 500 issues

  • Related issues branch with JQL: type = Feature that matches 2000 issues

対策

It’s recommended to reduce the overall number of issues a rule fetches, either via the trigger or the Related issues branch.

キューのアイテム数のサービス制限を超えないために、以下のガイドラインを参考にしてください。

  • 実行対象が最小限の課題セットに抑えられるように JQL を使用する。その方法は以下のとおり、いくつかあります。

    • Ensure your JQL search is as specific as possible. Don't just search for issues that match type = Task if you only care about issues currently In Progress. A better alternative in this case would be: type = Task and status = "In Progress".

    • Use the Only include issues that have changed since the last time this rule executed option. For many rules, it's perfectly fine to operate only on this small sub-set

  • Don't create Related issue branches for conditional checks. In the above example, the If/else block condition could be used to match based on the issue type.

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。