«

»

1月 04

024情報システムの保守マネジメントで大切な3原則とは

マネジメントレベルが低い場合、システム障害の多くはシステムのハードウェアやソフトウェアを変更する保守作業に起因する。保守に関する基本を整理し、信頼性を高めるために重要な3つの原則を紹介する。

□ 保守作業は障害の原因となることが多い
殺人事件が発生したとき、先ず疑うのは「動機がある人物は誰か?」である。
同様に、情報システムの障害が発生したときに先ず確認するのは、「直前に何か作業をしていないか?」である。実際に、システム障害の多くはハードウェア環境、ソフトウェア環境の変更作業後に発生することが多いが、これは、新規に入れたソフトウェアの不具合も当然あるが、保守作業のミスや考慮漏れによるものも多い。作業対象のサーバーとは別の本番稼働中のサーバーの電源を引き抜いてしまうようなことは論外としても(驚くべきことに、現実、これも結構あるのだが・・・)、システムは目に見えないさまざまなつながりをもっているので、本番稼働中のシステム環境に対する作業は慎重の上にも慎重におこなう必要がある。

□ 保守とはどのようなことか
本番稼働中の「システム」の構成要素を大きく3つに分けてみる。ハードウェア、ソフトウェアからなる「システム本体」、「業務データ」、「利用・運用ノウハウ」である。これを音楽プレーヤに例えてみると、それぞれ「音楽プレーヤ本体」、「音楽データ」、「取り扱い説明書や自分のノウハウ」である。最近のMP3プレーヤは形こそ小さいがCPUチップが内蔵されており「システム」といってもいい。
音楽データは常に増減があるだろうが、プレーヤそのものについても変更しなければ長年つかっていくことはできない。プレーヤのパネルにヒビが入れば(ハードウェア障害)交換するし、ソフトウェアにバグがあればアップデートする。登山に持って行くとなれば丈夫なカバーをかぶせるだろうし、新しいソフトが使いたければインストールする、といったようなことが必要だ。
情報システムについても同様で、システム本体に対する変更は避けることができない。システム本体に対する変更のことを「保守」とか、単に「変更」という。

□ 保守の目的とタイプ
共通フレーム2007(*1)を見ると、保守の目的、タイプについて、次のようなことが書いてある。
■保守の目的:
「保守プロセスは、障害の訂正、性能又は他の属性の改善を行なうため納入後のシステム、ソフトウェア製品を修正すること、又は変更された環境に適合させること」が目的である。

■保守のタイプ:
①是正保守;ソフトウェア製品の引渡し後に発見された問題を訂正するために行なう受け身の修正。
②予防保守;引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行なうための修正。
③適応保守;引渡し後、変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正。
④完全化保守;引渡し後のソフトウェア製品の性能又は保守性を改善するための修正。

共通フレームはソフトウェアのライフサイクルプロセスに関することが対象なのでハードウェアについては言及されていないが、ハードウェアを含めても同様であろう。

□ 保守マネジメント、3つのポイント
さて、保守を行なうとそれが要因になる障害が発生するというのはどのようなことなのだろうか。その変更(保守)を本当にやるべきかどうかという観点も含めて、3つの点に留意したい。
1つめは、物理的にシステム本体に対する作業を行なう「リリース作業」のミスだ。間違えて違うことをしてしまった、手順を漏らした、というようなことである。
2つめは、変更後のシステム状態に関する設計の誤りや考慮もれ、修正したソフトウェアの不具合などである。こちらは厳密には保守プロセスではなく、開発プロセスの話だが、保守の一環としておこなわれる。
3つめは、保守のメリットに対する費用やリスクから、その保守を本当に組織としてすべきなのかを評価、判断することである。大した効果も無いソフトウェアバグの修正に多大な費用をかけるよりは、多少使いづらくともだましだまし使った方がいい、ということもある。
以上のようなことが、保守や変更と呼ばれる分野におけるマネジメントの観点だが、これらの実施レベルが低いと保守に伴う障害が多発したり、システムコストがかさんだりすることになる。

□ 保守マネジメントを向上させる3つの原則
(1)下流から攻めていく
実施レベルが低い企業はリリースの管理が不十分なのですぐにわかる。いくら開発レベルが高くても、リリースがミスの連発ではいけない。先ずは、リリースをしっかりできるように、実施時のチェックリスト整備、複数名でのチェック体制、承認の体制を整備すべきである。

(2)要件発生からリリースまでのプロセスを整理
保守の要件は、上に上げた4つの「保守のタイプ」ごとに、出どころは異なるが、最終的にはすべてリリースに行き着く。タイプごとにプロセスを整理して、設計、プログラム作成、テスト、製品選定など、要所々々で品質を確認するようにしたい。

(3)保守、変更そのものの是非を審査する
新規システム導入では費用対効果をしっかりと評価してから進めることが多いが、保守や変更の際の審査が根付いている組織は少ないと思われる。やろうとする保守に関するリスクや費用と効果を、適切に評価し判断するには、CAB(変更諮問委員会:Change Advisory Board)を設置すべきというのがITIL(*2)で紹介されているプロセスである。
CABは、システム部門とビジネス部門からなる、システム変更に関する審査機関である。もちろん、全部の案件でCABでの審査が必要ということではなく、消耗部品の定期交換のようなルーチン作業は不要とするなど、リスク、費用の多寡を考慮したCABへ付議する対象を定めるルールを決めて運営していくのである。
(2012.3.30 執筆:山田一彦)

*1:共通フレーム2007第2版 (独)情報処理推進機構ソフトウェア・エンジニアリング・センター オーム社
*2:ITIL: アイティル、ITインフラストラクチャ・ライブラリ。英国の政府機関がITサービスマネジメントのベストプラクティスをまとめたフレームワーク。現在はNPOのitSMFが普及、推進している。