システムはなぜダウンするのか

　システムダウン――悪夢のような現場を、幾度も味わったことがある。

　鳴りつづける電話、飛び交う怒号、性能劣化、DB汚染、運用規制、緊急リリース、システム再起動、復旧、パッチ当て、究明・対策・謝罪文、お詫び行脚、徹夜、徹夜そして徹夜。体は臭いし、もちろんおしっこに行くヒマはない。

　デスマーチとは違った修羅場で揉まれるうち、別の嗅覚が効くようになる。ソフトウェアの不具合に因るのか、性能や容量不足に起因するのか、設定や操作ミスなのか、ハード故障といった不慮の事故なのか、初動時に嗅ぎ分けられるようになる。

　さらに、「この時期この時間はヤバい、魔の刻だぞ」とか、「あのチームが手を入れた機能がリリースされるから、致命的なやつが起きるならここ」といった、先の先を見越して水面下で準備するようになる。どんなに手を尽くしても、起きるものは起きる。けれども、きっちり準備をしておけば、被害を最小限に食い止めることができる。

　そんな中での悩みは、後輩が育たないこと。わたし自身が修羅場で学んできたので、いざ誰かに伝えようにも、伝える「ブツ」がないのだ。トラブル発生時に教えていたら足手まといだし、任せようにも任せられるだけのハード・ソフト・業務知識が伴っていない。しかもシステムダウンなんてトラブルはそう頻繁に起こるものでもない（起こらないように予防するのが肝心）。

　わたしの場合、未経験者には「ホワイトボードキーパー」と密かに呼んでいる仕事を任せている。ホワイトボード前に陣取って、時系列に何でも記録する係だ。発生事象と対処、関連部署との連絡、解析状況、復旧状況、後処理、影響調査を、ただひたすらに書きまくる。

　そうすることで、発生箇所を切り分ける「判断」や、被害を最小限に食い止めるための「方法」、あるいは関連部署や主要なステークホルダーを把握することができる。ダウン対策は総力戦だ。ネットワークの性能劣化により、隠れていたソフトウェアの不具合が現れたり、何年も前のパラメータ設定ミスが、ある日突然、ソフトウェアの誤動作を招く。何よりもスピードと見極めが肝心な、経験がモノを言う現場。

　なんぞ良いレクチャー本がないかと探していたら、ピッタリなものに出会えた。大規模系がメインだが、大量の事例が紹介されており、（遭う遭わないはともかく）運用者は必読だろう。

　たとえば、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年後も使える「現場の基本」を押さえておこう。