Рано утром 27 августа 2026 года в сервисах Proton произошел масштабный сбой, затронувший ряд пользователей. Основной причиной стал полный отказ системы охлаждения в нашем дата-центре во Франкфурте. Несмотря на то что все системы Proton зарезервированы и у нас достаточно мощностей, чтобы выдержать полный отказ дата-центра, существует небольшое количество сценариев, при которых аварийное переключение может занять больше времени и привести к перебоям в работе сервисов для пользователей.

Ниже представлена хронология событий, принятые нами во время инцидента решения, их причины, а также то, как проблема была устранена.

Хронология событий

В среду, 26 августа, вскоре после 23:00 (по центральноевропейскому времени) в основном машинном зале нашего дата-центра во Франкфурте произошел сбой в системе охлаждения. Около 23:15 температура начала расти и менее чем за полчаса поднялась с номинальных примерно 21,8 °C до 51,9 °C, при этом некоторые датчики фиксировали температуру воздуха в помещении на уровне 60 °C. По мере роста температуры серверное и сетевое оборудование на объекте стало одно за другим выходить из строя.

Инцидент, повлиявший на пользователей, начался около полуночи 27 августа, когда сбои участились настолько, что критически важное резервирование было утрачено. Это произошло из-за выхода из строя как основного, так и резервного сетевого коммутатора в критически важной стойке, где, к сожалению, находилось несколько основных копий баз данных. Хотя практически все системы Proton зарезервированы и автоматически и мгновенно переключаются при сбое, аварийное переключение основных баз данных не выполняется автоматически без контроля со стороны человека.

Мы сохраняем ручной контроль, чтобы избежать ситуаций так называемого «разделения сознания» (split-brain), когда временная недоступность основной базы данных приводит к тому, что реплики пропускают часть обновлений и рассинхронизируются так, что впоследствии их трудно согласовать. Кроме того, при аварийном переключении основной базы данных стандартная процедура предусматривает переключение на реплику в том же дата-центре из соображений задержки и производительности. Однако специфика проблемы заключалась в том, что такое решение могло оказаться опрометчивым, поскольку мы рисковали переключиться на узел, который также вскоре вышел бы из строя.

Принятые решения

В этот момент дежурным инженерам Proton пришлось принимать ряд важных решений в условиях сильнейшего стресса.

  • Что важнее: вернуть сервис в рабочий режим или решить проблему с охлаждением и спасти оборудование в дата-центре?
  • Выполнить аварийное переключение на реплики в том же здании во Франкфурте (быстрее и с меньшими перебоями, но, возможно, лишь временное решение, если не удастся справиться с перегревом) или переключиться на Цюрих?
  • Переключать ли все сервисы или только те, которые недоступны в данный момент? У нас есть планы реагирования на случай полного отказа дата-центра, когда все переключается целиком и практически полностью автоматически довольно быстро, однако ситуация, когда случайные серверы выходят из строя один за другим, плохо обрабатывается нашей логикой аварийного переключения.

В итоге скорость роста температуры вынудила нас отдать приоритет сохранению оборудования, а не скорейшему возвращению сервисов в рабочий режим. Обычно такой выбор делать не приходится, поскольку системы охлаждения, как правило, зарезервированы, а полная потеря охлаждения случается крайне редко, что дает достаточно времени до момента, когда температура станет критической. Проблема усугубляется значительным ростом плотности мощности серверов в последние годы из-за более мощных процессоров и графических ускорителей для ИИ. В результате то, что раньше нагревалось до критического уровня за 3–4 часа, достигло критической отметки всего за 20 минут.

Поэтому дежурная команда сосредоточилась на взаимодействии с операционной группой дата-центра на месте для восстановления охлаждения, одновременно отключая питание как можно большего числа серверов для их защиты. Из-за дефицита серверного оборудования, связанного с текущим бумом ИИ, большую часть этого оборудования в случае выхода из строя невозможно было бы быстро заменить. Его сохранение должно было стать приоритетом даже ценой потенциального увеличения времени простоя.

