Get best of the week

凤凰属的渡渡鸟的故事。渡渡鸟大倒塌IS

每年4月21日，我们都会回顾2018年Dodo IS大倒塌的历史。过去是位残酷而公正的老师。值得记住的是，重复课程，将积累的知识传给新一代，并感激我们成为的人。在削减的范围内，我们想向您讲述一个故事，并分享结论。您甚至都不希望敌人遇到这种情况。




伟大的秋天历史


第一天，这次事故使我们损失了数百万卢布


在2018年4月21日星期六，Dodo IS系统发生故障。摔得很厉害。几个小时以来，我们的客户无法通过网站或移动应用程序下订单。呼叫中心的呼叫线路已发展到这样一种状态，答录机的自动语音会说：“我们将在4个小时内回叫。”



那天，我们经历了Dodo IS最严重的坠落之一。最糟糕的是，在我们发起第一笔预算为1亿卢布的联邦电视广告活动的前一天。对于渡渡鸟披萨来说，这是一个了不起的事件。 IT团队也为竞选做好了充分的准备。我们实现了自动化并简化了部署-现在借助TeamCity中的单个按钮，我们可以在12个国家/地区部署整体。我们没有尽一切可能，因此搞砸了。

广告活动非常了不起。我们每分钟收到100-150个订单。那是个好消息。坏消息：渡渡鸟IS无法承受如此重的负载而死。我们达到了垂直扩展的极限，无法再处理订单。系统在大约三个小时内不稳定，会定期恢复，但立即又掉下来。每分钟的停机时间造成我们成千上万卢布的损失，这还不包括生气的顾客对您的尊重。开发团队让所有人失望：客户，合作伙伴，比萨店的工作人员和呼叫中心。



我们别无选择，只能袖手旁观，坐下来纠正这种情况。自从周日（4月22日）以来，我们一直在努力工作，我们无权犯错。

以下是我们关于如何在这种情况下找到自己以及以后如何摆脱困境的经验总结。朋友，不要犯我们的错误。

引发多米诺骨牌效应的两次失败


值得一开始的是一切开始以及我们在哪里搞砸。



在2018年4月21日（星期六）下午5:00，我们注意到数据库中的锁数量开始增长-这预示着问题的发生。我们已经准备好要解决的运行手册，因为我们了解了这些锁的来源。

Runbook两次失败后，一切都出错了。几分钟后，底座恢复正常，然后再次开始began锁。las，主数据库rollback_on_timeout有600秒，这就是为什么所有锁都在累积的原因。这是该故事中的第一个重要文件。一个简单的设置可以节省一切。

然后，尝试以多种方式使系统恢复活力，但都没有成功。直到我们意识到在移动应用程序和新站点上接收订单的方案有所不同。依次减少它们，我们能够了解旧的接单方案中的漏洞。

订单接受系统是很久以前写的。当时，它已经在处理中，并已在新站点dodopizza.ru上推出。在移动应用程序中未使用它。最初，创建新订购方案的原因仅与业务规则有关；性能问题甚至不在议程中。这是第二重要文件-我们不知道系统的限制。

第2天。事故消除


团队的反应非常透彻。我们的服务站在Slack上发表了一篇文章，第二天每个人都来了-4月22日，工作从早上8:30开始。没有人需要说服或请假。每个人都理解一切：需要测试，查询优化，基础架构等方面需要什么才能得到支持，帮助。有些甚至全家人来了！来自邻近团队的与IT无关的人员带着食物来到办公室，呼叫中心也派遣了更多人员以防万一。所有团队团结一致，共同奋斗-奋斗！



4月22日星期天的主要目标是重新接受该订单。我们了解到订单高峰将与星期六相当。我们有最严峻的期限-17点钟，新订单将减少。

在这一天，我们按照计划“确保它不会掉落”采取行动，该计划是在深夜的第21天前夕制定的，当时我们已经提升了系统并了解发生了什么。该计划有条件地分为两个部分：

  1. 在移动应用程序中以新顺序实施方案。
  2. 优化订单创建过程。

通过执行这些操作，我们可以确保Dodo IS不会跌落。

我们确定工作和工作的前沿


在移动应用程序中以新顺序实施该方案是最高优先级。我们没有整个方案的确切数字，但是在某些部分，数据库查询的数量和质量，我们专业地了解，它将提高生产率。 15人的团队日复一日地完成任务。

尽管实际上引入了新的订购方案，但我们是在04.21秋季之前开始的，但是并没有完成交易。仍然存在活动的错误，并且任务处于半活动状态。

团队将回归分为以下部分：来自两个移动平台的回归以及比萨店管理。我们花费大量时间手动准备比萨饼店，但明确的分离有助于并行化手动回归。

