修正ウィンドウ

補正ウィンドウを使用することで、サービスレベル目標(SLO)のパフォーマンス評価に誤りを生じさせる可能性のある特定の期間を除外することができます。 これらの期間には以下が含まれる可能性があります:
  • 計画メンテナンス期間

  • 営業時間外(例:週末、祝日、夜間など)。

  • 通常の運転状態を反映しない、単発的な事象または事故。

これらの期間を除外することで、SLOのパフォーマンスをより正確に把握でき、情報に基づいた意思決定が可能になります。 これにより、サービスの全体的な信頼性について不正確な評価を下すことを防ぐことができます。

調整期間中は、指定された時間枠がSLOの算出対象から除外されます。
  • 時間ベースのSLOについては、修正時間枠はカウントされません。

  • イベントベースのSLOでは、修正ウィンドウ内の全ての良好なイベントと不良なイベントはカウントされません。

一時的な事象を除外することで、SLOの補正はサービスのパフォーマンスをより現実的かつ正確に反映し、サービスの信頼性に関するより的確な判断を下し、必要な調整を行うことを可能にします。

修正は、1回限りのものにも、定期的なスケジュールで繰り返されるものにもなります。
  • 単発の修正 :特定の開始時刻と継続時間を指定する必要があります。
  • 定期的な修正iCalendar の定期的なルールを使用してください。 以下の再帰規則パラメータがサポートされています:
    • FREQ修正が繰り返される頻度(例:毎日、毎週)
    • INTERVAL各再発間の間隔
    • COUNT: 出現総数
    • UNTIL: 再発が終了する時期を示す
    • BYMONTH特定の月(例:1月と3月)
    • BYDAY特定の曜日(例:月曜日と金曜日)
    • BYMONTHDAY月の特定の曜日(例:1日と15日)

SLOの修正期間の設定

SLOの修正期間を設定するには、次の手順を完了してください:

  1. Instana のUIナビゲーションメニューから、 「サービスレベル」 に移動します。

  2. 補正ウィンドウ 」タブを選択してください。

  3. 修正ウィンドウを作成をクリック +。

    注: あるいは、特定のSLOダッシュボードに移動することで、そのダッシュボードから直接修正ウィンドウを作成することもできます。
  4. 修正ウィンドウ設定モーダルが表示されます。

  5. (任意):この修正期間の対象となるSLOを選択して、適用範囲を定義します。 この手順は任意であり、後で実行することも可能です。

    • 選択するには、 「SLOを追加」 をクリックして、SLO選択モーダルを開いてください。
    • 「SLOの追加」 モーダルでは、異なるエンティティタイプにわたって1つまたは複数のSLOを選択できます。
    • 右側のサイドパネルには、各エンティティタイプ(アプリケーション、インフラストラクチャ、合成テスト、Webサイト)ごとにグループ化された選択項目と、各カテゴリの選択件数が表示されます。
    • 「追加」 をクリックして選択内容を確認してください。
    • 「SLOを追加 +」 をクリックするとSLOを追加でき、「 アクション 」列の削除アイコンをクリックすると既存のSLOを削除できます。
  6. 開始日を設定する。 過去または未来の日付を選択できます。

  7. 補正ウィンドウの開始時刻と継続時間を設定します:

    • 1日単位のスケジュール :指定した開始日の午前0時から24時間続く修正期間を設定します。 このトグルを有効にすると、「 開始時間 」と「 継続時間 」を設定する必要がなくなります。
    • 開始時刻 :補正ウィンドウが開始される時刻を決定します。
    • 期間 :補正ウィンドウが有効である期間を指定します(分、時間、または日単位)。
  8. 修正ウィンドウの繰り返しを選択してください。 1回限り、毎日、毎週、毎月、または毎年から選択できます。 定期的なオプションを選択すると、追加の入力欄が表示されます。

    • 1回限り :このオプションは再発しない修正ウィンドウを作成します。

    • 毎日 : このオプションは毎日繰り返される修正ウィンドウを作成します。 ウィンドウを繰り返し表示する日を指定してください。例:2日ごと。

    • 毎週 : このオプションは、毎週繰り返される修正ウィンドウを作成します。 指定された週単位の間隔において、修正ウィンドウが発生する曜日を定義できます。 特定の週における曜日と、発生頻度を示す週単位の間隔を指定してください。例:3週間ごとに金曜日と日曜日。

    • 月次 :このオプションは、毎月繰り返される修正ウィンドウを作成します。 指定された月次間隔(例:2か月ごと)において、補正ウィンドウが発生する日を以下の方法で定義できます:

      • 月日を指定してください。例えば、隔月の21日など。
      • 曜日を指定してください。例えば、隔月の第2火曜日など。
    • 年次 : このオプションは、毎年繰り返される修正期間を作成します。 指定された年次間隔において、補正ウィンドウが発生する日を以下の方法で定義できます:

      • 月と日を指定してください。例:毎年12月25日。
      • 特定の月の曜日を指定する。例えば、9月の最終月曜日など。
  9. 修正ウィンドウが繰り返し発生する場合は、 繰り返しオプションを設定します:

    • 終了日 :反復補正ウィンドウが終了する特定の日付。
    • 発生回数 : 補正ウィンドウが繰り返し発生する必要がある総回数。
    • 永遠に :修正の機会は決して終わらず、繰り返し訪れる。
  10. 補正ウィンドウの名前と説明を設定します。