К 00:45 CEST нам удалось восстановить охлаждение, температура на объекте начала снижаться, и дежурная группа переключила внимание на восстановление работы сервисов. В этот момент мы приняли решение выполнить аварийное переключение основных баз данных на реплики во Франкфурте, если они еще работали, и на Цюрих в тех случаях, когда во Франкфурте не осталось работающих реплик, чтобы избежать сильного изменения потоков трафика и возможного возникновения новой нестабильности. Этот вариант был выбран потому, что мы предполагали: раз охлаждение взято под контроль, вернуть Франкфурт в строй будет относительно просто и быстрее, чем переключаться на Цюрих.

К сожалению, все оказалось сложнее. Во время инцидента многие сетевые карты в инфраструктуре Франкфурта нагрелись до 105 °C (при нормальной рабочей температуре 45 °C), что привело к срабатыванию специального режима защиты от перегрева и отключению сетевых карт до выполнения «холодной» перезагрузки систем. Наша модель безопасности ограничивает доступ к контроллерам внеполосного управления (out-of-band) наших систем, из-за чего нам пришлось разбудить дополнительных сотрудников для помощи в восстановлении.

К 01:30 CEST мы смогли вернуть большинство сервисов в рабочий режим для большинства пользователей. Однако работа некоторых менее критичных систем, таких как push-уведомления или обработка платежей, была восстановлена только около 02:00 CEST.

Как мы сообщали в первоначальном отчете об инциденте, ни одно электронное письмо не было потеряно, однако доставка писем в обоих направлениях во время инцидента задерживалась.

Хотя сервисы для пользователей были полностью восстановлены, для наших инженеров — особенно для команды баз данных — на этом ночь не закончилась. Наша инфраструктура осталась в крайне нештатном состоянии: часть основных баз данных находилась в Цюрихе, а часть — во Франкфурте, при этом некоторые из них работали со сниженным уровнем резервирования и/или пониженной производительностью. Наша команда работала всю ночь, чтобы решить наиболее неотложные проблемы, а работы по восстановлению полного резервирования продолжались в течение всего дня 27 августа.

Хотя нам удалось спасти практически всю инфраструктуру, некоторые серверы, к сожалению, вышли из строя из-за перегрева, и мы пока не знаем, повлияет ли инцидент с нагревом на срок службы уцелевшего оборудования.

Основная причина и следующие шаги

В ходе последующего расследования 27 августа было установлено, что первопричиной сбоя охлаждения стала замена воздушных фильтров на обоих резервирующих друг друга воздушных компрессорах, питающих систему охлаждения. К сожалению, оператор дата-центра проводил эти работы посреди ночи, без предварительного уведомления, а также не сообщил о сбое системы охлаждения в момент его возникновения, что резко сократило имевшееся у нас время на реагирование. Мы тесно сотрудничаем с оператором, чтобы предотвратить повторение подобных инцидентов.

Тем не менее известным ограничением нашей текущей инфраструктуры баз данных является и то, что сбой такого типа может привести к более длительному процессу восстановления, чем обычно. Череда событий, приведшая к этому инциденту, крайне маловероятна, но все же произошла.

Работы по повышению отказоустойчивости баз данных, необходимые для устранения возможности подобных сбоев, уже ведутся и по плану должны завершиться к концу года. Дополнительные инфраструктурные мощности, включая новые площади в дата-центрах, также вводятся в эксплуатацию и, как ожидается, станут доступны в ближайшие несколько недель, что еще больше снизит нашу зависимость от единой локации.

К сожалению, этот инцидент произошел до того, как данные улучшения были полностью внедрены. Сейчас мы изучаем возможности безопасного ускорения оставшейся части работ при сохранении уровня осторожности, необходимого для изменений в критически важной инфраструктуре баз данных.

Мы понимаем, что наши пользователи ожидают от Proton высочайшего уровня надежности, и этот инцидент еще раз подчеркивает важность завершения начатых работ и дальнейшего повышения наших стандартов отказоустойчивости. Мы еще раз искренне приносим извинения каждому затронутому пользователю.