本番データベースで開発してはいけないのはなぜですか？
実動データに対して開発することがなぜ真面目であるのかについての私の議論を整理する手助けが必要です。
Backstory： 6か月前にここで作業を開始し、実稼働データに対して直接開発していることに気付きました。コードベースはローカルですが、接続しているデータベースはライブデータです！だから私は何も壊さないように更新/保存操作を行うときは常に細心の注意を払わなければなりません。
近い将来、年次ソフトウェア会議が開かれ、懸念を表明したいと思いますが、議論が山積していますが、このことから明らかなはずのことについて、十分な根拠を示すのは非常に困難です。それは、なぜ私が呼吸する必要があるのかについての議論を思いつくように彼らに頼むようなものです。
私の質問：本番データベースで直接開発しない場合の引数はありますか？
開発者として効率的に作業できないだけです。
このSQLクエリは、指定された条件のすべてのステータスを更新しますか？
これで、テーブルのステータスフィールドが更新されました。
このSQLクエリはバージョンXからYに更新しますか？
これでデータベースが変更されました。許可された値0 ... 3のステータスフィールドが0 ... 5に更新され、新しい値が挿入された場合はどうなりますか？テーブルからフィールドを削除する必要がある場合はどうなりますか？
「コードがパスワードの変更を認識しているかどうかを確認しましょう」
DBのパスワードを変更しました。
「これからはすべてのデータベースパスワードをソルトするつもりでした」
DB内のすべてのパスワードを変更しました。おっとっと。
「このクライアントのレコードを削除してみましょう。」 SQLのwhere句が正しくありませんでした。
これらすべての例で、反論を思い付く可能性があります（「架空のクライアントを使用してテストする」、「トランザクションで作業をラップする」、「誰も使用していない真夜中から1時の間にそれを行うことができますデータベース "）しかし、それらはすべて余分な作業になりますおよびこれらはすべて事故に対する予防策です（時々失敗します）
あなたの質問であなたがそれを言い表す方法は正しいです：それは本番データベースに対して開発することはマッドネスです。遅かれ早かれあなたの会社は手に負えなくなるでしょう。あなたが知らない過去の事件はすでにあったと思います。
いくつかの理由があります。
最初の理由はリスクです。実際の顧客の電子メールアドレスを使用してシステムで作業している場合、電子メールを送信することになるリスクがあります（たとえどれだけ小さい場合でも）-同じロジックをテキストに適用できます/銀行の詳細など。このデータがない場合、開発サイトへのアクセスに対して誤ってメンバーに請求することはできません。
2番目（おそらくマイナー）は、現在使用しているシステムを認識する機能です。複数のバージョンのソフトウェア（live/dev）を開いており、それらが同じデータで実行されている場合、どのバージョンがどれであるかをどのようにして知ることができますか？開発者が意図した実際のシステムで誤ってアクションを実行してしまう可能性があります。
3番目の理由は最も重要です。あなたの会社には、クライアントの個人情報を保護する法的義務があります。ライブデータベースには、メンバーの名前、住所、連絡先情報、銀行の詳細が含まれる場合があります。これは最大限のセキュリティで処理する必要があります。それを開発者のマシンの上に置いたままにしておくのは安全です（私はラップトップと言ってもいいですか！？）あなたのオフィスが盗まれた場合はどうなりますか？バックアップはすべて安全に保管されていますか？機械を廃棄するとどうなりますか？
ライブシステムは、冗長性のためだけでなく、アクセスが制限されているために高価です。ホスティング施設に侵入するのは、オフィスよりもはるかに困難です。許可されていない人物がこの情報にアクセスしたというビジネスの評判に大きな打撃を与えたと想像してください。
顧客の個人情報は、最も機密性の高い情報の一部です。デスクトップマシンにあるべきではありません。
TL; DR：他の人にスタンスを変えるよう説得したい場合は、の利点を考慮してください。
開発中の本番データでの作業には、多くの欠点があります。
- Privacy：開発者への不要なデータの漏洩。ただし、devopsの動きを考えると、システム管理者でもあるため、これは避けられない場合があります。多くの場合、開発者の数が限られている限り、人々は気にしません。
- Security：本番データベースに接続することは、ハッキングされた開発者のマシンが非常に些細なことに本当に厄介なことを実行できることを意味します。ハックには攻撃ターゲットが必要であり、信頼性の低いミートバッグの1つを担当する完全にロードされたワークステーションは、多くの表面積を追加します。開発者がソース管理にアクセスできるのは十分に悪いことです。しかし、それを悪用するにはスクリプトキディ以上のものが必要であり、コードを介して侵入を隠すことは必ずしも容易ではありません。対照的に、サーバーにアクセスできるだけの場合は、自動化されたハッキングツールでもサーバーを制御できる可能性が高くなります。
- 信頼性：ライブデータでの作業は、次の2つの理由で悪いです。1つ目は、（トリッキーな限られたシナリオ以外で）データの変更を試すことができないため、開発者がコードを十分にテストできないそれを終えます。次に、バグはあなたが持っている最も重要なデータのビットに大規模な変更を加えることができるため、壊滅的な結果をもたらす可能性があります。
これらの3つの欠点には、ノックオン効果があります。リスクが高いため、作業にはより多くの時間と注意が必要であり、開発のコストが増加します。保護する必要のあるこれらの「特権」マシンが突然あるため、ネットワークにはより洗練されたファイアウォールとルーティングが必要な場合があります。すべての臨時雇用者に王国への鍵を与えることができないため、外部支援は少しトリッキーです。
しかしながら...
ライブデータベースでの作業のさまざまな欠点はかなり明白です。職場の人々は、たとえ本番データに集中していなくても、本番データでの作業には注意が必要であり、費用がかかることを確信しています。あなたは危険を明確にして強調するかもしれません、そしてそれはあなたを助けるかもしれません-しかしあなたはおそらく彼らに特に新しいことを何も言わないので、訴訟を起こすのを難しくします。あなたがしている特定のビジネスにとってのマイナス面が現実的なリスクである方法を具体化したいと思うかもしれません。
ただし、この議論に本当に勝ちたい場合は、少なくとも本番データで作業することの利点に重点を置く必要があります。あなたは彼らがなぜこれをするのか、明言されていない腸の感情さえも理解する必要があるでしょう。要するに：私の本当の答えは、あなたが間違った質問をしていると思います:-)。
理由を理解したら、代替案で十分である理由を説明できます。
私はあなたの職場を知りませんが、私は暗闇の中で野生の刺し傷を取ることができます：
- Spagetti data-code：コードはデータによって異なります。例えば。会計期間のようなものはsqlテーブルの行で、有効な会計期間がない場合（および有効なユーザー、有効な販売アイテム、有効な営業担当者など）、請求書を追加できません。これは現在開発中のものです。常に運用データを操作してきた場合は、モックデータが満たす必要のある複雑な相互関係の制約が存在する可能性があるため、かなり現実的なデータベースなしでコードを実行することも簡単ではありません。
- 模擬データは代表的ではありません：問題ドメインが大きく複雑な場合、模擬データは実際のデータを何らかの形で代表していない可能性があります。これは、重要なシナリオでコードを少なくテストできることを意味します。たとえば、レガシーまたは法的枠組みの変更により、または現在解決できない古いバグが原因で、例外的な会計期間が重複する場合があります。事態が複雑になると、これらすべてのコーナーケースがモックデータに含まれる可能性は低くなります。
- モックデータは高価です：モックデータの作成は、乗り越えられないタスクになる可能性があります（またはそのように見えます）。データモデルが十分に複雑である場合は、モックデータの作成に多くの時間を費やす必要があり、コードが進化しても、モックデータを維持および更新する必要があります。あなたはさらに多くのメンテナンス義務にサインアップしました。
- 保守的な考え方：開発プラクティスの変更は危険です。それが今うまくいくなら、なぜ変化を起こして事態を悪化させるリスクがあるのでしょうか？おそらくあなたが考えていなかったわずかな違いが何十とあるでしょう、そしてそれらのどれでも私たちにビジネスのコストをかけるかもしれません。実績のあるレシピを使います。
- 学習曲線：新しい方法の方が優れていても、投資する価値はありません（ITには常に何か新しいものがあるので、他にもっと価値のある改善を最初に行うのはなぜですか？）
理由はもっとあると思いますが、繰り返しになりますが、あなたのチームはわかりません。あなたが彼らの考えを変えたいなら、あなたは現状が持っていると彼らが考えるどんな利点も考慮し、新しい方法が（ずっと）悪くないことを説得力をもって証明する必要があるでしょう。
だから私は何も壊さないように更新/保存操作を行うときは常に細心の注意を払わなければなりません。
細心の注意を払わずに間違いを犯した場合はどうなりますか？
本番データの破壊/損失の可能性を排除する場合でも（たとえば、毎日のバックアップから作成されたコピーで作業することによって）、機密データを保護するという問題もあります。開発者は本当にそれにアクセスする必要がありますか？これが例えば医療データである場合、これは違法であるかもしれません。
あなたが非常に注意深くても、誰もが時々弱い瞬間を持っています。かつては本番データベースに対しても開発を行っていましたが、長い一日の終わりに、ユーザーテーブルの更新クエリで非常にシンプルなものを変更する必要がありましたが、where id = '$id'部分。したがって、すべてのユーザーが私のデータを自分のデータとして持っていました。幸い、最近のバックアップがありましたが、ほとんどの場合、何も問題がなくても、それはあなたがしたくない間違いです。 DB全体を停止するのに必要なのはoneミスだけです。
たとえあなたが細心の注意を払っていても、誰もが間違いを犯します。開発（およびテスト）するための最良の方法は、偽のデータで満たされたDB構造のコピーです。
- 人々は間違いを犯します。わずかな間違いが1つだけあり、会社のデータベースを破壊しました。これは、アプリケーションがデータベースをクエリするだけでなく、データベースを変更する場合に特に当てはまります。
- コーナーケースをテストする必要があります。それが顧客データベースである場合、ミドルネームを持たない顧客、アクセント付き文字または句読点を名前に含む顧客、電話番号を持たない顧客、海外住所を持つ顧客などを処理できますか？これをテストする唯一の方法は、そのような顧客をデータベースに追加することです。しかし、マーケティング部門が会社のすべての既存の顧客にメールショットを送信することを決定した場合はどうなりますか？
ライブシステムは高可用性であるはずですか？あなたの状況では、可用性は開発中のバグや人的エラーによって簡単に損なわれる可能性があります。
過去に問題がありましたか？ 優先順位は、多くの場合、人々を納得させる簡単な方法です。
会社はこのデータを保護することを法的に義務付けられています？開発者はすべてのデータをエクスポートして販売するか、または競合に送信できます。
私は、開発者の生産性の議論があなたをここまで遠くに連れて行く可能性は低いと思います。明らかに、これは開発者にとって問題であると誰も考えていません。私は、HAや法的義務などのビジネス目標について議論したいと思います。これらは経営陣が理解できる用語です。