7 апреля в 16:35 по всемирному координированному времени компания Scaleway столкнулась с серьезным инцидентом в зоне доступности FR-PAR-1, который повлиял на наш продукт Load Balancer. Часть инфраструктуры балансировщика нагрузки была недоступна во время инцидента. В результате также пострадали продукты Database, Kubernetes Kapsule и IoT Hub, которые полагаются на Load Balancer как часть своей инфраструктуры.

Проблема была обнаружена и устранена к 17:18 по всемирному координированному времени специалистами по сетевым продуктам и пользователям и API.

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

Сразу началось восстановление сервисов. Большинство сервисов Load Balancer были восстановлены к 20:34 по всемирному координированному времени, а несколько критических случаев заставили нашу команду по надежности сайта и инженеров по продуктам работать до 0:04 по всемирному координированному времени 8 апреля. Продолжительность основного отключения составила почти 4 часа, а общий инцидент длился 7 часов 29 минут.

Приносим извинения за неудобства, вызванные отключением, и благодарим вас за терпение в этот период недоступности. Ваши данные были в безопасности и всегда были защищены, и данные не были потеряны.

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

Анализ воздействия
Инцидент затронул несколько продуктов Scaleway.
Что касается Load Balancer, только 1574 экземпляра Load Balancer, принадлежащих 775 организациям-клиентам, были отключены до того, как мы исправили проблему и начали процедуру восстановления. Эти балансировщики нагрузки и их серверы были недоступны во время инцидента. После инцидента все ресурсы Load Balancer были восстановлены до нормального состояния.

Для базы данных было задействовано до 50 балансировщиков нагрузки, и был потерян доступ к соответствующим базам данных (до 500). Во время инцидента данные были в полной безопасности, но недоступны. В период восстановления создание базы данных и обновление «Разрешенных IP-адресов» было невозможно. Резервные копии оставались доступными и экспортируемыми в любое время.

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

Что касается Интернета вещей, это затронуло 33 клиента. Поскольку Центр Интернета вещей использует балансировщик нагрузки, базу данных и Kubernetes Kapsule, служба была недоступна во время инцидента. После инцидента все клиентские ресурсы Центра Интернета вещей были восстановлены в нормальном режиме.

Основная причина и решение проблемы
Инцидент был вызван ручным вызовом API-интерфейса Load Balancer Trust and Safety (T&S) с запросом на удаление ресурсов злонамеренного пользователя. Этот конкретный вызов не был частью обычного рабочего процесса; он состоял в созданном запросе, который должен был выдать ошибку. К сожалению, ошибка в API, представленная ранее реализацией функции «Проекты», вызвала обход проверок безопасности и спровоцировала лавинную недействительность экземпляров Load Balancer.

Хронологию инцидента можно найти здесь, на странице статуса Scaleway.

Звонок был сделан 7 апреля в 16:35 по всемирному координированному времени, а сигналы тревоги были включены в наш внутренний канал мониторинга в 16:45 по всемирному координированному времени.

Команда немедленно начала процедуру содержания и восстановления.

• 7 апреля 2021 г., 16:53 по всемирному координированному времени. API балансировщика нагрузки был переведен в режим только для чтения, чтобы избежать дальнейших операций со стороны клиентов.
• 7 апреля 2021 г., 17:20 по всемирному координированному времени. Конфигурации балансировщика нагрузки были восстановлены из нашей внутренней резервной копии базы данных, сделанной часом ранее. Данные не были потеряны, так как балансировщики нагрузки не имеют состояния.
• 7 апреля 2021 г., 17:54 UTC. Запущен процесс восстановления экземпляра Load Balancer.
• 7 апреля 2021 г., 20:10 по всемирному координированному времени 1400 экземпляров были успешно вылечены, 110 по-прежнему не работали и требовали ручного лечения.
• 7 апреля 2021 г., 20:35 по всемирному координированному времени. Все экземпляры Load Balancer были успешно восстановлены. Некоторые критические дела еще предстояло расследовать.
• 7 апреля 2021 г., 22:12 по всемирному координированному времени. Службы базы данных и IoT Hub вернулись в нормальное состояние. Некоторые крайние случаи с парой балансировщиков нагрузки и Kubernetes Kapsule все еще решались.
• — Пользовательские сертификаты TLS были недоступны, и их приходилось восстанавливать из безопасного хранилища сертификатов.
• — Обнаружение живучести серверной части не удалось из-за фильтрации IP-адресов на внутренних серверах и того факта, что IP-адреса балансировщика нагрузки изменились.
• 8 апреля 2021 г., 00:04 UTC. Все экземпляры Load Balancer были восстановлены и исправлены. Все услуги вернулись в нормальное состояние.

Как мы предотвратим повторение этого
После анализа происшествия сразу были приняты следующие меры:

• Ошибка Load Balancer T&S API была исправлена, и в тестовые наборы были немедленно добавлены дополнительные тесты.
• Процедура тестирования T&S API была обновлена с дополнительными межгрупповыми проверками и обзорами.
• Kubernetes Kapsule теперь проверяет состояние балансировщика нагрузки перед запуском автоматического восстановления.

И в ближайшее время будут реализованы:

• Улучшение рекомендаций по реализации T&S API.
• Улучшите тестовое покрытие Load Balancer T&S API и используйте инструменты анализа покрытия.
• Развертывайте и разрабатывайте инструменты для улучшения и ускорения общей процедуры восстановления Load Balancer.
• Продукт Database в рамках постоянного улучшения производительности в настоящее время модернизирует свою инфраструктуру Load Balancer, чтобы сделать ее менее подверженной сбоям.

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

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

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