Цена простоя: как обосновать бюджет на отказоустойчивость

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

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

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

Что на самом деле теряет компания, когда сервисы падают

Представим вымышленную Orbita Corp. Она развивает интернет-магазин, доставку, рекламную платформу и платежный кошелек Orbita Pay. Магазином пользуются 8 млн человек в месяц, доставкой — 3 млн, кошельком — 5 млн. Аудитории пересекаются, поэтому представим, что всего у экосистемы 12 млн уникальных пользователей в месяц. Отдельно считаем 50 тысяч компаний-рекламодателей.

Магазин зарабатывает на продаже товаров, доставка обслуживает собственные и сторонние заказы, рекламная платформа получает плату за размещения. Orbita Pay приносит доход от обслуживания платежей подключенных магазинов. Платежи и переводы проводит банк-партнер, а команда Orbita поддерживает приложение кошелька и его техническую платформу.

Orbita размещает собственное оборудование в трех дата-центрах в разных городах по модели colocation — арендует место для своих серверов на готовых площадках.

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

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

Открывающийся каталог не означает, что магазин способен продавать; недоступная оплата не означает, что прекратились все рекламные показы. Размер потерь зависит от того, какие услуги остаются доступны и как долго длится сбой.

Начнем с магазина

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

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

Чтобы посчитать все затронутые продажи магазина, зададим простую модель. Товары закупаются у поставщиков только под оплаченные заказы. Экономика одной покупки без НДС выглядит так:

3 000 ₽ выручки − 2 400 ₽ поставщику − 250 ₽ расходов на исполнение заказа − 50 ₽ внешним платежным участникам = 300 ₽.

В нашем примере перечисленные расходы возникают только при выполнении заказа. Оставшиеся 300 рублей идут на покрытие постоянных расходов и формирование прибыли.

Предположим, за выбранные сутки состоялось бы 100 тысяч таких покупок. Из-за сбоя 40 тысяч покупок переносятся на другое время, а 60 тысяч теряются окончательно. Тогда:

60 000 × 300 ₽ = 18 млн ₽ потерянного дохода после вычета избегаемых расходов.

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

Такой расчет подходит для товаров, которые Orbita закупает под оплаченный заказ. Если товар уже лежит на складе, отмена покупки не возвращает деньги за его закупку. Возможно, его продадут позже по прежней цене. Возможно, придется сделать скидку или списать испорченный товар. Поэтому расходы проверяют по отдельности. Вместе с отмененным заказом исчезают далеко не все затраты на него.

Теперь посчитаем остальные потери

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

Уточним, какие расходы здесь исчезают вместе с заказом. За выполненную стороннюю доставку Orbita платит внешнему перевозчику 350 рублей. Из 30 рублей платежного вознаграждения 20 перечисляет внешним участникам. Из 100 рублей дохода за тысячу рекламных показов 50 уходят сторонним площадкам. По условиям нашего примера эти выплаты возникают только за фактически оказанные услуги.

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

Компенсации в таблице — условная дополнительная выплата 4 тысячам пострадавших клиентов по 100 рублей. Это не возврат стоимости уже учтенных несостоявшихся заказов. В реальности расчет основания и суммы выплат определяются обязательствами компании и ее решениями по конкретному инциденту.

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

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

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

Неизменившиеся зарплаты и аренду повторно не прибавляем. Они присутствуют и в сценарии без сбоя, и в сценарии с ним. Отдельными потерями становятся дополнительные расходы — например, оплаченные аварийные работы.

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

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

Какие требования к надежности устанавливает компания

Руководству теперь нужно определить, какие последствия компания готова принять. Одна функция может некоторое время работать с ограничениями, другая требует срочного восстановления.

Для аварийного восстановления задают два основных требования:

RTO (Recovery Time Objective) — «целевое время восстановления»: за какое время после сбоя нужно восстановить работу сервиса до согласованного уровня. В него входят обнаружение проблемы, принятие решения, переключение и проверка результата.

RPO (Recovery Point Objective) — «целевая точка восстановления»: за какой период перед сбоем допустима потеря последних изменений данных. Например, RPO в пять минут означает, что восстановленное состояние может отставать от момента сбоя не более чем на пять минут.

Для Orbita зададим условия нашего примера: после отказа одной площадки прием платежей должен возобновляться не позднее чем через 60 минут, с производительностью, достаточной для согласованной пиковой нагрузки. Подтвержденные записи о принятых операциях должны сохраняться — для них требуется RPO = 0 в рассматриваемом сценарии. Час здесь является требованием бизнеса, а не результатом деления рассчитанных потерь.

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

Здесь речь о подтверждении сохранения записи в системе Orbita. Оно не заменяет ответ банка о результате самого платежа.

При отказе основной площадки работу нужно перевести на резервную, где сохранились все подтвержденные записи. Выбирают именно актуальную копию: отстающая реплика не выполнит требование RPO = 0. Перед переключением необходимо исключить возможность записи на прежнем основном сервере, чтобы два сервера не начали независимо изменять данные. Новый основной сервер тоже должен дожидаться сохранения записей на другой работающей площадке.

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

То есть копии записей у Orbita есть, но возможность восстановить прием платежей за час еще предстоит проверить. Нужно запустить приложения на другой площадке, восстановить необходимые соединения и проверить обработку платежей.

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

