Click here to visit our sponsor



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

A社検査実績収集システムにおける障害の切分け

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


----------------------------------------------------------------------
(設問ア)
----------------------------------------------------------------------
1.情報システムの概要と障害内容
----------------------------------------------------------------------
1.1.検査実績収集システム
----
 A社は電子部品を製造するメーカである。本論文では、
A社生産管理システムの一部機能である、検査実績収集
システムについて記述する。先ず、本システムの構成と、
検査実績の使用範囲を、以下に述べる。

a.基幹サーバ・FA・装置から構成される。
b.不良品の除去は、装置にて実施される。
c.検査実績は基幹サーバ上、以下のに使用される。
 - 最終的な出荷可否判断
 - 異なる注文に引き当て替えを行う場合の可否判断
 - 各種帳票発行

 上記、使用範囲の通り、検査実績はシステム上の品質
保証とトレーサビリティを確保するものであり、現品の
品質保証と同じレベルで重要である。例えば、現品が装
置により品質保証されている場合にも、データロストに
よりシステム上の品質保証が行えない場合には、該当現
品の出荷はできない。

 私の勤務するN社は、基幹サーバを含む上位の生産管
理システムを構築しており、本番稼動後はシステム管理
のアウトソーシングを請け負っている。そして、私はシ
ステム管理責任者として、数名のSEと共にA社に常駐
している。

 一方、FA・装置については、システムメンテナンス
の頻度が少ないことから、スポット対応をベースとする
保守契約を締結するのみで、A社への常駐者は居ない。

----
1.2.対応マニュアルでは切り分けできなかった障害
----
 検査実績収集システムでは、基幹サーバでの取り込み
エラーが検知された場合、メールにてシステム管理者に
自動通知する機能を有している。システム管理者は、
メールの内容から、対応マニュアルに従い、エラーの原
因を特定し、ユーザに処置を依頼している。

 今回論述の対象とする障害は、一部製品の検査実績が
基幹サーバに格納されていないというものであり、前述
のエラー通知メールも発行されておらず、予め用意され
た対応マニュアルでは対応不可能であった。

----------------------------------------------------------------------
(設問イ)
----------------------------------------------------------------------
2.切り分け作業の統括方法
----------------------------------------------------------------------

a.関係者の収集
 障害の切り分けを迅速にかつ、効率良く実施するため
には、関係者との密な連携が重要である。今回の障害に
対して、私は、以下の対策委員会を編成した。

 - A社に常駐する、基幹サーバ担当のSEを招集。
 - FA担当および、データ発生源である装置メーカに
  ついては、緊急には現地に赴けないとのことから、
  電話・メールでの連絡が可能な体制構築を依頼。
 - 特殊なオペレーションを行っていないかを確認する
  ために、製造部門より、現場オペレータを招集。
 - 障害回復の最遅日を決定するために、生産管理部門
  より、出荷担当を招集。
 - 情報システムの責任者、そして、A社として意志決
  定が必要な場合のトップマネジメントへの調整役と
  して、A社情報システム部長を招集。

b.影響範囲の限定
 原因が究明できない限り、どのような場合に検査実績
のロストが発生するかは限定できない。つまり、基本的
には工場の操業を止めざるを得ない状況にある。私は、
基幹サーバ担当者に、データロストの傾向分析を指示し、
結果的に特定品種においてのみ発生していることを突き
止めた。私は、対策委員会にて、該当品種以外の生産は
継続することを提案し、A社情報システム部長経由で、
A社としての最終決定をして頂いた。

c.障害復旧の最遅日確定
 該当品種の納期、注文投入状況を生産管理部門より提
示して頂き、対策は3日以内が必須であることを確認し
た。これ以上になる場合には、顧客との納期調整が必須
であり、そのような状況だけは避けるように、A社より
強く要請された。

d.対策会議
 障害に関する新たな情報が見つかる都度、会議を収集
した場合、原因究明の作業に集中できない。逆に、新た
な情報が無い場合には会議が開催されずに状況の把握が
不可能になる危険性もあることから、私は午前・午後・
夜間の定時に対策会議を設定した。

----------------------------------------------------------------------
3.切り分けの方法
----------------------------------------------------------------------
a.時系列解析
 私は、対策委員会の全てのメンバに対して、データが
正常に収集できていた頃から、ロストが発生するまでの
間に行った、装置・システム・オペレーションなど、あ
らゆる面からの変更点の洗い出しを依頼した。調査の結
果としては、以下の2点が変更点として挙げられた。

 - 基幹サーバおよびFAにて、セキュリティパッチを
  適用。
 - 測定精度を上げるための、装置改造。

 対策までの時間が限られていることから、私は各々に
ついて、並行的に調査を進めることを決定した。

b.ソフトウェア構成の関連調査
 本件については、該当セキュリティパッチとデータ
ベースの組み合わせにおいて、類似障害の有無を、基幹
サーバ担当および、FAを構築した取引先に調査を依頼
した。しかし残念ながら、類似の障害は、N社および、
FAの取引先、更にはデータベースベンダにおいても確
認されておらず、障害原因ではないと判断された。

c.装置との関連調査
 本件については、装置改造を本番化する際に行ったシ
ステムテストの記録を取り寄せ、以下の視点で内容の確
認を行った。

 - 今回のデータロストの品種がテストされているか
 - テスト結果は、装置・FA・基幹サーバ担当全員に
  よって確認されているか。

d.再現テスト
 システムテストの結果を確認したところ、該当品種に
ついては、顧客仕様により10パターンの測定方法があ
るが、テストでは3パターンしか実施されていないこと
とに気付いた。私は、残りの測定パターンについて、緊
急に再現テストを行うことをA社に依頼し、その結果、
残り7パターンの内2パターンの測定方法において、検
査実績のロストが発生することが確認できた。

----------------------------------------------------------------------
(設問ウ)
----------------------------------------------------------------------
4.切り分け手順の評価
----------------------------------------------------------------------
 該当の障害は、装置改造にともない修正を行ったFA
システムのデグレードであり、取引先よりリモートにて
保守をお願いし復旧に至った。最終的には、障害の発生
から回復までに要した時間は、15時間であった。これ
は、作業の統括方法・切り分けの方法、いずれについて
も、最短工期での該当品種の生産再開を念頭に取り組ん
だ結果であり、極めて短期間で回復できたと評価してい
る。

 一方で、最短工期での復旧を目的に、疑わしい箇所は
全て調査するという方針を設定し、セキュリティパッチ
とデータベースの組み合わせも同時並行的に調査を行っ
た。結果的には、セキュリティパッチについては全く問
題が無かった訳であり、時系列解析の結果と、障害原因
となり得る可能性を、もう少し評価した上で、絞り込ん
だ作業を行うべきであったと考える。





[ 戻る ]