航空券予約システムをダウンさせたバグの経験から始まります。
極論を言うと、この種のバグがひとつ残らず消滅するなんて夢物語にすぎない。 バグは発生する。消えてくれないなら共存するしかない。 [...] この例で最悪だったのは、ひとつのシステムのバグが全システムに伝播して影響したことだ。答えるべき問いは、「ひとつのシステムのバグが他に影響するのをどうやって防ぐか?」である。 (p.21)
バグの影響を伝播させないシステムの作り方、というのが、この本の「本番用システム」のあるべき姿です。その中からいくつかピックアップ。
本番と同じサイズのデータセットでないと、クエリで数百万行が返っ てきて、それをオブジェクトに変換するときに何か起きるか確かめることかできない。本番と同じサイズのテストデータを使えば、パフォーマンステストでより良い情報が得られるという副次的な効果もある。 (p.93)
ダミーでいいから量をある程度用意するのはよいことだと思う。いまやっているプロジェクトでは、想定ユーザ数と平均的なユーザの典型的な行動パターン（つまり各URLのアクセス頻度）のシナリオを用意してもらえた。まだ調整中なのだけれど、どこがボトルネックになっているのか分かるし、優先順位も明らかになっている。
待たせた結果がエラーメッセージであってはならないし、相手のタイムアウトまで待たせてもいけない。それでは、こちらの問題を呼び出し側に転嫁するだけだ。 (p.116)
フェイルファストっていうのは、なんか努力せずに諦めたみたいな感じがするんだけど、応答が遅い状態が長く続くくらいなら、さっさとフェイルして、アラートメールを出したほうがいい。どうせアラートメール出すハメになるのだから。
開発プロジェクトか大忙しのときに、こうした設計についてのトピックを意識するのは難しいかもしれない。[...] そんなあなたにいいニュースかある。これらの問題を開発中に取り上げるのは断念してもいい。ただし、これは悪いニュースでもある。開発中に収り上げないなら、 本番で取り組むことになるだろう。 (p.235)
開発開始段階ですべての機能/非機能要件が決定されていない（つまりほとんどの）場合、最適な設計も最初に決定できないということになる。少し設計して、作って、また設計して、の繰り返しになるので、設計コストは増加する。そのかわり不適切な設計のままつっぱしって、システムがダウンするリスクを避けられる。
今やっている案件でできていることは続けたいし、できていないことは今後やっていきたいものです。
