SLA運用設計書

この記事は、PDI（Zurich、2026-07-08 確認）の OOTB（初期設定）構成をもとに、SLA運用の設計判断を「なぜそう決めるか」まで整理した運用設計書です。目標時間・警告閾値・宛先などの具体値は一例で、自社導入時のたたき台に使うことを想定しています。

1. 運用設計の目的と範囲

障害対応の速さを組織の約束として定義し、その約束が守られているかを数字で追えるようにすることを目的として、本設計書ではServiceNowのSLA運用の設計判断を一つずつ決める。どの優先度に何分の初動を約束するか、計測をどの状態で止めるか、違反の前に誰へ知らせるか。あとから運用を変えるときに判断の背景までさかのぼれるよう、決定とその理由をあわせて記録する。

SLA定義（SLA Definitions）の一般的な位置づけは、タスクへの対応時間の目標を定義し、実績を自動で計測する仕組みです。ServiceNowでは contract_sla というテーブルに定義を置き、条件を満たしたインシデントに task_sla（計測レコード）が自動で付く。利用者から見たSLAは「いつまでに反応・解決してもらえるか」の約束であり、本設計書はこの約束を運用として成立させる設計に重心を置く。

SLA運用の設計が達成すべきことを、次のように置く。

• 影響の大きい障害ほど速く動く体制を約束することを目的として、優先度別の目標時間を設計する。

• 利用者への約束と内部の分担を混同しないことを目的として、SLA・OLA・Underpinning contract の3つの型を使い分ける。

• 対応の実態と計測を一致させることを目的として、開始・停止・一時停止の条件を業務に合わせて設計する。

• 違反してから知るのではなく違反の前に動けることを目的として、段階的な警告とエスカレーションを設計する。

• 約束の妥当性そのものを見直し続けることを目的として、達成率のレビューと目標時間の改定サイクルを設計する。

操作の「やり方」は、対になる運用手順書「ServiceNowのPDIをもとにしたOOTB SLA運用手順書」で、インシデント1件にSLAが付いてから停止するまでを実機で回して扱っています。手順書が「どの画面で何が起き、どの値がどう変わるか」を順番に見せるのに対し、本設計書は「なぜその条件・その閾値にするか」を決める。やり方を先に知りたい人は手順書が入口です。

対象範囲は、contract_sla（SLA定義）と task_sla（計測レコード）を中心とした、インシデント向けのSLA運用とする。設計の対象は次までとする。

• 定義の型と目標時間

• 開始・停止・一時停止の条件

• スケジュール（計測時間帯）

• 通知・エスカレーション

• KPIとレポート

• 役割分担

フロー内部が発行するイベント名や宛先の解決ロジック、警告・違反メールの実際の発火、スケジュールのタイムゾーン解決順序は、今回の実機検証範囲外として末尾に明記する。

設計の起点はOOTBとする。ServiceNowのSLAは、何も作らない初期状態でも次が最初から組まれている。

• 優先度別の定義14件

• 営業時間スケジュール

• 警告から違反までを段階処理するFlow Designerのフロー

• 通知定義

OOTBの構成のうち、どこをそのまま使い、どこを自社の値へ置き換えるかを決めることを本設計書の方針とする。 想定読者は、SLM（サービスレベル管理）の導入・改善を任された運用設計者、達成率に責任を持つサービスレベル管理者、SLAの数字を現場で受け止めるインシデント管理者です。

設計領域の全体像

SLA運用設計で決めることを5つの領域に分け、この順で設計を進める。

• 定義設計（3章）… 何を・どの速さで約束するか。型・優先度マトリクス・目標時間。

• 条件設計（4章）… いつ計測を始め、止め、保留するか。start / stop / pause / reset。

• スケジュール設計（3章・7章）… どの時間帯で数えるか。実時間か営業時間か、祝日の扱い。

• 通知・エスカレーション設計（5章）… 誰に・どの閾値で・何を届けるか。

• 計測・KPI設計（6章）… 達成をどう評価し、目標時間の見直しへどう戻すか。

矢印の終点をKPIから定義へ戻しているのは、達成率のレビューを目標時間の改定につなげるためで、5つの領域が一巡して閉じる構造を設計の枠組みとする。

2. 現状把握（OOTBのSLA構成）

設計の土台を確かめることを目的として、OOTBのSLA構成をここで整理する。今回確認したPDIでは、SLA定義（contract_sla）は14件で、すべて有効・すべてインシデント対象でした。

2-1. 定義14件の分布

内訳は次のとおりです。

• P1〜P5のResponse（初動）：5件

• P1〜P4のResolution（解決）：4件

• OLA：2件

• Underpinning contract：1件

• テスト自動化（ATF）用：2件

優先度と目標時間の対応を表にする。

分布には読みどころが2つある。P5にはResolution定義がなく、初動（40時間）だけを約束する構成になっている。そしてP1だけスケジュールが未設定で、24時間365日の実時間で計測される。P2以下は営業時間ベースで数えるため、同じ「8時間」でも実時間の8時間と営業時間の8時間（約1営業日）では意味が違う。この2点はどちらも、有料部の定義設計で「自社ではどうするか」を決める論点になる。

定義フォームには、型（Type）・対象（Target）・目標時間（Duration）・スケジュールとあわせて、開始・一時停止・停止・リセットの条件タブが並ぶ。

2-2. スケジュール（計測時間帯）

SLA定義から参照されているスケジュールは「8-5 weekdays」の1種類のみでした（7定義が参照）。OOTBには祝日カレンダーも用意されている。「8-5 weekdays excluding holidays」（祝日除外版）や「U.S. Holidays」、「24 x 7」があるが、SLA定義からは参照されていない。祝日除外への切り替えは、OOTBが残している拡張ポイントとして有料部で扱う。

2-3. 自動処理の実装（Flow Designerの2フロー）

SLAの警告・エスカレーションの自動処理は、Flow Designerの2つのフローが受け持つ。Response系5件とATF2件は「Default SLA flow」を参照していた。Resolution系4件・OLA2件・Underpinning contract1件は「SLA notification and escalation flow」を参照していた。レガシーWorkflowでのSLA実装は0件で、フローへの移行が完了した状態です。

どちらのフローも、経過率が指定値に達するまで待機するアクション（SLA Percentage Timer）と通知イベントの作成を段階的に繰り返す構造だ。エスカレーション側のフローには判断と処理の段階が追加されている。この段階構造が、有料部の通知・エスカレーション設計の土台になる。

2-4. 通知定義と計測レコードの分布

task_sla（計測レコード）を対象にしたメール通知はOOTBで4定義あり、警告用と違反用が2系統ずつ用意されている。宛先の欄はいずれも空で、イベントのパラメータで宛先を受け渡す方式でした。

計測レコードの全体像は、stage（段階）でグループ化すると見える。今回の環境では、実際にインシデントを1件回した分を含めて計20件が、達成・違反・キャンセル・完了・進行中・一時停止の6区分に分かれていた。

この構成を土台に、ここから先は定義・条件・通知・KPIの各設計を、自社で決めるパラメータ一覧・RACI・代替案の採否まで含めて一つずつ確定していく。