因为我们没有良好的暂存环境，所以我们经常不得不在生产系统上调试问题。我们有网络、应用程序和数据库服务器。
在执行此操作时，您使用了哪些保护措施来避免对生产环境进行意外更改？
该应用程序是一个非常复杂的 B2B 垂直 Web 应用程序。涉及的数据很多。有些表有接近 1 亿条记录。
我们现有的暂存环境不具备镜像生产的能力。除了实际的数据库数据外，还涉及数百 GB 的数据文件。
我们确实对代码使用源代码控制，但对存储过程不使用。源代码控制中有一些旧的存储过程，但没有人再保持更新。
主要关注的是文件系统上的数据库和数据。
顺便说一句，我是这家公司的顾问，而不是实际员工。
最直接的回答是：“不要那样做”。
源头控制。当事情发生不可挽回的错误时，没有什么比回滚更重要的了。此外，差异可以帮助您将更改复制到其他生产系统。
仅允许某些帐户写入访问权限，因此您必须以不同的方式登录才能进行更改
在 web 服务器上，有两个目录结构，相互镜像，一个只有一个 ID 可以写，另一个暂存目录，每个人都可以写。
在数据库服务器上，有一个生产数据库，只有一个 ID 可以写，有一个登台数据库，每个人都可以写。暂存数据库可以将每晚的备份还原到其中。
但是，如果您有错误的查询或暂存系统中的某些资源占用，将从生产中提取资源，并且机器可能会挂起。
只读/访客帐户。严重地。这与您并不总是以 root 或管理员身份登录的原因相同。
新的生产版本通过我们的系统人员进行，程序员和开发人员只能要求使他们的新系统上线，也需要批准，并且我们表明所做的每项更改都已经过测试（通过包括所有在此版本中的生产请求中进行了测试）。
我们保留以前的生产版本以备后备以防出现问题。
如果事情确实发生了故障（他们不应该经常使用适当的测试程序和托管版本），那么我们可以回滚或修补程序。通常当事情在现场被破坏并且修复很小时，我们可以修复，然后将修复移动到测试以进行适当的测试。
无论如何，有时事情会过去...
对于 Web 和应用程序服务器，我会尝试将环境复制到新位置（但在同一环境中），并让受影响的人在副本上重现行为。这至少可以让你在一定程度上避免与 100% 的客户不小心搞砸。
对于数据库服务器，我会在生产系统上配置用户帐户以赋予他们只读权限。
这是一件很难的事情，而且符合“无分期环境”的范畴。
出于多种原因，最好有一个专用的（复制的）PROD，您可以使用它来分阶段部署到...并进行调试，但我知道有时当您刚开始时，它不会很快或彻底如我们所愿。
我见过的一件事是使用 VM：除了调试环境之外，您还可以在 VM 中创建一个 mini-PROD 并使用它进行调试。考虑到您正在开发的应用程序类型，这可能不切实际，因此该领域的其他详细信息会有所帮助。
至于在调试期间避免更改 PROD：是否有理由需要更改任何内容以促进调试？如果是这样，那可能值得考虑以另一种方式解决。
版本控制对于控制对生产环境的更改非常有帮助 - 只需使您的生产环境成为存储库中相应目录或目录的工作副本。当您推出更新时，您的源代码控制系统会确保复制所有更改的文件。当更新破坏了某些东西时，您可以将生产工作副本回滚到未破坏的上一个修订版。此外，您可以从标签而不是行李箱中检查您的生产 WC；这样，您可以通过调整标签来决定将哪些存储库修订应用于生产环境。
如果你不熟悉版本控制系统的概念，我建议你做一些研究。它们在概念上很复杂，但非常有用和强大。维基百科文章是一个很好的起点： http ://en.wikipedia.org/wiki/Revision_control
对不起，你必须有一个登台环境。没有办法解决这个问题。如果这意味着您必须剔除数据集的大小，那么这就是您必须做的。如果您有生产系统，请在停机期间使用 VMware 和 VMware 转换器导入生产系统（这是一个耗时的过程，因此可能不实用）。
如果没有对生产数据库（或副本）的完全访问权限，您将无法解决某些类别的问题，性能就是其中之一。但是你真的应该建立一个登台环境，即使它是在某人的桌面机器上，并且有一个精简的数据集。
除此之外，我过去不得不和其中一些一起生活，而且真的，除了大量备份之外，你无能为力。您所做的每项更改都应先进行增量备份。这样一来，如果您对某些东西进行 fubar'd 操作，您损失的金额并不大。SQL Server 可以进行差异备份，从而限制用于备份的磁盘空间量。甲骨文也可以。
万一你真的别无选择，而且很可能是一种慢性情况……考虑在应用程序数据（文件或数据库）中添加一些方法来将一组数据标记为“请上帝不要真正主动更改”使用此数据的生产状态，结合激活此标志时流程中关键位置的数据转储，您可以在没有实际操作数据的情况下执行大部分生产逻辑。