东芝256定期维护时间
This article was sponsored by PagerDuty. Thank you for supporting the sponsors who make SitePoint possible.
本文由PagerDuty赞助。 感谢您支持使SitePoint成为可能的赞助商。
Scheduled website maintenance is the planned maintenance of a service, usually requiring a significant amount of time and manpower, as well as downtime for your service. It’s the internet equivalent of sending your car away for a tune up. The problem is, web apps are definitely not cars.
计划的网站维护是一项服务的计划维护，通常需要大量的时间和人力，以及服务的停机时间。 这相当于将汽车送去进行调校的互联网。 问题是，Web应用程序绝对不是汽车。
Let’s face it: no one loves scheduled maintenance — neither the customers nor the developers. It’s time-consuming, usually comes on a weekend, and potentially costs the company performing the maintenance money. Even if you perform your maintenance on a Sunday night in the United States, that’s early morning the next day in India, for example, so those users are affected by your outage.
让我们面对现实：没有人喜欢定期维护，无论是客户还是开发人员。 这很耗时，通常是在周末，并且可能使公司支付维护费用。 例如，即使您在美国的周日晚上执行维护，也就是在第二天的第二天清晨，例如在印度，这些用户仍会受到停机的影响。
Webmasters “schedule” such maintenance tasks to make major changes to websites. The only reason they do so even after knowing the potential effects is to avoid the interference they would face if their service was still working. Imagine a car mechanic trying to fix an engine when it’s still running.
网站管理员“安排”此类维护任务以对网站进行重大更改。 即使知道潜在的影响，他们这样做的唯一原因是要避免在服务仍在工作时将面临的干扰。 想象一下，汽车修理工试图在发动机仍在运行时对其进行修理。
Fortunately, modern development methods mean things have changed. This post will talk about ways to ditch scheduled maintenance and find a way to fix bugs in real time, without affecting a single user! Initially daunting, it is very achievable with proper planning and execution strategies.
幸运的是，现代开发方法意味着情况已经改变。 这篇文章将讨论放弃定期维护的方法，并找到一种实时修复错误而不影响单个用户的方法！ 最初令人望而却步，如果有适当的计划和执行策略，这是可以实现的。
Let’s start at the beginning and talk about the goal of scheduled maintenance. This is usually the time when you roll out major changes to your product — be it solving bugs or adding features. Usually, you’ll perform a bunch of changes during one session of maintenance to make the most of the downtime.
让我们从头开始，讨论预定维护的目标。 通常，这是您对产品进行重大更改的时间-无论是解决错误还是添加功能。 通常，您将在一个维护会话期间进行大量更改，以充分利用停机时间。
The other, better way of making these changes is simple — in real time. This is called continuous deployment. As soon as you identify a bug, you assign it to a developer to be solved. Once the bug has been rectified, you merge it with your main code base. It sounds pretty simple, but there are a few more steps involved.
进行这些更改的另一种更好的方法是简单-实时。 这称为连续部署。 一旦发现错误，就将其分配给要解决的开发人员。 修正错误后，即可将其与主要代码库合并。 听起来很简单，但是涉及更多步骤。
Many organizations maintain a staging server with a dummy database — one that acts as a link between your local machine and the main server. The primary motive of the staging server is to test how the changes would look to an end user. You’ll first preview the changes on the staging server and if you are satisfied with the changes, you’ll make them appear on the main server.
许多组织使用虚拟数据库维护一个登台服务器，该数据库充当本地计算机和主服务器之间的链接。 登台服务器的主要动机是测试更改对最终用户的外观。 首先，您将在登台服务器上预览更改，如果对更改感到满意，则将其显示在主服务器上。
Access to the staging server must be restricted and this could be achieved by hosting it on an uncommon sub-domain (something other than “staging.yoursite.com”).
必须限制对登台服务器的访问，这可以通过将其托管在一个不常见的子域(“ staging.yoursite.com”以外的东西)来实现。
You should ensure a proper testing framework (which includes tests like unit tests and integration tests) that a given fix should pass through before being merged with the main code base. This is important because the fix itself could introduce a new bug, which could lead to downtime. In many organizations, this testing is automated — your code is merged on the main server only when it has passed all the specified tests.
您应该确保在与主要代码库合并之前，给定修订应通过的正确测试框架(包括单元测试和集成测试)。 这很重要，因为修复程序本身可能会引入一个新的错误，这可能会导致停机。 在许多组织中，此测试是自动进行的-仅当代码通过所有指定的测试时，您的代码才会在主服务器上合并。
The idea here is to ensure that any bit of code that you add doesn’t end up breaking something.
这里的想法是确保您添加的任何代码最终都不会破坏某些内容。
Where does this automated testing take place? We need a centralized server that performs tests on the code before the changes go live. There are many open source solutions like Buildbot and cloud solutions like Travis CI or Jenkins CI which perform this task of automation.
这种自动测试在哪里进行？ 我们需要一个集中式服务器，以便在更改生效之前对代码执行测试。 有许多开源解决方案(例如Buildbot)和云解决方案(例如Travis CI或Jenkins CI)可以执行自动化任务。
I’m sure you use some kind of version control to manage your source code. In the popular version control system Git, you can write scripts called “hooks” to perform a range of tasks as per your requirements. The most common task would be to merge the code with the main repository once the tests have passed. Here is a detailed tutorial on the use of Git hooks for continuous integration.
我确定您使用某种版本控制来管理源代码。 在流行的版本控制系统Git中，您可以编写称为“挂钩”的脚本来根据需要执行一系列任务。 测试通过后，最常见的任务是将代码与主存储库合并。 这是有关使用Git挂钩进行持续集成的详细教程。
One problem that can really make scheduled maintenance tempting is the release of patches of features that require changes to your database schema. How do you proceed with such a release without any downtime?
真正使计划的维护更具吸引力的一个问题是，发布了需要更改数据库架构的功能补丁。 您如何在没有停机的情况下进行此类发布？
It turns out there’s is a way around that too, although it does require some careful steps to be taken. You’ll need to follow roughly the following steps:
事实证明，尽管确实需要采取一些谨慎的步骤，但是也有一种解决方法。 您需要大致遵循以下步骤：
Modify Schema by creating a new table, or adding a new column (without deleting the old table or column) 通过创建新表或添加新列(不删除旧表或列)来修改架构 Modify your application to read from the old data and write to both the old and new data 修改您的应用程序以读取旧数据并写入新旧数据 Migrate your data by copying the old data to the new schema 通过将旧数据复制到新架构来迁移数据 Modify your application to read and write only the new schema 修改您的应用程序以仅读写新模式You should proceed with caution at every step. Here is a more detailed tutorial.
您应在每一步上谨慎行事。 这是更详细的教程 。
Even if your deployment system is perfect, bugs can still creep in. These bugs are often first encountered by the end users. Good samaritans will report it, but you may not know about the bug immediately.
即使您的部署系统是完美的，错误仍然会蔓延。最终用户通常会首先遇到这些错误。 优秀的撒玛利亚人会报告该错误，但您可能不会立即知道该错误。
It is therefore important to set up an alert system that lets you know as soon as an end user encounters an error. Ideally, this could be done by sending an email to your developers’ mailing list, or assigning someone to be on call using ChatOps.
因此，重要的是建立一个警报系统，让最终用户在遇到错误时立即通知您。 理想情况下，这可以通过向开发人员的邮件列表发送电子邮件，或使用ChatOps分配待命人员来完成。
It’s enormously helpful to have a system in place for getting a single view of your infrastructure, so you can keep up with and respond to bugs and downtime. PagerDuty is a platform that lets your on-call devs keep track of issues, with detailed analytics and integrations with apps like New Relic, Crashalytics and AppDynamics. During an incident, alerts will come through email, phone call, push notification, or through integrations with these other services. The service has continuous routing and automatic escalation to make sure every alert is given the attention it warrants.
拥有一个用于获取基础结构单一视图的系统非常有帮助，因此您可以跟上并响应错误和停机时间。 PagerDuty是一个平台，可让您的待命开发人员跟踪问题，并进行详细的分析并与New Relic，Crashalytics和AppDynamics等应用程序集成。 在事件发生期间，警报将通过电子邮件，电话，推送通知或与这些其他服务的集成来发出。 该服务具有连续的路由和自动升级功能，以确保对每个警报给予应有的重视。
We have been talking mostly about bugs so far. When it comes to releasing new features, companies like Facebook roll them out in batches (like the new Timeline or the Graph Search). This helps fix bugs in earlier versions of a new feature without affecting service too much.
到目前为止，我们一直在谈论错误。 在发布新功能时，像Facebook这样的公司会批量推出这些功能(例如新的时间轴或Graph搜索)。 这有助于修复新功能的早期版本中的错误，而不会过多地影响服务。
In addition to fixing bugs, as the traffic to a new feature increases you can assess its performance and make the required changes for it to perform optimally.
除了修复错误外，随着新功能的访问量增加，您可以评估其性能并进行必要的更改以使其性能最佳。
Your users are (hopefully) spread throughout the globe, and your application gets traffic all throughout the day. This makes uptime very crucial. Developers look for as high as 99.9999999% uptime, which points to less than a fraction of a second of downtime in a year.
您的用户(希望)遍布全球，并且您的应用程序全天都在获得流量。 这使得正常运行时间非常关键。 开发人员期望的正常运行时间高达99.9999999％，这意味着一年内的停机时间不到一秒钟的几分之一。
With such requirements, high-availability approaches like load balancing and failover systems are needed. In addition to applying these principles on the application layer, you may also need to perform replication or sharding on your database as per your needs.
在这种要求下，需要诸如负载平衡和故障转移系统之类的高可用性方法。 除了在应用程序层上应用这些原理外，您还可能需要根据需要在数据库上执行复制或分片 。
Before we finish off this post, let me give you a few examples of companies that not only perform continuous deployment, but also encourage others to do so — Facebook, Google, LinkedIn and PagerDuty (here’s a post about how the latter manages it). It just shows you that continuous deployment is the way ahead.
在结束本文之前，让我给您提供一些公司的示例，这些公司不仅可以进行连续部署，还可以鼓励其他公司(例如Facebook ， Google ， LinkedIn和PagerDuty)进行部署 (这是有关后者如何管理它的文章 )。 它仅向您显示持续部署是前进的道路。
How did you make the move away from scheduled maintenance? Do you have any tips for making the transition easier?
您是如何摆脱定期维护的？ 您有什么技巧可以简化过渡过程吗？
翻译自: https://www.sitepoint.com/ditch-scheduled-maintenance/
东芝256定期维护时间
相关资源：东芝2303复印机故障代码