Когда у облака выключается зона: что проверить владельцу сайта

Утром 11 октября тысячи владельцев сайтов открыли Метрику и увидели ошибку вместо графика посещаемости. Маркетологи не смогли зайти в рекламные кабинеты, сеошники — в Вебмастер, а команды, чьи сервисы жили в облаке, получили уведомления о недоступной зоне. Сайты при этом продолжали открываться, заказы шли, но инструменты, через которые бизнес смотрит на свой сайт, пропали одновременно.

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

Что произошло, коротко и по официальным данным

С 8 по 11 октября инциденты затронули три дата-центра «Яндекса», но в разной степени. Площадка в Сасово, которая обслуживала зону доступности ru-central1-b, остановлена полностью. Во Владимире, где размещалась зона ru-central1-a, работа дата-центра тоже прекращена. В Калуге, по заявлению компании, из строя вышли несколько модулей, то есть часть инфраструктуры.

Компания связывает повреждения с атаками беспилотников, об этом пишут Ведомости со ссылкой на Yandex Cloud.

Облачная платформа перешла в аварийный режим: зоны ru-central1-a и ru-central1-b недоступны, виртуальные машины работают в ru-central1-d и ru-central1-e. Ресурсы, размещённые только в выпавших зонах, не работают. Часть потребительских сервисов к вечеру 11 октября вернулась, но кабинеты для владельцев сайтов, по данным Хабра, на 12 октября оставались недоступными.

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

Что сломалось у тех, кто просто держит сайт

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

Метрика перестала показывать статистику. Вебмастер закрыл доступ к отчётам об индексации и к отправке страниц на переобход. Рекламные кабинеты не открываются, а значит, остановить или перенастроить кампанию нельзя. В Яндекс Бизнесе не получается обновить карточку организации. Об этом подробно пишут Клерк и Хабр.

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

Важная деталь касается разницы между сбором данных и их показом. По информации специалистов, на которую ссылается Хабр, счётчики на сайтах у части пользователей продолжают собирать события, хотя посмотреть их сейчас негде. Это частая архитектура для аналитики: сначала данные принимаются и складываются в очередь, а считаются и показываются отдельно. Сломалась витрина, но не обязательно приёмка.

Наш замер: что отвечает, а что нет

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

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

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

Как проверить свою зависимость за полчаса

Узнать, на каких внешних сервисах держится сайт, можно без аудита и без подрядчика. Достаточно браузера и получаса времени.

Откройте главную страницу, карточку товара и страницу оформления заказа, затем в инструментах разработчика посмотрите вкладку сетевых запросов. В списке будут все сторонние домены: аналитика, шрифты, карты, виджеты чатов, платёжные формы, системы рекомендаций. Выпишите их и разделите на две группы — без чего сайт продолжит продавать, а без чего нет.

Дальше полезный опыт: в тех же инструментах можно заблокировать запросы к выбранному домену и перезагрузить страницу. Так видно, что произойдёт при его недоступности. Хороший результат — страница открылась, пропал только сам виджет. Плохой — страница висит белым экраном несколько секунд, потому что внешний скрипт подключён синхронно в начале страницы и ждёт ответа.

Второй случай лечится настройкой, а не переписыванием сайта. Сторонние скрипты подключают с атрибутами async или defer, тогда браузер не ждёт их перед показом страницы. Шрифты и мелкие библиотеки можно отдавать со своего сервера. Это полезно не только во время аварий: страница становится быстрее и в обычные дни.

Почему «другая зона того же облака» — не всегда резерв

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

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

Здесь полезно вспомнить, как устроены распределённые базы данных с кворумной записью, без привязки к конкретной компании. Такие системы держат несколько копий данных, то есть реплик, и принимают запись, когда с ней согласно большинство. Три реплики обычно позволяют продолжать работу при потере одной, пять — при потере двух. При потере большинства запись может остановиться, чтобы не допустить расхождения данных. Конкретное поведение зависит от СУБД и её настройки, поэтому для своей системы его стоит уточнить в документации.

Для владельца сайта из этого следует простая вещь. Если база данных магазина размещена в трёх зонах одного облака, она, как правило, защищена от поломки одной площадки, но не от события, которое задевает две. Защиту от второго сценария даёт только копия у другого оператора или на собственном оборудовании.

Что сделать на этой неделе

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

