Captain Obvious 告诉我们，在夏季，购买活动和网络项目基础设施的变化强度通常都会减少。 原因很简单，即使是 IT 专家有时也会去度假。 还有 CTO。 对于那些留任的人来说，这更加困难，但这不是现在的重点：也许这就是为什么夏季是慢慢思考现有预订计划并制定改进计划的最佳时期。 叶戈尔·安德烈耶夫 (Yegor Andreev) 的经历 ，他在会议上谈到 .
构建备份站点时可能会陷入几个陷阱。 而且绝对不可能陷入其中。 和许多其他事情一样，在这一切中毁掉我们的是完美主义和……懒惰。 我们努力把每件事、每件事、每件事都做到完美，但我们不需要做得完美！ 你只需要做某些事情，但要正确地做，完成它们，这样它们才能正常工作。
故障转移并不是一件非常有趣的事情；它是一种非常有趣的事情。 这件事应该只做一件事——减少停机时间，以便服务、公司损失更少的钱。 在所有预订方法中，我建议在以下背景下思考：钱在哪里？
第一个陷阱：当我们构建大型、可靠的系统并采用冗余时，我们可以减少事故数量。 这是一个可怕的误解。 当我们进行裁员时，事故的数量可能会增加。 如果我们一切都做得正确，那么我们将共同减少停机时间。 事故会发生更多，但发生的成本会更低。 什么是预订？ - 这是系统的复杂性。 任何复杂化都是不好的：我们有更多的齿轮，更多的齿轮，总而言之，更多的元件 - 因此，出现故障的可能性更高。 他们真的会破裂。 而且它们会更频繁地破裂。 一个简单的例子：假设我们有一个使用 PHP 和 MySQL 的网站。 而且急需保留。
Shtosh (c) 我们占据第二个站点，构建一个相同的系统...复杂性变得两倍 - 我们有两个实体。 我们还推出了一种将数据从一个站点传输到另一个站点的逻辑，即数据复制、复制静态数据等。 因此，复制逻辑通常非常复杂，因此，系统的总复杂度可能不是2倍，而是3、5、10倍。
第二个陷阱：当我们构建非常大型的复杂系统时，我们会幻想最终想要得到什么。 瞧：我们希望获得一个超级可靠的系统，可以在没有任何停机时间的情况下工作，在半秒内（或者更好的是，立即）切换，然后我们开始让梦想成真。 但这里也有一个细微差别：所需的切换时间越短，系统逻辑就会变得越复杂。 我们必须使这个逻辑越复杂，系统就越容易崩溃。 你最终可能会遇到一种非常不愉快的情况：我们正在竭尽全力减少停机时间，但实际上我们让一切变得更加复杂，当出现问题时，停机时间最终会更长。 在这里，您经常会发现自己在想：好吧……最好不要预订。 如果它能够单独工作并具有可以理解的停机时间，那就更好了。
你怎么能对抗这个呢？ 我们需要停止对自己撒谎，停止自我吹嘘我们现在要在这里建造一艘宇宙飞船，而是要充分了解该项目可以持续多久。 在这段最长时间内，我们将选择实际使用的方法来提高系统的可靠性。
现在是“w 的故事”的时间了……当然是生活中的故事。
示例一
想象一下 N 市 1 号轧管厂的名片网站。上面用大写字母写着 - 1 号轧管厂。 下面是标语：“我们的烟斗是 N 地区最圆的烟斗。” 下面是首席执行官的电话号码和姓名。 我们知道您需要进行预订 - 这是一件非常重要的事情！ 让我们开始弄清楚它由什么组成。 Html-statics - 也就是说，总经理实际上正在浴室的桌子上与他的搭档讨论某种下一步交易的图片。 我们开始考虑停机时间。 我想到：你需要在那里躺五分钟，不能再多了。 那么问题来了：我们这个网站总体上有多少销售额？ 多少——多少？ “零”是什么意思？ 这意味着：因为将军去年在同一张桌子上进行了所有四笔交易，与他们一起去澡堂和坐在桌子旁的同一个人进行了交易。 我们知道，即使该网站停留一天，也不会发生任何可怕的事情。
根据介绍性信息，有一天提出这个故事。 让我们开始考虑冗余方案。 我们为此示例选择最理想的冗余方案：我们不使用冗余。 任何管理员都可以在半小时内吸烟休息时提出整个问题。 安装网络服务器，添加文件 - 就是这样。 它会起作用的。 你不需要留意任何事情，不需要特别注意任何事情。 也就是说，从示例一得出的结论是非常明显的：不需要预留的服务不需要预留。
例子二
公司博客：受过专门培训的人在那里写新闻，我们参加了某某展会，但我们发布了另一个新产品，等等。 假设这是带有 WordPress 的标准 PHP、一个小型数据库和一点静态。 当然，我再次想到，在任何情况下都不应该躺下——“不超过五分钟！”仅此而已。 但让我们进一步思考一下。 这个博客是做什么的？ 人们从 Yandex、Google 根据一些查询有机地来到那里。 伟大的。 销量跟这个有关系吗？ 顿悟：不是真的。 广告流量流向位于另一台机器上的主站点。 让我们开始考虑预订方案。 从好的方面来说，它需要在几个小时内筹集到，最好为此做好准备。 合理的做法是从另一个数据中心取出一台机器，将环境部署到上面，即 Web 服务器、PHP、WordPress、MySQL，然后将其留在那里。 当我们明白一切都坏了的那一刻，我们需要做两件事 - 将mysql转储推出50米，它会在一分钟内飞到那里，并从那里的备份中推出一定数量的图片。 天知道这也不存在多久。 就这样，半个小时之后，一切就都起来了。 没有复制，或者上帝原谅我，自动故障转移。 结论：我们可以从备份中快速推出的内容不需要备份。
示例三，更复杂
网上商城。 敞开心扉的 PhP 稍作调整，MySQL 具有坚实的基础。 相当多的静态（毕竟，在线商店有漂亮的高清图像和所有这些东西），用于会话的 Redis 和用于搜索的 Elasticsearch。 我们开始考虑停机时间。 当然，很明显，在线商店不可能一天都无忧无虑地闲置。 毕竟，躺的时间越长，我们损失的钱就越多。 值得加快速度。 多少？ 我想如果我们躺一小时，没有人会发疯。 是的，我们会失去一些东西，但如果我们开始努力，情况只会变得更糟。 我们定义了每小时允许的停机时间计划。
这一切如何能被保留？ 无论如何你都需要一辆车：一个小时的时间相当短。 Mysql：这里我们已经需要复制，实时复制，因为一小时内 100 GB 很可能不会添加到转储中。 静态、图片：同样，一小时内 500 GB 可能没有时间添加。 因此，最好立即复制图片。 Redis：这就是事情变得有趣的地方。 在 Redis 中，会话是被存储的 - 我们不能只是拿走它并埋葬它。 因为这不会很好：所有用户都将被注销，他们的购物篮将被清空，等等。 人们将被迫重新输入用户名和密码，许多人可能会退出并无法完成购买。 同样，转化率将会下降。 另一方面，Redis 是直接最新的，可能也不需要最后登录的用户。 一个好的折衷方案是使用 Redis 并从昨天的备份中恢复它，或者，如果您每小时执行一次，则从一小时前恢复。 幸运的是，从备份恢复它意味着复制一个文件。 最有趣的故事是 Elasticsearch。 谁学过 MySQL 复制？ 谁学过 Elasticsearch 复制？ 之后对谁来说可以正常工作？ 我的意思是我们在系统中看到了某个实体。 它似乎很有用 - 但它很复杂。
复杂是因为我们的工程师同事没有使用它的经验。 或者有负面的经历。 或者我们知道这仍然是一项相当新的技术，存在细微差别或原始性。 我们想……妈的，elastic也健康，从备份恢复起来也需要很长时间，怎么办？ 我们知道，在我们的例子中，弹性用于搜索。 我们的网上商店如何销售？ 我们去找营销人员，询问人们来自哪里。 他们回答：“90% 来自 Yandex Market 的直接进入产品卡。” 他们要么买，要么不买。 因此，10%的用户需要搜索。 保持弹性复制，特别是在不同区域的不同数据中心之间，确实有很多细微差别。 哪个出口？ 我们从保留的站点获取弹性并且不对其进行任何操作。 如果案件拖延下去，我们可能有一天会提出，但这还不确定。 实际上，结论是相同的，无论是加还是减：我们再次强调，不保留不影响金钱的服务。 为了使图表更简单。
例子四，更难
积分商：卖花、叫出租车、卖货，一般什么都可以。 这是一个 24/7 为大量用户工作的严肃的事情。 拥有成熟的有趣堆栈，其中有有趣的基础、解决方案、高负载，最重要的是，躺下超过 5 分钟会很痛。 不仅仅是因为人们不会购买，而是因为人们会看到这个东西不起作用，他们会感到沮丧，可能根本不会回来。
好的。 53分钟。 对此我们该怎么办？ 在这种情况下，我们像成年人一样，用所有的钱建立一个真正的备份站点，复制所有内容，甚至可能尽可能自动切换到这个站点。 除此之外，您需要记住做一件重要的事情：实际上，编写切换规则。 即使一切都自动化了，规则也可能非常简单。 来自系列“运行这样那样的 ansible 脚本”、“单击路线 XNUMX 中这样那样的复选框”等等 - 但这必须是某种精确的操作列表。
一切似乎都很清楚。 切换复制是一项微不足道的任务，否则它会自行切换。 DNS中的域名重写也是同一系列。 问题在于，当这样的项目失败时，恐慌就会开始，即使是最坚强、留着胡子的管理员也可能会受到影响。 如果没有明确的指示“打开终端，到这里来，我们的服务器地址还是这样”，很难满足5分钟的复苏时限。 嗯，另外，当我们使用这些法规时，很容易记录基础设施中的一些变化，例如，并相应地更改法规。
好吧，如果预订系统非常复杂，并且在某些时候我们犯了一个错误，那么我们可以破坏我们的备份站点，并且另外将数据变成两个站点上的南瓜 - 这将是完全可悲的。
示例五，完全硬核
一项国际服务，在全球拥有数亿用户。 所有时区，最高速度下的高负荷，你根本无法躺下。 一分钟——这将是悲伤的。 该怎么办？ 再次根据完整的计划进行预订。 我们做了我在上一个示例中谈到的所有内容，甚至还做了更多。 这是一个理想的世界，我们的基础设施符合 IaaC devops 的所有概念。 也就是说，一切都在 git 中，你只需按一下按钮即可。
缺什么？ 一——练习。 没有他们这是不可能的。 似乎一切对我们来说都是完美的，一切都在我们的掌控之中。 我们按下按钮，一切都会发生。 即使事实如此（我们知道事情不会以这种方式发生），我们的系统也会与其他一些系统进行交互。 例如，这是来自路由 53 的 dns、s3 存储、与某些 api 的集成。 我们无法预见这个推测性实验中的一切。 在我们真正拉动开关之前，我们不知道它是否有效。
大概就是这样。 不要偷懒或过度。 愿正常运行时间与您同在！
来源： habr.com