2011/5/21
私は大学を卒業して、すぐに金融会社のシステム会社としてそのシステムの仕事をしました。どことはいいませんが、システム自体は決して新しいものではなく、大学でJavaをやってから入ったので、そこには見るもの聞くもの古臭いものばかりでした。
ですが、いざ、ITベンチャーに入ってみて、いろいろと役にたったなーと思ったことがあるものでした。そこには、あのみずほ銀障害の新聞で「システム担当者はそもそも処理能力に限界があること自体を知らなかった。」とありましたが、会社が違えど、今ではベンチャーと大企業のシステムが逆転してしまうほどになってしまったのかなと思うような内容があるので、COBOL時代にまなんだことを書いてみることにしました。
システムの処理がコストとして部門に知らされる
実際にお金として計算されているかは知りませんが、各部署ごとのCPUの使用率の連絡が来ていました。そして、うちのチームはちょっと使いすぎとかの連絡がきました。
今のクラウドをつかっていると課金されるのと同じような感覚です。
私はここで、いろいろなことを知り、サーバを運用する際にはCPUとかメモリなどはあたりまえですが、Javaで言えばスレッド数や、同時接続数、SQLのクエリー数などもやるようにしています。第三者にサービスを提供している場合にはコンピュータ全体の使用率だけでは十分ではないからです。
障害がわざと作られ、訓練が行われる
私が、ちょうど１年目の冬ごろにちょっとした障害を起こしてしまいました。
当時はみんながなんとなく残業していたころで、早く帰ることすら罪悪感があった時代です。おかげで夜遅くまでいると、自然と他人の障害のヘルプとしてやっていたこともあり、多少はなれてきて、高をくくっていた時期です。
そんなときに、自分で障害を起こしてしまいました。
さすがに、他人の障害と自分が起こしたものでは冷静度が違います。
まあ、先輩方のサポートもあり問題がなくすんだということですが、
それから、大体１年後、新人を教育してきてだいぶ仕事ができるようになってきた時期に、上司からこんな命令が・・・
「新人にどんな障害をさせるか、考えておいて」
ソース管理
１つのチームが管理するソースがどれほどあったのかは覚えていませんが、４段のキャビネットが３ブロックくらいはあったと思います。（紙に印刷されています。）
COBOLのソースは、Javaとかとは違ってCOPY区という定義部分が大量にあるので一概にその他の言語とは比べられないのですが、とにかく大量にあります。
行単位で修正をするときには、一番左（右だったかな）に案件IDを記入して変更します。
そして、印刷したソースには、注意事項などの付箋とそれに連動したドキュメントを挟んでおいたりしていました。
ソース自体の世代管理はライブラリアンという方がいてそこで管理されていました。
今で言えば、案件ID部分のリビジョンであり、付箋はTracなどの事案管理でありと手法などは違えど本質的にはかぶっている部分が多々あります。
ただ決定的に違うのが２つ。
すべてのソースがIDです。ProductList.javaみたいなソース名ではなく、PL0001みたいになっているということです。まあ、プログラムの単位が違うので一概にいいところばかりでもないのですが、IDというのはそこに責任境界線もあったりするので、管理としては進んでいると思います。
そして、プログラムが紙に印刷され保存される場所が物理的あるので、担当者として「あー、２段目の真ん中あたりだ」と感覚的に仕事が進みます。付箋などの量も変わってくるので問題があるあたりが目と感覚でわかるので、誰の目にも見えやすいです。
システムの分離性
とにかく、システムのデータが重複しており無駄が多いのです。
１つの情報を修正したくても、あそこもここも修正しなければなりません。
DBの正規化などをやろうしている人が見たら、だめだめといわれるかも知れません。
しかし、私もシステムが何を守りたいのかを知るまではそのように思っていました。
そして、それはそれから数年後、ASPを運用するときになってようやく意味がわかりました。
ただ、そのときには大学で勉強してきた情報管理の基礎もできていないのだと・・・
それは、私が午前４時ごろに社宅の管理者から起こされたときでした。
障害がおきたので対応してほしいと。
でも、私は初心者で業務全体を理解できていません。
そして、残念ながら私のチームのリーダと先輩には一切連絡がつきません。
多少は業務はしっているが、チームとはまったく関係がない先輩と二人で約３時間でシステムを復旧させないと全国のオンラインシステムのサービスが間に合わないこととなります。
当然、問題を解決し復旧させるには時間もなく、私自身の知識も足りません。
そこで、問題の先延ばしをオンラインシステムの立ち上げだけは問題がないようにすることにします。
ここで、データが重複している無駄が非常に役立ちます。
問題がおきているシステムに関連するデータだけを修正して、あたかも問題がないようにデータを直接、手で直してしまいます。
つまり、問題の場所しか見えていないような人でも問題に対応できるようにしておくことがシステムの重要性から必要だということです。
あの人しかしりません。そして、できません。そして、顧客の資産が減ります。それではサービスとしてありえませんから。
これだけではありませんが、こんな感じに今思ってもいろいろとよく考えられているなーと思うことばかりです。
でも、その中にいて、その中のルールで動いているうちはまったく気がつきませんでした。
まあ、ルールは作る側に立ったときに本当に他人のが作ったルールの意味がよく見えてくるものです。
しかし、今では銀行などでも小規模システムのルーズさと流行言葉に悪い影響をうけているように見えることが非常に残念です。
関連記事
Posted in 現場管理
