自動化できないシステム

例えば、銀行の公共料金自動引き落としの処理¹とか。絶対に時間内に終えなければならない、クリティカルな処理がある場合、処理を全部自動でやるのは無理でしょうね。システムに 100% の信頼性がなければ。宇宙線でメモリの内容が書き換わる、なんてことも − 極めて低い確率ではありますが − 起きるわけですし。²

我々の仕事は、開発部署が構築したシステムの下で正しく処理が動いているかを日々監視することにある。

監視する中でトラブルがあれば開発部署に問い合わせ、対応を要請する。

我々は次に動く処理を監視しなければならないので、対応はあちらに任せるのが常である。

後輩を育てることは難しいです

とはいえ、基本、処理は自動で動いて、処理の成功／失敗を待機要員（オペレータ）に伝える、という形になっているのが普通ではありますかね。

Aという業務があって、それを終えるためにa,b,c,dという作業を順にこなす必要がある。

だが、a->b->d->cとなったり、a->b->cで止まったり、時にはa->c->dとなったりした。

人間がひとつひとつプログラムを起動し、確認しなければならないのは、

1. ひとつひとつのプログラムの信頼性が極めて低い
2. 基本的なフォールトトレランスが実現されていない

といった理由があるのではないですかね。

1 は、頻繁にプログラムが処理を失敗するので、はじめから人間が関与したほうがよい、という運用になってしまっている状況。 2 は、それに輪をかけて、処理が失敗したときに、データベースの一貫性が破壊されてしまうというもの。単純に失敗したところから処理再開、とできないわけです。「基本的な」とつけているのは、つまり、データベースのロールバック／ロールフォワードが、ろくに考えられていないということですね。

私が見たことがあるケースですと、例えば、互いに関連するテーブル A, B, C がありまして、バッチ処理が以下のように組まれている、というのがあります。

for a in A
  A を処理

for b in B
  B を処理

for c in C
  C を処理

commit/rollback

巨大なひとつのトランザクションになっているわけですね。で、これが 2 時間かかる処理だとして、1時間50分くらいで、処理が失敗して、ロールバックに 2 時間、はじめからやりなおして 2 時間、などという楽しい運用になるわけです。 Oracle データベースですと、ロールバック・セグメント／UNDO表領域を使い切って処理が失敗する、というのが典型。

これは到底運用に耐えられないわけですが、さりとて、プログラムを直すとなると、全面的に制御構造を書き直しとなるわけでして。応急策として、以下のようになったりします。

for a in A
  A を処理
  commit/rollback

for b in B
  B を処理
  commit/rollback

for c in C
  C を処理
  commit/rollback

当然、この処理が途中で失敗しますと、テーブル A, B, C 間の整合性が崩れるわけです。で、どこで失敗したかによって、色々なリカバリ処理が運用現場でできあがっていくわけですね。

かくして、運用現場のオペレータは、プログラムをひとつひとつ手で起動し、どこで失敗したかを適宜確認し、状況に応じて回復／再開を行なうこととなるわけです。

トランザクション単位で、テーブル間の整合性を維持しつつ、漸次処理を行なっていけば、回復/再開は、 RDBMS のトランザクション機能だけで簡単にできるわけですけどね。

for x in トランザクション単位
  A を処理
  B を処理
  C を処理
  commit/rollback

信じがたいほど馬鹿げた − でも現実にあった − 話。

確か、 P.J. Plauger 氏だったかが、浮動小数点のバグで アリアン・ロケットが爆発した話で、「そのプログラムを書いた人間をロケットに乗せて打ち上げろ」などと、のたまっていたと思いますけど。開発志望の人間に運用をやらせるのは、そういった「含み」があったりするのかも、と思ったり。

---

1. 処理が失敗するとこういうことになるという例。数億円の損害賠償を払ったそうで。

みずほフィナンシャルグループ大規模システム障害 JST失敗知識データベース

http://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623

2. 半ば以上冗談ですけどね。

アルファ線によるLSIエラーの発見 マイコミジャーナル

http://journal.mycom.co.jp/articles/2008/08/22/dsn/

”ユーティリティ・コンピューティング”について思う

冒頭の台詞は単なる例示かもしれないけど、一度真剣に電気や水道などと情報やサービスの違いや共通点を考えてみるべきかなぁ、なんてそんなことを思ったりしている。

"電気や水道のように"って (ナレッジ！？情報共有 … 永遠の課題への挑戦)

"ユーティリティ・コンピューティング"のコンセプトというのは、私の知る限り、もっとも古いものは、 Multics プロジェクトですね。最近、オープンソース化されて話題になりましたけど。

Since it was designed to be a utility, such as electricity and telephone services, it had numerous features to provide high availability and security.

History of Multics (Multics)

ここでは、"電気や電話のように"とありますね。このサイトによると、コンセプトが提出されたのは、1969年のことだとか。Multics は、巨大なタイム・シェアリング・システムを構想していたわけですが。このプロジェクトのアンチ・テーゼとして開発されたのが、 Unix タイム・シェアリング・システムであるのも有名な話ですね。

この後、コンピューティングの歴史はむしろ分散化へと向かっていったわけでして、その極限が、"パーソナル・コンピュータ革命"、コンピュータの個人所有、というものでしょう。それを実現したのが、コンピュータの低価格化であったわけです。どうも、昨今の"ユーティリティ・コンピューティング"の話では、この点が過小に評価されすぎているきらいがありますね。

まあ、つまらない話ではありますが、結局、"設備"の所有形態として、集中か分散か、というのは、コストで決まるのではないでしょうかね。情報システムの所有コストが、発電設備のそれに匹敵するのであれば、より集中へと進むでしょうけど、現にそうではないわけでして。

発電設備が個人で所有できるほど低価格になったことは未だないのではないでしょうか。だからこそ、"分散型電源"というコンセプトが新しいのでしょう。

近年、技術革新や環境問題と相まって、電力を必要とする場所の近くに小型発電機を設置し発電する試みが行われています。この場合、発電機が電力を必要とする場所ごとに分散して設置されるので、ここで使われる発電機は「分散型電源」と呼ばれます。また、この分散型電源を用いてエネルギーを供給するシステムを、「分散型エネルギーシステム」と呼びます。

分散型エネルギーシステム 技術解説 (独立行政法人 新エネルギー・産業技術総合開発機構)

2兆円バラマキ

確か、瀬戸大橋の総工費が1兆円くらいだったよな、と。

塩飽諸島の5つの島の間に架かる6つの橋梁と、それらを結ぶ高架橋により構成されており、橋梁部9,368 m、高架部を含めると13.1kmの延長を持つ。これは鉄道道路併用橋としては世界最長である。橋梁は吊り橋・斜張橋・トラス橋の3種類を併設。総事業費はおよそ1兆1338億円。

瀬戸大橋 Wikipedia

財団つくって、年利１％で運用すると、毎年 200 億円 使えますね。

２兆円はもっとも有効な使い方をして欲しい (５号館のつぶやき )

定額給付金の自主的返納？ (５号館のつぶやき)

日本の政治も末期的な感じですな。