👨🏼‍🏭 🤑 ⏰ 我们如何帮助学校转变为远程学习并应对负担 🚵 🎅🏾 👨🏾‍🤝‍👨🏼

哈Ha！我叫Alexey Vakhov，我是Uchi.ru的技术总监。 3月中旬，当学校开始转向远程学习时，我们为教师和学生提供了一些在线课程服务。根据我们的计算，我们有一个安全极限，可以承受最大1.5-2倍的负载。 4月中旬，我们的访问量增长了8倍。我不得不做很多事情以保持漂浮。也许有人会需要我们的经验来度过这次或未来的危机。

我们没想到会有这样的惊喜，也没有为它们做好准备，也许在俄罗斯乃至世界上没有一家公司为此做好了准备。通常在三月份，由于春季和即将到来的暑假，Uchi.ru上的活动相对于秋季而言要低一些，当时我们已经在为9月做准备：我们正在查看功能，进行重构，进行大规模的建筑更改并执行另一个令人愉快的例程。但是，这次却有所不同。

该网站上的唯一身份用户峰值一次达到24万，我们记录了本学年以前的最高记录（3万）。此时，负载每天都在增加，我们全天候工作以稳定站点。

当这种负载落在站点上时，通常会形成应用程序，服务，平衡器，基础，网站，渠道。基础架构的所有“瓶颈”都已暴露。在这种情况下，很难诊断问题-从症状上讲，所有问题都是错误的。当流量平稳增长并且发生故障时，很容易进行维修。当负载波动时，最大的问题之一就是了解故障的原因。

在这种情况下工作的策略是消除对站点造成最大影响的因素，然后找到下一个最痛苦的地方，同时寻找潜在的问题并加以解决，依此类推。以下是我们为稳定平台所做的一些最值得注意的事情。

依靠自己

在交通之前的危机中，您作为一个团队成为一体。是否找到解决方案，是否应对危机取决于您的员工。

业内没有人会来，研究您的复杂系统，立即做点事情，一切都会好起来的。当然，如果有时间，世界上会有足够的专家来完成任务。但是，当目前需要基本的解决方案时，您只能依靠知道系统及其细节的团队。业务结果和责任在于团队。建议进行外部检查以逐点连接。

在Slack的一次特别聊天中，反危机团队的运营协调帮助我们快速导航和开展工作-所有问题都在这里和现在得到解决。我们在员工之间划分了责任范围，以确保没有交叉点，并且员工没有做双重工作。在最困难的日子里，我必须全天候保持联系。

扩展云

您无法确保能够应对所有危机，但保持灵活性很重要。云堆栈为我们提供了这种可塑性，并且即使负载急剧增加也有机会保持漂浮。

最初，我们在负载增加的情况下增加了资源，但是在某个时候，我们遇到了云提供商区域的配额。问题在其层面出现：我们的虚拟服务器受到邻居的影响，流量也随之增加，这导致我们的应用程序运行失败。这是预料之中的：我们依赖提供商及其基础设施，而后者又经历了高负荷。我们已经从非优先级虚拟机为主站点释放了一些资源。我们与供应商商定了专用资源。

升级的监控工具

在危机期间，警报实际上并未发挥作用。所有团队成员已经全天候监控所有系统，并且事件管理已缩减为在各个方面的不间断工作。要完全诊断我们遇到的问题，我们的数据太少了。例如，对于监视虚拟机，我们使用Prometheus的标准Node Exporter。他很高兴看到全局图，仔细研究了单个虚拟机开始使用NetData的情况。

优化的缓存存储

键值存储也出现了问题。在其中一个应用程序中，Redis无法应付-在一个副本中，它只能在一个内核上运行。因此，他们使用了称为KeyDB的Redis分支，该分支可以在多个线程中工作。

为了增加另一个应用程序的带宽，我们提出了10个独立的Redis'ov。它们由我们的服务网格代理，该服务网格还对密钥进行分片。即使一两个Redis崩溃，由于一致的哈希，这也不会引起问题。另外，它们实际上不需要管理。

扩大网络

如您所知，每个人640 Kb就足够了。我们始终使用专用的/ 24个子网，但是在隔离的背景下，我们不得不紧急扩展到/ 22。现在，该网络可容纳四倍的服务器，我们希望它足以满足需求。

PgBouncer单独进行

作为关系数据库，我们在任何地方，一些小型虚拟实例以及某处使用PostgreSQL-为主服务器和副本服务器安装多个大型专用服务器。该体系结构的明显瓶颈是母版，在理想情况下，母版仅用于记录，不能水平缩放。随着流量的增长，我们开始依靠CPU。

同时，我们使用安装在向导和每个副本上的PgBouncer来管理连接。在一个端口上，它最多只能使用一个处理器核心，因此在每台服务器上，我们都有多个启动器。在某个时候，很明显PgBouncer本身从底座上夺走了CPU的有形部分，并且在最大负载下，我们经历了平均负载的快速增加和系统性能的下降。

我们将启动器移到了单独的服务器上，这帮助我们在每个数据库服务器上节省了20-25％的CPU。

面对惊喜

只有一种工具无法信任，尤其是在危机时期。相反，工具的冗余会有所帮助，因为它可以看到更客观的图片。熟悉的工具由于各种原因而开始失败。例如，通常为了估计站点上的人数，我们通常使用实时Google Analytics（分析）报告，该报告是敏感而准确的指标。但是有时它很容易出错，这一次我们不得不查看内部指标，例如浏览量事件的数量和每秒的请求数。

对于集中式日志记录，我们使用ELK。我们的日志传递管道基于Apache Kafka和Elastic Filebeat。在高负荷下，原木输送机停止管理，原木开始丢失或滞后。通过操纵Elasticsearch索引，增加Kafka和Filebeat中的分区数量以及在各个阶段进行微调的压缩，我们提高了日志传输和存储索引的速度。由于用于收集日志的管道与生产是分开的，因此日志流量增加的问题对站点的功能没有任何影响。

接受游戏规则

不可能事先为每次危机做好准备，但是您可以首先尝试构建一个灵活的系统。逐渐不再是初创公司的初创公司或公司，在安静的时间里，为流量异常增长做准备并不总是合理的：团队的资源有限。如果我们搁置他们为可能永远不会发生的事情做准备，那么主产品将没有实力。当下正确做出反应，不要害怕大胆的决定，这一点更为重要。通常，摆脱危机的出路是质的新水平。

今年春天真有趣。当似乎所有可能的事情都已完成时，有时事实证明这仅仅是开始。

我们如何帮助学校转变为远程学习并应对负担