我应该什么时间投入生产？
我的用户几乎每天 24/7 都使用该网站。 有构建时间的模因吗？
国际观众，东部时间的单一服务器集群，但一直受到国际客户的攻击，一直持续到早上。
1 个数据库，几个网络服务器，所以如果没有数据库，简单，只要。
但是，当网站必须关闭时，作为一名程序员，您什么时候最不会因为看到网站关闭 15 分钟而生气。
My users use the site pretty equally 24/7. Is there a meme for build timing?
International audience, single cluster of servers on eastern time, but gets hit well into the morning, by international clients.
1 db, several web servers, so if no db, simple, whenever.
But when the site has to come down, when would you, as a programmer be least mad to see SO be down for say 15 minutes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
选择几次你想要做的事情，并将它们作为决策者类型的选择。 无论您做什么，在部署时都应设置“停机进行日常维护”页面。
Pick a few times that you'd like to do it and offer them as choices to the decider-types. Whatever you do, put up a "down for routine maintenance" page while you deploy.
首先使用分析工具尝试确定您通常的“轻量”交通时间。 根据网站以及您与大多数用户相比在世界上的位置，可能是凌晨 4 点，也可能是下午 1 点，谁知道呢。 然后，一旦确定了良好的时间框架，请确保部署过程尽可能自动化，以便快速完成，从而最大限度地减少站点的停机时间。
First use an analysis tool to try and determine your typically "light" traffic times. Depending on the site and your location in the world in comparison to most of your users, it could be 4am, it could be 1pm, who knows. Then, once you have a good timeframe nailed down, make sure to have your deployment process as automated as possible, so that it happens quickly to minimize the downtime of your site.
取决于您所在的位置：东海岸凌晨 4 点/西海岸凌晨 1 点通常是最亮的时间。
Depends on your location: 4AM East Coast/1AM West Coast is typlically the lightest time.
我想你得问问你的客户。
无论如何，现在是凌晨。 如果您谈论的是本地可用的网站，我认为用户不会介意他们在所在时区的凌晨 2 点收到“维护中”通知。
I guess you have to ask your clients.
In any case, there's the wee hours of the morning. If you're talking about a locally available website, I do not think users will mind if they get an "under maintenance" notice at 2 am in their time zone.
热插拔的问题是数据库仍将被共享，并且重大更改也会导致停机。
The issue with hot-swapping, is database would still be shared, and breaking changes would bring stand in down as well.
使用第二个站点，并根据需要进行热插拔。
Use a second site, and hotswap as needed.
它是一个什么样的应用程序？ 我使用的大多数网站倾向于在凌晨 2 点或 3 点左右更新。
What kind of an application is it? Most sites that I use tend to update around 2AM or 3AM.
如果您规模较小，那么是的，找到您的最低使用时间段，然后执行（对于我们个人而言，通常太平洋标准时间凌晨 1 点至凌晨 3 点左右是最低下降时间……但当然它永远不会降至 0）。 一旦您开始拥有更大的用户群，如果您希望人们认真对待您，您需要设计您的应用程序，以便您可以在不停机的情况下进行升级。 这并不简单，并且通常涉及拥有多个服务器。
我花了很长时间试图让我们的应用程序达到这一点，到目前为止我想到的最好的办法是同时运行旧版本和新版本几个小时。 切换时登录的用户将保留旧版本，直到注销为止。 下次他们进来时，他们会转到新版本。 切换后加入的任何用户都会直接发送到新版本。 它仍然不是万无一失的，但已经相当不错了。
If you're small, then yeah, find when your lowest usage period is, and do it then (for us personally, usually around 1AM-3AM PST is the lowest dip...but it never drops to 0 of course). Once you start growing to having a larger userbase, if you want people to take you seriously you'll need to design your application such that you can upgrade without downtime. This is not simple, and it often involves having multiple servers.
I've spent ages trying to get our application to this point, the best I've come up with so far is for a couple hours run both the old version and new version at the same time. Users logged in at the time of the switchover stay on the old version, until they log out. Next time they come in they go to the new version. Any users coming on after the switchover get sent straight to the new version. It's still not foolproof, but it's pretty good.
这是我所做的并且对我来说效果很好：
这将绘制每小时用户负载的图表
更新
Here's what I have done and its worked well for me:
which will graph hourly user load
updates
如果从用户的角度来看确实没有什么好时机，那么我建议您的团队有最多时间从任何与构建相关的灾难中恢复时进行此操作。
If there's truly no good time from the users' perspective, then I'd suggest doing it when your team has the most time to recover from any build-related disaster.