引入一些更改后，便立即将其部署到预生产环境中并立即进行测试。团队之间总是保持联系，他们实际上只是坐在一个设有视频群聊的大房间里。下诺夫哥罗德（Nizhny Novgorod）和西克蒂夫卡（Syktyvkar）的家伙也一直保持联系。如果有插头，他立即决定。

通常，我们会逐渐带出新的功能：1个比萨饼，5个比萨饼，10个比萨饼，20个比萨饼，等等，逐渐向整个网络扩展。那个时候，我们需要采取更加果断的行动。我们没有时间-下午5点开始新的高峰。我们只是不能错过它。

大约在15:00，此更新已部署到整个网络的一半（大约200个比萨店）。在15:30，我们确保一切正常，并打开了整个网络。功能切换，快速部署，分解成多个部分以及固定的API有助于完成所有这些工作。

其余的团队在创建订单时处理了不同的优化选项。新方案并不是全新的，它仍然使用了遗留部分。保存地址，应用促销代码，生成订单号-这些部分过去很普遍。他们的优化减少了，要么自己重写SQL查询，要么在代码中摆脱它们，或者优化他们的调用。某种东西进入了异步模式，事实证明，某种东西被多次调用而不是一次。

基础架构团队致力于将部分组件分配给单独的实例，以免造成负担。我们的主要问题组件是Legacy外观，该外观进入了Legacy基础。所有工作都献给他，包括实例的分割。

组织过程


早上，我们只有一天中的同步时间，分成小组并开始工作。

最初，我们将更改和任务的整个日志直接保存在Slack中，因为起初没有那么多任务。但是他们的人数在增长，所以我们很快搬到了Trello。在Slack和Trello之间配置的集成会通知拼图中的任何状态更改。

此外，对于我们来说，查看整个生产变更日志非常重要。电子版本位于Trello，备份版本位于卡上的基础结构板上。万一出问题了，我们需要快速找出要回滚的更改。完全回归仅适用于具有新顺序的方案，其余更改则更忠实地进行了测试。

任务以子弹般的速度飞向生产。当天，我们总共对系统进行了15次更新。他们被部署了测试台，每个团队一个。开发，快速检查，生产部署。

除了主要的CTO流程外，Sasha Andronov还在团队中不断提出“如何提供帮助？”的问题。这有助于重新分配努力，并且不会因为有人不考虑寻求帮助而浪费时间。半手动开发管理，将注意力和工作量降到最低。

那天过后，有一种外出的感觉，那就是我们尽了最大的努力。甚至更多。而我们做到了！在15:30，针对整个网络中的移动应用推出了一种接收订单的新方案。 Hackathon模式，每天每生产20个部署！

4月22日晚上平静而晴朗。既没有跌倒也没有任何暗示表明该系统可能很糟糕。

晚上10点左右，我们再次聚会，并概述了每周行动计划。局限性，性能测试，异步顺序等等。这是漫长的一天，还有很长的一周。

重生


4月23日这一周令人难受。之后，我们告诉自己，我们已尽力做到了200％，并尽了一切可能。

我们不得不保存Dodo IS，并决定应用一些医学类​​比。总的来说，这是使用隐喻的第一个真实案例（就像在原始XP中一样），它确实有助于理解正在发生的事情：

  • 复苏-当您需要挽救垂死的患者时。
  • 治疗-有症状但患者仍然健在。




复苏


复苏的第一阶段是根据某些参数在发生故障时恢复系统的标准运行手册。一件事已经堕落了-我们正在做，一件事已经堕落-我们正在做，依此类推。万一发生崩溃，我们可以快速找到所需的运行手册，它们都位于GitHub上，并且由问题构成。

复苏的第二阶段是命令的限制。我们从自己的比萨店采用这种做法。当很多订单被扔到比萨店时，他们知道无法快速煮熟，他们会停下来5分钟，只是为了清除订单行。我们为Dodo IS制定了类似的方案。我们决定，如果情况真的很糟糕，我们将启用一般限额，并告诉客户（他们说，伙计们），请等待5分钟，然后我们将接受您的订单。我们开发此措施是为了以防万一，但结果是我们从未使用过。没用。很好

治疗


为了开始治疗，有必要进行诊断，因此我们专注于性能测试。团队的一部分去使用GoReplay从生产中收集真实的负载曲线，团队的一部分专注于舞台上的综合测试。

综合测试不能反映实际的负载情况，但是它们为改进提供了一些依据，显示了系统中的某些弱点。例如，在此之前不久，我们将MySQL连接器从Oracle 迁移到了新的连接器。在该连接器的版本中，存在池会话错误，这导致以下事实：服务器只是达到了CPU的上限，并停止了服务请求。我们通过阶段测试复制了此内容，并构思并悄悄投入生产。有十多个这样的案例。

当他们诊断并确定问题的原因时，将逐点进行纠正。我们进一步了解，我们的理想方式是异步接收订单。我们开始着手将其引入移动应用程序中。

地狱周：流程组织


