船长证据告诉我们,在夏天,购买活动和Web项目基础结构变化的强度传统上都会下降。 仅仅因为IT人员碰巧都去度假。 还有CTO。 对于那些留在岗位上的人来说,这更加困难,但现在就不那么困难了:也许这就是为什么夏天是匆忙完成现有预订计划并制定改善计划的最佳时机。 在这方面,您将受益于AdminDivision的Yegor Andreev的经验,他在Uptime日会议上谈到了这一点 。在准备站点的建造过程中,您会遇到一些陷阱。 陷入其中绝对是不可能的。 而在这一切以及其他许多方面,完美主义和……懒惰毁了我们。 我们正在尝试做的一切都是完美的,但是您不必完美地做! 只需要做某些事情,但是正确地做它们,以使它们结束,以便它们正常工作。
故障转移不是某种“有趣的事情”; 完全应该做一件事-减少停机时间,以使服务公司损失更少的钱。 在所有预订方法中,我建议在以下情况下进行思考:这笔钱在哪里?
第一个陷阱 :构建大型可靠的系统并进行备份时,我们减少了事故数量。 这是一个可怕的谬论。 进行备份时,很可能会增加事故数量。 如果我们做对了所有事情,那么我们将共同减少停机时间。 将会发生更多的事故,但是发生的成本更低。 毕竟,冗余是什么? 是系统的一个复杂之处。 任何复杂的情况都是不好的:总之,我们得到更多的嵌齿轮,更多的齿轮,更多的元素-因此,出现故障的可能性更高。 他们真的打破了。 而且它们会更频繁地破裂。 一个简单的例子:假设我们有一个使用PHP,MySQL的网站。 而且他急需保留。
Shtosh(c)我们在第二个站点上,我们构建了一个相同的系统...复杂度变成了两倍-我们有两个实体。 同样,我们从上到下将数据从一个平台传输到另一个平台的某些逻辑-即数据复制,复制静态数据等。 因此,复制的逻辑通常非常复杂,因此,系统的总复杂度可能不是2倍,而是3倍,5倍,10倍。
第二个陷阱 :当我们构建真正的大型复杂系统时,我们幻想最终想要得到什么。 Voila:我们希望获得一个超级可靠的系统,该系统可以完全不停机地运行,在半秒内切换(或者通常立即生效),并开始实现梦想。 但也有一个细微差别:所需的切换时间越短,系统逻辑的结果就越复杂。 我们执行此逻辑越困难,系统崩溃的可能性就越大。 您可能会遇到非常不愉快的情况:我们正在尽最大努力减少停机时间,但实际上我们使事情复杂化,并且当出现问题时,停机时间会更长。 在这里,您经常会想到:在这里……如果不保留它们会更好。 如果它可以单独工作且停机时间可以理解会更好。
该如何处理? 我们必须停止对自己撒谎,不要自欺欺人,因为我们打算在这里建造一艘太空飞船,但要充分了解该项目可以撒下多少钱。 在这个最大的时间内,我们将选择实际上可以提高系统可靠性的方法。

当然,该是“从w开始的故事”了……从生活开始。
示例一
想象一下N市1号轧管厂的现场卡,上面写着巨大的字母-1号管道厂。 较低的口号:“我们的烟斗是N型中最圆的烟斗”。 并在CEO的电话号码和他的名字下面。 我们了解您需要保留-这是非常重要的事情! 我们开始了解它的组成。 Html-statics-即几张照片,实际上将军正与他的伴侣在浴池的桌子上讨论下一步的交易。 我们开始考虑停机时间。 我想到:您只需要躺在那儿五分钟,就不用了。 然后的问题是:这个站点的销售量一般是多少? 多少钱多少钱? 零是什么意思? 这就意味着:因为在过去一年中,将军在同一张桌子上进行了全部四笔交易,与他们去澡堂的人坐在桌子上。 而且我们知道,即使该站点躺了一天,也不会有什么可怕的。
在介绍的基础上,有一天要提出这个故事。 我们开始考虑备份方案。 在本例中,我们选择了最理想的备份方案:我们不使用冗余。 任何管理员在冒烟的半个小时内都会冒起烟来。 放置Web服务器,放置文件就可以了。 会的。 您无需遵循任何内容,也无需特别注意任何事情。 也就是说,第一个示例的结论很明显:不需要保留的服务。

第二个例子
公司博客:受过专门训练的人在那儿写新闻,所以我们参加了这样的展览,但是在这里我们发布了另一种新产品,依此类推。 假设这是带有WordPress,小型数据库和一些静态功能的标准PHP。 当然,我再次想到您永远都不要说谎-“不超过五分钟!”,仅此而已。 但是,让我们进一步考虑。 这个博客在做什么? 它们来自Google的Yandex,Google的某些有机物。 哇 销售与他有什么关系吗? 见解:并非如此。 广告访问量流向主站点,该站点位于另一台计算机上。 我们开始考虑小册子预订方案。 以一种很好的方式,它需要在几个小时内被吊起,为此做好准备。 将一台机器放置在另一个数据中心中,然后将环境驱动到该数据中心(即Web服务器,PHP,WordPress,MySQL)并将其放下,这是合理的。 当我们了解到一切都坏了时,需要做两件事-将mysql dump滚动到50米,它会在一分钟内飞到那里,并从那里的备份中滚动一些图片。 这也不是好消息。 因此,在半小时内,整个事情就上升了。 没有复制,或上帝原谅我自动故障转移。 结论:我们可以快速取消备份的内容没有必要保留。

