Атаки на ЦОДы «Яндекса»: почему падает больше, чем один дата-центр, и как Pabit строит отказоустойчивость

Сроков восстановления площадок компания не называет. Данные из разных источников местами расходятся — мы опираемся на официальные сообщения «Яндекса» и Yandex Cloud, ссылки собраны в конце статьи.

Утром 8 октября перебои начались не только у сервисов «Яндекса». Временно остановились портал и приложение «Циана», пропала онлайн-продажа билетов «Мострансавто» на 1,4 тыс. маршрутов, с задержками работали «Авито» и Wildberries, тормозили сайты РБК, «Ведомостей» и «Коммерсанта». Днём к этому добавился сбой у DDoS-защитного провайдера Curator — компания объяснила его ошибкой при настройке, но для пользователей всё слилось в один длинный «интернет не работает».

Из этой истории видно три типичные причины, по которым отказ одной площадки превращается в каскад:

• Всё в одной зоне. Сервис формально живёт «в облаке», но все серверы и база стоят в одной зоне доступности. Зона гаснет — сервис гаснет целиком.
• Общие точки отказа. Вычисления разнесены по разным ЦОДам, но авторизация, внутренний DNS или API-шлюз остались в одном месте. Эксперты отмечают, что именно так упали платформы, которые считались распределёнными.
• Резерв, который не проверяли. Резервная копия есть, но где она лежит и сколько займёт восстановление, никто не знает. «Циан», например, переводил процессы на альтернативные ЦОДы и восстанавливал данные из резервных копий — то есть время простоя определялось скоростью восстановления.

Сам по себе пожар в дата-центре — не уникальное событие: оборудование горит, питание пропадает, кабели перерубают. Устойчивость определяется не тем, насколько защищена одна площадка, а тем, что происходит, когда она исчезает.

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

1. 1

   Где физически работает сервис

   В каком облаке или ЦОДе, на скольких площадках и что будет, если одна из них пропадёт целиком.

2. 2

   Где лежат резервные копии

   Если бэкапы хранятся в том же дата-центре, что и основная база, при пожаре они сгорят вместе с ней.

3. 3

   Сколько данных можно потерять и как быстро сервис вернётся

   Это два числа — RPO и RTO. Если поставщик не может их назвать, скорее всего, их никто не измерял.

4. 4

   Когда последний раз восстанавливались из бэкапа

   Копия, из которой ни разу не восстанавливали, — это надежда, а не резерв.

5. 5

   Можно ли выгрузить свои данные

   Экспорт задач и документов — ваш личный план Б на случай любой аварии на стороне поставщика.

Pabit не размещён в Yandex Cloud, поэтому отключение зон ru-central1-a и ru-central1-b на работу team.pabit.ru не повлияло: задачи, мессенджер, документы и созвоны работали в обычном режиме.

Но делать из этого вывод «нас это не касается» было бы ошибкой. Октябрьские события показали, что из строя может выйти любая площадка — у любого провайдера и в любом регионе. Поэтому мы относимся к ним как к учениям, которые провели за нас, и ускоряем работу над отказоустойчивостью платформы.

Цель простая: потеря одного дата-центра не должна останавливать работу команд в Pabit и не должна приводить к потере данных. Вот что для этого входит в наш план:

1. 1

   Резервные копии вне основной площадки

   Автоматические копии базы и файлов, которые хранятся у другого провайдера в другом регионе. Пожар или обесточивание основного ЦОДа их не затронет.

2. 2

   Несколько дата-центров

   Вторая площадка у независимого провайдера с постоянной репликацией базы. Если основной ЦОД пропадает, рабочая копия Pabit уже поднята и содержит актуальные данные.

3. 3

   Распределение нагрузки и автоматическое переключение

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

4. 4

   Никаких общих точек отказа

   DNS, авторизация, хранилище файлов и почтовые уведомления не должны зависеть от одной площадки или одного поставщика — именно на этом в октябре «споткнулись» распределённые сервисы.

5. 5

   Регулярные учения по восстановлению

   Плановое отключение площадки и восстановление из резервной копии по расписанию. Мы считаем резерв рабочим, только если проверили его на практике.

6. 6

   Публичная страница статуса

   Чтобы во время любого инцидента было видно, что происходит, без догадок в чатах.

О каждом этапе будем рассказывать здесь, в Медиа: что сделано, как проверяли и какие показатели получились.

Независимо от того, каким трекером вы пользуетесь, несколько простых шагов сильно смягчают любую аварию:

• Раз в неделю выгружайте задачи и ключевые документы — экспорт есть в настройках рабочего пространства Pabit
• Держите короткий список «если всё упало»: где собираемся, кто принимает решения, как связаться без рабочих инструментов
• Проверьте, от каких внешних сервисов зависят ваши продукты, и где они размещены
• Не храните единственную копию важного в одном месте — ни в одном облаке, ни в одном чате

• Yandex Cloud: нарушение электропитания в зоне доступности ru-central1-b
• Т—Ж: хронология сбоев 8 октября
• CNews: атака на второй дата-центр «Яндекса»
• RUБЕЖ: какие сервисы пострадали после остановки ЦОДа в Сасово
• «Фонтанка»: остановка дата-центра во Владимире