blocks|key|887487|text|最直接的回答是：“不要那样做。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887488|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The most direct answer is: "Don't do that."

blocks|key|4105761|text|源代码控制。当事情变得不可挽回时，没有什么比回滚更好的了。另外，diff可以帮助您将更改复制到其他生产系统。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4105762|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

source control. nothing like a rollback when things to irreparably wrong. Also, a diff can help you replicate the changes to other production systems.

blocks|key|6927|text|仅允许某些帐户具有写访问权限，因此您必须以不同方式登录才能进行更改|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6928|在web服务器上，有两个相互镜像的目录结构，一个只有一个ID可以写入，另一个暂存目录，每个人都可以写入。|6929|在数据库服务器上，有一个生产数据库，其中只有一个ID可以写入，还有一个登台数据库，每个人都可以写入。分段数据库可以将夜间备份还原到该数据库。|6930|但是，如果您有一个错误的查询或您的临时系统中的一些资源占用，资源将从生产中拉出，机器可能会挂起。|6931|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

only allow certain accounts write access, so you have to log in differently to make a change

on web server, have two directory structures, that mirror each other, one where only one ID can write, the other staging dir, everyone can write.

on database server, have one production db, where only one ID can write, have a staging db where everyone can write. the staging DB can have nightly backup restored to it.

HOWEVER, if you have a bad query or some resource hog in your staging system resources will be pulled from production, and the machine could hang.

blocks|key|887622|text|只读/来宾帐户。我是认真的。这与您不总是以root或管理员身份登录的原因相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887623|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Read-Only/Guest accounts. Seriously. It's the same reason you don't always login as root or Administrator.

blocks|key|4105946|text|新的生产版本通过我们的系统人员，程序员和开发人员只能请求让他们的新系统上线，也需要批准，并且我们表明所做的每个更改都经过了测试(通过在生产请求中包含在此版本中测试的所有快照)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4105947|我们保留以前的生产版本，以防出现问题。|4105948|如果东西确实坏了(通过适当的测试程序和托管版本，他们不应该经常这样做)，那么我们可以回滚，或者热修复。通常情况下，当事情在生活中被破坏，并且修复很小时，我们可以热修复，然后将修复移动到测试以进行适当的测试。|4105949|不管怎样，有时候事情会过去的..。|4105950|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

New production releases go via our systems guys, the programmers and developers can only request to make their new system go live, approval is needed as well, and we show that each change that has been made has been tested (by including a snapshot of all that was tested in this release in the production request).

We keep the previous production releases for fallback in case of issues.

