ホチキス先生の「プログラマーと呼ばれたい」

InfoPath & SQL Server !

システムを作りこむと運用を誤ったときの問題解決に手間取る

leave a comment »

システムを作り込むと、本来必要なデータに加えて様々な属性情報を付け加えることになる。例えば成績データに対して、生徒の在籍状況や成績が確定したことを示すロックフラグなどが付いている。これは例えば年度途中で退学した生徒の単位を学期末に認定してしまったり、卒業してしまった生徒のデータを書き換えないため、単位認定会議が終わった後で成績を変更されないため、など、データ処理の安全性を高める役割をしている。だが運用を誤ると、これが問題解決を複雑にし、手間取らせる原因になる。今回おこったことは、こういうものだった。

私の勤務校は前期後期制をとっており、ほとんどの科目は半期で単位認定を行う。また入学、卒業も半期ごとに行い、毎年9月に「前期卒業式」を行い、同月に「後期入試」を行って10月に新入生を迎える。今年の前期末処理を行う際、ある理由があって単位認定のシステム上の処理が遅れてしまった。単位認定処理を行ってから通知表などの成績資料を出すのだが、その一連の処理が終わる前に、教務の担当者が前期卒業生に対して「卒業処理」を行ってしまったのだ。

生徒を「卒業」としてしまうと、その生徒はもはや本校に「在籍していない」ことになってしまう。この生徒の在籍状況は、たくさんのテーブルに影響を与える。システムは「在籍していない」生徒に対して、単位の認定をしないようになっている。冒頭に書いた「安全装置」が働いているのだ。そこで前期卒業生の単位認定処理ができなくなってしまった。

「卒業処理をした」ことが私に伝えられなかったため、初動調査が遅れた。このとき私は、単位認定処理が正しく行われない理由を、ストアドプロシージャにバグがあったのだろうか、と思っていた。しかしそうではなく、卒業処理が問題だった。その後、卒業処理によって生徒の在籍状況がどのテーブルに影響するかを調べる作業が必要となった。在籍状況は数多くのテーブルに影響を与える。これにかなり時間を必要とした。その結果、前期末処理が完了するのも、ますます後にずれることとなった。

卒業処理がどのテーブルのどのデータに影響を与えるか、ドキュメントを残しておけばよい、というのは模範的な解答だと思うが、例えば一年間で行われる処理は様々にあって、それらのすべてについてどのテーブルにどんな影響を与えるかをドキュメントに残すことは、言うは易し行なうは難しである。仮にドキュメント化されていたとしても、手作業でデータを修復しなければならないことは変わらない。

システムを使いやすく構築すると、データ構造は複雑になることが避けられない。運用が簡単になるように一連の作業をストアドプロシージャ化すると、今回のように処理の前後が間違ったとき、問題解決に時間がかかる。

運用を誤る可能性がゼロにならない限り、システム運用にはシステムを熟知した管理者が必要なはずである。

Written by Yoshio Matsumoto

2010年10月20日 @ 12:38 AM

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。