システムにおこる不具合や障害の原因は、プログラムのバグ、ハードウェアの故障、設定ミス、機器配置のミスなど、ソフトウェア単体の場合と比べて幅が広い。特にちょっとした拡張やハードウェアの入れ替え等のあまり問題が起きないであろうと気楽に考えてしまいたくなるような場合でも、大きな障害につながる可能性がある。
最近ではシステムがスタンドアローンで構成されることはほとんどなく、ネットワークでつながった複数の計算機が互いにサブシステムとして成り立っていることが多く、その間のスイッチングハブ（LAN機器）が故障しただけでもシステムに障害を起こしてしまう場合がある。サービス拒否攻撃（DoS）等の故意のアタックが発生した場合、特定の送信元からのリクエストを遮断するような設定をしたネットワーク機器やプログラムの追加の際に、必ずしも意図通りの配置や設定ができるとは限らない。本来受け付けるべきリクエストを設定ミスやプログラムのバグにより、遮断してしまう可能性がある。比較的短時間で対処をしなければならない場合に特に起こりやすいと言えるだろう。
これらについて抜本的な対処方法は存在しないが、開発環境や準運用環境など、実運用環境の前に設定変更や機器交換を試せるような環境を作っておき、運用ルールとして、その環境で試験をした後に実環境に適用することを課すことは1つの解決策であろう。ただし、実環境とのずれにより思わぬミスを招く場合があるため、これらの環境を実環境と異なる部分がないように維持することは意外とコストがかかる。また、システムの一部が多数のバージョンを持つソフトウェアであったり、インターネット等の自由度の高い構成要素で成り立っている場合には、実環境の再現が困難になりがちである。
これらの設定不具合の計測は、基本的に運用上の障害として計測されることがほとんどであるが、機器設計の複雑さや設定の難しさについても、何らかの計測指標が必要だ。指標はたとえば、開発環境から実環境へのステージングする際の確認の有無や、保守の上で再設計を検討するかどうかを決める判断材料になるだろう。
Special
- PR -| バルバロッサ | 2007/07/10 15:04 |
|
>その環境で試験をした後に実環境に適用する | |
| 森崎 | 2007/07/10 20:37 |
|
たしかに、分野によっては初歩的と感じられる方もいらっしゃると思います。しかしながら、試験環境の維持や構築が可能な分野に限られる話だと思います。この一文はもう少し後ろにも読んでいただきたい部分があり、試験環境からのステージングが解決の１方法となり得ることを示すとともに、そのコストを考慮しなければならないことを示しているつもりです。 試験環境で試験せずに起こった障害が数えるほどしかない、というのは比較的限られたコンテキスト、プロファイルを持ったシステムなのではないでしょうか。たとえば、人命にかかわるようなシステム、通信、金融などではご指摘のとおり、試験環境での試験を省略することはほとんどないと思います。 分野によっては試験環境自体を持たない、もしくは、試験環境を維持するコストに見合わない分野が存在するのも事実で、試験環境の保守や再現性が十分でなく、試験環境では起こらなかった不具合が実稼働環境で起こることはそれほど稀ではないと思います。また、試験環境自体が存在しなかったり、試験環境での試験を省略する場合も少なからず存在します。読者の方々には、そのような内容をご理解いただき、ご自身のご経験と照らし合わせて、試験環境や試験の方法について再考するための一助となればと思って書いた文章のつもりでした。 | |
富士通元社長の山本卓眞氏が残した次代へのメッセージ
Facebook就活はもう古い？
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