将测试环境和生产环境放在同一台机器上是不是很糟糕？
设置 MySite.com 为生产环境而 test.MySite.com 为测试环境会不会很糟糕？两者都在同一台机器上运行。该网站没有获得大量流量。
更新
我正在讨论在 Windows 服务器上运行的 ASP.NET Web 应用程序。
Would it be bad to have things set up so that MySite.com is production and test.MySite.com is test? Both running off the same machine. The site doesn't get a lot of traffic.
UPDATE
I am talking about an ASP.NET web application running on a Windows server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
理论上是的。开发时，有很多事情可能会出错，就像 @Oded 提到的那样。通过使用专用的网络服务器运行您的主站点，您可以避免重复数据库、虚拟主机等的复杂性。不过，您当然可以公开
test.mysite.com。作为客户，我通常做的第一件事就是访问公司的网站。如果该网站无法访问，即使是短暂的，也会显得不专业，我很快就会失去兴趣。您不想因为太便宜而无法购买一台额外的计算机而失去业务！
编辑：从您上面的评论中我看到这确实是一个业务服务器。答案已更新。
In theory, yes. When developing, there are a lot of things that could go awry, like @Oded mentioned. By having a dedicated webserver run your main site, you avoid the complexity of having duplicated databases, virtual hosts, etc. You could certainly make
test.mysite.compublicly available, though.As a customer, often times, the first thing I do is visit a company's website. If the site is inaccessible, even briefly, it looks unprofessional and I quickly lose interest. You do not want to lose business because you were too cheap to buy one extra computer!
Edit: I see from your comments above that this is indeed a business server. Answer updated.
“好，坏，我是拿枪的人。” - Ash
Bad 确实是一个射程。它可以是在插上电源并且手湿的情况下更换主板，也可以是使用过短的变量名称。您真正想知道的是权衡是什么。您显然知道其中的一些好处，否则您不会考虑使用生产服务器进行测试。
最大的缺点是测试代码在与生产环境共享环境中运行。如果没有沙箱（进程限制、内存限制、磁盘限制、chroot 文件系统等），则测试中出现问题可能会影响生产服务器。您可能会意外地消耗掉所有特定资源，从而导致自己遭受 DOS 攻击。您可能会意外删除生产站点。有人可能认为进行负载测试就可以了。如果您愿意承担这些风险，那么您可以继续在生产服务器上运行测试应用程序。
顺便说一句：这很糟糕。
"Good, bad, I'm the guy with the gun." - Ash
Bad is really a range. It can be anywhere between replacing motherboards with the power plugged in and wet hands, to using excessively short variable names. What you really want to know is what are the tradeoffs. You obviously know some of the benefits or you wouldn't be thinking about using the production server for testing.
The big con is the test code is running in a shared environment with production. If there is no sandbox (process limits, memory limits, disk limits, chroot file system, etc) you risk impacting the production server is something goes awry in the testing. You may accidentally DOS your self by consuming all of a particular resource. You may accidentally remove the production site. Someone may think it's okay to do a load test. If you are fine with taking those risks, then you can go ahead an run your test app on the production server.
BTW: It is bad.
由于您的问题不是特定于平台的，因此我将尝试以一般形式回答。我也将仅提及您问题的“同一台机器”部分，因为“域名”应该很容易更改......如果已采取所有常见的预防措施。
您真正需要的是隔离环境。根据所使用的技术，这可能意味着“单独的机器”，也可能不是。
举例来说，世界上许多中小型银行都在一台大型机上运行其关键系统。这些野兽之一的成本（外围设备和所有）六位数并不罕见。他们中的一些人选择使用单独的较小的机器来进行开发和测试，而另一些人则在同一台机器上运行数百个环境（有时作为虚拟机）。棘手的细节是，大型机硬件和操作系统确实在这些环境之间提供真正一致的隔离，根据严格的策略（可以是细粒度的）分配磁盘、CPU、通信通道、凭证、库、操作系统模块、数据库等。如你所愿。
许多其他平台的问题在于，找到隔离环境的方法取决于您，而在恐龙平台中，则由 HAL 提供。
哈！
As your question is not platform specific, I'll try to answer in a general form. I'll lso refer only to the "same machine" part of your question, since the "domain name" should be very easy to change ... if all common precautions have been taken.
What you really need is to isolate environments. Depending on the technology used, that may mean "separate machines" or not.
As an example, a lot small to medium banks in the world run their critical systems on one mainframe. It's not unusual for one of those beasts to cost (peripherals and all) six figures. Some of them opted to have separate, smaller machines for development and testing, while others run hundreds of environments (sometimes as VMs) on the same machine. The tricky detail is that the mainframe hardware and OS do provide real and consistent isolation between those environments, assigning disks, CPUs, comm channels, credentials, libraries, OS modules, DBs, etc, etc based on a strict policy that can be as granular as you want.
The problem with many other platforms is that finding the way to isolate the environments is up to you, while in a dinosaur platform is provided by the grace of HAL.
HTH!
是的，这是一个坏主意。
假设您的测试代码有一个错误，消耗了所有内存/CPU/磁盘空间？然后你的生产站点就瘫痪了。
使用单独的机器进行生产和测试，并使用 DNS 将 URL 指向每台机器。
编辑（更多要点）：
如果站点共享一台机器，它们共享一个IP地址，因此当使用IP地址访问站点时，您将不知道您是在生产还是测试。
当共享同一台机器时，部署可能会很棘手，您必须格外小心，不要将未经测试的代码部署到生产中（更容易做到，因为两者都位于同一台机器上）。
生产和测试的安全考虑应该是分开的——这种设置使得它变得更加困难。
Yes, it is a bad idea.
Suppose your test code has a bug that consumes all memory/cpu/disk space? Then your production site goes down.
Have separate machines for production and test and use DNS to point the URLs to each.
Edit (more points):
If the sites share a machine, they share an IP address, so when using an IP address to access a site, you will not know whether you are on production or test.
When sharing the same machine, deployment can be tricky, you have to be extra careful not to deploy untested code to production (easier to do, since both live on the same machine).
The security considerations for production and test should be separate - this kind of setup makes it more difficult.
在同一台机器上测试和生产环境是否更新（新版本的 php/perl/python/apache/kernel/whatever）真的很难。
It'd be really hard to test whether environment updates (new version of php/perl/python/apache/kernel/whatever) with test and production on the same machine.
这是一个坏主意。当您有一个未经测试的新功能时，它可能会破坏生产站点。
It is a bad idea. When you have a new untested feature it may kill the production site.
遵守任何类型的标准都会有问题吗？通常，您希望开发人员能够大量访问测试环境，以便解决问题。然而，对于开发人员来说，拥有相同级别的生产系统访问权限并不总是一个好主意（甚至不允许）。
Is compliance with any kind of standard an issue? Generally you want developers to have lots of access to test environments so they can resolve issues. However, it's not always a good idea (or even allowed) for developers to have the same level of access to production systems.