• Оставить счётчики на месте. Сайт они не замедляют, а данные могут продолжать собираться.
• Завести список страниц, опубликованных за время сбоя. Его понадобится отправить на переобход, когда кабинеты заработают.
• Проверить, что карта сайта доступна и её адрес указан в robots.txt. Это помогает роботам находить новые адреса, но не гарантирует немедленной индексации.
• Подключить второй канал аналитики, если его до сих пор нет. Хотя бы для ключевых цифр: посещаемость, заявки, заказы.
• Проверить способы оплаты на сайте. Если среди них есть сервисы, которые затронул сбой, покупателю стоит заранее показать альтернативу.
• Посмотреть, где лежит резервная копия сайта и не завязан ли доступ к ней на ту же учётную запись, что и основной сервер.

Последний пункт самый важный и самый недооценённый. Резервная копия в том же облаке, под тем же логином и в той же зоне защищает от ошибки администратора, но не от проблем самого облака.

Правило 3-2-1 и одна поправка к нему

Классическое правило резервного копирования звучит так: три копии данных, на двух разных типах носителей, одна из них — вне основной площадки. Оно появилось задолго до облаков и за тридцать лет почти не устарело.

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

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

Для небольшой компании самый доступный вариант второй ноги — сетевое хранилище (NAS) с двумя дисками в зеркале (массив RAID 1: оба диска хранят одни и те же данные). Оно стоит в шкафу или на полке, забирает копии по расписанию и не зависит ни от одной внешней панели управления.

Здесь важно не перепутать две вещи. Зеркало из двух дисков — это не две резервные копии, а защита от отказа одного диска. От случайного удаления файлов, шифровальщика или кражи самого устройства оно не спасает: изменение мгновенно попадает на оба диска. Поэтому на хранилище нужна история версий, то есть снимки с защитой от удаления, а для по-настоящему важных данных — ещё одна копия в другом месте.

Synology DS223J — простой вариант на два диска с зеркалом RAID 1 и гигабитным портом. Память в нём впаяна, поэтому под тяжёлые задачи он не подойдёт, но на роль хранилища резервных копий этого хватает. Подробно про двухдисковые модели мы писали в материале «Synology DS225+ vs DS223j».

Локальное железо: что оно даёт и чего не даёт

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

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

Если данных больше, чем помещается в зеркало из двух дисков, логично смотреть на модели с тремя и более отсеками. QNAP TS-364-8G держит три диска в массиве RAID 5, имеет сетевой порт на 2,5 Гбит/с и два слота M.2 (разъёмы под компактные SSD с интерфейсом NVMe) для кеширования. Предел — до 22 ТБ на один диск и до 66 ТБ в сумме. Восьми гигабайт памяти хватает и на копирование, и на виртуальную машину со вспомогательными задачами.

Для офисов со стойкой есть стоечный вариант — QNAP TS-433eU высотой 43 мм на четыре диска. У него два сетевых порта по 2,5 Гбит/с и поддержка массивов от RAID 1 до RAID 60. Про то, как собрать небольшую стойку с питанием и полками, рассказано в материале «Серверная стойка 6U–15U».

Отдельно о дисках. Для хранилища, которое работает круглосуточно, нужны модели, рассчитанные на такой режим, и обязательно с технологией записи CMR. Диски с черепичной записью SMR в массивах RAID ведут себя плохо, и почему так происходит, мы разбирали в статье про диски для серверов и NAS.

WD Gold на 8 ТБ — диск серверного класса с записью CMR, скоростью 7200 об/мин и буфером 256 МБ. В рабочем режиме он потребляет 7,7 Вт, так что даже массив из четырёх таких дисков не создаёт заметной нагрузки на электропитание.

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

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

Raskat HI-650VA выдаёт 650 ВА и 390 Вт, имеет четыре розетки IEC C13 и линейно-интерактивную схему. Для настольного хранилища с внешним адаптером на 60–65 Вт такого запаса достаточно. Стоечному серверу с активным корректором мощности нужен онлайн-ИБП с чистой синусоидой, и о разнице между схемами подробно написано в материале «Онлайн-ИБП против линейно-интерактивных».

Зависимость — это не ошибка, а строка в плане

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

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

Актуальный статус облачной платформы публикуется на status.yandex.cloud. Хранилища для резервного копирования есть в разделе «СХД и NAS», источники питания — в разделе «ИБП» каталога AFOX.SU.