随分前に読み始めたのですが、最初の方のページが面白かった割に後半がつまらなくて途中放置していました。ようやく最後まで読みました。全体として書いてあることは正しいと思いますが、個人的に全面的な同意はできません。

本書のテーマはリスク管理です。主張を一言で言うと「幸運の遺伝子を当てにするな」です。

リスクがあると予測しながら何も準備しないのは罪だと説きます。運良くリスクが発生しなくても罪は変わらないと説きます。

リスクの定義を次のように書いています(後半、少し違う定義がありますが、わかりづらいので引用しません)。

リスクの定義
1. 将来起こりうる出来事で、望まない結果を生むもの
2. 望まない結果そのもの

1.が原因で2.が結果です。リスク管理は原因となるリスクを管理します。

リスクを心配するだけは、リスク管理ではありません。リスク管理とは、リスクを分析(発生確率と起きた場合の被害の大きさを見積もる)し、リスクが発生したことを検知できる仕組み(指標)を作り、リスクが発生した場合の対策を準備しておくことです。

と、言うは易しです。できていると胸を張って言える人がどのぐらいいるでしょうか。ぼくはできていません。ありがちなふたつのアンチパターンが耳に痛いです。

アンチパターン1.

対策を考えられそうなリスクだけを挙げて、対策を思いつけないリスクは無視する

よくあるどころか、自分が行うリスク管理はほぼ常に当てはまっているのでないか、と思うぐらい耳が痛い話です。

でもしょうがない、とも反論したくなります。キーマンが明日死んだら、とか考え出すとキリがありません。どうせどうしようもないなら考えるコストの方がムダだと思います(このような態度こそが本書で徹底的に批判される態度そのものですが)。

もちろん、無視してよいリスクもあると本書は説きます。次のようなリスクです。

1. 実現の確率が無視できるほど小さい
2. 万一実現した場合、現在管理している仕事など、たいしたことではなくなる
3. リスクの影響がきわめて小さく、軽減する必要がない
4. 他人のリスクである

アンチパターン1の派生として「成功のための管理」しかしない、というのがあります。ここでの「成功のための管理」は次のように表現されるものです。

「成功のための管理」
リスク管理はしていないが、いつもリスクに注意し、リスクが発生しないようにしている

リスク管理よりも成功のための管理の方が好ましく思えるのは、後述する前向き思考の文化にいるからかもしれません。起きそうな不幸な出来事があれば、起きないように対策を十分に練り、後は運を天に任せる、というのはいつもの話です。

アンチパターン2.

前向き思考、やればできる文化、挑戦欲

上の用語はプラスな印象を持つ用語ですが、リスク管理には反すると説きます。リスク管理はマイナス思考で、できないかもしれない、失敗するかもしれない、と考えることから始めます。なんとかなる、やればできる、というプラス思考ではありません。このような企業文化を端的に表現したのが次の一文です。

間違えるのはかまわないが、不確かなのはだめだ。

更に言い替えて次のようにも書いてあります。

遅れたことに対して後から「赦し」を請うのはかまわないが、遅れることに対して前もって「許し」を求めてはならない

アリエルもこの文化でしょう。始める前から弱音を吐いても仕方ないからです。やってダメならそれは仕方ありません。このような、やればできる文化がリスク管理をできなくする、と本書は説きます。

一見もっともらしいのですが、総論としては同意できません。幸運の遺伝子を信じている方が幸せです。

「Unixコマンド生活実践」の講義が終わったので、冬休みの宿題を出してみます。

講義資料

• http://dev.ariel-networks.com/articles/workshop/unix-operation/

1. 入力(ファイルなど)から空行を除いた出力をする方法
2. 空白文字(とりあえずスペース文字とタブ文字だけでもよい)だけの行も空行と見なして、空行を除いた出力をする方法
3. あるディレクトリの下の全てのファイルに書かれた Linux の文字列を GNU/Linux に置き換える方法(ただし既存のGNU/Linuxはそのまま)
4. これから行う操作で変更されるファイル一覧を知る方法 (date(1)コマンドで現在時刻を調べるより簡易な方法があります)
5. apacheの標準的なアクセスログから、最もアクセス数が多いリクエストURLを求める方法
6. apacheの標準的なアクセスログから、レスポンスのバイト数の平均を求める方法
7. /etc/passwdファイルに重複ユーザがいないかを確認する方法
8. CSVフォーマットのユーザ名簿の先頭カラムにメールアドレスがある時、/etc/passwdに存在しないユーザを求める方法

おまけ問題

• ls(1)の-fオプションがデフォルト動作ではない理由を考えよ(表示の問題ではなく、ファイルシステムの構造の観点で)

どれも解答はひとつではありません。答えは年明けに(覚えていれば)書きます。自分の解答がベストと主張する気はありません。上のような問題は、1時間考えてベストな解を得るよりも、30秒で適度に解いてしまう方が現場では役に立ちます。

記事を読んで答えを書きたくなった人は、コメントではなく、自分のサイトに答えを書いてください(コメントされると宿題にならないので)。

• http://www.ariel-networks.com/whatsnew/info/news081209.html

社内では以前から周知の事実でしたが、Webサイトでの発表するまでここに書くのを控えていました。

