哈Ha！
一周前，有
一篇文章 ，我就如何准备一个电子商务项目以应对爆炸性的流量增长和其他大规模促销活动进行了对话。
我们找出了关键的技术细节，现在我们将关注高峰负载期间的管理问题和优化支持流程：
- 是什么使站点不稳定，以及为什么云不是灵丹妙药？
- 为了在出现重大损失之前发现问题，需要监视哪些业务参数；
- 如何将事件从事件路由到解决方案而不会造成混乱，并定位故障。
还有更多-我要求所有人削减！
以我的经验，为大规模行动做准备时最大的麻烦是强大的行政压力。 直到那时，这家公司一直很平静，但突然间，它希望每个人都在路上，把灰尘吹走，等等，“上帝禁止发生的事情，我们将被罚款。” 让我们尝试满足这种普遍的愿望。 我们将以“黑色星期五”为例来讨论这个问题，因为这是站点负载急剧增加的最明显例子。
我们将从一个基本问题开始：到底是网站不稳定运行的原因是什么？
是什么导致网站不稳定
是时候做您一直拖延很久的事情了。 要了解导致站点不稳定的因素，请提出并分析问题的历史记录。 只是不要说您没有它。
您的最高收入将有以下原因：
- 释放相关的崩溃。
- 管理员搞砸了-修复了一个，但是另一个坏了。 不幸的是，这样的覆盖层通常是隐藏的，并且没有历史记录。
- 破坏业务-歪曲行动，删除某些内容等。
- 联盟服务已损坏。
- “悲伤”软件。 最常见的是由于段落而发生。 1和2。
- 物理伤害。
- 其他问题。
当然，所有情况都不同，您的“评分”可能会略有不同。 但是，
与网站和
人为因素的 变化相关的问题
，以及他们共同的爱的果实（发布或尝试优化某些东西）仍然会导致问题。
消除这些问题，以便在第一次尝试进行必要的更改时不会破坏正常工作的任务，这是许多副本已被破坏的任务。 而且我们只有很少的时间，大约只有四个月。 幸运的是，这可以在本地处理。 为此，请遵循一些简单的规则：
1.有效-请勿触摸。
在一个月的几周内尽早完成所有计划的工作。 尽早解决改进将告诉您事件的历史。 它显示问题的主要尾部持续多长时间。 之后，在负载通过之前，请勿触摸站点和产品基础架构。
2.如果仍然需要紧急维修，请进行测试。
定期，孜孜不倦地进行，即使是最小和较小的更改。 首先，在包括负载在内的测试环境中，然后再将其传输到产品。 再次，测试并重新检查站点的关键参数。 最好在负荷最小的夜晚进行工作，因为如果出现问题，您应该有时间保存情况。 好的测试是一门科学，但是即使是
智能测试也比没有测试要好。 最主要的是不要依靠“也许”。
在高负载下冻结更改是唯一可靠的工具。
与会员服务有关的内容，我们已经在上一篇文章中讨论过了。 简而言之-毫不留情地断开连接以解决任何问题。 大多数情况下，服务的许多用户会立即遇到问题，因此联系技术支持是一种低效的措施。 您的来信将无法帮助他们更快地修复，在没有他们的情况下，服务的IT部门会很忙。
但是，如果您没有报告问题，也没有在事件发生时得到事件编号，则很可能将因违反SLA而向服务处以罚款。
关于可靠性的一点
作为准备的一部分，您需要更改所有发生故障的硬件和群集服务。 我以前的一篇文章中对此
有更多的介绍。
我想提请您注意以下流行的误解：在许多人看来，将站点从其服务器转移到云会立即提供+100的可靠性。 不幸的是，只有+20。
为了提高虚拟服务器的容错能力，商业云只需几秒钟即可自动执行并加速故障硬件的“更换”，从而自动在其中一台实时服务器上提升虚拟机。 关键字-“加速”和“下落的铁”。 虚拟机仍将重新启动。 由于资源消耗和受保护虚拟机的性能下降，在商业虚拟化中通常不使用允许您从重新引导中退出的VMware Fault Tolerance和类似产品。 因此得出以下结论：商业云不是容错的灵丹妙药，它的主要优点是灵活性和可伸缩性。
查看您必须更换或维修物理设备的停机时间的历史记录。 迁移到云端后，它们的数量将减少，并且-是的，您的生活会变得更加轻松。 您不必为新服务器而跑到仓库或商店。 但是现在，虚拟化笑话将被添加到崩溃中。
机器可能不可用，但是物理主机仍在响应。 云将不会看到此问题。 或正好相反：主机没有响应，但是虚拟机一切正常。 在这种情况下，虚拟化会将它们提升到其他地方。 需要花一些时间才能开始，然后您又会变得无所适从。 在负载下，这可能是致命的。 因此，即使在云中，您也需要记住冗余。 顺便说一句，警告虚拟化提供商有关哪些计算机相互备份是一个好主意。 否则，您的所有汽车都可能最终会驻留在同一台物理服务器上并同时死亡。
这是在负载测试期间将节点放到群集中并查看会发生什么情况的时候。 使用
正确配置的群集和
正确分配的资源，这不会对测试结果产生不利影响，并且不会引起很多错误。
看来我们已经完成了所有典型的“鼓”。 在继续阅读之前，建议您刷新
上一篇文章中描述的技术细节。 毕竟，如果站点在技术上无法承受负载，那么反应速度将无法为您节省。
现在让我们考虑如何为异常或突发事件做好准备。 我们无法从定义上阻止它们，因此仍然需要卷起袖子并学习如何尽快修复它们。
解决事件的步骤
考虑什么时间可以消除事故：
- 故障检测速度-监视延迟，接收来自用户的消息等
- 对检测到的事件的响应时间-有人应注意该报告并进行处理。
- 是时候确认事件的发生了-是男孩吗？
- 是时候分析事件并找到解决方案了。
- 是时候解决事件和问题了。 并非总是可以在第一时间修复所有问题，并且此阶段可能需要进行多次迭代。
通常，支持服务负责故障排除。 如果团队很大，则每个步骤可以由不同的人员执行。 如您所知，时间就是金钱。 就我们而言，确实如此。 黑色星期五的持续时间固定，竞争对手时刻保持警觉-客户可以花所有的钱在他们身上。 因此，至关重要的是，每个员工都必须了解自己的职责范围，并由输送机解决事件。
让我们分别查看每个阶段，确定问题点并考虑快速优化它们的方法。
下面的所有技巧，提示和建议都不是“美丽生活”的秘诀，而是您可以在剩下的3-4个月内（直到黑色星期五）实施的特定操作。
检测事故
在最失败的情况下，客户端会告知您问题所在。 就是说，问题是如此严重，以至于他
花时间报告 。 在这种情况下，只有非常专注的客户端会写或打电话，而简单的用户会耸耸肩离开。
此外，客户通常无法直接访问IT部门。 因此，他要么写信给一些info@business.ru，要么从呼叫中心打电话给女孩。 当信息蔓延到IT部门时，将花费大量时间。
假设我们有很多忠实的客户，每个人都认为撰写TP中的问题是他的职责。 尽管该事件被归类为大规模事件，但在逐步升级和决定的过程中，将花费数小时。 同时，个人通话可能会丢失，并且有时infoinfo@business.ru的邮件有时数周都没有抽空。
因此，对主要业务参数启动独立监视将非常有用。 至少-网站上的用户数量，购买的数量及其比例。 这些数据将使您能够在出现问题时快速做出响应，并大大减少了识别（和解决）站点中特定问题的时间。
没有用户？ 我们需要看看他们可以去哪里。 网站上有用户，但没有销售？ 这是问题的信号，而且很晚了。 自动化的方案测试将帮助您发现
某处发生了
某些事情。 通常，自动测试可以在内部版本或发行版上运行，但是它们对于监视来说很好。 在他们的帮助下，您可以通过用户的眼睛看到某些重要业务流程的崩溃或放缓。
当然，如果您没有进行场景测试，那么在黑色星期五之前的几个月内，您将无法涵盖所有的生产测试。 是的，它们会给您带来沉重的负担。 但是，通过对十几个基本过程的测试，很可能及时完成。
跟踪平均服务器响应时间也非常有用。 如果增长，您会遇到销售问题。 此类数据应由监视系统自动监视。
如您所见，通过强大的监视功能，您可以将检测问题所需的时间
从数小时和数天减少到
几分钟，有时甚至可以在问题完全解决之前就看到问题。
事件响应时间
我们做得很好，并且由于有了监控，我们立即发现了故障。 现在，您需要开始事件，分配优先级，路由并分配负责进一步处理的人员。
这里有两点很重要：
即使他们的智能手机上有客户，许多IT专家也不习惯快速回复信件。 因此，重要的通知不应通过电子邮件发送。
使用SMS发出事故警报。 更好的是，在最关键的情况下实现自动拨号程序。 我个人还没有看到这种机器人的任何实际实现，但是如果资源允许，为什么不呢？ 作为最后的选择，请使用WhatsApp / Viber / Jabber。 las，出于许多可以理解的原因，俄罗斯联邦境内的电报不能成为紧急通知的可靠渠道。
如果没有确认，自动升级事件也可能很有用。 也就是说，如果通知的主要接收方未响应，则监视将通知下一行。 该系统将向您保证何时出现问题（或某人）。
现在让我们谈谈如何快速响应故障消息。 首先，必须准备有人负责处理警报。 整个团队的警报都是有用的，但只是为了使人们保持最新状态。
当需要速度时，集体责任是不可靠的。
如果您没有在整个操作过程中按时间表安排手表，则可能会遇到不可抗力时有人入睡，并且有人无法在家中使用的情况。 有人会在路上。 实际上，没有人在接下来的一个小时内解决这个问题。 当然，您可以安排一个全天候的业务值班员，但是这里有些细微之处。 您不会强迫优秀的专家不断轮班工作，这意味着当您需要他们时，您仍然必须寻找他们并唤醒他们。 而那些仍在轮班工作的人则紧密地脱离了团队生活的一般背景。 这对其计划任务的有效性具有最致命的影响。
可以为我们节省的是，在大多数项目中，我们需要快速响应消息，了解发生的情况，并且急需每天
大约18小时进行维修。 通常情况下，从第二天早上6点到晚上8点到第二天早上1-2点，流量和销售额最多可达到90％。
为了避免重叠，将值班人员的工作时间表更改为以下格式就足够了：
- 6：00-15：00和17：00-22：00-“在家”值班；
- 15：00-17：00-掩盖办公室里的人；
- 02：00-06：00-流量很少。 但是，请任命一个睡得不好的人。
不要忘记周末。 此问题可以通过相同的方式解决。
如果您的日常用户活动分配不同，请选择一个类似的时间表，在该时间表中，黄金时间站点不会无人值守。
值班意味着负责处理监视事件，来自先前线路的呼叫（客户支持）并监视整个系统。 但是，当一切都安静下来时，值班人员仍在从事他的主要工作。
确保在装载开始前几天开始值班。 首先，这将再次确保每个人都具有所有访问权限。 其次，工作模式的改变是压力，许多人将需要“安顿下来”。 如果成瘾的时期与主要的高温不相吻合会更好。
太好了，警报来了，应该对那些人做出反应。 但是，值班人员的响应时间在很大程度上受到不必要和未处理的警报以及通知的影响，这些通知在原则上不涉及任何操作。
重要的是不要留下未处理的警报。 如果定期发生许多类似事件，请调查原因并进行修复。 监视系统
中根本不应有活动警报。
根据经验，如果某项无法快速修复或不需要修复，但仍然“闪烁”，最好抑制通知并创建开发任务。 不断闪烁的警报早晚会变得熟悉，并且不再引起注意。 问题在于，当出现实际问题时，人们会混淆灯泡，而忽略真正重要的事件。
监视系统中事件的正确配置和优先级仍然非常重要。 系统应确切通知您需要修复的内容。 关于特定故障或发生故障的风险。 您不会修复100％CPU使用率吗？ 您将消除WEB服务器上的高延迟，因为CPU使用率是用于调试的信息，而不是问题。 如果在黑色星期五，处理器以目标负载，响应速度和考虑到库存的100％负载加载了处理器-这意味着您已经正确计算了所有内容。
必须控制系统资源的使用，但这是一项稍有不同的任务，这对于资源规划和确定事故影响区域很重要。我们设置了事件，现在重要的是正确地确定要首先纠正的问题的优先级。 为此，我们将找出“严重”和“警告”警报级别之间的区别。 让我给您一些夸张但可以理解的例子。
至关重要 -这是您在地铁上去奶奶时收到警报并前往最近的车站的时候。 您拿出一台笔记本电脑，坐在小长凳上开始工作-停止了销售或出现了严重亏损。 也就是说，关键对用户有直接但重要的影响。
警告 -这是您在维修之前不离开工作的时间。 不必为了警告而扔掉一切并竭尽所能。 您可以完成/做出决定。 例如，很明显存在严重问题的风险，例如HA对中的服务器掉落，日志中出现错误等。 如果您不参与并认真修复此类事件（以及深入研究原因并进行预防工作），那么这些事件将很少。
另一件事经常被遗忘。 不要只让管理员值班。 确保为每个班次形成工作对以吸引开发人员。 在接下来的步骤中，这将对我们有用。如果该项目的功能复杂，则可以派遣顾问，分析师，测试人员和所有可能对值班有用的人员。 至少通过电话确保其可用性。 专家将必须确认问题（反之亦然），并在功能本地化方面提供帮助-当您必须抚养人进行维修时，这将节省您的时间。 我将在下一节中更详细地讨论此问题。
最后一点。 在紧急情况下，每个值班人员应彻底了解其所有同事的联系和职责范围。 如果他不能自己解决问题，并且慌乱地开始寻找可用的救援人员，那么混乱将会来临，因此您将浪费大量时间。
遵守这些简单规则将有助于避免因错过通知而造成的问题，并确保在紧急情况到来时（请同时阅读“黑色星期五”和“紧急情况”），人们将能够迅速解决问题。
确认事件
收到通知后的下一步是了解究竟出了什么问题以及原则上是否存在问题：立即确定谁是对的用户或系统并不总是那么容易。 事实是，同一警报可以根据视角进行不同的解释。
例如，一位典型的管理员收到有关搜索引擎中错误的信息（货物丢失），他将去检查搜索服务器并阅读日志。他将花费大量时间，并确保搜索工作正常。然后，他将爬得更深，以尝试了解损坏的地方。结果，事实证明，“丢失”的商品被特别隐藏了，没有问题，只是用户不知道。否则，管理员将进入昏迷状态，然后由于缺少语料库而关闭票证。好吧，什么，其他产品很好看！但是实际上，有人不小心从数据库的着陆页中删除了商品，整个广告活动变成了“无用的”活动。在第一种情况下，由于信息不完整，管理员花了一些时间来定位一个不存在的问题。第二是“责备”他的视角。管理员将搜索一个技术问题，而分析师则迅速发现了逻辑并恢复了货物。只有一种解决方案-如果收到自动通知，您应该清楚地知道它的含义以及如何检查它。优选地，以书面指示的形式。如果我们谈论的是来自用户的消息，首先，应该由具有技术背景的功能专家来处理消息。将由他来处理另一个烦人的问题-您完全熟悉的混乱消息，例如“一切都在我身边闲逛”，“您的网站已关闭”和“我点击了，但它不想这么做”。在进一步研究之前，您需要了解一个人究竟发生了什么，并确保问题是“真实的”。为此，有礼貌且经验丰富的专家应该坐在技术支持中，用户报告问题。根据访问者的说法，他们的任务是尽可能多地获取信息并了解哪些功能无法正常工作。根据这些信息，我们可以判断的依据：这是一个技术问题与网站，或者我们应该说，界面直观证明是不够的。我们定位故障
很好，我们收到了警报。确保有问题。接下来，您需要了解其技术本质并概述其影响范围。我们必须看到什么完全不起作用，为什么以及如何解决。在这一阶段，我们的主要敌人与以前一样：缺乏信息。良好的监视和记录功能有助于补充它。首先，我们在第一段中讨论的系统的关键参数-销售，访问者，页面生成速度，服务器响应中的技术错误，应在服务室的大屏幕上以图形的形式显示（越多越好）支持。
所有重要数据始终应该在您的支持团队面前。在紧急情况或任何其他行动中，这将使他们能够快速响应指示器的变化并防止出现问题。要定位发生故障的组件，您将需要一个站点图，其中包含有关组件交互及其关系的数据。为了快速检测问题点，您需要动态跟踪每个交互流的数据。例如，应用程序访问数据库。这意味着对于服务器端和客户端端的每个数据库服务器，我们应该看到以下内容：- 每秒的请求数；
- 回应数
- 响应生成时间；
- 传输的响应数量；
- 此互动的技术错误（授权，连接等）。
将问题组件本地化之后，您可以转到日志中，查看它有什么问题，可怜的东西。最好使用集中式日志收集器来加快此过程。例如，在ELK上。而且，正如我在上一篇文章中所写，由于搜索集群日志的便利性以及跟踪整个链上的请求处理的能力，因此可节省大量时间。解决崩溃
在这个阶段，我们终于修复了故障，并找出了如何加快此过程的过程。显然，我们的最佳帮助是故障排除说明。不幸的是，只有在我们之前已经遇到这种情况时，我们才会拥有它。好吧，他们没有忘记写下可行的解决方案。如果没有说明，您将不得不采用反复试验的艰难方法。当您必须修理产品上的新东西时，您需要权衡工作的安全性和早期干预的需要。在测试环境中检查校正，一方面可以降低风险，另一方面可以延迟解决问题的速度。我尝试遵循以下规则：如果我绝对确定它不会变得更糟，或者不可能在测试环境中重现该问题，则可以尝试立即将其修复在产品上。但是只有当三个因素同时发生时，这种方法才是合理的：- 一切都在说谎；
- 这种药物不会影响有价值的数据。
- 有备份。
在其他情况下，值得在测试中重现该问题，并在将其转移到生产环境之前仔细检查所有内容。前阶段的高质量工作（对问题及其定位的意识）将有助于避免重复进行更正。通常，如果我们修复未损坏的东西或未考虑到某些东西，则第一次修复它是行不通的。再一次，负载测试可以解决。我们效仿生产人员的工作，并开始专门破坏它。为了了解其工作原理以及某些问题对其产生的影响，这是必需的。此外，这是学习如何修复应用程序的好方法，同时-编写有关修复应用程序的说明。之后，可以进行战术练习来定位并消除测试区域中的问题。例如，当一位领先的专家巧妙地弄碎某物时，甚至可能不在一个地方，然后派人去整理并自己修理。一会儿。很好的做法。习惯于在压力很大的情况下工作，并且您学习系统并磨练自己的技能，大海就是新的指示。在结束我们的小型有条不紊的教育计划后，我想提请您注意当前指示，正式时间表和许多人不喜欢的其他无纸化内容的重要性。是的，它消耗了大部分时间和精力。但是当雷声来袭时，所花费的时间将返还给您一百倍，您可以将其“固定在一张纸上”，而不必担心。操作是SLA。SLA是关于在每个阶段整体上和分别地遵守时序。为了控制SLA的实现以及这些时间安排，您需要知道每个阶段的时间限制。否则，除非您超出框架范围，否则您不会意识到自己已经来不及了。而且，如果不固定每个阶段的工作算法和特定操作，就无法评估或保证这些阶段的持续时间。创造力非常有趣，但完全不可预测。为灵魂而做，并测试和实施最成功的解决方案，但不要在黑色星期五或其他促销活动的准备期间进行。商家对此表示感谢。
到目前为止，这就是我要讲的全部内容。如果我的建议被转移到您的业务现实中，能够使我从容应对高负荷，那么我将感到很高兴。如果您需要有关如何采取行动的建议，我邀请您参加我的黑色星期五研讨会。生存的秘密。” 以问答形式，我们将讨论为流量增长准备站点的过程，并讨论此过程的技术和组织细节。研讨会将于8月16日在莫斯科举行。由于活动将是很多会议厅（最多25人），因此需要预约。我正在等待其余的评论中的讨论。 :)