自動化サービスの制限

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

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

制限違反

監査ログに次のエラーが含まれている場合は、サービス制限に違反している可能性があります。

• 監査項目のステータスは "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 件の課題にマッチする別の関連課題ブランチ

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.

• トリガー: 課題の更新

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

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

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

対策

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

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

• 実行対象が最小限の課題セットに抑えられるように 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".

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

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