ステージング環境のDBは本番環境と同じであるべきでしょうか？

Question

問題

ステージング環境だと動いたのに、本番環境だと動かなかったことがあります
原因としてステージングと本番のDBに差異があることが原因であることがあります

対策

本番環境の個人情報はマスキングして、ステージング環境のDBと日次で同期する
（自動で同期するとテスターが不便なので、同期のタイミングは要相談）

質問したいこと

• 対策として上記がそもそも正しいかどうか
• そもそもステージングと本番環境と同じデータであることが必要か

Answer 1

ステージング環境に何を求めるかによりますけど、本番で実行して検証したいがデータが変更されるとまずいので、別途環境を準備するというのが一番の理由だと思います。
なので、データは極力同じであるべきです。

ステージング環境は、本番環境リリース前に、本番のデータバックアップから都度構築するのがお手軽だと思います。
個人情報に関する制約があるなら、バックアップから構築する手順の中にマスキング処理を含めれば良いですし。

上記の場合、開発や検証環境は別途準備し、そこでの検証を終えているのが前提です。

環境のバリエーションについて考察されている記事がありましたので、紹介しておきます。
ステージング環境とは結局なんなのか。

Answer 2

ステージング環境で本番環境のデータを使うことについて

対策として上記がそもそも正しいかどうか

これは開発・運用体制によって事情がことなるため、
一概に正しいかどうかは判断できませんが、
僕は同様の運用を行っていました

個人情報の扱いに関するセキュリティを心配されていると思います

「本番環境のデータを開発環境で使うべきではない」という話があります

そこで、ステージング環境を本番環境の一部とみなし、
ステージング環境でのテスターを
本番環境を操作する権限を持つメンバーに限定することで
ある程度セキュリティを担保することができます

また、別のサービスにデータをポストしたりしないよう、
他のネットワークとはできる限り隔離して構築します

上記の回答は、自動テストのための環境を別途用意していることが前提です

• 本格的なテストを行っていては、実質的に開発しているのと同様であるため
• 限られたメンバーがさっと問題ないかだけを見るのに使うので、
  ステージング環境でのテスト項目を十分減らす必要があるため
• ステージング環境でのテストの安全性を確保するため

本番環境 →データは本番と同様のものを使用, 本番環境の運用とみなします

• 本番環境
• ステージング環境

開発環境 →データはダミーを使用, 開発作業とみなします

• 自動テスト環境
• ローカル開発環境

そもそもステージングと本番環境と同じデータであることが必要か

リスクとコストの比較によります

発生し得るリスクを分析して、その対策にどこまで投資するべきかを検討します

参考:
発生確率・影響度マトリックスとは何か？PMBOKのリスク分析の手法を解説 | Promapedia
リスクマネジメントとは? | 株式会社日本アルマック

今回の事故の原因のみを防ぎたい場合

同様の事故を再現させるテストデータを自動テストに組み込めば
防ぐことができます

将来起こり得る、想定していない本番環境のデータによる事故すべてを防ぎたい場合

ステージング環境で本番環境のデータを使うのが良さそうです