中目黒と遂にお別れです。もう飽きていたので、引越しは良い気分転換です。

新しいオフィスもそうですが、今のオフィスでも、ネットワークのケーブルを床下に這わせています。記憶がないのですが、自分たちでやったようです。這わせた記憶がないぐらいなので、ケーブルがどこをどう這っているのかも当然記憶にありません。ケーブルの色分けなど、もっと計画的にネットワークの配線を行えば良かったはずですが、少なくとも自分自身に限れば、当時、そんな発想はありませんでした。

新しいオフィスでは、ケーブルも色分けして、計画的に配線されるようです。ようです、と言うのは自分は何もせず見ているだけだからです。

上記サイトには、サーバ移設のため一時的なメール配送に支障があるかもしれないと、断り書きがありますが、マスター浜岸の高速イリュージョンによりメール遅延は気づかれないぐらい最小限になる予定です。まあ失敗するとしばらく停止するかもしれませんが。

タイトルではapache2.4と書いてしまいましたが、開発版のapache2.3の最初のリリース(2.3-alpha)の計画がMLに流れただけです。

2.3リリースから安定版の2.4リリースまでどれぐらいかかるかは分かりません。2.1-betaから2.2リリースまで9ヶ月ぐらいかかっているようなので、今回もそんなものかもしれません。

apache2.4はそんなに目をひく新機能は見つかりません。(プログラミング言語)Luaが使える新モジュールが標準で入りましたが、地味です。

experimentalではなく、新しいmpmが入っています。名称はsimpleです。説明文に'poll callback event system'とあるのでこれだけ読んで勘違いしそうですが、(巷で高速をうたうhttpサーバが採用する)いわゆる1スレッド・ノンブロッキングI/Oモデルではありません。モデル的にはいわゆるworker-threadモデルです。ただし、従来のworker mpmとは少しだけ動作が違います。

従来のworker mpmでは、listener threadがソケットをpoll(2)して、accept(2)可能になるとaccept(2)して、TCPセッション確立後のソケットをworker threadに渡します。その後は、worker threadがそのHTTPセッションの面倒を見ます。難点として、クライアントがだらだらとHTTPのやりとりをしたり、keep-aliveでセッションを張りっぱなしでHTTPのやりとりを続けるとworker threadが占有されてしまいます。意図的にHTTPでポーリングしてくるクライアントでない限り、apache側のタイムアウトを適切に設定すればworker threadは解放されますが、worker threadの占有が増えれば、結果的に、さばける同時アクセス数は減ります。

simple mpmでもlistener threadがソケットをpoll(2)して、accept(2)後にTCPセッション確立後のソケットをworker threadに渡すまでは同じです。その後、(正確なタイミングは不明ですが(*))worker threadはソケット監視をlistener threadのpoll(2)に戻して、worker thread自身がスレッドプールに戻ります。理想的に動作すれば、占有されて遊休に近いworker threadが減るので、並行性は上がりそうです。

もっとも机上で考えるほど理想的に動作するかはなんとも言えません。不当にスレッド切替えが頻発してパフォーマンス劣化の可能性もあるからです。

(*)コードを眺めるだけではread、writeをノンブロッキングにしているかも不明です。

会社のアドレス宛のメールを、自宅用ISPのアドレス宛に転送する設定をしています。理由は、家でメールをまとめて読む方が効率が良いからです。

諸般の事情で、最近、自宅のISPを変更したのですが、メールボックスの容量が一杯になるまでぎりぎり一日、という状況になってしまいました。 ISPを選択する時、メールボックスのサイズがここまで問題になるとは思っていませんでした。失敗しました。

改めてISPのサイトを見直すと、メールボックスのサイズは50MBでした。

メール一通の平均サイズは100KBぐらいあります(中央値はここまで大きくありませんが)。これだと、一日のメール受信数が約500通でメールボックスが一杯になります。SPAMメールだけで一日に300通程度はあります(むしろ、ISP変更により少し減った数です)。メーリングリスト宛のメールなどを含めれば、一日の受信メール数は500通に近い数字になります。数MB単位のメールが一定の確率で存在することを考慮すると、メールの平均サイズが100KBというのは低めの見積りかもしれないぐらいです。

運が良くて二日間です。毎日、popでメールを全削除し続けないとメールボックスが一杯になります。

思いつく、技術的な解決策は次の三つです。

1. 転送をやめて、家から複数のpopサーバを参照する
2. 集約する場所を容量の大きいサイト(gmailなど)にする
3. 会社でSPAM判定したメールを転送しないようにする

とりあえず、3.を試してから、解決しないようなら2.かもしれません。メールの読み書きはemacsで行いたいので、gmailにimapでアクセスすることになると思います。メールを読む時は、ざっと目を通して残す価値がなければ消す、という操作の繰り返しです。ストレスの無い速度で動くのかが心配です。

それにしても、SPAMメールがひどすぎます。SPAMメールを送る業者よりも、SPAMメールにいまだにだまされるバカに腹が立ちます。SPAMメールに律義に返信してしまう人は流石に多くないと思いますが、メールの中のリンクをクリックしてしまう人は今でもいるのでしょう。めぐりめぐって、そういう行為がみんなに迷惑をかけている事実に気づいてほしいものです。