クラウドサービス導入とSLAについて - 非機能要件との関係と内部SLA
クラウドサービスを利用して提供するサービスのSLA定義を行ったのですが、その中でクラウドサービス導入とSLAについて、2つの学びを得たのでシェアします。
導入時: クラウドサービス導入時のSLAと非機能要件について
クラウドサービス導入時には、SLAと非機能要件がこれまでのシステム開発とは違う関係になっています。
非機能要件とSLAの違い
まずは、非機能要件とSLAの違いについておさらいしておきます。
非機能要求は、サービスやシステムを開発（外部に委託する場合は委託）する際に、そのサービスやシステムに対して求める、可用性やセキュリティなどの機能面以外の要件です。
SLAは、サービスやシステムの提供者が、そのサービスやシステムの利用者に対し、どの程度のサービス品質を保証するかを約束したものです。SLAにおけるサービス品質は、一般的に非機能面について定義されます。
スクラッチ開発における非機能要件とSLA
Java等によるスクラッチ開発では、サービスやシステムを提供する側が、自分たちのサービスに関して非機能要件を定義し、それに基づいて設計、開発を行います。そして、出来上がったサービスやシステムを利用者に提供する際に、どの程度のサービス品質を保証するかをSLAとして約束します。
クラウド事業者の目線では、これは今でも変わりません。しかし、クラウドサービスを導入する側の目線では、非機能要求とSLAが裏返しの関係になります。
クラウドサービス導入時は非機能要件とクラウドサービスのSLAを比較して選ぶ
クラウドサービスの利用者は非機能要件を定義することができますが、クラウドサービスはクラウド事業者によって既に完成しているため、例えば可用性をもっと高めたい、DRサイトを作りたいと言っても、クラウド事業者側が提供していなければ、それは叶いません。
そのため、クラウドサービス導入時は、非機能要件を定義し、それに合うようなサービスやシステムを作るのではなく、非機能要件を満たすようなクラウドサービスを選ぶことになります。その際に、クラウドサービスのSLAを確認することで、自社の求める非機能要求を満たすかどうかがわかります。
なお。SLAはService Level Agreementなので、交渉可能であるようなイメージがあるかもしれませんが、特に海外のクラウド事業者はユーザごとにサービスレベルを合意するのではなく、予め提供できるサービスレベルを提示しておき「納得できるなら使えばいい」というスタンスが基本です。
この関係については下記の記事で深堀りされていました。
クラウドサービス導入の際の非機能要求項目
クラウドサービス導入時の非機能要件を定義において、どのような項目を定義すべきでしょうか。調べたところ、経産省のSaaS向けSLAガイドライン（こちらはSaaS事業者が提示するSLAに関するガイドラインですが、上述の通り非機能要件はその裏返しなので項目を流用できるはずです）をベースに、IPAの非機能要求グレードから追加したい項目があれば追加する、というのがよさそうです。
導入後: クラウドサービス導入後にユーザ企業側が定義すべきSLA
クラウドサービスの導入後は、それを使って社内のユーザや、顧客に対してサービスを提供するはずです。その場合、クラウドサービスを導入した主体が、今度は自らのサービスの提供者となるため、場合によってはそのサービスのSLAを定義する必要があるでしょう。
例: クラウド導入部門が社内の利用部門対して約束するSLA
例として、SaaSの人事ソリューションを社内で導入することを考えてみます。この場合、人事部が直接導入することもありますが、多くの場合IT部門が導入や、導入後の運用保守を行っているはずです。この時、IT部門はクラウド事業者のサービス・システムの利用者であると同時に、利用部門である人事部に対しては、サービス・システムの提供者になっています。
クラウド事業者のSLAを考慮して独自サービスのSLAを考える
このような場合、例えば障害が発生したときはどのくらいの時間で対応するか、といったSLAをIT部門が独自に定義する必要があるかもしれません。（会社によって厳密さが異なるため、SLAのようなものを定めない場合もあるでしょう）
このような場合は、IT部門のSLAはクラウド事業者のSLAを前提として定義していく必要があります。
可用性やDRといったインフラ領域の項目など、多くの項目については、クラウド事業者のSLAに準拠することになるでしょう。
一方で、クラウド事業者では約束されていない領域についてサービスレベルを上げたり、クラウド事業者では約束されていない項目を追加する必要もあります。例えば、AWS上に構築したアプリのアプリレベルの監視や障害対応などは、AWS側では行ってもらえないので、運用保守部門のSLAとして定義すべき内容です。
さらに、場合によってはクラウド事業者で約束しているSLAよりもサービスレベルを下げることもあるでしょう。例えば、仮にクラウド事業者側が問合せを24時間365日受け付けていても、利用部門からの問い合わせの一時窓口をIT部門にする場合、クラウド事業者のSLAに準拠しようとすると24時間人を張らなくてはならなくなってしまうので、業務時間のみの受付とすることがあります。
以上です。
この記事が気に入ったらサポートをしてみませんか？