要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

IPAの非機能要求グレードの小項目を理解する(No11/119:データ)

[A.2.6]可用性>耐障害性>ネットワーク機器

今回は、耐障害性(データ)について紹介する。ここで決めるべきことは、①バックアップ方式、②データ復旧範囲、③データインテグリティである。

ざっくり言うと、

もしものときのために、どのようにデータを保管し、

いざ障害が起こったら、どこまで復旧し、

データの正しさの保証はどこまでしておくか

を決めておくこととなる。

 

①バックアップ方式

最初に検討すべきポイントは、そもそもデータをバックアップする必要があるのかないのかである。データの保管もタダではない。費用を負担してでもバックアップする必要があるのかを検討するようにしよう。

検討する際はランニングコストという点には注意したい。何もしなくてもデータは溜まっていく。データ量はどのくらいの速度で増えていき、それにともなって費用はどのように増えていくのか?月額でいくらぐらい必要なのか?を考慮しておくようにしよう。

費用を負担してでもバックアップすべきと判断した場合は、データをバックアップする仕組みをどのように実現するのかについての検討が必要となる。大きくは、システムを止めてバックアップする方法(オフラインバックアップ)と、システムを止めずにバックアップする方法(オンラインバックアップ)に分けられる。

システムを止めずにバックアップする方が、仕組みは複雑だ。システムが動いている間にも、データはたまっていく。そのような状況下でデータ間の整合性をとりつつデータを退避させることは難しい。できるならば、システムを止めてバックアップをするほうが望ましい。どうしてもシステムを止めることができない場合に限り、オンラインバックアップを採用するようにしよう。

 

②データ復旧範囲

ここでのポイントは、まずは、障害が発生したときに、復旧できるようにするのかしないのかだ。データが重要でないシステムにおいては、そもそもデータを復旧させる必要はない。データを復旧させる必要があるならば、どこまでのデータを復旧させられるようにするべきかを検討することとなる。事前に検討しておかねばならない点は2つある。

1点目:「いつ」のデータを復旧させねばならないか

2点目:「何」のデータを復旧できないといけないのか

1点目については、最低限、いつまでのデータがないとビジネス上致命的となるのかを考えるとよい。例えば、従業員の勤怠を管理するようなシステムであれば、前日までのデータは復旧できるようにしておく必要がある。これが、例えば、1か月前のデータしか復旧できないとなると、従業員の給与を正しく計算できなくなってしまう。

2点目についても、何のデータさえ残っていれば、ビジネスが継続できるのかを考えるとよい。再びの例えとなるが、従業員の勤怠を管理するようなシステムであれば、勤怠実績は必要だが、参考情報として蓄積している行動履歴ログのようなものは、仮にデータが消失したとしても、そこまで必要ないかもしれない。

 

③データインテグリティ

データインテグリティとは、情報処理などの分野で使われる用語で、データがすべて揃っていて、欠損や不整合がないことを保証することを意味している。

まずは、データの欠損や不整合を検出できるようにしたいかが、ポイントとなる。ライブカメラの映像データのようなものは、ストリーム再生でユーザーに情報を提供するもので、映像データが一部欠損していたとしても、システム上深刻な欠陥とはならない(ある意味許容されている)。

データの欠損が許容されない場合、エラーを検出できるようにするかどうかが次の検討ポイントとなる。また、エラーを検出できたならば、再試行して正しいエラーを保存できるようにするかどうかも検討ポイントとなる。ビットレベルでは、検出した誤りをそのまま訂正できる技術もあり、そのような技術を導入するかもポイントとなる。

まとめ

最後に、まとめを記載しておく。

[No11][A.2.6]データ

 

req-definer.com