のんちゃん。あーい。
by tsuyodrive
S M T W T F S
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30


XML。

いきなり、XMLに興味を覚えた。
なぜなら、仕事で有効に活用できるかもしれないと思ったからである。
現在開発中のシステムはシステムダウンや致命的な例外が発生するとトレースファイルを吐く。これがユーザーさんのところから毎週60~70個くらいの規模で私のところに届く。このトレースファイルを分析・整理して、我々の開発部分に不安定なところがないか確認するのが仕事である。

通常、再現手順が判れば問題解決は非常にたやすい。なぜなら再現手順により問題が見つけやすいからだ。しかし、私のユーザーはまずデータが機密であるためおいそれと出せない。次にユーザーさんの負荷が高く、丸1日操作している中のほんのひとかけらの操作について覚えていないことの方が多い。3つめにトレースファイルの分析が送られてくるのは翌週であるため、分析を開始してからユーザーへのヒアリングができるまでにものすごくタイムラグがある。これも再現手順を聞きだしにくくなっているひとつの要因である。

また、トレースファイルを分析するのは結構骨だ。1ファイルあたり200行~300行くらいある。情報を一つ一つ注意深く追う時間などは割けない。そのようなことをしても効果が薄いからだ。また、開発メンバーへの問題のディスパッチが遅れてしまう。できるだけ早い段階で問題をディスパッチし、早期解決に努めなければならない。そのためには効率よく情報を取捨選択する必要があるのだ。
しかしながら、トレースファイルだけを一つ一つ追いかけても、問題がどこにあるのかとてもわかりづらいというのが現状である。非常に不毛な作業を強いられているのだ。

そこで、この状況を打開すべく、思いついたのがトレースファイルのXML化と、パターンファイルをXMLファイルでDBにして活用すること。
ユーザーは何度か同じことにチャレンジし、同じところでダウンしているという操作がトレースファイルから伺える。これは再現手順を覚えている可能性が非常に高いはずだ。
また、プラットフォーム既知の問題というのはある程度トレースファイルの出力がパターン化されている。このパターンと一致するようなトレースは「既知」としてこれ以上調査する必要はないはずだ。
あまたのパターンを目で追いかけ、行き当たりばったりにチェックするのは正確さを欠くばかりか時間がかかってしまう。こんなことに注力するより、問題をもっと詳細に分析することに注力すべきである。

トレースファイルはただのテキストファイルなので、これまではある程度のフィルタリングとしてcygwinのC Shellを利用してgrepやawkなどでふるいにかける程度だった。
これをさらに強化し、誰でもどこでも使え、分析ノウハウを漏らさず分析に適用するようなツールが必要だと感じた。

XMLはXMLパーサと呼ばれるファイルの「読み・書き」ができる機能が用意されている。
これをVC++で作ったモジュールから呼び出せばXMLを自由自在に操作可能だ。
(他にもJavaやらPerlやらVBやらあるらしいが、門外漢なので省略)
しかもファイルIOのデバッグから開放されるというメリットもある。
加えて、プラットフォーム開発元(フランス)などに分析結果をそのまま送ることもできるだろう。(今のままでは日本語部分が文字化けを起こすだろうが、Unicodeに変換することにより、文字化けを起こさずデータを失わなくて済むというメリットも。)

さらに言えば、SQLなどは他のパッケージが必要であり、利用PC上で環境設定を余儀なくされるが、XMLはツールさえ作ってしまえばそれをデリバリするだけで使えるはず。
XMLファイルはテキストなので特別なツールがなくても読める。
これは非常に大事なことだ。

トレースファイルは見出し毎に出てくる内容が異なるが、見出し一つ分のステートメントをタグで囲んでしまい、あとはローカルなフォーマットを適当に定義してやればそれだけでXMLファイル完成である。
その後はXMLのツリーを読み込み、メモリ上で加工するだけとなる。
報告文書作成については、csvで出力しExcelで整形して見せることも比較的簡単だろう。
(手動の集計作業もツールでやってしまえる)

XMLを使うのは初めてなのでインプリに多少時間をとられるかもしれないが、やって損はないだろう。むしろ柔軟で強力なソリューションとなるかもしれない。
[PR]
by tsuyodrive | 2004-11-02 03:37
<< いすぉがすぃ。 追いつかない。 >>