Облако тоже стоит на земле: что такое дата-центр и как не потерять сервис вместе с одним ЦОДом

Облако - это просто чужой компьютер

Фраза смешная ровно до того момента, пока этот компьютер не перестает работать.
В ночь с 7 на 8 октября 2026 года дата-центр Яндекса в Сасово получил серьезные повреждения, после чего его работа была полностью остановлена. На следующий день компания сообщила о повреждении еще одного дата-центра - в Калуге. На момент официального сообщения часть инфраструктуры там вышла из строя, а Яндекс предупреждал о возможных перебоях отдельных сервисов. Yandex
Одновременно в Yandex Cloud оставалась недоступной зона ru-central1-b. Провайдер сообщил, что нагрузку переключили на другие зоны, однако создание новых виртуальных машин, кластеров и баз данных могло быть ограничено. Yandex Cloud Status

На фоне этой истории я как раз переносил инфраструктуру Wiseohub на другой хостинг. Но здесь важно не сделать неправильный вывод.

Проблема не в том, что «Яндекс плохой» и надо срочно бежать к другому провайдеру. Любой дата-центр - это физический объект. В нем может пропасть питание, сломаться сетевое оборудование, отказать система охлаждения, случиться пожар. Или просто совпасть несколько редких аварий сразу.

Что такое дата-центр и облако

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

Облако эту физику не отменяет. Оно просто скрывает её от пользователя. Вместо покупки отдельного сервера вы говорите провайдеру: «Дайте мне 4 ядра, 8 ГБ памяти и диск на 100 ГБ». Через минуту появляется виртуальная машина. Нужна ещё одна - создаёте ещё одну. Главный смысл облака в том, что вам не нужно знать, в какой именно стойке находится ваше железо.

Где лежат данные

Не все данные нужно хранить одинаково. На диске виртуальной машины обычно находятся операционная система, приложение, Docker, конфигурация и иногда база данных. Для системы это выглядит почти как обычный SSD.

Фотографии, видео, архивы, PDF и пользовательские файлы удобнее складывать в Object Storage, чаще всего через S3-совместимый интерфейс. Тогда файл не привязан к конкретному веб-серверу: приложение просто обращается к объекту в хранилище. Это удобно, потому что сервер можно удалить и создать заново, а файлы останутся отдельно.

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

Почему одного сервера мало

Самая простая архитектура выглядит так:

Интернет
   |
 Сервер
   |
   ├─ Сайт
   ├─ База данных
   └─ Файлы

Дёшево, просто и удобно. Но если сервер умирает, умирает всё. Можно поставить второй сервер, но если оба находятся в одном дата-центре, остаётся другая проблема: что произойдёт, если недоступным станет весь ЦОД?

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

Реплика - не бэкап

Это одна из самых важных вещей, которые стоит понимать. Допустим, у вас есть основная база PostgreSQL и её реплика. Все изменения автоматически копируются на второй сервер. Если основной сервер умер - отлично, можно переключиться на реплику.

Но если кто-то случайно выполнит:

Удалить ВСЕ из базы данных;

реплика тоже удалит пользователей. То есть репликация защищает от отказа сервера, а бэкап - от потери данных. Это разные задачи.

Бэкапы при этом желательно хранить отдельно от production. Если сайт и единственная резервная копия находятся у одного провайдера, в одном аккаунте и в одном регионе, они всё ещё могут исчезнуть вместе. Хорошая схема - основной сервер у одного провайдера, резервная копия там же плюс ещё одна копия в отдельном хранилище.

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

RPO и RTO

Есть два полезных термина. RPO отвечает на вопрос: сколько данных мы готовы потерять? Если резервная копия создаётся раз в сутки, теоретически можно потерять почти 24 часа данных. Для блога это может быть терпимо, для интернет-магазина - уже серьёзная проблема.

RTO отвечает на другой вопрос: сколько времени сервис может быть недоступен? Десять минут, два часа или сутки? От этих требований напрямую зависит стоимость инфраструктуры. Система, которую можно спокойно восстановить завтра утром, стоит значительно дешевле системы, которая должна переключиться за несколько секунд без потери данных.

Почему сменить хостинг недостаточно

Если было так:

Один сервер у провайдера A
          ↓
Один сервер у провайдера B

то провайдер поменялся, а архитектура - нет. У вас всё ещё есть одна точка отказа. Поэтому полезнее спрашивать не «какой хостинг никогда не упадёт?», а «что будет с сервисом, когда он упадёт?»

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

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

Если основной сервер Wiseohub завтра полностью исчезнет, для меня гораздо важнее знать, за сколько часов проект можно поднять на чистой машине, чем иметь красивую схему из двадцати микросервисов :D