IT運用や監視サービスを比較するとき、「SLAに基づく対応」「迅速な障害対応」といった表現だけでは、実際のサービス水準を判断できません。
例えば「30分以内に対応」と書かれていても、それがアラートの受付、調査開始、担当者への連絡、暫定復旧、完全復旧のどれを指すかによって意味は大きく異なります。
SLAでは、測定対象、開始・終了条件、例外、報告方法まで具体化することが重要です。
「30分以内」という一行を、誰が同じ方法で測っても同じ結果になる約束に変えられるでしょうか。測定方法と未達時の行動まで合意して、初めて運用に使えるSLAになります。
SLAはサービス水準を測れる言葉に変える
SLAはService Level Agreementの略で、サービス提供者と利用者の間で合意するサービス水準です。契約または契約に付随する文書として、提供範囲、品質目標、測定方法、報告、未達時の扱いなどを定めます。
一方、SLOはService Level Objectiveの略で、可用性や応答時間など、達成を目指す個別の目標値を指します。組織によって用語の使い方が異なるため、名称よりも文書の内容を確認してください。
SLAで決めるべき10項目
1. 対象サービスと対象システム
クラウド基盤、OS、ミドルウェア、アプリケーション、ネットワークなど、どの範囲をサービス提供者が担当するかを明記します。開発会社やクラウド事業者との責任境界も整理します。
2. サービス提供時間
24時間365日という表現でも、監視、受付、一次対応、技術調査、顧客窓口のすべてが同じ時間帯とは限りません。業務ごとに提供時間を分けます。
3. 重大度の定義
重大度は技術的なエラーではなく、利用者と事業への影響で判断できるようにします。
| 重大度 | 判断条件の例 |
|---|---|
| Critical | 主要サービスが利用できず、代替手段がない |
| High | 重要機能に影響があるが、限定的な回避策がある |
| Medium | 一部利用者または非主要機能に影響がある |
| Low | 事業影響が小さく、計画対応が可能 |
実際の区分名と条件は、システムごとに合意します。
4. 応答時間
「応答」を、チケットの自動受付ではなく、担当者が内容を確認して対応を開始した時点とするかを決めます。測定開始は、監視ツールの検知時刻、顧客の連絡時刻、チケット作成時刻などから選びます。
5. 一次報告と更新頻度
初回報告に含める情報と、障害継続中の更新間隔を決めます。原因が未確定でも、現在の影響、実施中の対応、次回更新予定を伝えることで、関係者が判断しやすくなります。
6. 復旧に関する目標
サービス提供者がシステム全体を管理していない場合、復旧時間を保証できないことがあります。その場合は、一次切り分け、暫定復旧、担当チームへの引き継ぎなど、管理可能な活動に目標を設定します。
7. エスカレーション
一定時間内に解決しない場合や影響が拡大した場合、データ・セキュリティに影響する可能性がある場合など、エスカレーションの条件と連絡先を定めます。
8. 除外条件
計画メンテナンス、顧客側作業、第三者サービスの障害、不可抗力など、測定から除外する条件を明記します。除外が広すぎると実態を把握できないため、根拠と確認方法も必要です。
9. 測定と報告
データの取得元、集計期間、タイムゾーン、端数処理、レポート提出日を決めます。月次レポートでは、平均値だけでなく、重大な未達と改善アクションも確認します。
10. 未達時の対応
サービスクレジット、改善計画、レビュー会議など、未達時の扱いを合意します。返金条件だけでなく、原因と再発防止を誰がいつまでに整理するかも重要です。
SLAを作るときの注意点
数値を増やしすぎない
測定項目が多いほど管理が高度になるとは限りません。事業上重要で、正確に測定でき、改善行動につながる指標を優先します。
平均値だけで判断しない
平均応答時間が良好でも、重大障害への応答が一度大きく遅れていれば、事業リスクは残ります。重大度別の達成状況と個別事象を確認します。
測定元を曖昧にしない
監視ツール、チケット、電話受付など、どの時刻を正式な記録とするかが決まっていなければ、顧客と運用会社の測定結果が一致しません。タイムゾーン、データ欠損時の扱い、証跡の保管期間も含めて定義します。
ベンダーが制御できる範囲を区別する
監視ベンダーがアプリケーションの修正権限を持たない場合、完全復旧を単独では管理できません。検知、一次対応、報告、引き継ぎと、恒久修正を分けて設計します。
SLA確認用チェックリスト
- 対象と対象外がシステム単位で分かるか
- 各業務の提供時間が分かるか
- 重大度を事業影響で判断できるか
- 応答時間の開始・終了条件が明確か
- 初回報告と継続報告の内容が決まっているか
- 顧客、運用会社、開発会社の責任境界が明確か
- 除外条件と測定方法が確認できるか
- 未達時の改善プロセスがあるか
SLAを運用改善に生かす
SLAは、短い応答時間を掲げるための資料ではありません。運用会社と顧客が、何を、いつ、どの水準で行い、その結果をどう確認するかを共有するための仕組みです。
契約書に時間目標があっても、開始時点、終了時点、計測元、対象外、未達時の行動のいずれかが空欄なら、その数字は現場の判断基準になりません。契約更新や委託先の比較では、この五つを同じ表に並べて確認してください。AMELAのIT運用支援 24/7では、システムの重要度に合わせ、重大度、対応範囲、連絡フロー、レポート方法を設計します。