---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# SLO フォームの作成

# SLO フォームの作成 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：3分

サービスレベル目標 (SLO) を サービスリライアビリティ管理 に追加するために使用できるフィールドについて説明します。

## \[サービスレベル目標\] フォーム {#sr-create-slo-sli-form__section_ehr_h2n_y1c}

次の表では、サービスレベル目標フォームで利用可能なオプションについて説明します。詳しい手順については、「[SLO、SLI、およびエラー予算ポリシーの作成](https://servicenow-prod.fluidtopics.net/eTwp0jGrzCj1ddm3FPZsuQ "サービスレベル目標 (SLO)、サービスレベルインジケーター (SLI)、およびエラー予算ポリシーを定義して、サービスヘルスを監視します。これらのツールは、ユーザーとチームがパフォーマンスを追跡し、必要に応じてアクションを実行するのに役立ちます。")」を参照してください。
{#sr-create-slo-sli-form__id_sdb_v2n_y1c__entry__2}

| フィールド | 説明 |
|-|-|
| 名前 | SLO の名前。 |
| SLI タイプ | メトリクスを計算する基準となる SLI のタイプ。利用可能な SLI タイプは次のとおりです。 * 可用性：サービスが利用可能な時間の割合。(デフォルト) * エラー：サービスエラーの発生頻度の測定値。 * 遅延：要求のサービスに要した時間。実際に経過した時間です。 * 飽和度：システムの割合の測定値。制約が最も大きいリソースを強調します。 {#sr-create-slo-sli-form__ul_vk4_nq1_s4b} |
| この目標をどのように測定しますか？ | この目標は、次の方法で測定できます。 * 期間：サービスが違反なしで費やす時間。これが利用可能な唯一の値です。 * カウント：期間の数または特定のコンプライアンス期間中の発生回数。 {#sr-create-slo-sli-form__ul_pwc_d3c_mzb} |
[表 : 1. サービスレベル目標フォームのフィールド]

{#sr-create-slo-sli-form__id_sdb_v2n_y1c} {#sr-create-slo-sli-form__id_xhm_y2n_y1c__entry__2}

| フィールド | 説明 |
|-|-|
| 目標 (%) | 一定期間にわたってサービスに求める可用性 (アップタイム) のパーセンテージ。期間別に測定する場合、ファイブナイン (99.999%) の目標パーセンテージは、サービスが月に 26 秒、つまり年間約 5 分 35 秒利用できなかったことを意味します。これは、エラー予算の計算に使用されます。 |
| コンプライアンス期間 | メトリクスが計算される期間。使用可能なオプションは、次のとおりです。 * 月：期間は現在の月と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 1 月 1 日から 1 月 31 日までと見なされます。{#sr-create-slo-sli-form__slo_month} {#sr-create-slo-sli-form__slo_month} * 7 日間 (Rolling 7 days)：期間は現在の日付までの 7 日間と見なされます。{#sr-create-slo-sli-form__slo_rolling_7} {#sr-create-slo-sli-form__slo_rolling_7} * 30 日間 (Rolling 30 days)：期間は現在の日付までの 30 日間と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 12 月 25 日からと見なされます。{#sr-create-slo-sli-form__slo_rolling_30} {#sr-create-slo-sli-form__slo_rolling_30} * 90 日間 (Rolling 90 days)：期間は現在の日付までの 90 日間と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 10 月 25 日からと見なされます。{#sr-create-slo-sli-form__slo_rolling_90} {#sr-create-slo-sli-form__slo_rolling_90} {#sr-create-slo-sli-form__ul_nlx_4r1_s4b} |
| エラー予算 | 自動入力されます。 一定期間に許容されるエラー (ダウンタイム) の最大レベル。サービス可用性の合計に対する割合。目標 (%) を設定すると、エラー予算は「1 - (目標とする) 可用性」の計算式を使用して自動的に計算されます。 サービスのエラー予算は、1 年間で 99.99% (フォーナイン) という目標とする可用性について、日、時間、分、秒単位で次のように計算されます。 1. 1 年間の合計時間を秒単位で計算すると、31536000 秒になります。 2. エラー予算を「1 -- (目標とする) 可用性：1 - 0.9999 = 0.0001」と算出します。 3. エラー予算を時間単位に変換します。 {#sr-create-slo-sli-form__ol_uwd_qnm_kbc} たとえば、エラー予算が 0.0001 の場合： * エラー予算 (秒) = 0.0001 \* 31,536,000 秒 = 3,153.6 秒。 * エラー予算 (分) = 3,153.6 秒 / 60 = 52.56 分。 * エラー予算 (時間) = 52.56/60 = 0.875 時間。 * エラー予算 (日) = 52.56 分 / (24 \* 60) ≈ 0.0364 日。 {#sr-create-slo-sli-form__ul_iqm_wnm_kbc} 注: エラー予算は、期間で SLO を測定する場合にのみ、日、時間、分、秒の単位で表示されます。 |
[表 : 2. 期間別の測定]

{#sr-create-slo-sli-form__id_xhm_y2n_y1c} {#sr-create-slo-sli-form__id_hnl_w2n_y1c__entry__2}

| SLO タイプ | 期間別件数または発生別件数 |
|-|-|
| 発生件数の制限 (Limit occurrences) | 何回発生すると違反が発生するか。 発生件数の制限はエラー予算として機能します。 |
| コンプライアンス期間 | メトリクスが計算される期間。使用可能なオプションは、次のとおりです。 * 月：期間は現在の月と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 1 月 1 日から 1 月 31 日までと見なされます。 * 7 日間 (Rolling 7 days)：期間は現在の日付までの 7 日間と見なされます。 * 30 日間 (Rolling 30 days)：期間は現在の日付までの 30 日間と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 12 月 25 日からと見なされます。 * 90 日間 (Rolling 90 days)：期間は現在の日付までの 90 日間と見なされます。たとえば、現在の日付が 1 月 26 日である場合、期間は 10 月 25 日からと見なされます。 {#sr-create-slo-sli-form__ul_wlr_12n_y1c} |
[表 : 3. カウント別の測定]

{#sr-create-slo-sli-form__id_hnl_w2n_y1c}  
注:  
\[アサイン先グループ\] には値が自動的に挿入されます。