robotsnoindex
robotsnoindex

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

要約

limit

制限に違反する場合

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

65

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

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

100

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

検索される課題

1,000

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

同時にスケジュールされたルール実行

1

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

ルールの関連項目

5,000

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

たとえば、スケジュールされたトリガーが 100 件の課題を取得し、続いて関連ブランチが課題あたり 10 件のサブタスクを取得する場合、100 x 10 = 1000 件の関連項目がこの制限に追加されます。

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

50000

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

*日次の処理時間

12 時間あたり 60 分

ルールが 5 分ごとに実行され、1 回あたり 5 秒以上かかる。たとえば、ルールで動作の遅い外部システムと通信する場合はこのケースに当てはまる可能性があります

ループ検知

10

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

* サービス制限の超過トリガーを使用して、日次または毎時の処理制限に近づいた場合に通知を送信する自動化ルールを作成できます。

制限違反

監査ログに以下のエラーがある場合は、サービス制限を超えている可能性があります。

  • 監査項目のステータスは "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:

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



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

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

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

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

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

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

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

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

ルールがキューに並ぶ項目の制限に達した場合、監査ログに詳細が記録され、このルールは今後実行されないように無効となります。

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

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

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

  • 100 個の課題にマッチするスケジュールされたトリガー

  • 関連課題ブランチが 50 件の課題にマッチする

  • 80 件の課題にマッチする別の関連課題ブランチ

if 条件をシミュレーションする多くの関連課題ブランチを含むルールでも、多数のキュー アイテムが発生します。以下の例では、ブランチの数によっては、結果として 3,500 個以上のアイテムとなります。

  • トリガー: 課題の更新

  • 関連課題ブランチの JQL タイプがバグであり、課題 1,000 件にマッチする

  • 関連課題ブランチの JQL タイプがタスクであり、課題 500 件にマッチする

  • 関連課題ブランチの JQL タイプが Feature であり、課題 2,000 件にマッチするもの

対策

トリガーまたは関連課題ブランチを使用し、1 つのルールが取得する課題の総数を減らすことをおすすめします。

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

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

    • JQL 検索の内容をできるだけ具体的にする。現在、"進行中" の課題にのみ関心がある場合、単純に type = Task に一致する課題を検索しないでください。このケースでより良い JQL は type = Task and status = "In Progress" です。

    • [このルールが最後に実行されてから変更された課題のみを含める] オプションを使用する。ルールの多くは、この小さいサブセットで運用するだけでも問題ありません。

  • 関連課題ブランチを条件付きの確認用に作成しない。上の例では、課題のタイプに基づいてマッチを探すために、If/else ブロック条件が使えます。