システム障害を防ぐにはどうすべきか――。日経システム構築9月号の特集「あのトラブルは防げたか」で，この難題に取り組んでみた。記事中では，実際に障害に見舞われた企業，組織を取材し，本当に障害は防げなかったのか，防げるとすればどのタイミングだったのかを検証していった。
あくまで結果論ではあるが，導き出された結論は，「防ぐチャンスは皆無ではなかった」というものだ。詳しくは上記の特集をご覧いただければ幸いだが，システム稼働の前後それぞれに障害を防ぐチャンスはあった。稼働前のチャンスとは，「設計/テストの徹底」である。障害を起こした少なからぬ企業は，考慮漏れや思い込み，油断などから，設計の不備やテストの漏れを見落とした。
他方，稼働後のチャンスとは，システムにもたらされる「変化/予兆の捕捉」である。障害を起こした企業も，平常時からシステムの状態などは常時監視していたが，予兆と見なす「基準」と対策である「ルール」を明確化していなかった。このため，監視で予兆を捕らえていたのに抜本的な対策を採れなかったり，障害の予兆となる情報が世代交代する担当者間で引き継げなかったりして，障害に至った。
障害を経験した企業の多くが，今，この2つのチャンスを生かすために全力で取り組み始めている。記事では，これら企業の取り組みを中心に追ったので，本稿では2つのチャンスを生かすために求められるトレードオフと，最近の動向について言及しておきたい。
生産性を下げても品質を優先
稼働前の設計/テストの徹底にせよ，稼働後の変化/予兆の捕捉にせよ，予防策を採る以上，それなりの“ムダ”を覚悟しなければならない。予防策が後手に回っては意味がないからだ。稼働前ならより上流で，稼働後なら少しでも先回りして，障害の芽を摘み取る必要がある。そのためにどれだけの“ムダ”を受け入れるのかというトレードオフは，システムが提供するサービスの重要性に応じて，企業が判断するしかない。
日本IBMは，正しく開発されていれば，実施するだけ“ムダ”になるはずの品質評価（レビュー）を重視することにした。2004年2月に，品質評価の専門部隊を設立した。前月の11日には，同社が開発した統合ATM用接続ソフトの不具合が原因で，複数の銀行で一部の取引ができなくなるという障害が発生していた（関連記事）。
西暦2038年問題にまつわるこの不具合は，設計/実装/テストの各フェーズで見過ごされてしまった。その反省から，今後は折に触れて，専門部隊が品質をチェックすることにしたのだ。間違い，不備，漏れなどを，専門部隊が徹底的に暴き出す。専門部隊は大和研究所の所長に直属しており，開発部隊とは独立した権限を持つ。「生産性を優先しがちな開発部隊とは別の視点から，厳格な評価を貫徹する」（ソフトウエア開発研究所 ソフトウエア製品保証 岡崎毅久氏）という。
「もったいない」では防げない
某大手コンビニエンス・ストア業者の場合は，店舗マシンのディスクを故障前に交換するという予防保守を徹底している。ディスクのセクター異常率などを保守センターで集計。一定のしきい値を超えたら経年劣化と見なし，同時期に導入したディスクをすべて新品と交換する。未故障のディスクだろうと例外はない。
さらに，店舗マシンを構成する部品の製造時期（ロット）まで管理する。設定した故障率を超えた部品については交換するなど，明確な基準を設けている。「もったいないが，“ムダ”を覚悟しないと障害を未然に防ぐことは難しい」（保守を担当するNEC 流通業システム開発事業部 シニアマネージャー 金子博保氏）。
“ムダ”を省く手だてが徐々に浸透
このように，障害を予防するためには，ある程度の“ムダ”を受け入れざるを得なかった。ところが最近になり，この状況が変わりつつある。“ムダ”を省きながら障害を予防する方法や製品が，企業に浸透し始めたのだ。
その一つが，実績のあるOS/ミドルウエアなどを社内で「システム基盤」として標準化するという手だて。ソニーグローバルソリューションズ（SGS）は2002年ごろから，サーバー機，ストレージ機，OS，ミドルウエア，データベース・ソフトなどを，特定製品/特定バージョンのみに限定してきた。UNIXサーバー機であれば「Sun Fire」，PCサーバー機であれば「IBM eServer BladeCenter」というように，製品を絞り込んだ。製品の組み合わせを制限することで，システム設計やシステム・テストの工数を削減しながら，安定したシステムを構築できるようにした。
それだけではない。SGSは，サーバー機の製造時期（ロット）による品質のバラツキを抑える工夫もしている。具体的には，同じロットのサーバー機をハードウエア・メーカーに数十台規模で用意してもらい，SGS社内に予備機として設置してもらっている。Webシステムの負荷が急増したなどの予兆を捕捉したら，この予備機をSGSのシステムに追加する。予備機の代金は，実際にSGSが利用を開始したとき，または利用している日数分だけ支払う。「キャパシティ・オンデマンド（CoD）」という考え方を取り入れ，ベンダー/販売店数社と数年間の交渉を重ねて実現させた。この方法なら，障害の温床を減らせる上に，高価なサーバーの予備機を自社で抱え込むという“ムダ”を減らす効果も期待できる。
自律機能を搭載した製品も増加
障害の予兆を見分け，自動的に予防措置につなげる製品も増えてきている。「自律機能」をウリにした製品群だ。こうした製品を使うメリットは，予兆を見分ける最適な基準値を求めて試行錯誤を繰り返すという“ムダ”を省きやすいことにある。予兆を見分ける基準値は，かなりの運用データとノウハウの蓄積がなければ決めづらい。しかし，自律機能を搭載した製品には，基準の候補となり得る情報と，目安になる値を，あらかじめベンダーが定義していることが多い。利用すれば，最適値を探る管理者の負担は軽くなる。
例えば，東芝ソリューションのクラスタ・ソフト「DNCWARE ClusterPerfect」と日本IBMのブレード・サーバー機「eServer BladeCenter」の組み合わせは，金融業者の情報系Webシステムを中心に複数の導入実績があるという。両製品を使うと，ブレードが故障する予兆を検知して，代替サーバーを用意するという運用を自動化できる（関連記事）。
具体的には，ブレードに搭載した日本IBMのエージェント・ソフト「Director」が，単位時間内にメモリーにパリティ・エラーが頻発するとか，ディスクの書き込み再試行が繰り返されるなどの予兆を検出。ClusterPerfectに予兆検知のアラートを上げる。アラートを受け取ったClusterPerfectは，あらかじめ定義しておいたポリシーに基づき，予防措置を実行する。ブレード上でアクティブ/スタンバイ構成のデータベースを稼働させていた場合であれば，次のような予防措置に結び付けられる。まず，アクセスがなくなる深夜帯を見計らってサービスをいったん停止。次に，アクティブ機を停止してデータベースを退避させ，スタンバイ機にフェールオーバーする。スタンバイ機上でサービスを復旧させる――。
システムの障害を防ぎ，安定稼働させることは重要な課題だが，企業の情報部門の予算は限られているし，管理に避ける人手にも限界がある。「最善の障害対策は未然防止に尽きる」と分かっていても，これまでは“ムダ”を受け入れられずに十分な予防策を採れなかった企業も多いだろう。キャパシティ・オンデマンドや自律機能を搭載した製品などをうまく使うことで，増える一方だった“ムダ”を減らしながら障害を抑制することも検討に値する。
なお，末筆ながら，障害というデリケートな話題にもかかわらず，取材に協力してくださった企業/担当諸氏には，この場を借りて改めてお礼を申し上げたい。本当にありがとうございました。
