Давеча, поговаривают, были повреждены дата-центры Яндекса: по сообщениям СМИ, в результате атак беспилотников — в ночь на 8 октября в Сасове (Рязанская область), на следующий день в Калуге, а затем была затронута и третья площадка.
А как это повлияло на обычного пользователя, который, казалось бы, вообще никак не связан с ИТ?
«Я»-сервисы гиганта — Карты, Пэй, Музыка и прочие — какое-то время были недоступны. Но есть и другое: посыпались и те, кто к Яндексу формально отношения не имеет. Среди пострадавших называли даже государственную систему ВетИС. Бизнесы, чьи системы стояли на железе в этих ДЦ, остановились вместе с ним, а кое-кто, например, некоторые медицинские страховые, до сих пор не смогли восстановить работу.
Сегодня поговорим о том, почему «облака» — это, в общем, просто чужие компьютеры, и почему надёжность вашего бизнеса — это ваша головная боль, а не проблема Яндекса, VK или Сбера.
Не первый год наблюдая ИТ-аутсорсинг и аутстаффинг изнутри, не побоюсь утверждать: значительная часть предпринимателей с большим удовольствием живёт в парадигме «Мы переехали в облако крупного гиганта — мы в домике!». ИТ с не меньшим удовольствием поддерживает этот вайб: собирать готовые XaaS-решения на верхних слоях легко и удобно, никаких хлопот.
С другой стороны, избыточность стоит денег, и она, ясный пень, избыточна, и когда топ-менеджмент транслирует «на такой бюджет ты меня не убедил», ИТ отвечает: «ОК, наше дело предложить и просигналить, а там хоть не рассветай».
Да, многим руководителям кажется, что всякий IT-гигант нанял армию инженеров, построил бункер и лично охраняет каждый байт наших номенклатур и контрактов — причём по сходной цене.
Справедливости ради: провайдер действительно может обеспечить очень высокий уровень надёжности. Резервное питание, несколько каналов, дублирование, распределённые площадки — всё это существует и работает. Но надёжность провайдера и устойчивость именно вашего бизнеса — не одно и то же. Вторая зависит от того, где лежат ваши данные, куда уходят ваши копии и как устроено ваше восстановление.
Горящий дата-центр не выбирает, чьи данные уничтожить — транснациональной корпорации или вашего ИП по продаже сантехники. Когда ЧП случается на физической инфраструктуре, «падают» все.
И пока юристы гиганта будут ссылаться на форс-мажор в договоре (а они будут), ваш бизнес будет простаивать здесь и сейчас. Даже если провайдер юридически ничего вам не должен, это не вернёт потерянные заказы.
Всё хорошо, только пока всё хорошо. ауф!© :)
В инженерной среде есть золотое правило: отказ неизбежен. Разница между хорошей архитектурой и решением «на коленке» не в том, что первая никогда не ломается. Разница в том, что происходит, когда она рушится.
Сервисы, база данных, альтернативные машины и бэкапы находятся в одном ДЦ.
"ДЦ упал — бизнес стоит до воскрешения площадки".
А вместе с площадкой может оказаться недоступно и то, что должно было вас спасти.
Критичные данные реплицируются на другую площадку другого провайдера. Бэкапы каждые сутки улетают на независимое хранилище и в пирамиду версий. Имеется сценарий: кто, что и в какой последовательности делает, если основная площадка недоступна. Возможно, автоматизировано переключение на запасной контур автоматически — или руками, по заранее проверенной инструкции.
"этот ДЦ упал, а пользователи и не заметили, работа будет продолжаться", или "мы стоим, но время до восстановления известно".
Понятное дело: не ждём чудес. Да, ещё одна площадка сама по себе не значит "всё само себя настроит". Нужны свежие данные, подготовленные доступы, рабочие каналы и отрепетированная процедура. Но даже ручное восстановление по понятной инструкции лучше, чем впервые разбираться в устройстве системы посреди аварии.
Нас приглашали как аварийную команду несколько раз - это ОЧЕНЬ трудно.
Корейские госуслуги. В сентябре 2025-го пожар в государственном дата-центре в Тэджоне (Южная Корея) остановил сотни госсервисов. Из 96 уничтоженных систем впоследствии 95 таки вернули из резервных копий. Не вернули одну — файловое хранилище чиновников G-Drive на 858 ТБ: копий у него не было, «слишком большой объём, дорого хранить». Восемь лет рабочих материалов ушли в дым. Да. Даже у государства. Даже на одну систему из девяноста шести. [Korea JoongAng Daily / DCD]
Если вам кажется, что устойчивость — космически дорого и только для банков, давайте спокойно посчитаем.
Не будем брать Озон или ВБ (хотя им тоже досталось), особенно с учётом последних трендов по оттоку с маркетплейсов на собственные интернет магазины. Вот, скажем, небольшой интернет-магазин встал на сутки. Потери — это не только недополученная выручка. Это ещё зарплаты простаивающих сотрудников, проплаченная реклама, сорванные сроки, возвраты, лиды, ушедшие к конкурентам. Теперь сравните эту сумму со стоимостью независимого хранения копий и заранее подготовленного сценария восстановления, да даже с полным дублированием на резервную площадкус автоматическим подхватыванием!
Не всегда выгодно строить резервный контур с автопереключением. Но пока вы не знаете цену часу простоя, вы не можете решить, сколько разумно тратить на защиту от него.
И важный нюанс:
Если восстановление занимает три дня, а бизнес выдерживает простой не больше четырёх часов, самая аккуратная резервная копия проблему не решает. Нужен другой сценарий.Это и есть RTO — время восстановления (см. глоссарий внизу). Это нужно знать до аварии, а не после.
Не обязательно строить собственный ЦОД. Не обязательно дублировать каждую систему. Не обязательно платить за максимальную доступность. Иногда хватает одного провайдера и независимого хранения копий. Иногда нужны две площадки. А иногда — понятная инструкция ручного восстановления и порядок работы без части цифровых сервисов.
О, эта вечная классика системного администрирования!
— У нас есть резервные копии?
— Да, конечно, настроено автокопирование каждый день!
— А восстановить пробовали?
— …Зачем?
Пользователи часто не хотят тратить время на проверку своих данных в копиях. Иногда и ИТ не считает это приоритетом: задания выполняются, ошибок в журнале нет, значит, всё хорошо. Но любой бэкап находится в состоянии неопределённости, пока из него не развернули рабочую систему начисто. До тех пор у вас нет резервирования. У вас есть просто файл, который красиво называется и занимает место на диске.
И ещё: репликация — не бэкап. Реплика исправно перенесёт на вторую площадку и сбой, и ошибочное удаление, и шифровальщика. Копия нужна, чтобы вернуться к состоянию до беды.
Для бизнеса, который не может позволить себе надолго остановиться, я бы выделил четыре обязательные вещи:
Знание. Свои RPO и RTO: сколько свежих данных вы готовы безвозвратно потерять (во что это обойдётся?) и сколько готовы ждать восстановления (а во что обойдётся это?).
Размножение. Правило 3–2–1: минимум 3+ копии данных, на 2+ разных типах носителей, 1+ из них — вне основного дата-центра или офиса. Не магия, но хороший базовый ориентир.
Изоляция. Копии не должны быть так же доступны, как основная система. Если вредонос или злоумышленник получит права на сервер, он заберёт и бэкапы, лежащие рядом. Помогает изолированное или неизменяемое хранилище.
Регулярные учения. Разворачивать тестовую среду начисто из архива и получать от пользователей результаты сверки: документы, заказы, справочники на месте? Система запускается, а не просто показывает красивый экран входа?
Копии — это важно, но это только про данные. А бизнес сегодня держится ещё и на сервисах и зависимостях между ними. Пройдитесь по списку и честно спросите «а если этого не станет?»:
Домены и DNS: кто ими управляет и как вернуть управление, если основной аккаунт недоступен. Противодействие угону.
Коммуникации. Телефония, почта и мессенджер: чем связываться с сотрудниками и клиентами, если основной канал лёг.
Сайт и рабочие системы: где данные и настройки, как поднять всё на другой площадке не так, чтобы чистый лист.
Связь и оборудование: запасной канал и запасное устройство там, где их потеря остановит работу.
Люди: документация, чтобы восстановление не зависело от единственного человека, который знает все пароли.
И оговорка: «разнести всё по пяти провайдерам» — это ещё не стратегия. Если все сервисы висят на одной учётной записи, одном канале или одном человеке, устойчивость не растёт, а управлять такой конструкцией только сложнее.
На одном из складов, которые мы сопровождали на заре времён, ящик с бумажными типографскими ордерами и другими документами, подготовленными для бумажного документооборота, был заполнен из расчёта недельного отключения цифровых сервисов.Сейчас цифра интегрирована в наш мир гораздо глубже, и вернуться к бумаге просто так уже не выйдет. Но сам принцип остаётся разумным: сценарий работы при полной остановке должен быть проработан.
Что можно делать вручную?
Что придётся отложить?
Какие данные должны быть под рукой?
Кто принимает решения и как сотрудники узнают, что делать?
Иногда такой резервный сценарий важнее второго сервера и ещё одного комплекта железа.
Надёжность — это не только отсутствие сбоев. Это сохранность данных и отлаженный порядок действий на случай, когда всё пошло не так.
для разумной устойчивости не нужны специальные знания. Достаточно здравого смысла, калькулятора и желания не терять деньги в моменты простоя. А дальше уже можно подключать специалистов.
И, конечно, каждый пост с нами ваша любимая рубрика ВСТАНЬ И ИДИ
Задайте своему ИТ-специалисту или подрядчику прямой вопрос: «Где физически лежат наши бэкапы? Сколько их? Как организовано резервное копирование?»
Убедитесь, что бэкапы НЕ хранятся только на том же сервере, где крутится сама система
Проверьте, что они находятся именно там, где вам сказали
Убедитесь, что доступ к ним ограничен. (спроси меня, как:)
Уточните, защищены ли копии от удаления, если взломают основной сервер или админскую учётку. спросите, "Как?"
Попросите провести контрольное восстановление важных данных на тестовый контур и засеките время (это и есть ваш реальный RTO).
Спросите себя: сколько часов (или дней) простоя выдержит ваш бизнес без катастрофических убытков?
И, конечно, не кормите яо-гаев
Оставляйте заявку на бесплатный экспресс-аудит ИТ-инфраструктуры, текущих процессов и систем на нашем сайте administrators.ru, или свяжитесь с нами удобным для вас образом:
звоните на +7-98-98-11-13-98 (тап),
пишите на get1@administrators.ru
Подписывайтесь и следите за нашими анонсами в
@RuAdminGuild в тг, дзен и вк
🎧 [Harley Davidson & The Marlboro Man - Bon Jovi / Wanted Dead or Alive]
* Мария Маркова. "Глобально всё в этом мире делится на сырники и не сырники"
Отказоустойчивость (Fault Tolerance)
Способность системы продолжать работу при отказе отдельных компонентов. Например, сгорел один из двух блоков питания — второй тянет нагрузку, или «упал» один сервер кластера — остальные работают.
Катастрофоустойчивость (Disaster Recovery, DR)
Готовность инфраструктуры к масштабным внешним ЧП: пожару, затоплению, потере дата-центра, физическим повреждениям площадки. Включает резервные площадки в разных точках, сохранность данных и чёткий, проверенный регламент переключения.
RPO (Recovery Point Objective)
Допустимая потеря данных, выраженная во времени. RPO в четыре часа означает: при аварии бизнес согласен потерять не более четырёх часов изменений. Если бэкап делается раз в сутки ночью, а сбой случился в 18:00, вы теряете почти весь рабочий день.
RTO (Recovery Time Objective)
Целевое время восстановления работоспособности после сбоя. Если RTO — четыре часа, план восстановления должен позволять вернуть сервис в этот срок. Проверяется только тестовым восстановлением.
Бэкап и репликация
Бэкап — отдельная копия данных для возврата к состоянию до инцидента. Репликация поддерживает копию в другом месте в актуальном виде, но вместе с данными переносит туда и повреждения, и ошибочные удаления. Репликация не заменяет бэкап.