If things do break (which they shouldn't do often with a proper testing procedure and managed releases) then we can either roll back, or hotfix. Often when things are broken in live and the fix is small, we can hotfix, then move the fix to test to do a proper test.

Regardless, sometimes things get by...

blocks|key|887791|text|对于Web和应用程序服务器，我会尝试将环境复制到新的位置(但在相同的环境中)，并让受影响的人员在副本上复制行为。这至少会让你和100%25的客户保持一定程度的隔离。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887792|对于数据库服务器，我将在生产系统上配置用户帐户，使其具有只读权限。|887793|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For Web and Application Servers, I would try to copy the environment to a new location (but on the same environment) and have the affected people reproduce behavior on the copy. This will at least give you a level of separation from accidentally screwing with 100% of your clients.

For Database Servers, I would configure user accounts on the production system to give them read only rights.

blocks|key|4106018|text|这是一件很困难的事情，它符合“无暂存环境”的范围。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4106019|出于许多原因，最好有一个专用的(复制的)+PROD，您可以使用它来部署to...and以进行调试，但我知道有时当您刚开始时，它不会像我们希望的那样快速或彻底地工作。|4106020|我见过的一件事是VM的使用:除了调试环境之外，您还可以在VM中创建一个mini-PROD并使用它进行调试。考虑到您正在开发的应用程序的类型，这可能并不实用，因此在该领域的其他详细信息将是有帮助的。|4106021|至于在调试过程中避免对PROD进行更改:有没有理由需要更改某些内容以便于调试？如果是这样的话，这可能值得寻找另一种解决方法。|4106022|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is a tough thing, and it goes with the territory of "no staging environment."

For many reasons, it's best to have a dedicated (duplicate) of PROD you can use to stage deploys to...and to debug on, but I know that sometimes when you're starting out that doesn't work out as quickly or thoroughly as we'd want.

One thing I've seen work is the use of VMs: aside from the debug environment, you can create a mini-PROD in a VM and use that to debug. This may not be practical given the type of app you're developing, so additional detail in that area would be helpful.

As for avoiding changes to PROD during debugging: is there a reason you'd need to change anything to facilitate debugging? If so, that might be worth looking into solving another way.

blocks|key|887846|text|版本控制对于控制对生产环境的更改非常有帮助-只需使您的生产环境成为存储库中适当目录的工作副本即可。当您推出更新时，您的源代码控制系统会确保复制所有更改的文件。当更新破坏了某些内容时，您可以将生产工作副本回滚到未被破坏的最后一个修订。此外，您还可以从标记中签出生产WC，而不是从主干中签出；这样，您就可以通过调整标记来决定将哪些存储库修订应用于生产环境。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|887847|如果您不熟悉版本控制系统的概念，我建议您做一些研究。它们在概念上很复杂，但却非常有用和强大。维基百科的文章是一个很好的起点：http://en.wikipedia.org/wiki/Revision_control|offset|length|887848|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Revision_control^0|0|1Q|19|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Version control is immensely helpful for controlling changes to production environments - just make your production environment a working copy of the appropriate directory or directories from the repository. When you roll out an update, your source control system makes sure that ALL the changed files get copied. When an update breaks something, you can roll the production working copy back to the last revision which wasn't broken. Also, you can check your production WC out from a tag instead of from the trunk; that way you can decide which repository revisions to apply to the production environment by adjusting the tag.

If you're not familiar with the concepts of version control systems, I'd advise you to do some research. They're conceptually complex but incredibly useful and powerful. The Wikipedia article is a good place to start:
<a href="http://en.wikipedia.org/wiki/Revision_control" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Revision_control</a>

blocks|key|4106152|text|我很抱歉，你必须有一个临时的环境。这是绕不开的。如果这意味着你必须剔除数据集的大小，那么这就是你必须要做的。在停机期间使用VMware和VMware转换器导入生产系统(这是一个长达数小时的过程，因此可能不切实际)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4106153|在没有完全访问生产数据库(或副本)的情况下，有一类问题是无法解决的，性能就是其中之一。但你真的应该构建一个登台环境，即使它是在某人的台式机上使用精简的数据集。|4106154|抛开这一点不谈，我的生活中曾经有过一些这样的东西，真的，除了大量的备份，你什么也做不了。您所做的每一项更改都应该在增量备份之前进行。这样的话，如果你用了什么东西，你损失的数量并不是很多。SQL+server可以执行差异备份，从而限制用于备份的磁盘空间量。甲骨文也可以。|4106155|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I'm sorry, you have to have a staging environment. There's no getting around this. If it means you have to cull the size of your datasets, then that's what you have to do. Use VMware and VMware converter to import the production systems during down-periods, if you have them (this is a many-hour process, so maybe not practical). 

There are a certain class of problems you can't solve without having full access to production DBs (or a copy), performance is one of these. But you really should build a staging environment, even if it's on someone's desktop machine with a stripped down dataset.

That aside, I've had to live my life with a few of these in the past, and really, there's nothing you can do except lots of backups. Every change you make should be preceded by incremental backups. That way if you fubar'd something, the amount you've lost is not substantial. SQL server can take differential backups that limit amount of diskspace used for backups. Oracle can as well.

blocks|key|6982|text|以防你真的别无选择，这很可能是一个长期的情况...考虑向应用程序数据(文件或数据库)添加一些方法，以将一组数据标记为“请上帝不要用这些数据主动更改生产状态”，再加上进程中关键位置的数据转储。当此标记被激活时，您可能能够执行大部分生产逻辑，而无需实际操作数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6983|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In case you really have no other choice, and it is likely to be a chronic situation... consider adding some way to the application data (files, or database) to flag a set of data as 'please god do not actually actively change production state with this data', combined with data dumps at critical positions in a process when this flag is activated, you may be able to exercise most of the production logic without the data actually being acted upon.

Because we don't have a good staging environment we often have to debug issues on our production systems. We have web, application, and database servers.
What kind of safeguards do you use to avoid accidentally making unintended changes to your production environment when doing this?
<hr />
<h3>EDIT:</h3>
The application is a very complex B2B vertical web application. There is a lot of data involved. Some tables have close to 100 million records.
<hr />
<h3>EDIT:</h3>
The staging environment we have in place does not have the capacity to mirror production. There are also hundreds of gigabytes of data files involved besides the actual database data.
<hr />
<h3>EDIT:</h3>
We do use source control for the code but not for the stored procedures. There are some old stored procedures in source control but nobody keeps that updated anymore.
The main concerns are the database and data on the file system.
BTW, I am a consultant at this company, not an actual employee.

What kind of safeguards do you use to avoid accidentally making unintended changes to your production environment?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

因为我们没有一个好的登台环境，所以我们经常不得不在生产系统上调试问题。我们有web、应用程序和数据库服务器。在执行此操作时，您会使用哪种保护措施来避免意外更改生产环境？编辑：该应用程序是一个非常复杂的B2B垂直web应用程序。这涉及到大量的数据。有些表有近1亿条记录。编辑：我们现有的转移环境没有镜像生产的能力。除了实际的数据库数据外，还涉及数百of的数据文件。编辑：我们对代码使用源代码控制，但不对

问您使用了哪种保护措施来避免意外地更改生产环境？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您使用了哪种保护措施来避免意外地更改生产环境？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问您使用了哪种保护措施来避免意外地更改生产环境？
EN