Jira Automation には、自動化ルールを抑制するための一連のサービス制限が用意されています。ルールがこれらの制限に違反すると、Jira インスタンスに影響を与えないように調整されて無効化されます。

ルールの制限違反を特定する

ルールの制限違反は、監査ログ内の次のエラーによって見分けられます。

• 調整済み: 監査アイテムのステータスは THROTTLED です。

• 詳細な説明: 監査アイテムには次のような詳細な説明が含まれています。

この自動化ルールは前日の合計処理時間の上限を超えた。1 日の最大処理時間 (秒):

Automation for Jira が過去 1 時間のルール実行数の上限を超えた。

この自動化ルールの JQL 検索が 1 回の検索で取得できる最大課題数を超えた。最初の課題から次の上限数までしか処理されていない:

REST によって制限を表示して設定する

REST によって現在の制限を表示して変更できます。

制限を表示する

制限を確認するには、次の REST 呼び出しを使用します。

https://YOUR_JIRA_INSTANCE_URL/rest/cb-automation/latest/configuration/property

応答の例を次に示します。

{
    "max.processing.time.per.day": "3600",
    "rule.rate.per.five.second": "2",
    "short.scheduled.interval.issue.limit": "1000",
    "max.rules.per.hour": "5000",
    "max.issues.per.search": "1000",
    "max.queued.items.per.rule": "25000"
}

制限を設定する

制限の 1 つを設定するには、次の REST 呼び出しを使用します (Content-Type が application/json に設定されている必要があります)。次の表に、各制限のプロパティを示します。

PUT https://<your Jira instance url>/rest/cb-automation/latest/configuration/property

{
    "key": "max.processing.time.per.day",
    "value": "10000"
}

curl コマンドの例

curl -X PUT -H 'Content-type: application/json' \
 -d '{"key": "max.rules.per.hour", "value": "10000"}' \
 https://your-instance.com/rest/cb-automation/latest/configuration/property

サービス制限とそのプロパティ キー

サービス制限の制御には次のプロパティを使用します。

サービス制限がルールに与える影響

下の図は、ルールを実行するか調整するかを決定するために使用されるアルゴリズムを示しています。プロセス全体に一連のサービス制限が含まれており、違反したサービス制限が多すぎるとルールが調整されます。

キューに入れられるアイテムに対するサービス制限

Jira Automation では、ルール処理キューによって自動化ルールの実行を管理します。

Jira では、ブラウザーでユーザーからのリクエストを処理、また自動化ルールなどのバックグラウンド サービスを実行するための処理能力に限界があります。Jira が過負荷にならないようにするため、ルール実行はキューに入れられて、同時に処理されるアイテムの数が制限されます。初期設定では、サーバーごと (または Data Center のノードごと) に 6 個のスレッドが同時に使用されます。

自動化ルール ビルダーによって、ほぼすべての処理に対応したルールを設定できます。その結果、それらのルールの実行に非常にコストがかかる可能性があります。 

例として次の課題を扱うシナリオについて考えましょう。

• ABC-120 - 課題タイプが「タスク」の親開発課題
  • ABC-121 - サブタスク 1
  • ABC-122 - サブタスク 2
  • ABC-123 - サブタスク 3
  • ABC-124 - サブタスク 4
  • ABC-125 - サブタスク 5
• ABC-130 - 課題タイプが「タスク」の別の親開発課題
  • ABC-131 - サブタスク 1
  • ABC-132 - サブタスク 2
  • ABC-133 - サブタスク 3
  • ABC-134 - サブタスク 4
  • ABC-134 - サブタスク 5

ここで、次のルールを考えてみましょう。

この単純なルールでは、13 個の個別アイテムが自動化キューに入れられます。では、順番に解説していきましょう。

• 1 アイテムがキューに入っている目的は、検索を実行するために最初にスケジュールされたトリガーの実行です。
• 2 アイテムがキューに入っている目的は、親課題 ABC-120 & ABC-130 のマッチングです。
• 次に、それらの各アイテムについて、関連する課題のブランチがそれぞれ 5 アイテムをキューに入れています。

たとえば、最初にスケジュールされたトリガーが多数の課題にマッチする、または関連する課題ブランチが多数の課題にマッチする場合、こうしたタイプのルールではキュー アイテムがすぐに増える可能性があることが分かります (また、関連する課題ブランチは JQL 別に課題を検索できます)。

制限に違反するルールを無効にする

ルールの実行終了時にキューに過剰な数のアイテムが追加されると、そのルールは監査ログに記録されてそれ以上は実行されないように無効になります。

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

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

• 100 件の課題にマッチするスケジュールされたトリガー
• 50 件の課題にマッチする関連課題ブランチ
• 80 件の課題にマッチする別の関連課題ブランチ

この結果は (約) 13,000 アイテム (100 * 50 + 100 * 80) です。

(if 条件をシミュレートするための) 多数の関連課題ブランチ含むルール

• トリガー: 課題の更新
• 関連課題ブランチの JQL タイプがバグであり、課題 1000 件にマッチする
• 関連課題ブランチの JQL タイプがタスクであり、課題 500 件にマッチする
• 関連課題ブランチの JQL タイプがフィーチャーであり、課題 2000 件にマッチする

この結果は、ブランチの数に応じて 3,500 アイテム以上になります (1000 + 500 + 2000)。

限度内に収まるようにルールを改善する

ルールが許容限度内に収まるようにするには、次のようないくつかのステップを実行します。

間隔を短くする

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

JQL クエリを制限する

実行対象を最小限の課題セットに抑えた JQL クエリを使用します。そのための方法は、次のとおりいくつかあります。

• JQL 検索の内容をできるだけ具体的にします。たとえば、現在「進行中」の課題にのみ関心がある場合は、単純に type = Task に一致する課題を検索しないでください。type = Task and status = "In Progress" と検索することをお勧めします。
• Only include issues that have changed since the last time this rule executed チェックボックスをチェックにして、ルールを最後に実行してから変更された課題のみを含めます。ルールの多くは、この小さいサブセットで運用するだけでも問題ありません。

条件チェックのブランチを避ける

関連課題ブランチを「条件付きの確認」用に作成しないでください。そのため上記のルールは多くの関連課題ブランチで type = Bug、type = Task などを確認することで、次のように効率的に書けます。

• トリガー: 課題の更新
• 目的の課題とマッチする特定 JQL の関連課題ブランチ (何らかの形でトリガー課題に関連する)
• このブランチで、if/else ブロックによってマッチを課題タイプに基づいて探す

一般的に、トリガーまたは関連課題ブランチによって、1 つのルールで取得する課題の総数を減らすことを目的としています。

ルールの最適化方法に関する詳細は「自動化ルールを最適化する」をご参照ください。