TV番組でもよく取り上げられる企業。そのブランドのファンも多い。ECサイトの月間PVは1000万ぐらい。秒間アクセス数は10∼1000ぐらい。検索に30秒ぐらい掛かる。購入に1∼3分ぐらい掛かる。TV放送時にシステムダウン。購入しようとした人も諦める。購入時のシステムエラーが毎日数十回。ネストは10段ぐらい余裕。ifとelseで同じ処理を書くとか余裕。複雑度とか200ぐらい余裕。そもそも、ちゃんと作れない。問題を直すと、他の問題を発生させる。–直す過程で壊すことがないように。FindBugsを掛けつつリファクタ。可読性を向上させながら、ソースを理解しよう。300KLもあるクソコード。試験項目の作成中にもエラーが頻発。まともに試験項目が作れない。その間にも、本番システムではエラーが多発。購入時にシステムエラーが起きる。TV放送などでアクセスが集中すると、システムがダウンしてしまう。Elasticsearchを使おう。検索処理が、日常的に遅い。ページによるが、10∼30秒程度。2∼3日に一度の頻度で、極めて遅くなる。システムがダウンする。同一のSQLを1万回ぐらい実行しているという警告が出ていた→数回のSQLで済むよう修正。→改善はしたが、まだ遅い。お客様からのクレームで気づくことも。カード決済など絡んでいるので、色々まずい。購入処理の開始時にロギング。処理の途中、終了時にもロギング。終了していない処理に分類。この日は10件のエラー。発生件数が多いエラーから順に対応する。購入エラー数が半減した。現在は、外部システム要因を除き、ほぼエラーが発生しない。TV放送などで大量アクセスがあると、レスポンスが悪化し、システムがダウンする。TV放送前にはAPサーバの台数を増やしているが、捌ききれない。例のストアドプロシージャが、やはりネックになっている。APサーバごとに、検索処理の同時リクエスト数が一定数を超えたら、503エラーページを表示。APサーバごとに、重いストアドプロシージャの同時実行数を制限。後続の処理は、検索結果のキャッシュを利用。→一定の成果は出たが、根本解決はしない。スケールアウトしても捌けないし。TV放送時にもスケールアウトしないよう決断。(^^;;→レスポンス改善、さらに購入処理の改善にも繋がった。長期的なトラブルシュートにおいてログを可視化するのは、超効果的。現実に起きてる問題が分かる。改善効果が如実に分かる。スケールアウトを間違えると怖い。ClipboardCancelSave。