认为网站应始终可访问是不礼貌和平庸的说法，但是100％可访问性虽然是先决条件，但通常仍然是无法访问的理想选择。 现在市场上有许多解决方案可以保证最大的正常运行时间或提供增加运行时间的解决方案，但是它们的应用不仅不总是有用的，在某些情况下，甚至可能导致风险增加和项目可访问性降低。 在本文中，我们将介绍我们经常遇到的经典错误。 大多数问题都是基本问题，但是人们一次又一次地允许它们。
必要的序言：在尝试确保项目的最大正常运行时间之前，应将成本与停机时间相关联。 通常，这对于其工作依赖于其他公司的工作的公司非常重要-B2B解决方案，API服务，交付服务。 几分钟的无法访问性至少会导致不满意的客户给呼叫中心带来负担。 对于另一类型的公司，例如小型在线商店或客户工作时间为9到18岁的公司，即使是几个小时也无法访问，这比完整的备份站点要便宜。
1.将整个项目本地化到一个数据中心/一个云托管区域
云托管营销已牢固地解决了人们头脑中的错误概念：云托管不与硬件捆绑在一起，这意味着云基础架构不会崩溃。 三起24小时的Amazon Web Services崩溃，最近的cloud4y崩溃以及cloudmouse数据丢失表明，在一个数据中心内对数据和项目本身进行本地化是保证长时间停机的一种保证方式，而又无法轻松地将项目提升到另一个站点。 在这方面，有关个人数据的法律产生了其他问题。 我们认为，任何云托管都应经历几次重大事故，以了解如何预防（闪电袭击亚马逊，与人为因素相关的网络配置问题等），并且如果西方云托管经历了这一系列灾难，那么许多俄罗斯站点尚未做到这一点，必须考虑到这一点。
“铁”数据中心的情况大致相同。 通常，我们会看到客户端的配置，其中一个站点上会保留几台服务器，以防其中一台发生故障，但是根据我们的经验，当一个数据中心或整个数据中心的多个机架无法访问时，会出现网络问题与单台服务器崩溃相比，这种情况发生的频率要高得多，这也需要加以考虑。
AWS推荐的项目工作流程涉及使用多个默认可用性区域，以实现最大的项目正常运行时间。
2.备用地点缺乏足够的重复
因此，我们得出了这样一个荒谬的结论：需要有一个备份站点来实现项目的最大正常运行时间，但是，为了切换到该站点，数据必须足够用于生产站点。 这里重要的不是储备金的初始创建-这是一个相当简单且易于理解的过程，同步和监视进一步更改的同步更为重要。 首先，我们在谈论：
- 当我们谈论复杂站点时，集群中的集群配置/数据同步
- 文件结构同步和同步滞后的监视
- 跟踪服务器配置中的更改
- 监视和调试站点上新项目/服务的同步的调试过程。
- 跟踪新辅助服务（新队列，处理机制和交互作用等）的添加。
- 对所有这些过程进行充分的持续监视。
3.缺乏转换计划，无法定期转换到备份站点
任何监控，即使是最好的监控，也不能保证备份站点在真正需要时可以随时进行切换。 根据我们的经验，第一次切换到后备箱时会发生事故，并且还会发生多次。 Stack Overflow在他们的报告中说，他们花了大约五次切换到备用站，然后他们才确信事故发生后现在已经完全准备好接受流量了。 因此，在增加项目正常运行时间的工作计划中，有必要将测试开关包括在储备金中，并考虑到这样的开关会导致事故。 在确定并修复了文档中的切换机制之后，您需要继续定期切换到储备金，以确保一切仍在进行。
4.保留站点在云的相同通道/相同区域中的本地化
如果生产站点和备用站点在同一托管公司内，则很可能在发生事故的情况下，您的两个站点都将立即停止工作。 AWS的几起重大事故立即影响了一个地区的所有可用区域，Selectel落在了圣彼得堡和莫斯科的数据中心的同时，公司可以谈论完全隔离，但是cloud4y事故导致Bitrix24完全无法访问，这表明即使在这种情况下有很大的风险。 从我们的角度来看，理想的配置是一个备份配置位于同一托管公司中（用于使用常规方法切换到备用资源，例如VRRP ），并在另一托管公司中使用辅助备份平台。
5.在主站点和备用站点上放置相同版本的文件。
即使使用经过验证的备用站点以及在另一个数据中心中使用辅助站点，也不能保证备用磁盘可以快速接管生产负荷。 这是由于冗余的本质所致：在生产环境中造成致命负载的新版本代码将在备份站点上创建完全相同的负载，并且项目将变得完全不可访问。 作为一个简单的解决方案，应该有一种机制可以回滚到以前的版本，但是，在争取版本的业务竞赛中，这并不总是可能的，然后我们开始考虑使用先前版本的另一个备份站点。 我们还应该讨论备份 ：主站点上数据的意外删除也会影响备份站点，因此您应该考虑延迟（每小时15分钟）复制，以便能够切换到尚未发生的数据库致命的操作。
6.对项目正在访问的外部服务的依赖。
但这还不够。 现在，大量项目使用外部服务来提供自己的服务。 大多数人都使用SMS进行双重身份验证，在线商店使用送货服务来计算送货时间，通过第三方付款门户接受付款，并且如果这些服务失败，则无论是否有预订，该项目仍然不可用。 我们很少看到保留外部服务的情况，但是与此同时，这些是完全相同的项目，可能在保留站点方面有问题，或者根本没有保留。 如果无法使用外部服务，也将无法为客户提供服务。 我们建议您复制所有关键的外部系统，监视它们的可用性，并计划在发生事故时进行切换。
这远不是全部，但至少是基本的东西。 我们将在uptime.community会议上详细讨论此问题，下一次会议将在10月举行，但现在您可以在电报组中聊天。