Два вопроса к команде, которые определяют бюджет на инфраструктуру

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

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

                         АВАРИЯ
                            │
   ─────────────────────────┼─────────────────────────►
        последняя точка     │      возврат к работе
        сохранных данных    │
                            │
   ◄──────── RPO ──────────►│◄──────── RTO ──────────►
   сколько данных потеряем  │   за сколько поднимемся

RTO: за сколько мы вернёмся к работе

RTO (recovery time objective) — предельно допустимое время от момента аварии до восстановления работы.

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

Что на самом деле входит в это время

Здесь кроется главная ошибка планирования. RTO почти всегда оценивают как длительность технических работ по восстановлению, тогда как в него входит вся цепочка:

обнаружение → оповещение нужного человека → диагностика → решение → восстановление → проверка

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

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

Как RTO определяет архитектуру

Сутки. Достаточно одного сервера и ежедневных резервных копий. Инженер поднимает новую машину и разворачивает систему без спешки.

Несколько часов. Нужны заранее подготовленная резервная площадка, реплика базы и написанная инструкция переключения. Решение принимает человек, поэтому время зависит от того, насколько быстро он доступен.

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

Секунды. Достижимо для отдельных компонентов, но не для системы целиком. Требование «секунды» на уровне всего бизнеса на практике означает «мы не считали».

RPO: сколько данных мы готовы потерять

RPO (recovery point objective) — предельный объём данных, измеряемый временем, который допустимо потерять безвозвратно.

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

Как RPO определяет архитектуру

Сутки. Достаточно ночного копирования. Авария в шесть вечера означает потерю всех данных за рабочий день. Для контентного сайта приемлемо; для интернет-магазина, как правило, нет — но проверять это должен бизнес, а не инженер.

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

Близко к нулю. Одной архивации журналов недостаточно — это распространённое заблуждение. Гарантия отсутствия потерь требует, чтобы база подтверждала клиенту запись только после того, как её приняла резервная копия, то есть синхронной репликации. Плата за это — каждая операция записи становится медленнее на время обмена с резервным сервером; в пределах одной площадки это доли миллисекунды, между регионами — десятки миллисекунд к каждой записи. Ровно поэтому нулевое RPO на географическом плече стоит дорого не только в деньгах, но и в скорости работы продукта.

Оба параметра задаются на функцию, а не на систему

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

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

Разговор, который стоит провести

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

Разговор идёт продуктивнее, если начать с трёх вопросов по каждой ключевой функции:

1. Сколько она может не работать, прежде чем мы понесём ущерб, который нельзя возместить? Не «сколько бы нам хотелось», а после какого срока последствия становятся необратимыми.
2. Данные за какой период мы сможем восстановить вручную? Иногда ответ обнадёживает: заказы за последние десять минут есть в почте и в CRM, их можно ввести заново. Тогда жёсткое RPO не нужно.
3. Что это стоит? Каждое ужесточение требований должно сопровождаться ценой. Разница между «четыре часа» и «пятнадцать минут» обычно кратная.

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

Что записать

Итог обсуждения — таблица на одну страницу: функция, RTO, RPO, чем это обеспечено, когда проверялось в последний раз.

Последний столбец важнее остальных. Заявленное RTO — предположение; подтверждённое учениями — факт. Как их развести, разобрано отдельно: бэкап, который никто не восстанавливал.