補正ウィンドウ計算の例

補正ウィンドウがSLO計算に与える影響を理解することは、正確なパフォーマンス評価に不可欠である。 以下の例は、補正ウィンドウが時間ベースおよびイベントベースのSLOに与える影響を示しています。

例1:計画メンテナンスの一時的な修正期間

シナリオ :2025年3月15日、UTC 02:00~04:00の2時間における計画メンテナンス期間。

SLO設定 :

  • エンティティ: アプリケーション
  • 設計図:レイテンシー(時間ベース)
  • 目標:99%
  • 時間枠:ローリング7日間
  • ウィンドウ内の総分数: 10,080 分
  • 誤差許容値:10,080 × (1 - 0. 0.99 ) = 101分

修正ウィンドウなし :

  • メンテナンス中の不良時間:120分(2時間すべて)
  • その他の悪い時間:15分
  • 合計悪い時間:135分
  • SLOステータス: 100% × (10,080 - 135) / 10,080 = 98.66 %
  • 残りのエラー予算: 101 - 135 = -34 分 (枯渇)

修正ウィンドウを適用した場合

  • 調整済み時間枠:10,080 - 120 = 9,960 分
  • 調整済み誤差予算:9,960 × (1 - 0.99 ) = 100分
  • 不良分(メンテナンスを除く):15分
  • SLOステータス: 100% × (9,960 - 15) / 9,960 = 99.85 %
  • 残りのエラー予算: 100 - 15 = 85分

影響 :修正ウィンドウにより、計画メンテナンスがエラー予算を消費するのを防ぎ、通常稼働時のサービスパフォーマンスをより正確に把握できます。

例2:非営業時間における定期的な修正ウィンドウ

シナリオ :営業時間外(平日の午前10時~午前 PM-8 時および週末全体)をSLOの計算から除外する。

SLO設定 :
  • エンティティ: ウェブサイト
  • 設計図:可用性(イベントベース)
  • 目標:95%
  • 時間枠:ローリング7日間
  • タイムゾーン: America/New_York

補正ウィンドウ設定

2つの異なる定期的な調整局面:
  1. 夜間時間帯(平日)

    • 再発頻度:毎日(月曜日~金曜日)
    • 開始時間:22:00(午後10時)
    • 所要時間:10時間(翌朝8時まで)
    • 週当たりの除外時間:5日 × 10時間 × 60分 = 3,000分
  2. 週末

    • 再発頻度:毎週
    • 曜日:土曜日、日曜日
    • 期間:終日(24時間)
    • 除外時間(週あたり):2日 × 24時間 × 60分 = 2,880分

除外時間の合計 :3,000 + 2,880 = 週あたり5,880分

補正ウィンドウなし
  • 7日間の総イベント数:50,000ビーコン
  • 営業時間外イベント:30,000ビーコン(全体の60%)
  • 非業務上の不測の事態:1,800件のビーコン
  • 営業時間中の異常事象:400ビーコン
  • 総不良イベント数:2,200ビーコン
  • エラー予算: 50,000 × (1 - 0.95 ) = 2,500 ビコン
  • SLOステータス: 100% × (50,000 - 2,200) / 50,000 = 95.6 %
  • 残りのエラー予算: 2,500 - 2,200 = 300 ビコン
修正ウィンドウを適用した場合
  • 調整済み総イベント数:50,000 - 30,000 = 20,000 ビコン
  • 調整済みエラー予算:20,000 × (1 - 0.95 ) = 1,000 ビーコン
  • 悪い出来事(営業時間のみ):400ビーコン
  • SLOステータス: 100% × (20,000 - 400) / 20,000 = 98%
  • 残りのエラー予算: 1,000 - 400 = 600 ビコン

影響 :非業務時間を除外することで、SLOはサービス品質がユーザーにとって最も重要なピーク利用時間帯に焦点を当てます。

