----------------------------------------------------------------------

Ａ社情報システムにおける障害発生の未然防止策について

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1.システムの概要と障害発生の未然防止策の概要
----------------------------------------------------------------------
1.1.システムの概要
----
　Ａ社は化学薬品を製造するメーカであり、工場は２４
時間３６５日で操業を続けている。システムにも当然高
い信頼性が要求され、本番機に加え、テスト環境を兼ね
たバックアップ機の計２台のメインフレーム上で稼動し
ている。

　しかし、長引く不況の中、システム費用の大幅な削減
が要請された事や、新工場の建設と新品種への対応が、
既存システムでは困難であった事から、Ａ社では新シス
テムの構築と同時にダウンサイジングを実施する事を決
定した。

----
1.2.新システムにおける障害発生の未然防止策
----
　新システムはＡ社の既存工場に加え、新工場と新品種
の生産管理をサポートするものである。特に新工場と新
品種については、Ａ社が社運をかけて取り組むものであ
り、システムの障害により操業が停止した場合の損失は
大きい。したがって、新システムには以下の視点で、障
害発生を未然に防止する施策を組み込んでいる。

　a.システム構成
　　ＡＰサーバとＤＢサーバ、加えてテスト機の３台の
　ＰＣサーバで構成しているが、各サーバの障害時には
　縮退運転が可能であり、最悪の場合テスト機の１台だ
　けでも本番運用が可能な構成としている。

　b.稼動監視機能の組み込み
　　システムを、アプリケーション・基盤ソフトウェア・
　ハードウェアの３層に分割し、各々の層にて稼動状況
　を定期的にモニタリングする機能を組み込んでいる。

----
1.3.私の立場
----
　私の勤務するＮ社は、Ａ社新システムの構築を請け負
っており、私はシステム管理に関する機能の設計・開発
を任されるチームリーダとしてプロジェクトに参画した。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.稼動状況や障害の前兆を把握分析する方法
----------------------------------------------------------------------
　システムを３層に分割し、各々の層で定期的なモニタ
リングを行っている事は既に述べた。このモニタリング
機能では、アプリケーションの異常終了時や、ＣＰＵ・
ディスクの使用率が予め設定したしきい値を超えると、
警告を管理者にメールで通知する機能を有している。シ
ステムの本番化後、新システムの運用責任者としてＡ社
に常駐していた私は、このモニタリング機能を使用して
システムの稼動状況を監視していた。

　新システムの稼動後３ヶ月が経過し、新工場の製造す
る新品種の量産が開始された頃に問題は発覚した。具体
的には、Ａ社では日々生産計画の見直しを行っているが、
週末に限り生産計画をシミュレーションするアプリケー
ションがタイムアウトするというものである。私は、こ
の異常をメールにて認識し、直ちにＣＰＵ・ディスク使
用率・同時稼動トランザクション等のログより原因を分
析した。しかし、ＣＰＵ・ディスク使用率のデータ採取
間隔は５分に設定されており、有益な情報を得る事はで
きなかった。そこで私は、更に木目細かいデータが必要
であると判断し、データ採取の間隔を１分に引き上げモ
ニタリングを続けた。

　その結果、生産計画シュミレーションが実行される間
は、特定のディスクの使用率が９０％を超えており、こ
れが原因でタイムアウトが発生している事が判った。ま
た、この状況が悪化した場合、他のアプリケーションも
タイムアウトを引き起こす事は容易に想像できた為、私
は直ちにＡ社ユーザとＮ社システムエンジニアと詳細な
原因分析と対策を検討した。

　a.Ａ社ユーザへのヒヤリング状況
　　週末には、翌週分の生産計画を立案するために、シ
　ュミレーション対象のデータが多い。また新品種は小
　ロット生産のため、新品種の量産もデータ量増加の原
　因となっている。私は、生産計画シミュレーションの
　頻度・対象期間の見直しを依頼したが、Ａ社では業務
　プロセス変更の負荷が高く現実的では無いとの事であ
　った。

　b.Ｎ社システムエンジニアへのヒヤリング状況
　　生産計画シミュレーションのタイムアウトはシステ
　ムテストの頃より発生しており、ＤＢ設計・ＳＱＬの
　書き方など、アプリケーションレベルで可能なチュー
　ニングは既に実施済みである。

----------------------------------------------------------------------
3.障害の未然防止策の内容
----------------------------------------------------------------------
　このまま新品種の生産量が増加した場合、他のアプリ
ケーションがタイムアウトし、システムが広範囲でダウ
ンする事が予想されたため、私はＮ社システムエンジニ
アと協力し、防止策を直ちに検討することにした。

　その結果、生産計画という単位では十分なチューニン
グが実施されているものの、システム全体で見た場合に
は、更なるチューニングの余地が残されている事が分か
った。具体的には、サブシステム単位の利用頻度・必要
なシステムリソースの差異から、ディスクの使用率にバ
ラつきがかり、データベースの配置替えを行うというも
のである。

　私は、配置替え後のディスク使用率の見積もりをＮ社
システムエンジニアに要求したところ、ＲＤＢＭＳの詳
細なログよりピーク時でも現行の９０％を６０％に低減
できるとの事であった。一方、配置替えに伴う他アプリ
ケーションへの影響については、現行ディスクの使用率
が低く、１０％が２０％になる程度であり、ユーザへの
直接的な影響は無いとのことであった。

　以上の調査結果をＡ社に報告・承認を得た後に、私は
対策に取り掛かった。


----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
4.未然防止策の評価と改善
----------------------------------------------------------------------
4.1.データベース再配置後の評価
----
　前述の施策を実施した結果、問題のディスク使用率に
ついては５０％に低減され、生産計画シミュレーション
のタイムアウトも無くなった。また、現在しきい値とし
て設定している８０％に達する時期も、Ａ社の中期計画
に基づくと５年後と見込まれた。また、この時期までに
は新システムのハードウェアはリース更改を迎えており、
再リースは行わないというＡ社の方針より、問題になる
ことは無いと判断できた。

　以上のように、システム全体に及ぶ可能性のあた障害
を事前に検知し、対策を実施できたことは、新システム
の設計時点より組み込んだモニタリング機能が大きく寄
与しており、システム管理者としての私の適切な判断が
奏効していると判断する。

----
4.2.今後の改善
----
　今回の問題は結果的にシステム全体でみた場合にディ
スク使用率に余裕があったため、障害を防ぐことができ
た。勿論この余裕が無い場合には、新たなハードウェア
の増強をせざるを得なかったものである。

　今後同様の障害を発生させないためには、システム全
体としての設計時点からの性能設計、および仕様変更時
の性能設計の見直しが重要であると考える。