イントロダクション
前回はRFPで定義する非機能要件について、網羅すべき内容についてお話しました。
今回から数回に渡って個別の非機能要件について深堀りしていきたいと思います。
まず最初に取り上げるのは「可用性」の要件についてです。
可用性の要件となると、セットでついてくるのがSLA（ServiceLevelAgreement）です。
SLAはベンダーとユーザーの責任範囲を明確にするものです。
どちらかというと導入・開発についての契約ではなく保守での契約の話になりますが、開発と保守で契約は別だけど調達は一本ということもあります。
現行業務を確認するにあたっての観点として活用することで、RFI・RFPに活用するだけでなく、自社の業務を正確にに把握する指針にもなります。
可用性とSLAについて
「業務が止まってるんだ！すぐ復旧させろ！」
情シスをやっていると一度ならずこれを言われたことがあるのではないでしょうか。
SEをやっていても言われたことはあります。ただ頻度が違います。
何せ対象となる製品やサービスの種類や数が、情シスのほうが圧倒的に多いです。
そして問題が起こっている製品・サービスのスペシャリストなわけではないので、早期に解決できるかどうかもわかりません。
「障害」と一言で言っても、ハードに起因するもの、ネットワークに起因するもの、アプリケーションに起因するものと様々な原因があります。
障害を全く発生させないことは物理的に不可能です。
人間が作り出すものに100%間違いが無い物は存在しません。
それを許容した上で、障害が起こっても最低限は業務が継続できるようにしたり、発生した時に早急にリカバリが行えるようにすることで、障害の影響を最小限にすることは可能です。
「可用性」とは「システムの障害に対する強さ」と言い換えることができるかもしれません。
レベルの高い要件にはそれ相応に費用がかかる
可用性は製品そのものの要件と、製品外で提供されるサービスとで高めることができます。
製品そのものの要件でいくと、初歩的なところで仕様書の作成とメンテナンスがあります。
最新の仕様がドキュメントとして整備されていることで、「導入当時のメンバーが誰もいないから内容がわからない」という事態を防止することができます。
ハード関係でいえば障害時の縮退運転を可能にする冗長化構成があります。
復旧のスピードを向上するために最適なバックアップ範囲と頻度、世代管理の設計とそれを実現するハード／ソフトの選定も可用性に影響します。
製品外のサービスでは障害発生時の問い合わせについて24時間365日サポート受けることや、発生している現象がシステムに起因するものかの切り分けを含めた調査・対応までを求めることで、障害復旧の速度の向上に繋がります。
これらは不可能な要件ではありませんが、当然ですが求めるレベルが高くなればなるだけ規模は膨らみ費用は増大します。
現行業務の確認の中で、本当に稼働させなければいけない時間帯や時間数、業務への影響を考慮した復旧時間の要件を確認する必要があります。
現場の声を拾うだけなら、冒頭にあったように「すぐ直せ」とか「なるべく早く」という話になりがちですが、障害時の代替運用も含めてどこまでを要件とするかは情シスにてコントロールしなくてはいけません。
アプリのバグと可用性
一方で実現不可能な要件もあります。
例えば「アプリのバグは絶対起こすな。」というような要件を本気で要求したりすれば、どこのベンダーも手を挙げてくれないでしょう。
先ほども述べたように、障害＝バグの発生しない製品は絶対に存在しません。
どれだけ厳密な管理の下に作られた製品でも、ある程度の確率で不良品は発生します。
かといってどれだけバグが出てもOKという意味ではありません。
開発規模に対して許容されるバグ件数の指標というものがあります。
アプリのバグについては開発プロジェクトの品質管理の要件で、これも可用性に関する非機能要件です。
気を付けなければいけないのはパッケージシステム導入で、販社が他社のシステムを担ぐような場合、カスタマイズバグとパッケージバグの品質責任が分かれることがあります。
そもそもバグだらけのパッケージを担がれて、販社に「パッケージの品質までうちの責任で対応することはできない」とはしごを外されないように、パッケージそのものの品質管理も気に留めておきましょう。
双方で合意した稼働率に対しての取り決め＝SLA
システムが運用に入ってから、どれくらい正常に稼働しなければいけないかを図る基準として稼働率があります。この稼働率に対する要求をベンダーと合意するのが合意サービスレベル水準＝SLAです。
稼働率を図るには、まずは「稼働しなければいけない時間」を決めなくてはいけません。
・システム稼働時間は平日〇時～〇時、休日〇時～〇時
・バックアップ時間は平日〇時～〇時、休日〇時～〇時
・メンテナンスのための停止は第〇水曜日の〇時～〇時
・稼働していると判断する基準
稼働していると判断する基準は、原因と範囲の特定が必要です。
例えば表面的に発生した事象としてシステムにログインできなくなった、というだけで、稼働していないと判断はできません。
それがシステム外のネットワーク機器の問題であれば、ネットワーク障害によってログインできなくなっているけどシステムは正常に稼働していると言うことになります。
アプリケーション障害については、概ね「稼働していない」という判断に含まれません。
個別機能の特定の処理が行えなくなっているけど、システム全体として見たときに「稼働していない」とは言えないからです。
アプリケーション品質については稼働率とは別の観点で評価する必要があります。
稼働率の計算方法：MTBFとMTTR
このあたりから情処の試験勉強みたいになってきますが、稼働率の計算には以下のような式が用いられます。
・MTBF：平均故障間隔
・MTTR：平均修復時間
・稼働率＝MTBF ／ （MTBF + MTTR）
MTBFとは「SLAで定められた稼働時間の内、正常に稼働していた時間」です。
MTTRとは「SLAで定められた稼働時間の内、正常に稼働できていなかった時間」です。
稼働率とは「SLAで定められた稼働時間に対して、正常に稼働していた時間の割合」のことです。
例えば１日10時間稼働することがSLAで定められたシステムが、ハード障害等で１年間に20時間稼働しなかったとします。
SLAで定められた稼働時間は１年間で10時間×365日で3650時間です。
稼働していなかった20時間がMTTRになります。
ということは正常に稼働していた時間＝MTBFは3650-20=3620時間になります。
稼働率はMTBF3620時間÷SLAで定められた稼働時間3650時間なので、稼働率は99.2%ということになります。
稼働率99%以上というようなSLAが求められる場合もありますが、上記の例で考えると年間20時間も停止するシステムでも稼働率は99%を達成します。
稼働率を向上させるためには、稼働していない時間を発生させないか、可能な限り短くする必要があります。つまり障害発生時の復旧速度が稼働率を向上させます。
これでSLAが可用性の要件である障害時の復旧スピードと繋がるのがわかるかと思います。
中締め
可用性の話もまだ半分くらい
可用性の話もまだ半分くらいなのですが、文章が長くなりすぎるので今回は一旦ここまでにします。
次回は可用性要件の続きとしてバックアップ・リカバリと可用性を実現する機器・サービスについてお話したいと思います。
このペースでいけば非機能要件の話だけでも超長編のシリーズになりそうです。
記事のカテゴリを別で設けた方が良いかもしれないと思い始めました。
RFI・RFP／プロジェクト管理関連の記事を纏めています。
この記事が気に入ったら
いいね！をお願いします