例3: 毎日繰り返されるメンテナンス時間枠

シナリオ :毎日01:00~02:00に定期メンテナンスを実施します。

SLO設定 :

  • エンティティ: インフラストラクチャ(ホスト)
  • ブループリント: サチュレーション (時間ベース、CPU)
  • ターゲット: 99.9 %
  • 時間枠:2025年4月15日から始まる固定7日間
  • タイムゾーン: UTC
  • 総分数:10,080分
  • 誤差許容値:10,080 × (1 - 0. 0.999 ) = 10分

補正ウィンドウ設定

  • 再発:毎日
  • 開始時刻: 01:00
  • 所要時間: 1 時間
  • 週あたりの総除外時間:7日×60分=420分

修正ウィンドウなし :

  • 日常メンテナンス中の不良時間:420分(全メンテナンス期間)
  • その他の悪い時間:5分
  • 総不良時間:425分
  • SLOステータス: 100% × (10,080 - 425) / 10,080 = 95.78 %
  • エラー予算:大幅に不足(-415分)

修正ウィンドウを適用した場合

  • 調整済み時間枠:10,080 - 420 = 9,660 分
  • 調整済み誤差予算:9,660 × (1 - 0.999 ) = 10分(四捨五入)
  • 不良分(メンテナンスを除く):5分
  • SLOステータス: 100% × (9,660 - 5) / 9,660 = 99.95 %
  • 残りのエラー予算: 10 - 5 = 5分

影響 : 定期的な修正ウィンドウは日次メンテナンスを除外するため、SLOに影響を与えるのは計画外の障害のみとなります。

例4: SLOタイムゾーンバインディング付き修正ウィンドウ

シナリオ :SLOをヨーロッパ/ベルリンのタイムゾーンに紐付け、営業時間内に補正を行う。

SLO設定 :

  • エンティティ: アプリケーション
  • 設計図:レイテンシー(時間ベース)
  • 目標:99%
  • 時間枠:ローリング7日間
  • タイムゾーン: Europe/Berlin (SLOはタイムゾーンに縛られています)

補正ウィンドウ設定

  • 再発頻度:毎日(月曜日~金曜日)
  • 開始時間:09:00
  • 所要時間:8時間
  • 週あたりの総除外時間:5日 × 8時間 × 60分 = 2,400分

重要 :修正ウィンドウはSLOのタイムゾーン(Europe/Berlin)を使用します。 SLOタイムゾーンがEurope/Berlinにバインドされている場合:

  • 修正ウィンドウの開始時刻(09:00)はベルリン時間09:00と解釈されます
  • 夏時間への移行期間中、修正ウィンドウはタイムゾーンに合わせて自動的に調整されます
  • 補正ウィンドウでは手動でのタイムゾーン変換は不要です

計算

  • 調整済み時間枠:10,080 - 2,400 = 7,680 分
  • 調整済み誤差予算:7,680 × (1 - 0.99 ) = 77分
  • このSLOは、サービスの利用パターンが異なる非営業時間に焦点を当てています
例5: 修正ウィンドウ付きイベントベースのSLO

シナリオ :2025年4月18日の10:00~14:00の4時間における負荷テスト期間を除外する。

SLO設定 :

  • エンティティ: アプリケーション
  • 設計図:可用性(イベントベース)
  • ターゲット: 99.5 %
  • 時間枠:ローリング7日間
  • タイムゾーン: UTC

補正ウィンドウ設定

  • タイプ: ワンタイム
  • 開始日: 2025年4月18日
  • 開始時間:10:00
  • 所要時間:4時間

修正ウィンドウなし :

  • 総イベント数: 100,000回の呼び出し
  • 負荷テストイベント:25,000回の呼び出し(テスト中の高負荷時)
  • 負荷テストの異常イベント:500件の呼び出し(テスト中のエラー率2%)
  • 通常の悪い事象:200件の通報
  • 総不良事象数:700件
  • エラー予算: 100,000 × (1 - 0.995 ) = 500回の呼び出し
  • SLOステータス: 100% × (100,000 - 700) / 100,000 = 99.3 %
  • エラー予算: 枯渇 (-200 コール)

修正ウィンドウを適用した場合

  • 調整済み総イベント数:100,000 - 25,000 = 75,000件の呼び出し
  • 調整済みエラー予算:75,000 × (1 - 0.995 ) = 375回
  • 不良イベント(負荷テストを除く):200件
  • SLOステータス: 100% × (75,000 - 200) / 75,000 = 99.73 %
  • 残りのエラー予算: 375 - 200 = 175 回

影響 :補正ウィンドウはテストから人工的な負荷を除外し、実際のユーザー体験をより正確に測定します。