どうも上村です。

今年もQiitaで、色々なジャンルのアドベントカレンダーをやってましたね。
私は「本番環境でやらかしちゃった人 Advent Calendar」が好きで毎年読んでます。

笑って読んでるだけじゃなくて、教訓にもしないとけません。

 

 

ということで（！？）

若き日にやった私の本番やらかを１つ紹介します。

 

・・・

新機能を追加するよ
ということで設計～リリースまでを担当し、リリースが終わった翌日に惨劇が起きてました。

朝出勤すると「上村君アラートメール凄いけど大丈夫？」・・・

 

 

眩暈がするほどの大量のアラートメールを受信している。

内容は「バッチの処理が終わってない」というもの。・・・orz

 

・・・何がダメだったかというと？

バッチは新規実装で深夜に動くやつなんですが、何百億レコードとあるテーブルを参照する為、検索条件に使うカラムに新規インデックスを追加しないといけなかったんですけど漏れてました。
その結果、検索処理が長時間（確か7時間くらい）終わらなくて、ヤバイよヤバいよ！となっていた。
実はその新規部分の業務、莫大なレコードが毎日INSERTされることを失念し･･･どのフェースでもその莫大なレコードを用意できていなかったので発見できず。

 

このあとクソほど怒られまして･･･（当たり前）

色々と大変でした。

その後、再設計を行い無事にリリースされました。

 

・・・設計時のレビューで発見できなかったの？
って思いますよね。だけどアジャイルでリーダーも沢山案件を持っていたので、開発する側でもっと丁寧にやらないといけなかったなという反省。

・本番コピー環境を用意することは重要
・設計する際は業務をちゃんと調べて行うこと
・カラムへのインデックス追加による影響も考慮すること

これらを失敗から学びました。

今でこそ色々できるのは、失敗から学んだのがでかいな･･･とシミジミ

～最後に～

本番で失敗しないことは重要ですが、その前の開発中には沢山失敗して良いと思います。

最近は失敗を恐れて縮こまったコーディングなんかをよく見ます。
「影響範囲が～」とか「怖いので・・・」みたいなのを見かけるんですけど･･･

調べてダイナミックにリファクタしちゃう、とか失敗しても良いからそれくらいのほうが個人的には好きと言うか良いと思います。
プログラミングだけでいうと色々とプロダクトのコードを見て、良くない箇所を見て直し方等の設計思想やコーディング力を身に着けられるためです。
※もちろんスケジュールとの相談ですけど

失敗を恐れては行動できないので、そういう傾向がある人は今一度考えてみてください。

来年もよろしくお願いいたします。