［運用管理編］SLAを後回しにしてはいけない

　「SLA（Service Level Agreement）」とは，ITサービスを提供する組織が，自身の提供するサービスの内容や品質レベルについての数値目標を定義し，その値について顧客と合意を図ることである。SLAは，顧客とサービス提供者が相互理解を図るための有効なツールとして，広くユーザー企業にも知られてきている。しかしながら，いざSLAの導入となると，その検討が後回しにされてしまうことは少なくない。実際には，有効なSLAを定義できなかったり，そもそもSLAがない状況でサービスが開始されてしまったりするのである。

　SLAとひと言でいっても，その内容は，システムの機能や非機能要件に関連する項目，日常の保守運用に関連する項目，サポート窓口や障害対応などに関する項目などさまざまである。本来はこれらのSLA項目を遵守するために，要件定義段階から十分な検討を行なう必要がある。検討が遅れると，開発フェーズでの設計に盛り込むべき項目がもれてしまい，結果的に対応可能なSLA項目が少なくなったり，要求されたSLAの数値を保障できなくなってしまうこともある。

　例えば，サービスの稼働率に関するSLAを定義する場合は，設計段階から2重化やクラスタリングなどの高可用性を考慮した設計を行なう必要がある。また，リカバリ・ポイントやリストア時間に関するSLAを定義する場合も同様に，バックアップ設計の段階から十分な検討が必要である。

　これらの項目がシステム開発の初期段階で十分検討されていないシステムでは，サービス提供直前になって，高い稼働率のSLAを要求されたり，短時間でのリストアを要求されたとしても，それらに対応するのは難しい。場合によっては，設計フェーズに戻って実装をやり直すことにもなりかねない。

「システム関連SLA」に対応できなくなる

　図1に，開発の初期段階からSLAの検討を始めたパターンと，そうでないパターンを示す。ここでは，稼働率やレスポンス・タイムといった，システムの機能/非機能要件に関するSLAを「システム関連SLA」，サポートデスクの一次回答時間や障害通知時間といった保守サポートに関連するSLAを「保守サービス関連SLA」と大きく二つに分けることとする。

図1●上流工程から検討されたSLAと，検討を後回しにされたSLA

[画像のクリックで拡大表示]

　このうち，ユーザーとサービス提供者の間でより早くSLAの検討を始めなければならないのは，システム関連SLAだ。SLAを検討するのがサービス開始直前になってしまうと，システム関連SLAの議論は難しく，検討できる対象は，保守サービス関連SLAのみとなってしまう。システム関連SLAを定義する場合は，開発フェーズからの十分な検討と設計，および，開発部門と運用部門の強固な連携が不可欠だからだ。

　一般的に，稼働率やレスポンス・タイムといった項目は，要件定義の非機能要件として，開発担当者によって設計に盛り込まれる。だが，「サービス提供フェーズで継続して保証していく数値」であるSLAとしてこれらの項目を見た場合はそれだけでは不十分だ。その測定方法や保守運用でのメンテナンス内容，継続保障の条件などを，事前に開発部門と運用部門で十分に検討しておかなければならないのである。

　例えば，SLAの対象となる稼働率の測定方法についてみても，システム・メンテナンス時間を含めるのかどうかや，一部のユーザーへのサービス停止の扱いをどうするか，また，障害復旧時間の開始と終了の定義はどうするかなど，事前にユーザーを交えて十分に合意しておく必要がある。そうしないと，サービス開始後にSLAの数値についてもめる原因になるし，そもそも運用部門でSLAを保障することもできない。

　このような状況を避けるためにも，SLAの検討を後回しにしてはいけないのである。