Jira Service Management ガードレール
このページで説明する内容は、最新の長期サポート バージョンである Jira Service Management 5.4 に適用されます。
背景
アトラシアンは、大手顧客のニーズをサポートすることを約束しています。その取り組みには、製品のパフォーマンスとスケーラビリティの継続的な改善が含まれます。インスタンス内のデータ量は、パフォーマンスと安定性の問題の要因になる可能性があります。インスタンスが大きくなるにつれて、時間の経過とともにパフォーマンスが低下するリスクも増えます。多くの場合は段階的に低下するため、チームに重大な影響を及ぼす状況に達するまで気付かれない可能性があります。
次の表では観察されたパフォーマンスと安定性への影響を説明して、リスクを軽減するために実行できるいくつかのアクションを提案しています。ガードレールは、一部の大手顧客の実際の経験と、スタンドアロンの Jira Service Management インスタンスでのパフォーマンス テストに基づいています。ガードレールは、必ずしもすべての組織の経験を表すものではありません。
パフォーマンスと安定性に関する重大な問題が発生するリスクを軽減する方法には、次のようなものがあります。
アプリの変更。たとえば、パフォーマンスを向上させるために新しいアプリ バージョンにアップグレード、またはユーザーの管理方法を変更します。
インフラストラクチャの変更。たとえば、メモリや CPU を増設、またはクラスターやミラーを実行します。
フットプリントを削減するためのデータ クリーンアップ アクティビティ。たとえば、アーカイブ、またはモノリス サイトを分割します。
これらはハード制限ではなく、一部の製品インスタンスは既にこれらのしきい値を超えている可能性があることにご注意ください。異なるデータ タイプ間の相互作用やサイトの負荷など、さまざまな要因によって次に示すような潜在的な影響が発生する可能性とその影響の程度が決まります。あらゆるタイプのリスクと同様に、リスクを特定して計画を立てることが不可欠です。そうすれば、これらのアクションに優先順位付けて将来のパフォーマンス問題の可能性を減らすのに役立ちます。
ガードレールとは
製品ガードレールとはデータ タイプに関する推奨事項であり、潜在的なリスクを特定してインスタンス最適化ジャーニーの次のステップに関する意思決定をサポートするように設計されています。
Jira Service Management ガードレール
次のガードレールは、スケール リスクを特定して軽減し、インスタンスのクリーンアップに関する意思決定を下すのに役立ちます。
サービス レベル アグリーメント (SLA)
CONTENTTYPE | プロジェクトあたりの SLA の数 |
---|---|
ガードレール | プロジェクトあたり 30 件の SLA |
この数を調べる方法 | プロジェクトごとの SLA の数を調べるには、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
SLA 目標
CONTENTTYPE | SLA 目標の数 |
---|---|
ガードレール | SLA あたり 100 件の目標 |
この数を調べる方法 | SLA ごとの目標数を調べるには、次の SQL クエリを実行します。
プロジェクトごとの SLA 目標の数を調べるには、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
アセット オブジェクト スキーマ
CONTENTTYPE | オブジェクト スキーマの数 |
---|---|
ガードレール | 1000 個のオブジェクト スキーマ |
この数を調べる方法 | 次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 オブジェクト スキーマの数を調べるには、返された応答内の |
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
アセット オブジェクト タイプ
CONTENTTYPE | オブジェクト スキーマあたりのオブジェクト タイプの数 |
---|---|
ガードレール | オブジェクト スキーマあたり 500 個のオブジェクト タイプ |
この数を調べる方法 | 次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 オブジェクト スキーマのオブジェクト タイプの数を調べるには、返された応答内の または、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
アセット オブジェクト
CONTENTTYPE | オブジェクトの数 |
---|---|
ガードレール | オブジェクト スキーマあたり 500k 個のオブジェクト インスタンスあたり 200 万個のオブジェクト - 主に重いオブジェクトが使用されています。つまり、次のようなオブジェクトです。
インスタンスあたり 500 万個のオブジェクト - 主に軽いオブジェクトが使用されます。 |
この数を調べる方法 | オブジェクト スキーマあたりのオブジェクト数を調べるには、次のいずれかの方法をお勧めします。
インスタンス内のオブジェクトの数を調べるには、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
アセット属性
CONTENTTYPE | オブジェクト タイプあたりの設定された属性の数 |
---|---|
ガードレール | オブジェクト タイプあたり 100 個の設定された属性 |
この数を調べる方法 | 次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 オブジェクト タイプごとに設定された属性の平均数と最大数を調べるには、返された応答内でそれぞれ または、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
|
緩和オプション |
|
アセット属性の値
CONTENTTYPE | すべてのオブジェクトに保存されている属性値の数 |
---|---|
ガードレール | 2500 万個の属性値 - 主に重いオブジェクトが使用されます。次のようなオブジェクトが該当します。
5000 万の属性値 - 主に軽いオブジェクトが使用されます。 |
この数を調べる方法 | インスタンス内の属性値の数を調べるには、次の SQL クエリを実行します。
|
リスク | このガードレールを超えて運用した場合は、次の問題が確認されています。
このガードレールは、事実上すべてのオブジェクトが単一のオブジェクト スキーマ内で作成されるという最悪のシナリオを想定して設定されています。オブジェクトがより均等に分散されていれば、パフォーマンスへの影響はそれほど大きくならないと考えられます。 |
緩和オプション |
|