»システムはなぜダウンするのかシステムダウン――悪夢のような現場を、幾度も味わったことがある。お詫び行脚、徹夜、徹夜そして徹夜。体は臭いし、もちろんおしっこに行くヒマはない。デスマーチとは違った修羅場で揉まれるうち、別の嗅覚が効くようになる。ソフトウェアの不具合に因るのか、性能や容量不足に起因するのか、設定や操作ミスなのか、ハード故障といった不慮の事故なのか、初動時に嗅ぎ分けられるようになる。「この時期この時間はヤバい、魔の刻だぞ」とか、「あのチームが手を入れた機能がリリースされるから、致命的なやつが起きるならここ」といった、先の先を見越して水面下で準備するようになる。どんなに手を尽くしても、起きるものは起きる。準備をしておけば、被害を最小限に食い止めることができる。そんな中での悩みは、後輩が育たないこと。わたし自身が修羅場で学んできたので、いざ誰かに伝えようにも、伝える「ブツ」がないのだ。トラブル発生時に教えていたら足手まといだし、任せようにも任せられるだけのハード・ソフト・業務知識が伴っていない。システムダウンなんてトラブルはそう頻繁に起こるものでもない(起こらないように予防するのが肝心)。わたしの場合、未経験者には「ホワイトボードキーパー」と密かに呼んでいる仕事を任せている。ホワイトボード前に陣取って、時系列に何でも記録する係だ。することで、発生箇所を切り分ける「判断」や、被害を最小限に食い止めるための「方法」、あるいは関連部署や主要なステークホルダーを把握することができる。ダウン対策は総力戦だ。ネットワークの性能劣化により、隠れていたソフトウェアの不具合が現れたり、何年も前のパラメータ設定ミスが、ある日突然、ソフトウェアの誤動作を招く。何よりもスピードと見極めが肝心な、経験がモノを言う現場。良いレクチャー本がないかと探していたら、ピッタリなものに出会えた。大規模系がメインだが、大量の事例が紹介されており、(遭う遭わないはともかく)運用者は必読だろう。34年早く起きた「2038年問題」。C言語で開発したシステムをUNIX環境で動かしている場合に、2038年1月19日3時14分8秒を過ぎると、システムが正しく時刻を認識できなくなる問題だ。これが2004年1月11日に発生している。23行の銀行でATMが利用できなくなったそうな。34年も早く顕在化したのか?それは、時刻の2倍に足し合わせる処理が入っていたため。1970年と2038年1月19日の半分を超えた、2004年1月11日から桁あふれしていたことになる。分かってしまえばなんでもないが、解析には手間取ったことだろう。DASDのコンデンス(デフラグ)を実施したらダウンしたという事例。ぶっちゃけありえないのだが、あったのだ。過去に不具合が発生し、緊急で対応する必要があり、「本番環境で」修正してしまった経緯があったそうな。本来ならば開発環境で修正→本番環境へリリースという手続きを経るべきなのに、緊急ということで手順を飛ばしたわけ。その際、エイリアスの再設定が漏れ、同一名称のモジュールを新旧で2世代分格納したまま動かしていたそうな。年月を経てコンデンスを実施したところ、旧モジュールの格納位置が変わり、新旧モジュールのどちらもエイリアスとつながっていない不具合が顕在化したという。旧モジュールで動いていたというのも驚きだが、一見無関係の作業が思わぬ事態を引き起こす怖い例として覚えておきたい。プログラミングや運用時だけではない。検討段階で不具合が紛れ込むこともある。システムに要求される性能を見積もる時、「伝票枚数=トランザクション処理件数」としていた例。伝票を1枚作るために、システムを何度も操作しているはずだから、「伝票1枚あたり、何回システムを操作しているか」に着目するべき。誤った見積もりを机上で見つけられない場合、顕在化するのはかなり先、ひょっとすると本番環境という恐ろしいことになるかも。暴いてしまえば、なんてことのない不具合やミスも、現場で見つけるのは難しい。原因から結果をトレースするのは想像つくが、結果から原因を突き止めるのは極めて困難だから。本書では警察の捜査にたとえている。システムダウンは事件の現場で、その原因は犯人のようなもの。犯人の自供をもとにして犯罪の経緯を追いかけるのは後付けで済むが、事件現場に残された状況から犯人にたどり着くのは大変だろう。いわゆるプロファイリングのトレーニングとしても使えるし、「ありえないことがありえる」失敗事例の予行演習として読んでもいい。秒進分歩といわれるコンピュータ、10年後はまるで違ったテクノロジーかもしれないが、人の性は変わらない。同じエラー、同じミスをくりかえすだろう。10年後も使える「現場の基本」を押さえておこう。»コメント年度末の決算も目の前のこのような時期に、このようなスゴタメ本をご紹介いただきありがとうございます。私も元は大手ハードベンダーでフィールドSEをしておりました。DASDの用語の意味がわかる年代です。現在は中規模の基幹システムの運用をやっておりますので、なるべく早めに書店に走り現物を手にとろうと思います。17:05>>ぺーすケさんDASDが分かるなら、新聞雑誌で目にしたり、噂話で耳にしたり、あるいは実際に体験したものばかりでしょう。「ああ、そんなのあったなー」というやつ。そんな「動かないコンピュータ(運用編)」を一冊にまとめたものはコレしかないと思っています。07:02まだ現物は手にとれてないのですが、新聞雑誌で公開されているのをまとめてもらったのはぜひやって欲しかったことであり、著者に感謝します。物足りないということはありませんでしたか。自分からみてこれはないぁとか。私なんかは自分の体験や諸先輩からおそわった話なんて、とても怖くていえたものではありません。近くの事例でも某社が一般消費者向けにシステムメンテをするといっている本当の理由とか、2000年問題で実際はトラブルが起きたけどマスコミには報道されていなかった某社のことなどなど。守秘義務ということもありますが、家族にもこのようなことは話すことなく、お墓にもっていくことになることでしょう。11:23>>ぺーすケさん!!!それは守秘義務云々に限らず、最初から外しておくものかと。仄めかしですら、どのグループか分かってしまうものですから。この業界、広いようで、案外狭いです。お互い、お墓までもって行きましょう。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。