Сначала выбирают, что измерять. Например, долю времени, когда пользователи могут воспользоваться сервисом. Это SLI (Service Level Indicator) — показатель уровня обслуживания. Затем задают цель: например, сервис должен быть доступен не менее 99,9% времени за год. Такое требование называют SLO (Service Level Objective) — целевой уровень обслуживания.

При измерении доступности по времени за 365 суток получаем:

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

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

Обязательства перед клиентами могут быть закреплены в SLA (Service Level Agreement) — соглашении об уровне обслуживания. В нем определяют условия оценки качества сервиса и последствия нарушения обязательств — например, компенсацию. SLO задает техническую цель, а SLA закрепляет договоренности с клиентами.

Требования к восстановлению и доступности должны согласовываться между собой. При целевой доступности 99,99% времени за год полная остановка на 55 минут уже превышает соответствующий предел. При этом команда может уложиться в RTO, равное часу. Выполнить одно требование еще не означает выполнить другое.

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

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

Что помогает сервисам пережить отказ дата-центра

Проблема Orbita уже понятна. Данные сохранены, но общий платежный сервис слишком зависит от первой площадки. Сейчас посмотрим, как устранить эту зависимость. Будем обращаться к опыту других компаний.

Подготовить резерв вместе с запасом мощности

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

В AWS тоже заранее готовят запас мощностей на случай сбоя. Для части своих сервисов компания заранее распределяет серверы приложений между тремя зонами доступности. Зона AWS может включать один или несколько дата-центров. При потребности в 100 условных единицах мощности размещает по 50 в каждой зоне. После потери одной остаются необходимые 100. Дополнительный запас составляет 50%. Расчет относится к приложениям, запросы которых можно распределять между взаимозаменяемыми серверами. Для базы данных нужна отдельная проверка.

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

Обеспечить запуск без помощи отказавшей площадки

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

Когда Meta готовилась к внезапному отключению питания, инженеры проверили, смогут ли системы заново запуститься после его возвращения. В Twine (системе управления запуском приложений) обнаружили риск замкнутого круга. Для работы ей нужны собственные служебные программы, а их запуск мог зависеть от самой Twine. Разработчики создали Twine recovery kit — набор инструментов, который помогает запустить эти программы и разорвать такую зависимость.

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

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

Сделать повтор платежа безопасным

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

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

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

Проверить переключение до следующей аварии

Наличие резерва должно подтверждаться испытаниями. Можно вспомнить ситуацию с Cloudflare.

После отключения питания в ноябре 2023 года Cloudflare ускорила работу над отказоустойчивостью. Подготовка переключения баз данных заняла в общей сложности больше года. К марту 2024 года компания обеспечила их автоматическое переключение, добавила необходимые мощности и проверяла восстановление еженедельно. 26 марта 2024 года та же площадка снова потеряла питание. Через семь минут интерфейс управления и API работали нормально без ручного вмешательства. Более ста баз данных автоматически переключились с отказавшей площадки, но аналитические сервисы восстановились позднее.

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

Когда расходы на защиту оправданы

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

Что делать сейчас и что оплатить на будущее

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

Аварийные работы, временную аренду ресурсов и компенсации мы уже учли в расчете суточных потерь Orbita — в таблице с итогом 24 млн рублей. Теперь отдельно посчитаем, сколько стоит подготовить резерв и поддерживать его работу.

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

Из чего складывается смета

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

В нашем примере у Orbita уже есть работающие реплики базы данных, сеть между ЦОД, защищенные соединения и инструменты для управления системой. За сервисами круглосуточно следит дежурная команда. Нужно проверить, что эта инфраструктура тоже справится с нагрузкой после отказа первой площадки, а инженеры сохранят доступ к управлению. Мы дорабатываем существующую систему, поэтому строительство ЦОД и создание платежной платформы с нуля в смету не входят.

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

Начнем с подготовки резерва. Заложим 1 000 дополнительно оплачиваемых часов работы специалистов по 3 000 рублей. Столько времени мы отводим на доработки. Для другой платежной системы объем работ может отличаться:

☝️ это стоимость дополнительно оплачиваемых работ. Если Orbita поручит проект штатной команде без дополнительных выплат, ее обычные зарплаты повторно прибавлять к расходам не нужно. Но придется проверить, хватит ли сотрудникам времени и на этот проект, и на текущие задачи. Возможно, часть других работ придется отложить.

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

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

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

240 часов в год относятся только к дополнительному плановому сопровождению. Аварийные работы оплачиваются отдельно и уже учитываются в ущербе от конкретного сбоя.

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

Первый год проекта потребует 5,4 млн рублей: 3 млн на внедрение и 2,4 млн на эксплуатацию.

Насколько уменьшатся потери

Сначала мы рассчитали потери Orbita в сценарии, когда оплата недоступна сутки. Затем предложили подготовить резерв, чтобы возобновлять прием платежей за час. Теперь рассмотрим восстановление за 15 минут. Это поможет понять, сколько еще денег компания могла бы сохранить и стоит ли доплачивать за такое ускорение. Если оплата заработает через 15 минут, покупатель может вернуться и завершить заказ. Если оплата не работает сутки, тот же покупатель может купить товар у конкурента. Поэтому потери за час и за 15 минут посчитаем отдельно, а не будем делить суточную сумму на равные части. Для каждого сценария оценим, сколько операций потеряно окончательно и какие дополнительные расходы возникнут. Затем сравним, насколько ускорение уменьшает потери и сколько придется за него заплатить.

Ниже