一个由40人组成的团队致力于实现一个大目标-稳定系统。所有团队一起工作。不知道该怎么办？帮助其他团队。专注于特定目标有助于避免被浪费，也不会参与我们不必要的废话。



每天有3次同步，这是典型的站起来，就像在经典Scrum中一样。 40人。三周中只有两次（几乎90次同步），我们没有见面30分钟。最长的同步持续了57分钟。尽管通常他们花了20到30分钟。

同步的目标：了解需要帮助的位置以及何时将这些或这些任务投入生产。这些家伙团结在项目团队中，如果他们需要基础架构的帮助，那么一个人来了，所有问题都得到了迅速解决，讨论减少了。

在晚上，为了支持他们，我们的研发实验室在晚上为开发人员准备了食物。疯狂的比萨食谱，鸡翅，土豆！真是太酷了！这种支持尽可能地激励了这些家伙。



在这样的不间断模式下工作真是太难了。 4月25日（星期三）下午5点左右，我们的开发人员之一Oleg Blokhin与CTO取得了联系，CTO从周六开始一直在不停地玩。他的眼睛充满了不人道的疲劳：“我回家了，我受不了了。”他睡得很好，第二天很开心。因此，您可以描述许多人的一般状况。

4月28日的下一个星期六（这对俄罗斯每个人都是一个工作的星期六）更加平静。我们什么都没做，我们看着系统，伙计们稍稍放松了一下。一切都悄无声息。负载不是很大，但确实如此。他们幸存下来，没有任何问题，这使我们确信我们走了正确的路。

跌倒后的第二和第三周已经处于较为平静的状态，直到深夜的地狱般的步伐消失了，但是戒严的一般过程仍然存在。

第二天X：强度测试


第二天X是5月9日！有人坐在家里监视系统的状态。我们当中那些去散步的人带上了笔记本电脑，以防万一出问题。我们的服务站Sasha Andronov靠近傍晚高峰的一家比萨店，以便在遇到问题时亲自查看一切。

那天我们在俄罗斯收到了91500个订单（当时是渡渡鸟历史上的第二个结果）。甚至丝毫没有问题的迹象。5月9日证实我们走上了正确的道路！注重稳定性，性能，质量。流程重组进一步等待着我们，但这是一个完全不同的故事。

复古大秋天和6种习俗


在紧急情况下，会发展出可以并且应该转移到安静时间的良好做法。集中精力，团队间的帮助，快速部署到生产而无需等待完整的回归。我们从复古开始，然后开发了流程框架。



前两天讨论了惯例。我们没有为自己设定“在2点进行回顾”的目标。在发生这种情况之后，我们准备花时间详细阐述我们的想法和新流程。大家都参加了。参与恢复工作的每个人都以一种或另一种方式。



因此，我想详细谈谈6种重要的做法。

  1. Top N . , . Product Owners , , , . . , . , , , . , . N – Lead Time .
  2. . . -, , . , , , . .
  3. . , « » . , . , , . , - . Dodo IS. .
  4. Pull Request. , Pull Request, - . . , , , , - . , . , . 15 .
  5. Performance- — . performance- . , . Performance- . baseline , PR . , .
  6. Performance . — . , , -, , , . . , .



1.

21.04.2018 – Dodo IS. ?


(Site Reliability Engineering): . , .

(Site Reliability Engineering, Product Owner Dodo IS): . , , .

auth’, . . , .

, () :



. , .

. , . . -. , , . - , , . , -, , .

. redis, . . - , . .

Dodo IS . . , . , , , , . , — .

. « ». « , » .

- ?


:

– . . . , . . .

:

. , . ( ), - . .

. :

  1. .
  2. .
  3. , .

?



:

, , , .

:

, , . , .

? ?



: , – .

:

  1. — . - - .

    , . 2018 , PerformanceLab, .
  2. , . Less-.
  3. . 2018 -, . , . - 2018 .
  4. async . , 21.04.2018 . , . async.
  5. . , SaveOrder async-await. , . : , LF, 20 . , . , . !

    , , , .

    , , . — -. .
  6. . , (, ). , . «» . nginx , - , .

    : innodb_lock_wait_timeout = 5; innodb_rollback_on_timeout = ON. . , , , , .

, ?


:

  1. , , , . , .
  2. , .
  3. , , , . – .

:

  1. .
  2. . , , -. .
  3. . , - , .

, ?


:

«» , «». , , . .

:

, . , , . .

2. , (Dodo IS Architect)
— , . , — .

, , . , (, , ) .

IT-. Dodo IS, . …

X , . . Dodo IS , , , . , , , . . 146%, . , Dodo IS ?

, . , , . , . , !

, . « »: 11- , , 2 . «» . 3-4 , . , . .

, , . . Dodo IS , « ». ! ( ).

, Dodo IS , . Dodo IS . « », , . ( ), loadtest, , .

More articles:


All Articles