SLOとは？IT初心者向けに意味・SLA・SLIとの違いや設定例をわかりやすく解説
SLO（Service Level Objective：サービスレベル目標）とは、ITサービスで目指す品質や性能の目標値を定めたものです。
SLA（Service Level Agreement）のような契約ではなく、サービス提供者が安定した運用を実現するために設定する運用目標です。
クラウドサービスや社内システムの運用では、「稼働率99.95％を目標とする」「Webページの95％が2秒以内に表示される」といったSLOが設定されます。
SLOとは
SLOとは、サービス品質を維持・改善するために定める具体的な目標値です。
サービスの可用性や応答時間、エラー率などを数値で表し、システム運用の指標として利用します。
SLOを設定することで、サービスが目標どおりの品質を維持できているかを客観的に判断できます。
SLOが重要な理由
目標がないまま運用すると、「現在のサービス品質が良いのか悪いのか」を判断できません。
SLOを設定しておけば、運用チーム全員が同じ目標を共有でき、品質改善や障害予防に役立ちます。
また、目標と実績を比較することで、システム改善の優先順位も決めやすくなります。
SLO・SLA・SLIの違い
| 用語 | 意味 | 対象 |
|---|---|---|
| SLO | サービス品質の目標値 | 運用チーム |
| SLA | サービス品質を保証する契約 | 利用者と提供者 |
| SLI（Service Level Indicator） | 品質を測定する指標 | 測定データ |
それぞれの関係を簡単にまとめると、次のようになります。
- SLI：サービス品質を測定する
- SLO：測定結果の目標を決める
- SLA：利用者へ保証するサービス品質を契約する
SLOの具体例
| 項目 | SLOの例 |
|---|---|
| 稼働率 | 99.95％以上 |
| Web応答時間 | 95％のリクエストを2秒以内に処理 |
| API応答時間 | 500ミリ秒以内 |
| エラー率 | 0.1％未満 |
| 障害復旧時間 | 30分以内 |
SLOは「できるだけ良くする」という曖昧な目標ではなく、数値で定めることが重要です。
IT現場での利用例
- クラウドサービスの運用
- Webサービスの品質管理
- ECサイトの運用
- 社内システムの監視
- インフラ運用
- DevOps・SRE（Site Reliability Engineering）の運用
SLOに利用される主な指標
| 指標 | 内容 |
|---|---|
| 可用性 | サービスが利用できる割合 |
| 応答時間 | 処理が完了するまでの時間 |
| エラー率 | 失敗した処理の割合 |
| スループット | 一定時間に処理できる件数 |
| 復旧時間 | 障害から復旧するまでの時間 |
SLOを達成するための監視項目
- CPU使用率
- メモリ使用率
- ディスク容量
- Web応答時間
- API応答時間
- サービス状態
- イベントログ
- ネットワーク遅延
これらの監視項目を継続的に確認し、SLOを満たしているかを評価します。
障害発生時の確認する順番
- 監視ツールのアラートを確認する
- SLIの測定値を確認する
- SLOを下回っているか確認する
- 影響範囲を確認する
- 原因を切り分ける
- 必要に応じてエスカレーションする
原因の切り分け
| 確認内容 | 考えられる原因 |
|---|---|
| CPU高負荷 | 処理集中・異常プロセス |
| 応答時間が長い | ネットワーク・データベース・アプリケーション |
| エラー率増加 | アプリケーション障害 |
| 通信断 | ネットワーク障害 |
| サービス停止 | OS・アプリケーション障害 |
GUIで確認できる内容
- 監視ツールのダッシュボード
- サーバーマネージャー
- タスクマネージャー
- イベントビューアー
- クラウド管理画面
コマンドプロンプトで確認できる内容
- ping
- tracert
- netstat -ano
- ipconfig /all
ネットワークや接続状況を確認できます。
PowerShellで確認できる内容
- Get-Service
- Get-Process
- Get-Volume
- Test-NetConnection
サービス状態やサーバーリソースを確認できます。
イベントビューアーで確認する内容
- Windowsログを開く
- システムログを確認する
- アプリケーションログを確認する
- エラーや警告を調査する
障害発生時刻のログを確認すると、SLO未達の原因を特定しやすくなります。
初心者が混乱しやすいポイント
- SLOとSLAを同じ意味だと思ってしまう
- SLOは契約内容だと誤解する
- 目標値を高く設定すれば良いと考えてしまう
- SLIを設定せずにSLOだけ決めてしまう
SLOは実現可能で継続的に達成できる目標値を設定することが重要です。
現場でよくあるトラブル例
応答時間の悪化
CPU使用率は正常でも、データベースの処理遅延によってWebページの表示速度が遅くなり、SLOを満たせなくなることがあります。
目標値が高すぎる
実際のシステム性能に対して過度なSLOを設定すると、常に目標未達となり、運用品質の評価が難しくなることがあります。
筆者が経験した現場での事例
あるシステムでは「サーバーが停止していないから問題ない」と考えられていました。しかし利用者からは「画面表示が遅い」という問い合わせが続いていました。
そこで応答時間をSLOとして設定し、監視を始めたところ、毎日決まった時間帯だけ応答時間が悪化していることが判明しました。原因はバックアップ処理によるディスク負荷であり、実行時間を変更したことで利用者からの問い合わせが大幅に減少しました。
上司へ報告するポイント
- どのSLOが未達になったか
- 発生時刻
- 影響範囲
- SLIの測定値
- 考えられる原因
- 実施した対応
- 今後の改善案
エスカレーションするタイミング
- SLOを継続的に達成できない
- 利用者への影響が大きい
- 原因が特定できない
- システム構成の変更が必要
- ベンダー対応が必要
新人が覚えておくべきポイント
- SLOはサービス品質の目標値
- SLAは契約、SLIは測定指標
- 数値で設定することが重要
- 監視結果をもとに継続的に改善する
- 利用者目線の品質も意識する
関連するIT用語
- SLA（Service Level Agreement）
- SLI（Service Level Indicator）
- SRE（Site Reliability Engineering）
- 可用性
- 稼働率
- 監視項目
- 監視対象
- アラート
- KPI（Key Performance Indicator）
- インシデント管理
よくある質問（FAQ）
SLOとSLAは必ず同じ数値になりますか？
いいえ。一般的には、SLOはSLAより高い目標値に設定されます。例えば、SLAが「稼働率99.9％」の場合、SLOを「99.95％」に設定することで、契約上の保証値に余裕を持たせることがあります。
SLOは社内システムにも必要ですか？
はい。社内システムでも、応答時間や稼働率などの目標を設定することで、運用品質を客観的に評価しやすくなります。
SLOは一度決めたら変更できませんか？
変更できます。システムの利用状況や業務要件の変化に応じて、定期的に見直すことが推奨されます。
まとめ
SLO（Service Level Objective）は、ITサービスで目指す品質を数値で定めた運用目標です。SLIで測定したデータをもとに達成状況を確認し、SLAで利用者へ保証する品質を維持できるように運用を改善していきます。
IT運用では、「SLIで測定し、SLOを目標とし、その結果をもとにSLAを満たす」という関係を理解することが重要です。この考え方を身に付けることで、システム監視や品質改善の流れをより深く理解できるようになります。