悲しい記事である。11月17日にJASDAQのシステムが落ちた件。コンピュータネタ、目次へ
日経ITProの記事によると、障害情報ファイルを消す手順が運用マニュアルになく、結果、障害情報ファイルがディスク領域を圧迫して、システムが起動しなかったというものらしい。
日経は節度を持って取材内容を淡々と述べている。しかあし、タイトルがよくない。「JASDAQのシステム障害、運用マニュアルの不備が根本原因」。記事をきちんと読めば気がつくが、運用マニュアルには全く問題がなかった。にもかかわらず、JASDAQの取締役が「運用マニュアルから漏れていた」などというもんだから、こんなタイトルになっている。これでは関係者が傷つくではないか。
記事をよく読んでいるうちに、だんだん関係者に同情してきた。最近障害分析の仕事もやっているので、他人事とは思えなくなってきたわけだ。彼らにも言いたいことはたくさんあるだろうが、「だけどシステムを止めたじゃないか」と言われればそれ以上何も言えない。だから思いっきり裏読みして、多少は代弁したくなった次第。（もっともこういうのを私がやると逆にとどめを刺しているのでは、といわれることが多い。）簡単に障害の原因をまとめると、
UNIXサーバにおいて、障害情報取得ファイルが/varディレクトリに溜まってしまい、空き容量が少なくなってしまったため、起動時に確保されるべき領域が確保できず、OSの起動が失敗した、というもの。
でもって、これの根本原因は障害テスト時に作られた障害情報取得ファイルを削除する手順が運用マニュアルになかったことらしい。少なくともジャスダックの取締役はそう言っている。しかし、障害が発生したときに参照するマニュアルには、障害情報ファイルを削除する旨がきちんと書かれていたそうだ。つまり、書かれていなかったのは、本番環境を使って障害テストを行ったときの障害情報ファイルを削除するという作業である。
従って、運用マニュアルの不備が根本原因としたことの前提として「障害テストの後始末（障害情報ファイルの削除）が、通常の運用マニュアルに記載されているべきである」という認識があったということが判明する。
果たしてこの認識は妥当だろうか。確かに障害情報ファイルの削除は忘れやすい。だから通常の運用に「あれば削除」するのを含めるという考えも成り立つ。しかし、本来障害テストで本番環境に作られたファイルは障害テストの一連の手順で削除するのが当然である。だってテストでデータ汚したら、バックアップから戻すのはテスト手順の範疇でしょ。つまり、本当に不備であったのは「運用マニュアル」ではなく「テスト手順書」だったのだ。では、今までの障害テストの時はどうしていたかというと《これまで何度も障害テストを実施していたにもかかわらず障害情報取得ファイルの容量が肥大することがなかったのは、このシステムの開発を請け負った日立製作所の担当者が、テスト実施時などに削除していたため》だそうだ。
この問題の根深さはここにある。まずは、ファイルの削除がテスト手順書に組み込まれていなかったことが、この文より明らかになる。今までのテスト手順書に含まれていて、今回無くなっているのだとしたら、テスト手順書レビュー時に、いくら何でも気がついたはずだろう。つまり、ファイル削除は現場の担当者が、現場の判断で行っていたことになる。現場の判断でやってしまうのは、プロジェクト管理上は問題があるかもしれないが、よかれと思ってやったこと。作業リスクも殆ど無い。そう責めるわけにはいけない。では、なぜ今回から（正確には９月から）現場の判断で削除を行わなくなったのだろうか。文章のニュアンスから言うと、テストの担当が替わった（今までは開発元に発注していたが、別の運用会社に切り替えた、など）からのような気がする。ならば救いがある。テスト担当を切り替えたのは、コストの問題が絡んでのことだろうからだ。工賃の安いところに頼めば、その分スキルの低い人間がやってきて、こういうところ（いわば基本的な手順）に気がつかない。当たり前のことだ。JASDAQはその辺を反省すればよい。これからも少なくとも手順書作成だけは開発元に発注すればよいのだ。
もし、今回の作業も開発元の皆さんが行っていたとしたら、これは深い。
先ほど述べたように、現場の判断で手順を追加するというのは、プロジェクト管理上は問題がある。場合によっては事故になる。で、そういった事故が開発元の他の部門で発生したのかもしれない。当然再発防止策として、おふれが回ったはずである。「現場で手順書以外の作業を行わないように。行うときには上司の判断を仰ぐように。」全く問題はない。至極当然の施策である。で、ジャスダックでのテスト当日。現場の担当者が悩む。「あれー、障害情報ファイルって消さなくていいんですか？」「当然消すよ」「でも手順書にないですよ」「ほんとだなあ、上司に連絡してみよう。」
ところがその日は休日。在宅の上司は「うーん、今手順書が手元にないから（自宅に持って帰ってたりしたら今度はセキュリティ上問題がある）分かんないなあ。まあ絶対当日に消さないといけないということはないから、明日検討しよう」と答えてしまった。 で、11月17日。サーバーが上がらない。誰かが目立ったミスをしたわけではない。一つ一つの判断は間違ってはいない。しかしサーバは立ち上がらない。だとすると、根が深いのだ。この問題。
それはいろいろ言うべきことはある。/varをなんで10GBしかとっていないのだ。/var以外に障害管理ファイルを吐き出すようになぜしていない。/varの容量管理の大切さなんてFreeBSDのインストール本にだって書いてあることではないか。容量オーバーが予測できなかったなんて定期的なディスク使用情報すら取得していなかったと言うことか？
そもそもファイル削除が手順書にないのがおかしい。ないなあと気がついたところで修正しておかなければならない。担当者に都度判断させていた管理に問題がある。（修正を言い出しにくい雰囲気があるのかもしれないが。）
もっと言うと、障害テストを本番機で行うのが間違っている。環境の問題から本番でしかできないテストというのはあるかもしれないけど、それならテスト終了後に再立ち上げをして、動作確認をするのが普通じゃないか。だって障害テストだよ。環境の戻し漏れ（例えばシステム日付の戻し）があったら、今度は本番で本当の障害が起こってしかるべきなんだよ。最低でも正常起動を確認しないと。まあ、手順書の徹底的見直しを、ということで、ジャスダックではこれから大レビュー大会が開かれることになろう。でも改善される見込みはきわめて薄い。たぶんシステムは思いっきりアウトソースしているのだろう。従ってジャスダック自体はチェック能力を持っていない。テスト手順書がおかしいのに「運用マニュアルが根本原因」と発表してしまうような認識しか持っていない組織に、とてもそんなことは期待できまい。
取引所とそこに上場されている企業に直接の因果関係はない。しかし数多くの新興IT企業を抱えていることで名を売ったJASDAQが、基本的なシステム運用もできないようでは、JASDAQに上場されている企業全体に対するイメージが悪くなるんではないかなあ、こんなことまで心配させられてしまった。
しかし、心配したような事情ではなさそうだ。原因究明に１週間以上の時間がかかっているからだ。/varがフルになって落ちたことくらい、開発元ならすぐに判断できる。ということは今回の作業に開発元は関与していなかったということだから。
メーカーからシステム提案を受けて発注する際に気にしなければならないことがメインフレームの時代と比べずいぶんと増えてきたようだ。システムのオープン化やミドルウェアの多様化といったことに起因する複雑さの拡大もさることながら、発注先がいずれいなくなることを前提としなければならない。
コンサルタント会社は、要件をまとめたところでいなくなるし、開発元も開発がおわったところでいなくなる。それなりに保守契約をしていたようだが、乗り換えたところで起こったのが今回のジャスダックの例。結局、自社のシステムが分かって、手を入れられる要員は自前で用意しなくてはいけないということらしい。
ふっと思い出したのが、オーディオアンプメーカーであるサンスイの件。
確かトランスメーカーだったんだよね。でオーディオアンプが伸びてきた。そこで本体はオーディオアンプの製造に力を入れて、トランスの製造は子会社化してしまった。
やがて、本体の業績が傾くと、その子会社が本体にトランスを納入してくれなくなった。
ポリーペックに買収されたのはその直後。