今まで、対面的な話をしてきました。システムは何でもできるという事が大前提で、コストから制限し、そこに無理がたたるという話です。では、冒頭ででてきたレントゲンのような診察はどのようなものか。プログラムでは、ログが全てです。大量にでるログは、問題を隠してしまい。一方で、肝心な情報がでてこないという事もあります。でる、でないは別途、述べるとして内面的な作りとログについて述べます。
【プログラムの構成】
プログラムは大きく、３種類ほどに分類されます。入り口部分によくある、規模は小さいけれども大量に起動されるもの。WEBシステムでのユーザ画面がこれにあたります。処理順番を正しく守り、上から順に動作するもの。これは、夜間などに起動するバッチ処理と言われるものです。不規則に周りを見ず、目の前の仕事をこなすもの。通信系にある、役割分担が明確化され、右から左へと回す処理の事です。これはタイプとして分けていますので、WEBシステムでも、バッチ処理のような動きをするところはありますし、その逆もあります。この３つの分類で、どういうところに問題があるか、という事がなんとなくわかるのではないでしょうか。
大量に起動する処理の問題は、自分達はいいのですが、どこかで集約しなくてはならず、その集約する場所が、ネックとなります。だいたいはデータベースや共有メモリといったところになります。障害試験では、同時処理のテストを実施します。早いもの勝ちなのか、後優先なのか。A課長とB部長が同時にC社員の勤怠データを修正した場合が、これにあたります。もちろん、入金、出金など似たようなパターンは、いくつもあります。この更新順番は、データから要因を与えた人達を探す為、大量のログと時系列で並べる必要があります。そして、問題は優先順位がある機能と別な機能で異なっているという事です。通常、同一データのアクセスではデータの書き込みで、他者に書き込ませないという排他処理を行いますが、排他処理は遅延を誘発したり、エラーとなった場合にただしく、利用者に伝えられなかったりします。そもそも、排他されていなかったという事もあります。画面の目的は、休みフラグを更新するだけの機能だったのですが、画面に出退勤時刻が表示され、誤って休みフラグだけではなく、出退勤時刻も更新するような仕組みになっていたとします。しかも、画面名が休暇入力画面というように、まさに出退勤をいじるように見えない場合、テストすら行われない可能性があるのです。この画面はこうだろうという先入観が、事態の発見を遅らせる事につながります。レントゲンではありませんが、ログの出力内容は全てを疑って先入観なしに見極める必要があります。
順番を正しく守るバッチ処理の問題は、順番を守っていなかったという事象がWEB画面同様時間がかかる事になります。順番を守らないという事はどういう事でしょう。バッチ処理には複数の目的があります。業務面からは本日中にやらなければいけない事を最優先にします。要は処理時間が限られているという事です。会計面では、多少の時間の余裕がありますが、金銭に関する情報を集計しなくてはなりません。経営面からは、売上情報だったりコスト管理だったり、複数の情報をつなぎ、明日移行の指針をださなくてはなりません。ざっくりとした例ですが、この３つの目的をどの処理順番で、満たす事ができるか、場合によって、業務を優先し、再度、経営の為に今度は時間をかけて集計しなくてはならない場合もあります。構築当社は、それぞれの目的に沿うように設計されていても、経営面は常に変わります。バッチ処理が不正になる事は、大きな問題に発展しやすいもので、毎年、見直しや改善により、忘れたころに恐ろしい事が待っています。こういった問題は、原因は特定しやすいのですが、改善方法が見つからないという事があります。データの流れをくみなおすには、全てのバッチ処理の流れと、その時々のデータの状態を理解していなくてはなりません。そして、あるべき姿に修正するわけですから、中途半端にやってしまうと、問題はより大きくなります。私は、随分障害対応を行ってきました。そのおかげもあってか、ログからExcelにおとし、比較したり、簡単なプログラムを作って整形したり、という作業は、ほんと早くなりました。プログラムコードを見るよりログやデータの解析の方が、多くなりました。
最後に右から左へと次々引き渡す処理についてです。この処理は、異なる機能のプログラム間をデータが行き来します。そして、引き受け元も引き渡す先も、違う機能になります。要は、大きな変更を加える必要があったとして、その大きな変更は、A変更、B変更、C変更と分けられるとします。A変更は、それを専門に行うAの処理への引き渡します。B変更はBの処理へ、C変更はC処理へ。一方、違う大きな変更処理は、B変更、D変更と分けられるとします。何が言いたいかというと、人の気も知らずに、いろんな奴がやってきて仕事を任せていくといった感じです。時に、えっ、それ俺じゃないよね。あれ、そうだっけ、でも、ちょこっと、かぶってるものもあるし、やっといて。入力データのパターンが非常に多く、また、頼んできた者の意図を理解する必要もなく、決められた事をすればいいのです。この作りは、解析屋からすると、本当にやっかいです。それぞれの意図を理解しなくては、ならないからです。ここで問題が起きたという事は、両社の意図がずれていた事に他なりません。意図がずれるのは、他のプログラムでもありますが、不特定多数から引き渡されている現実に大きな問題があります。また、この改修も困難なものになります。ただ、後先考えないのであれば、対応は難しくありません。不特定多数を特定にすればいいからです。A変更処理において、特定の処理から引き渡された時に、問題があるのであれば、AA変更処理を作り、専任にすればいいです。AA変更、AAA変更と増えていった時に全てのA関連変更処理に致命的な問題が見つかった場合は、AA変更、AAA変更も直さなければいけないので、先の事を考えると不用意に増やすべきではないでしょう。対応はいいとして、とにかく誰にとって不都合だったかを見極める方が、大変です。