Крупный сбой у хостинг-провайдера Gandi: почта и сайты не работали

В воскресенье 2025-03-09 в Gandi произошёл серьёзный инцидент на платформе, вызванный отказом системы хранения данных файлера, который затронул множество сервисов, включая почтовые ящики.

Краткое описание: – Множество сервисов были серьёзно нарушены с воскресенья 9 марта 0:31:10 до 16:49:15, включая 39% всех почтовых ящиков – Некоторые почтовые ящики (~15%) оставались недоступными до понедельника 10 марта 10:29. Однако, все пользователи восстановили все свои письма к среде 12 марта 17:00:00.  – Важно отметить, что этот инцидент не привёл к потере или повреждению каких-либо данных.

Какова была основная причина инцидента?: 

Основной причиной стал отказ SSD-файлера хранения данных. Однако, несколько дополнительных факторов способствовали серьёзности воздействия:

• Некоторые системы, включая внутренний мониторинг, не имели эффективных мер избыточности для обработки сбоя хранилища

• Некоторые системы, которые имели избыточность на уровне ВМ, были некорректно спроектированы, так что все ВМ зависели от одного затронутого файлера

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

Полная хронология:

Временные метки (UTC)	Событие
2025-03-09 00:31:10	Начало инцидента, дежурные начали расследование более 1500 оповещений; сложно определить основную причину, бот мониторинга был недоступен
2025-03-09 01:11:19	Инцидент был эскалирован, отреагировал технический директор
2025-03-09 01:21:51	Опубликован публичный статус на status.gandi.net с первыми идентифицированными затронутыми сервисами
2025-03-09 01:23:31	Попытка объявить инцидент через инструменты ChatOps
2025-03-09 01:25:15	Обнаружен сбой VPN для сотрудников не из команды операций
2025-03-09 01:33:03	Выявлена проблема: файлер вышел из строя
2025-03-09 01:34:46	Предпринята попытка перезапуска файлера
2025-03-09 01:47:09	Перезапуск файлера не удался
2025-03-09 02:16:21	Дежурный направлен в дата-центр
2025-03-09 03:31:11	Первый отчёт из дата-центра — файлер перезапущен вручную после отключения питания
2025-03-09 04:03:05	Попытка перезапуска не устранила проблему
2025-03-09 04:15:51	Начало перевода сервисов хранения на другой файлер
2025-03-09 05:37:27	Все затронутые системы идентифицированы; мы определили, что все письма корректно поставлены в очередь и потери данных невозможны
2025-03-09 06:40:04	Дополнительные дежурные прибыли на место
2025-03-09 07:01:41	Начато обновление прошивки
2025-03-09 07:15:07	Определён первый критический сервис для перезапуска
2025-03-09 07:20:55	Обновление прошивки не удалось
2025-03-09 07:30:40	Обновление прошивки успешно, но проблема сохраняется
2025-03-09 07:41:11	Мы выявили, что проблема с прошивкой может быть связана с PCI-устройством, поэтому нам пришлось извлечь файлер из стойки и удалить все PCI-устройства
2025-03-09 09:15:57	Нам удалось вернуть в онлайн нашего бота мониторинга
2025-03-09 10:25:00	Нам удалось восстановить VPN, чтобы команда поддержки могла работать корректно
2025-03-09 16:49:15	Нам удалось восстановить все сервисы, кроме почтовых ящиков
2025-03-09 16:50:10	Мы начали восстановление почтовых ящиков
2025-03-10 10:29:06	Файлер вернулся в онлайн после множества аппаратных изменений, и ВМ также вернулись в онлайн
2025-03-10 11:30:15	Мы выявили, что в некоторых случаях некоторые почтовые серверы не монтировали почтовую NFS-систему и сохраняли письма локально. Это некорректное монтирование привело к исчезновению всех старых писем из почтовых ящиков
2025-03-10 13:30:00	Мы начали восстановление соответствующего раздела на затронутых почтовых ящиках. В результате клиенты могли видеть старые письма, но не письма, полученные во время инцидента; мы начали процедуру корректного восстановления писем, которые хранились на неправильном разделе; ни одно письмо не было утеряно, и каждый почтовый ящик имел свои письма корректно сегментированными
2025-03-12 17:00:00	Нам удалось восстановить все письма в каждом почтовом ящике в выделенной папке
2025-03-13 09:00:15	Выявлены проблемы репликации в базе данных квот: Эта база данных хранит используемое пространство для каждого почтового ящика. Нам потребовалось пересоздать базу данных, так как ошибка была неразрешимой. Принято решение воспользоваться возможностью создать новую базу данных, соответствующую нашим новым стандартам.
2025-03-14 14:30:00	Мы пересоздали базу данных. Создание базы данных потребовало ввода всех квот с нуля, что означало пересчёт используемого пространства во всех почтовых ящиках заново. Из-за отсутствующего индекса обновление квот вызывало проблему блокировок, что приводило к падению Postfix и снова затрагивало почтовый сервис.
2025-03-14 16:30:00	Все почтовые ящики снова стали операционными, и мы решили отложить все операции с квотами и перенести их после выходных.

Анализ

Определение основной причины сбоя было осложнено несколькими факторами:

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

Корректирующие действия 

После этого инцидента было принято несколько решений для минимизации вероятности повторения такого инцидента:

• В первую очередь улучшить избыточность для всех наших ботов мониторинга, так как без мониторинга мы ограничены в возможности видеть, что происходит, и это явно замедлило наше время реакции и усложнило принятие решений. 
• Улучшить механизмы избыточности путём настройки автоматического отключения ВМ на затронутых файлерах
• Убедиться, что все избыточные сервисы распределены между несколькими файлерами.
• Обновить документацию и отработать процедуры обходных путей для сбоев критических инфраструктурных систем, таких как аутентификация и сети.
• Увеличить количество ВМ для некоторых сервисов для обеспечения дополнительной мощности для поглощения колебаний трафика, если часть экземпляров недоступна.
• Увеличить избыточность ВМ, предоставляющих почтовые ящики клиентам
• Мы работаем над переходом с системы zfs на ceph, что сделает нас менее уязвимыми к аппаратным проблемам.