示例三,更复杂
网上商店。 PhP心胸开阔,MySQL的基础扎实。 静态很多(毕竟,在线商店有漂亮的高清图片和爵士乐),Redis用于会话,Elasticsearch用于搜索。 我们开始考虑停机时间。 在这里,当然,很明显,在线商店无法毫不费力地度过一天。 毕竟,时间越长,我们损失的钱就越多。 值得加速。 多少钱 我相信,如果我们躺下一个小时,那么没有人会发疯。 是的,我们会失去一些东西,但是如果我们开始热心,只会变得更糟。 我们确定每小时允许的空闲时间。
如何保留所有这些? 无论如何都需要一台机器:一个小时的时间是相当多的。 Mysql:复制,这里已经需要实时复制,因为在一个小时内100 GB的转储很可能不会倒出。 静态图片:再次,一小时内500 GB可能没有时间合并。 因此,最好立即复制图片。 Redis:这里更有趣。 会议在Redis中进行-我们根本无法接受并掩埋它。 因为效果不是很好:将注销所有用户,清空购物篮,依此类推。 人们将被迫重新输入用户名和密码,许多人可能会逃脱而无法完成购买。 同样,转换将下降。 另一方面,Redis直接是一对一相关的,可能也不需要最后登录的用户。 一个不错的折衷办法是让Redis昨天恢复备份,或者从一个小时前(如果每小时进行一次备份)恢复备份。 从备份还原它的好处是复制一个文件。 最有趣的故事是Elasticsearch。 谁曾提出MySQL复制? 谁提出过Elasticsearch复制? 她之后谁正常工作? 我在做什么:我们在系统中看到某个实体。 它似乎很有用-但很复杂。
从某种意义上讲,这是复杂的,因为我们的工程师没有经验。 否则会有负面的经历。 或者,我们知道到目前为止,这是一种相当细微或潮湿的新技术。 我们认为...该死的,弹性的也是健康的,从备份中恢复它还需要很长时间,我该怎么办? 我们知道在我们的情况下弹性是用于搜索的。 以及我们的在线商店如何销售? 我们去找商人,问人们从哪里来。 他们回答:“ Yandex市场的90%直接来自产品卡。” 要么买要么不买。 因此,有10%的用户需要搜索。 为了保持弹性复制,尤其是在不同区域中不同数据中心之间的复制,确实存在很多细微差别。 出路是什么? 我们在保留站点上采取弹性措施,对此不采取任何措施。 如果情况继续下去,那么总有一天我们可能会提出来,但这还不确定。 实际上,正负结论是相同的:我们再次不保留不影响金钱的服务。 为了使电路更简单。

示例四,更难
集成商:一般来说,卖花,打车,卖商品。 对于许多用户而言,这是一件24/7的严肃工作。 拥有一堆完整有趣的堆栈,其中有有趣的基础,解决方案,高负荷,最重要的是,躺5分钟以上对他造成伤害。 这不仅是因为人们不会购买,而且不是因为人们会看到这东西不起作用,这不仅是因为他们不高兴,而且他们可能第二次不会回来。
好吧 五分钟 我们将如何处理? 在这种情况下,我们将以成年的方式,用所有的钱来建立一个真正的备份站点,复制所有内容,甚至自动进行到该站点的最大切换。 除此之外,一定不要忘记做一件重要的事情:实际上,要编写切换时间表。 即使您将所有内容都自动化了,法规也可能非常简单。 从“运行这样的脚本”,“在路线53中单击这样的脚本”之类的序列中,依此类推-但这应该是一些确切的动作列表。
一切似乎都很清楚。 切换复制是一项琐碎的任务,否则它将自行切换。 用同一系列重写dns中的域名。 问题在于,当一个类似的项目崩溃时,恐慌就开始了,即使是最有能力,最有胡子的管理员也很容易受此困扰。 如果没有明确的指示“打开终端,到这里,我们服务器上的地址仍然是这样”,分配给复苏的5分钟期限就难以维持。 好吧,此外,当我们使用这些法规时,很容易修复基础架构中的某些更改,例如,并相应地更改法规。
好吧,如果备份系统非常复杂,并且在某个时候我们犯了一个错误,那么我们也可以放置备用站点,此外,将数据变成两个站点上的南瓜,这将非常可悲。

示例五,完整的铁杆
一项全球服务,拥有数亿用户。 所有时区(仅存在),最大速度下的高负载,您根本不应撒谎。 一分钟-这将是可悲的。 怎么办 再次保留全部。 他们做了上一示例中提到的所有事情,还有更多。 一个理想的世界,以及我们的基础架构-就是IaaC devopa的所有概念。 也就是说,一切都在git中,只需单击按钮即可。
缺少什么? 一种是教义。 没有他们,你做不到。 似乎一切对我们来说都是完美的,总体上一切都在控制之下。 我们按下按钮,一切都会发生。 即使是这样-并且我们知道这不会发生-我们的系统与其他一些系统交互。 例如,这些是来自路由53,s3存储的dn,并与某些api集成。 我们将无法预见此推测性实验中的所有内容。 而且,直到我们真正拉开开关,我们才知道它是否有效。

那可能就是全部。 不要懒惰,不要过度使用它。 并可能与您保持正常运行时间!