Четыре уровня отказоустойчивости: на каком вы и что вам действительно нужно

Отказоустойчивость — это не состояние «есть или нет». Это лестница из четырёх уровней, и каждый решает свою задачу на своём этапе жизни продукта.

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

Уровень определяется двумя величинами, и обе задаёт бизнес, а не инженер:

• RTO — сколько времени бизнес может прожить без работающей системы.
• RPO — за какой период допустимо потерять данные.

Главный закон отказоустойчивости

Инженеры хотят строить распределённые системы, потому что это интересная задача. Бизнес устроен иначе.

Уровень отказоустойчивости диктуется не амбициями команды, а простым неравенством:

Стоимость решения за год < ожидаемый убыток от простоя за год

Правую часть считают так: стоимость часа простоя × ожидаемое число часов простоя в год. Если час простоя интернет-магазина стоит 40 000 ₽, а реалистичный прогноз — восемь часов простоя в год, ожидаемый убыток составит около 320 000 ₽. Переход на четвёртый уровень обойдётся в миллионы в год. Вывод очевиден: вам нужен не четвёртый уровень, а честно доведённый до конца второй из описанных ниже — с проверенными резервными копиями и внешним мониторингом.

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

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

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

Уровень 1. MVP: «Лишь бы работало»

RTO: до суток · RPO: до суток · Бюджет: минимальный

Продукт только появился. Главная задача — проверить гипотезу и понять, нужен ли он рынку. Пользователи чаще всего либо не платят, либо участвуют в бета-тестировании.

Как устроена инфраструктура

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

Главные риски

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

Вторая ошибка мягче, но встречается чаще: копии делаются, но хранятся на том же сервере. Такая копия исчезает вместе с оригиналом.

Вердикт. Один сервер и настроенное копирование в стороннее хранилище — экономически оправданное решение для MVP. Ничего сверх этого на данном этапе не нужно.

Уровень 2. Базовая надёжность: первые платящие клиенты

RTO: часы · RPO: десятки минут · Бюджет: умеренный

Продукт вырос: появились платящие пользователи, а вместе с ними — обязательства. Бизнес начинает требовать гарантий.

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

Как устроена инфраструктура

1. Отдельный балансировщик трафика. Nginx или его аналог выносится перед приложением. Это даёт управление трафиком: если серверная часть упадёт, пользователь увидит внятную страницу-заглушку, а не ошибку 500.
2. Вынос статики. Изображения и пользовательские файлы переезжают в объектное хранилище (S3 и совместимые). Диск сервера больше не переполняется.
3. Разделение слоёв. Серверная часть разносится на два-три сервера, база данных живёт отдельно. Пользовательские сессии выносятся в общий кэш (Redis), чтобы любой запрос мог обработать любой сервер.
4. Репликация базы данных. Настраивается схема «основной сервер — реплика»: реплика непрерывно повторяет изменения основного. Резервные копии снимаются с реплики и хранятся на другой площадке.
5. Базовый мониторинг. Отслеживаются заполнение дисков, расход памяти и — отдельной внешней проверкой — доступность ключевых страниц и сценариев: оформление заказа, вход, оплата. Появляются первые письменные регламенты восстановления.

Главные риски

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

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

Отдельно стоит помнить: вынеся сессии в Redis, вы создали новую единую точку отказа. На этом уровне это допустимый компромисс, но знать о нём нужно.

Что здесь всё ещё вручную

Переключение на реплику. Репликация работает сама, но решение «основной сервер умер, повышаем реплику» принимает и выполняет человек. Именно поэтому RTO измеряется часами — в них входит время, пока инженер проснётся, разберётся и переключит.

Вердикт. Единые точки отказа на уровне железа устранены, но восстановление по-прежнему держится на дежурном инженере.

Уровень 3. Зрелый продакшн: автоматизация

RTO: минуты · RPO: секунды · Бюджет: средний

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

Как устроена инфраструктура

