Примерно в 06:00 UTC 20 октября сбой электропитания затронул часть инфраструктуры Google Cloud, которую мы используем в Лондоне. Во время сбоя многие клиенты Revolut не могли совершать платежи, снимать наличные или заходить в приложение для проверки баланса.
Мы понимаем, какое беспокойство и неудобства это могло вызвать, и приносим извинения за то время, которое потребовалось для возобновления работы сервисов. Даже во время перебоев с доступом к счетам все счета, клиентские средства и данные оставались в безопасности.
Хотя наши системы спроектированы так, чтобы выдерживать подобные сбои, на этот раз наши резервные системы не приняли нагрузку так, как ожидалось.
В этой статье блога мы предоставим технический обзор первопричины, объясним, почему восстановление заняло больше времени, чем следовало, и расскажем о мерах, которые мы уже принимаем, чтобы это не повторилось.
Что произошло?
Revolut работает в нескольких облачных регионах. Базы данных, затронутые этим сбоем, функционируют в трех отдельных дата-центрах («Зона A/B/C») в лондонском регионе Google Cloud, с репликами в другом регионе для аварийного восстановления.
20 октября примерно в 06:00 UTC в одном из дата-центров (Зона B) пропало электричество, и некоторые базы данных не смогли корректно выполнить аварийное переключение зон.
Мы используем серверы координации, чтобы определять, какая реплика базы данных может принимать новые транзакции. Эти серверы работают группами по пять штук и распределены по трем зонам, причем для достижения кворума требуется не менее трех серверов в каждой группе.
В некоторых группах один сервер был отключен еще до отключения электроэнергии, однако наш мониторинг не выдал предупреждения. Когда в Зоне B отключились еще по два сервера в каждой из таких групп, осталось всего два, чего недостаточно для достижения согласия. Некоторые инструменты, на которые полагались наши инженеры для мониторинга и восстановления баз данных, также зависели от Зоны B, что еще больше задержло устранение неполадок.
Обработка резервных запросов позволила провести некоторые карточные платежи во время сбоя.
- К 12:40 UTC 20 октября авторизация карт и платежи в магазинах снова заработали.
- С 15:45 UTC клиенты начали восстанавливать доступ к приложению, видеть обновленные балансы и совершать переводы. Некоторые платежи, совершенные во время сбоя, отображались в приложении дольше обычного.
- К 17:15 UTC все оставшиеся сервисы возобновили работу.
Что пошло не так?
Наша схема отказоустойчивости баз данных включает реплики в трех отдельных лондонских зонах. Еще одна реплика в другом регионе поддерживает восстановление после более масштабного регионального сбоя. Если зона выходит из строя, менеджер аварийного переключения должен был переключить реплику базы данных в другой зоне. Kubernetes независимо перепланирует затронутые приложения на исправные серверы.
Менеджер аварийного переключения, установленный в каждой реплике, использует распределенное хранилище конфигураций (DCS) для определения того, какая реплика может взять на себя управление. Эти серверы координации используют голосование большинства, называемое кворумом, чтобы фиксировать, какая реплика базы данных является первичной. Серверы работают группами по пять штук и распределены по трем зонам, причем для достижения кворума требуется не менее трех серверов в каждой группе.
До сбоя в затронутых группах были доступны только четыре из пяти DCS-серверов. После того как в Зоне B пропало электричество, два выживших сервера больше не могли сформировать кворум. Менеджер аварийного переключения не смог назначить новую первичную базу.
Позже мы выяснили, что перед сбоем в результате плановой замены серверов не удалось восстановить всех пяти участников одной из групп. Оставшиеся четыре продолжали работать, поэтому клиенты не заметили немедленных перебоев. Тем не менее, мы не получили предупреждения об отсутствии одного из участников, пока еще было время его восстановить.
Ранние отчеты предполагали, что могут быть затронуты несколько облачных регионов, включая наш резервный регион. Некоторые из наших собственных инструментов мониторинга не работали, поэтому нам потребовалось время, чтобы установить масштабы сбоя. Убедившись, что отключение электроэнергии ограничилось лишь лондонской Зоной B, а Зоны A и C по-прежнему доступны, мы решили продолжить восстановление сервисов в этих двух зонах в соответствии с нашим планом восстановления после сбоя в одной зоне.
Факторы, задержавшие восстановление
Восстановление PostgreSQL
После восстановления кворума DCS некоторые кластеры PostgreSQL оставались доступными только для чтения, так как задержка репликации препятствовала автоматическому аварийному переключению. Инженерам необходимо было проверить состояние реплик и определить безопасный путь восстановления. Мы работаем напрямую с Google Cloud, чтобы лучше понять предполагаемое временное падение производительности инфраструктуры и то, как оно повлияло на восстановление баз данных.
Сбои вспомогательных инструментов
Наш основной экземпляр для визуализации метрик баз данных был развернут в Зоне B. Инженеры были вынуждены диагностировать распределенные топологии баз данных через логи, утилиты командной строки и создание специальных автономных экземпляров мониторинга в уцелевших зонах, прежде чем можно было полностью приступить к устранению неполадок.
Что мы меняем
Чтобы гарантировать, что сбой в одной зоне доступности больше не сможет вызвать такой уровень перебоев, мы внесли некоторые изменения незамедлительно и начали работу над стратегическими улучшениями.
По состоянию на 13 ноября мы:
- устранили первопричину и разрешили базовую деградацию серверов координации для восстановления полной функциональности аварийного переключения
- провели тщательный анализ первопричин, направленный на укрепление нашей операционной устойчивости и снижение будущих рисков
- развернули системные улучшения для немедленной обработки возвратов по картам после разрешения очереди автономной обработки (STIP)
- усовершенствовали инфраструктуру мониторинга баз данных для обеспечения доступности во время сбоев в отдельных зонах
Текущие архитектурные и операционные изменения:
- Укрепление тестирования аварийного переключения зон: наша программа тестирования аварийного восстановления охватывает широкий спектр сценариев сбоев. Теперь мы расширили тесты аварийного переключения зон, включив в них условия, наблюдаемые во время этого инцидента, и увеличили частоту проведения тестов.
- Более раннее предупреждение о снижении избыточности: мы внедрили комплексный мониторинг состава кластера DCS, работоспособности голосующих узлов и отказоустойчивости кластера для выдачи ранних предупреждений при угрозе кворуму. Мы также внедряем сквозной мониторинг наших конвейеров оповещения для обнаружения сбоев в создании и доставке предупреждений. Мы добавляем проактивные предупреждения при приближении к нашим квотам облачных ресурсов и нехватке сетевых адресов, необходимых для аварийного переключения зон. Наши учения по аварийному переключению зон будут проверять, сможем ли мы вернуть сервисы в работу под нагрузкой.
- Более устойчивые вспомогательные компоненты и инструменты: мы улучшаем наши вспомогательные инструменты, чтобы сделать восстановление более эффективным и снизить потребность в ручном вмешательстве при выходе зоны из строя. Мы тестируем эти улучшения в рамках существующих учений по восстановлению.
- Ребалансировка размещения баз данных и DCS по зонам доступности: мы уже распределяем реплики баз данных по зонам, однако наш процесс развертывания отдавал предпочтение одной зоне при размещении первого сервера в каждой группе. Мы меняем правило размещения и проверяем, сможет ли каждая группа продолжать работу при выходе из строя любой отдельной зоны в рамках учений по аварийному переключению зон.
Наши обязательства
Revolut строится на ожидании того, что сервисы доступны 24/7, без исключений. 20 октября мы не дотянули до этого стандарта.
Хотя первопричиной стал сбой внешней инфраструктуры, наша архитектура должна была справиться с ним незаметно. Мы устранили уязвимости, которые помешали переключению на резервную систему, и повысили требования к процессам восстановления после сбоев. Мы ценим неизменное доверие наших клиентов и продолжаем укреплять нашу операционную устойчивость, чтобы подобное не повторилось.
