就在最近，我遇到一位开发人员，他本应该将数据库恢复到暂存副本，却意外地尝试将数据库恢复到生产状态。这很容易做到，因为数据库名称很相似，即 CustomerName_Staging 与 CustomerName_Production。
理想情况下，我会把它们放在完全独立的盒子上，但成本太高，而且严格来说，如果用户连接到错误的盒子，它并不能阻止同样的事情发生。
从本质上来说，这不是一个安全问题 - 正确的用户正在使用临时数据库，如果生产数据库上需要进行工作，那么他也应该这样做。我希望有一个部署官员来分离这些问题，但团队规模不够大。
我很想听听有关如何防止这种情况的实践、配置和控制方面的一些建议。
答案1
如果这是你经常做的事情，那就让它自动化。既然你们都是开发人员，编写一些代码应该是你的拿手好戏。:) 不过说真的……通过自动化，你可以做以下事情：
- 验证您是否在正确的服务器上进行恢复（即没有 dev -> prod 恢复）
- 验证它是否为正确的数据库“类型”（在您的情况下为“暂存”和“生产”）
- 通过查看 msdb 中的备份表来确定要自动恢复哪些备份
等等。你只受你的想象力的限制。
答案2
我不同意问题中的假设——是安全——但我也不同意自动化本身就能解决问题。我先从问题开始：
你不应该能够意外地任何可以投入生产的事情！
其中包括意外地执行自动化操作。
您将系统安全性与“谁可以做什么”等概念混淆了。您的开发帐户应该只能写入其副本、版本控制服务器和开发数据库。如果它们可以读取/写入生产，则可能会被黑客入侵并利用来窃取客户数据，或者（如您所展示的）可能会因处理不当而丢失客户数据。
您需要首先理清您的工作流程。
您的开发者帐户应该能够写入他们自己的副本、版本控制，并可能从版本控制中拉入测试环境。
备份用户应该只能从生产中读取并写入备份存储（应该受到适当保护）。
在生产环境中进行任何其他读/写操作都应该需要特殊的不方便身份验证。您不应该能够悄悄进入或忘记您已登录。物理访问控制在这里很有用。智能卡、翻转开关“启用”帐户、同时旋转双钥匙访问。
访问生产环境不应该是你每天都需要做的事情。大部分工作应该在你的测试平台上进行，并在仔细审查后在非工作时间部署到生产环境。一点不便不会害死你。
自动化是部分的解决方案。
我并不是不知道整个周转过程（上传到 VCS、检查覆盖率、拉到测试服务器、运行自动测试、重新验证、创建备份、从 VCS 拉取）是一个漫长的过程。
那是自动化可以提供帮助，正如 Ben 的回答。有许多不同的脚本语言可以使某些任务的运行变得非常容易。只要确保不要让做蠢事变得太容易。你的重新认证步骤仍然应该明确（如果危险的话）应该很不方便，而且不经过思考就很难做到。
但独自的自动化比无用更糟糕。它只会让你在缺乏思考的情况下犯下更大的错误。
适合各种规模的团队。
我注意到你提到了你的团队规模。我只有一个人，我愿意承担这一切，因为只要有一个人发生事故就行。虽然有开销，但这是值得的。最终你会得到一个更安全、更有保障的开发和生产环境。
答案3
我的一位同事对此有一个有趣的方法。他的生产终端配色方案是丑陋的灰色和粉色，难以辨认，理论上这是为了确保无论他写什么，都是他真正想写的。
您的里程可能会有所不同...而且我可能不必说它本身几乎不是万无一失的。:)
答案4
简短的回答是 RBAC——基于角色的访问控制。
您对所有环境的权限需要有所不同 - 尽管 UAC 之类的东西很烦人，但您仍然需要它们：尤其是对于 PROD 环境。
有绝不开发人员可以直接访问 Prod 的原因 - 无论组织/团队规模有多小。您的“开发人员”可能也戴着“Stage”和“Prod”的帽子，但他需要具有不同的凭据和流程才能进入不同的环境。
这很烦人吗？当然。但它能帮助防止环境变得混乱吗？当然。