テストデータに気をつけなはれ

#miscellaneous

うっかり本番環境にテストデータがひょっこり出ちゃいかねないので、普段からふざけたデータは作らないようにしましょうってのは よくある注意なんですが、あと、マジメにやっていてもダメなものがあるのでその話。

メールアドレスのドメインに気をつけて

ユーザー情報を取り扱うなら、大体メールアドレスが必須項目にあると思います。どんなメールアドレスをつけますか? 万が一メール送信機能が動いてしまっても特にメールが到達することのない、.test とか、 example.com はマシですが、 これと同じようなノリで test.com をつけるのはダメです。別に利用できないものとして予約されているドメインではないです。うっかりやりそうですけど。

今のところは test.com には MX レコードが登録されていないようで、別にメールが到達したりしないのですが、今後このドメインの所有者が Catch-All でもして、 あらゆるシステムでテスト送信されたメールを収集し出すなんてことも否定はできないので…。

バウンス

.test とか example.com なら、うっかりメール送信機能が働いてしまっても、到達しないのですが、最近のメール送信サービスは、 バウンス率が高くなるとメール送信機能に制限がかけられる認識です。

何かの拍子に登録ユーザーに一斉メール送信がされたりした時、あまりに大量に .test やら example.com がいると、制限対象になるのでは?という懸念があります。 こういうことを考えると、テストユーザーを作ったりするためのドメインを1つ用意して、その ドメインの Catch-All をメールサーバー側で設定して、 いかなるアドレスであってもバウンスしないようにするのが一番の安全策?メール送信サービス側のサンドボックス機能とか使って「実際にはメールが送信されることがない」を担保できるなら良いです。

開発環境は自分たちしか使わないと思った?

今までの経験の中で、「開発中の機能でデモがしたい」という話が営業から上がってきたことがあります。 まあ、開発中にフィードバックいただけたらそれはそれで嬉しいですし、受注に至るポイントになれば嬉しいことですので、やっていただこうと思ったのですが、 開発中機能だったので、開発環境にしかなく、そしてそこにあるデータはとてもとても荒れ放題でした。

営業で使いそうなとこだけ慌ててDBをいじって綺麗にしましたが、中々苦しい作業でした。 普段からそれっぽいデータを作った方がいいですよ…本当に…

だいたい起きてほしくないことが起きる

何が起きるかわからないので、できる限り安全にしておきましょうね。

以上!

コメント

コメントを読み込み中...

コメントを投稿