1.SLOの前にSLAを理解しよう

---

この章ではまず、SLOを理解するための前提知識としてSLAについてお伝えします。

 

SLAとは

SLAは「Service Level Agreement」の略であり、日本語では「サービスレベル合意」などと訳されます。

サービス提供側と利用側の、当該サービスが満たすべき品質基準に関する同意・契約のことであり、サービスレベルの管理において非常に重要な役割を果たします。

 

サービスの利用側と提供側はプロバイダーと顧客のケースだけでなく、社内のIT部門と業務部門のケースもあります。

SLAにはサービス提供側が利用側に提供するサービスの内容や範囲、水準などが記載されています。

 

具体的には、以下のような項目を定義します。

 

 

上記の前提条件は「サービスの定義」とも言われ、どのようなサービスを提供するのかを意味します。

サービス提供者と利用者の間で前提条件が異なっていると意疎通が図れず、契約自体が成立しません。

 

SLAの設定対象はセキュリティやネットワーク、ホスティングなど多岐に渡りますが、全てに対して設定をしてしまうのはおすすめできません。

そのサービスが自社にとって重要か、内容を明文化・測定できるか、SLAの内容を達成できる状況にあるのかを整理して、設定対象を見極めることが大切です。

 

SLAを設定することで提供されるサービスレベルを確保し、サービス全体の水準を統一することが期待できます。

また、SLAは一度締結したら終わりという訳ではなく、サービスレベルの見直しを不断に行っていくことが重要です。

 

SLA導入の際にはサービス基準のPDCAサイクルを継続的に回し続け、適切なサービスレベルを確立していくことが求められるでしょう。

 

可用性で示されることが多い

SLAで約束するサービスレベルは、「可用性」で示されることが多くあります。

可用性とは、サービスが利用できる時間の割合である稼働率を示す言葉です。

 

例えば、月間の可用性が99％で合意した場合は、1月の間に1％のサービス停止までを利用者側が許容することになります。

そのため、1か月30日の場合簡単に計算すると「24時間×30日×1％」で7.2時間までのサービス停止が許容されます。

 

つまり、可用性が高いほどシステムの安全性は高く不具合が起きにくいと考えられていると言えます。

可用性は、「SLA99.95％」「SLA99.999％」などといった形で表示されます。

 

 

SLAを満たせなかった場合は罰則を規約に盛り込むことが可能

SLAで合意したサービス基準を満たせなかった場合に備え、罰則を規約に盛り込むことが可能です。

サービス基準を達成できなかった場合の罰則を盛り込むことで、SLAが損失補填や万が一の場合の保険として機能します。

 

ただし、不可抗力等が原因のケースは例外事由としてサービス基準未達時のペナルティ対象外とすることで、公平感を担保することも仕組みとしては重要です。

 

 

 

2.SLOとは

---

 

この章では、ここまで説明してきたSLAの概要を踏まえ、SLOとは何かについてお伝えします。

 

SLOの意味

SLOは「Service Level Objective」の略であり、日本語では「サービスレベル目標」を指します。

SLOはサービス提供側が設定する目標のことであり、SLAよりも高い目標設定にすることが通常です。

 

例えば、SLAで月間稼働率99.9％で合意した場合、SLOではそれよりも高い月間稼働率99.95％などに設定します。

つまり、SLOを目指すことで、必然的にSLAの基準を達成できるような目標値にするということです。

 

SLOは計測可能な値で表現されることが多く、目標達成したか否かが検証できるようにするのが通常です。

ただし、システムの不具合が起こらない可能性を0にすることは現実的にできないため、SLOにおける稼働率を100％に設定することはできません。

 

SLOでは、以下のような項目を設定します。

 

 

可用性はSLAと同様に、月間でどの程度の稼働が維持できるのかを示します。

具体的には、システムが停止する頻度やその告知方法などを記載します。

セキュリティは、システムのセキュリティ体制が準拠する基準や体制の維持方法を記します。

作業手順ではサービス利用者が利用する手順を示し、サポート体制ではトラブルや質問の際のサポート方法・時間などを記します。

 

また、SLOは単純にサービスレベルに関する水準を定めるだけでなく、サービス提供を実際に行う際の計測方法や報告方法も定めます。

 

 

SLOは合意が必要なく利用者側に開示されないことが多い

SLOはSLAとは異なり合意の必要がなく、利用者側に開示されないことも多くあります。

SLOはあくまでもサービス提供側の「目標」を記す物であり、利用者側などとの契約ではないためです。

 

SLOはあくまでもサービス提供側の内部目標であり、公開責任はないと理解しておくと良いでしょう。

ただし、提供者側からすると公開することで利用者と数値目標を共有でき、業務の優先順位を決めやすくなるなどのメリットはあります。

 

また、公開することで利害関係者から達成できないような高いサービス品質を求められることも防げるでしょう。

利用者側の目線になっても、SLAを達成するための提供者側の目標が具体的に確認できれば期待できるサービスのレベルを確認できるようになります。

 

つまり、SLOの公開をすることによるメリットもあるということです。

SLOの有効性を高めるためには利用者にとって重要ではない部分に高い基準を設定せず、優先性の高い課題を数値目標にすることが大切でしょう。

 

 

SLOに罰則はない

SLOは第三者への公開責任がないだけでなく、万が一達成できなかったとしても罰則が科せられる訳ではありません。

そもそも公開されないことも多いため、罰則を設定したところであまり意味がないとも言えるでしょう。

 

 

 

3.まとめ

---

SLAは「サービスレベル合意」などと訳され、サービス提供側と利用側の、当該サービスが満たすべき品質基準に関する同意・契約のことを意味します。

SLAは可用性であらわされることも多く、サービス内容を達成できなかった際の罰則も盛り込むことが可能です。

 

一方のSLOとは、サービス提供側が設定する目標のことです。

SLOはあくまでもサービス提供側の目標であるため公開されないことも多く、未達時にも罰則は設定されない点は押さえておきましょう。

 

フリーランスエンジニア専門の求人・案件一括検索サイト「フリーランススタート」に少しでも興味がある方は是非ご登録ください。

 

なお、フリーランススタートはiOSアプリ版やAndroid版をリリースしています。

通勤しているエンジニア・デザイナーでちょっとしたスキマ時間で手軽にフリーランス求人・案件を検索したい、開発言語の単価が知りたい、フリーランスを将来的に検討している方などは是非インストールしてみてください。

 

フリーランススタートのアプリを有効活用して、フリーランスとして第一線で活躍しましょう！

 

フリーランススタート iOSアプリのインストールはこちらから→

 

フリーランススタート Androidアプリのインストールはこちらから→

 

本記事が皆様にとって少しでもお役に立てますと幸いです。