• Оркестрация. Внедряется Kubernetes или аналог: он распределяет нагрузку по серверам, перезапускает упавшие сервисы без участия человека и масштабирует их по нагрузке.
• Сеть доставки контента (CDN). Статика раздаётся с узлов, ближайших к пользователю.
• Автоматическое переключение базы данных. Управление репликацией передаётся специализированной системе — например, Patroni для PostgreSQL: она сама обнаруживает отказ основного сервера и повышает реплику. Соединения проходят через пул (PgBouncer), иначе при переключении приложение упрётся в лимит подключений.
• Надёжная передача сообщений. Асинхронные задачи уходят в брокер (Kafka, RabbitMQ). Здесь важна не сама установка, а настройка: коэффициент репликации больше единицы и требование подтверждения от нескольких реплик — иначе отказ одного узла уничтожит непереданные сообщения.
• Наблюдаемость. Мониторинг перестаёт быть набором графиков о железе: добавляются бизнес-метрики (заказы в минуту, доля успешных оплат), исторические тренды и внешние проверки. Мониторинг наблюдает и за самим собой — иначе система оповещения тихо умрёт первой, и наступит обманчивая тишина.
• Организационная готовность. Появляется письменный план аварийного восстановления, и команда регулярно проводит по нему учения. Разборы аварий проводятся без поиска виновных: инженер, который боится сообщить об ошибке, сообщит о ней поздно.

Главные риски

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

Вердикт. Рутину берёт на себя автоматика. Потеря сервера, базы данных или целой зоны доступности отрабатывается без участия человека — инженера не нужно будить в три часа ночи.

Уровень 4. Географическое распределение

RTO: минуты даже при отказе целого региона · RPO: близкий к нулю · Бюджет: высокий

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

Как устроена инфраструктура

• Несколько регионов. Инфраструктура распределяется по географически независимым площадкам с раздельным питанием, каналами связи и юрисдикцией.
• Управление трафиком на сетевом уровне. Анонсы BGP из собственной автономной системы или глобальная балансировка позволяют увести трафик из отказавшего региона, не дожидаясь обновления DNS у операторов.
• Управление несколькими кластерами. Единая выкатка и согласованные конфигурации на всех площадках. Стоит учитывать, что штатная федерация кластеров Kubernetes развития не получила — на практике задачу решают инструменты доставки конфигураций и внешняя балансировка.
• Распределённые базы данных. Переход от классических СУБД к системам, спроектированным для работы в нескольких регионах одновременно (CockroachDB, YugabyteDB, Spanner).
• Управляемые отказы. Устойчивость проверяется регулярными экспериментами в продуктивной среде — от отключения отдельных машин до имитации сетевых разрывов между регионами. Проверенным считается только тот сценарий, который выполняли на практике.
• Аварийная процедура в одно действие. Изоляция отказавшего региона выполняется одной командой, а не последовательностью из сорока шагов, которую в стрессе никто не помнит.

Главные риски

• Физику не обойти. Между регионами задержка составляет десятки миллисекунд, и это неустранимо. Синхронная репликация прибавляет это время к каждой операции записи — приложение становится ощутимо медленнее. Асинхронная сохраняет скорость, но при аварийном переключении вы теряете данные, которые не успели доехать. Выбор между «медленнее» и «с потерями» — архитектурное решение, а не настройка.
• Расхождение данных. При разрыве связи между регионами каждый может решить, что выжил именно он, и продолжить принимать записи. Итог — два набора противоречащих друг другу данных, которые придётся сводить вручную.
• Нелинейная сложность. Стоимость поддержки растёт быстрее, чем надёжность. Нужны редкие и дорогие специалисты, а любое изменение выкатывается на все площадки согласованно.

Вердикт. Дорого, сложно и требует отдельной команды сопровождения — но бизнес переживает потерю целого дата-центра.

С чего начать

1. Определите стоимость часа простоя. Без этой цифры любой разговор об отказоустойчивости остаётся спором о вкусах.
2. Нарисуйте карту зависимостей. Что от чего зависит: домен, DNS, почта, платёжный шлюз, база данных, внешние сервисы. Отметьте то, чей отказ останавливает продажи.
3. Проверьте восстановление. Не «делаются ли копии», а «когда мы в последний раз восстанавливались из копии и сколько это заняло». Копия, из которой никто не восстанавливался, — это не резервная копия, а предположение.
4. Сверьте уровень с реальностью. Если вы обнаружили у себя инструменты третьего уровня при задачах первого — вы платите за надёжность, которой не пользуетесь.

Если не уверены, на каком уровне находитесь, начните с внешней проверки: сервис проверит DNS, почту, TLS-сертификат и скорость сайта и покажет слабые места простым языком.

Если нужен разбор глубже — определим ваш уровень, посчитаем стоимость простоя и составим план перехода без лишних трат.