SLA<法規・基準<Web教材<木暮仁

Web教材一覧法規・基準

SLA(Service Level Agreement)

学習のポイント

情報システムの運用では多くの障害が発生します。その障害の発生頻度や対策について、発注者と受注者が共通した認識を持ち、合意することをSLAといいます。そして、SLAを円滑に運営し改善する管理をSLMといいます。
 ここでは、SLA/SLMの必要性、その導入や改善における留意事項などについて説明します。

キーワード

SLA、SLM、ITサービス


SLAとは

SLA(Service Level Agreement)とは、ITILでのサービスレベル管理を詳細化・具体化したものです。情報システムの運用にさいして、発注者(利用者)と受注者(提供者)の間で、提供するITサービスの内容と範囲、品質に対する要求(達成)水準を明確にして、それが達成できなかった場合のルールを含めて、あらかじめ合意しておくこと、あるいは、合意内容を文書化した契約書(サービスレベル合意書)のことです。
 例えば、次のような合意内容があります。
  ・システムの稼働率を99%以上にする。
  ・システムが故障したときは、最大5時間以内で復旧する。
  ・注文データは入力してから結果が得られるまでの時間を5秒以内とする。
  ・ヘルプデスクでは、質問に1回の電話で答える割合を80%以上とする。

SLAを行う時期

情報システム開発の受注者が、納品した情報システムの機能や性能について保証する場合と、納入後の運用を新たに契約する場合があります。そのため、受注者ごとにSLAを行うこともあります。

SLAは、運用段階に入る時点で行うのが適切です。企画段階や設計・開発段階の業務は、繰り返して行われないので、サービスの品質を継続的に測定することができないからです。しかし、情報システムのエラー発見率や応答時間などに関しては、情報システムの設計に大きく関係しますので、RFPに示したり、開発契約に明記することが必要な項目もあります。

(注)ソフトウェアの検収にあたり,一定期間内に発見された欠陥に対して,開発側が無償で修正を行ったり損害賠償責任を負ったりすることを瑕疵担保責といいますが、SLAは瑕疵担保責任とは異なります。
 SLAは瑕疵担保責任の対象よりも広い範囲、複数のシステム全体を対象にすることもあります。また、契約先も該当システム提供者に限定せず、第三者のITサービス業者と契約することもあります。

SLAの必要性と効果

物事には完全を期待できません。十分にテストしたつもりでも、発見できない誤りがあります。ネットワークは、多様な原因により障害が発生します。これらの発生確率を低く抑えたいのは当然ですが、確率を下げる、すなわち、サービスレベルを上げるには、大きな費用がかかります(参照:「システム障害の日米比較」)。

どの程度のサービスレベルが適当かについて、発注者と受注者の間の合意がないと、トラブルの原因になります。そこで、委託者と提供者の間で誤解や不満が起こる原因であった曖昧さの排除を目的として、契約時に、双方の間でサービスの対象と品質水準を明確にして共通認識をもつことが必要なのです。
 SLAを行うことにより、
  ・発注者は、期待通りのサービスが保証され、権利が確保される。
  ・受注者は、提供責任を明確にし、これを全うしたことを証明できる。
  ・双方にとって、責任のなすりあいのようなトラブルになるのを回避できる。
などのメリットがあります。

SLA対象項目とレベルの選定

SLAの目的は、(広義の)可用性を大きくすることであり、可用性管理といいます。可用性管理は次の4つで構成されます。

このうち対障害弾力性は多分に利用者側の決定事項ですので、SLAとしては他の3つに着目して対象項目やサービスレベルを設定するのが適切です。

SLAの対象項目は、次の基準で選ぶのが必要です。

サービスレベルの設定には、次の2つがあります。
  ・目標保証型:受注者が責任を負うレベル
  ・努力目標型:努力はするが、責任までは問われない
 また、目的保証型で達成できないときはペナルティを課し、努力目標型で達成したときにはインセンティブを与えるといった契約にすることもあります。
 努力目標型では強制力がないのが欠点ですが、それでも双方でサービスレベルが明確になりますし、合意を得るのが容易です。

SLAの対象項目やサービスレベルへの要求は、運用経過とともに変化します。当初は大きな問題だったのに対策を講じて安定して満足する状態になったときには、もはや対象にする必要がないでしょう。逆に、当初予測した以上にシステムの利用度が高まったときには、応答時間の遅れが深刻な問題になるなど、新しい項目やサービスレベルの見直しが必要になります。
 また、当初は予見が不十分だったために、「とりあえず」の設定をしたので、現実には到底実現できない/あまりにも緩やかで利用者の満足が得られないという状況が発生することがよくあります。
 そのため、SLAは逐次改訂する必要があります。それをマネジメントとして行うのがSLMです。

SLM

SLAを作成しただけでは効果がありません。
 ・サービスレベルが定期的にモニタリングされ、
 ・サービスレベルの状況と異常時対応などが定期的に報告され
 ・発注者と受注者がサービス改善に建設的な検討を行ない
 ・継続的に改善が行われる
ようにマネジメントすることが大切です。
 このように、ITサービスの品質を維持し,向上させるためのマネジメント活動をSLM(Service Level Management)といいます。

SLAの標準

SLAの対象項目やレベルは、対象情報システムにより、発注契約対象により大きく異なりますが、参考になる標準やガイドラインがあります。
経済産業省『情報システムに係る政府調達へのSLA導入ガイドライン』2004年
JEITA(電子情報技術産業協会)『民間向けITシステムのSLAガイドライン(第3版)』2006年
ITコーディネータ協会『RFP・SLA見本』
SaaS環境に特化したもの
経済産業省『SaaS向けSLAガイドライン』2008年
JEITA(電子情報技術産業協会)『民間向けITシステムのSLAガイドライン-追補版:SaaS対応編』2008年


過去問題