1/21に経済産業省のWebサイトでSaaS(Software As A Service)向けのSLAのガイドラインが公開された。
ガイドラインなので、具体例はそれほど多くないが、巻末の表に掲載されており、「可用性」のカテゴリには「サービス時間」「計画停止予定通知」「サービス稼働率」等が、「信頼性」のカテゴリには「平均復旧時間」「障害通知プロセス」等があり、「性能」や「拡張性」のカテゴリもある。
詳細はPDFを読んでいただくとして、ガイドラインに記されている確認しておいたほうがよいSLA項目の中で私が参考になると思った項目は以下のとおり。
- 平均復旧時間
ハードウェア故障時の復旧などを含め、通常想定される復旧時間。ハードウェアのスタンバイ機の有無、ホットスタンバイ、コールドスタンバイ、データベース障害時のリストアやネットワーク機器まで含めた想定の上での平均時間であれば、どの程度業務に影響するかを把握する上で重要な指標となるだろう。 - サービスを変更する際のデータ移行方法
なんらかの理由で別のサービスに移行するときに今までのデータをどのようにして取り出せるかは、サービス導入時には現実よりも簡単に想定してしまいがちではないだろうか。たとえば、データベースの中身をセキュアなネットワークを通じて取り出せるのか、何らかのメディア(USBメモリ等)を利用できるのか等、これから稼動しようとしている段階で終了のことを考えるのはなかなかたいへんだが検討すべき項目は多いだろう。 - バックアップ手段
データのバックアップ手段もデータ移行と同様であり、ハードウェア故障等、何らかの理由でデータが消失した場合のリストアの方法をあらかじめ確認しておく必要があるだろう。
今後、SaaSが浸透していってカスタマイズしたものが当たり前になってきたときには以下あたりのSLA項目もほしくなるのではないだろうか。
- アップデート時の試験環境の有無
定型サービスや準パッケージサービスをカスタマイズして使っているときには、ミドルウェア、DB, OS等のアップデートを実施する前に、利用者が動作確認試験ができる環境があるかどうかは気になるところだろう。機能試験の環境有無、本番環境と同等の環境で性能試験ができるかどうか、本番環境で大規模なデータがある場合には試験環境にレプリケーションした上で実行できるかどうか等についても知りたいところだろう。 - 試験項目と試験実行
上の項目と関連するが、アップデート時やリリース前に実施する試験項目を定義し、アップデートのどのくらい前に確認のための試験を実行するか、サービス側で実行する部分や試験で不具合が発見されたときの連絡方法。自動実行用の単体試験プログラムに関する取り決め等も必要になるだろう。
コメント
コメントを投稿する
Twitter流行に異議アリ？
ソーシャルメディアマーケティングの具体的戦術
ワクワクさせてよ――目標設定の極意
ネットでリアルを楽しくしたい
やり直せる時代の新教育論（4）
