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

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

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

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

Представим вымышленную 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 минут посчитаем отдельно, а не будем делить суточную сумму на равные части. Для каждого сценария оценим, сколько операций потеряно окончательно и какие дополнительные расходы возникнут. Затем сравним, насколько ускорение уменьшает потери и сколько придется за него заплатить.

Ниже ? объемы окончательно потерянных операций заданы отдельно для каждого сценария. Например, 800 покупок за час и 100 за 15 минут — условия этого расчета, а не результат деления суточных 60 тысяч покупок.

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

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

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

Если резерв сработает и оплата вернется за час, потери Orbita в нашем примере составят 420 тысяч рублей вместо 24 млн при суточной остановке. Однако переключение может не пройти по плану. Поэтому при оценке пользы резерва нужно учитывать и возможность длительного сбоя.

Для расчета условно примем, что в 95% подобных аварий оплату удается вернуть за час, а в оставшихся 5% она недоступна сутки. Это выбранное нами допущение, а не статистика работы Orbita. Требование восстановиться за час сохраняется: суточная остановка будет его нарушением. Но возможность такого исхода тоже учитываем, чтобы не завысить ожидаемую экономию от резерва.

Для простоты мы рассмотрели только два варианта: оплата возвращается за час или остается недоступной сутки. На практике восстановление может занять и другое время. Поэтому для реального бюджета нужно посчитать потери и при других сроках. Значения 95% и 5% мы выбрали для примера, а не получили из реальных проверок. Чтобы оценить, как часто переключение на резерв может не сработать вовремя, нужны результаты испытаний и разбор возможных причин сбоев.

Тогда средний ущерб на одно событие после внедрения составит:

0,95 × 420 000 ₽ + 0,05 × 24 000 000 ₽ = 1 599 000 ₽.

Среднее уменьшение ущерба:

24 000 000 − 1 599 000 = 22 401 000 ₽ на событие.

Как частота отказов влияет на решение

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

Теперь посчитаем, насколько резерв может сократить потери Orbita за год:

Ожидаемое уменьшение потерь за год = ожидаемое число событий за год × среднее уменьшение ущерба на событие.

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

Получаем:

0,2 × 22 401 000 ₽ = 4 480 200 ₽ ожидаемого уменьшения потерь в год.

Сравним расходы Orbita и ожидаемое сокращение потерь за три полных года работы резерва после ввода в эксплуатацию. Для упрощения отнесем все вложения в подготовку к началу этого периода. Часть денег компания вложит сразу, а экономию получит позже. Время тоже имеет значение, ведь доступные сегодня деньги можно вложить и получить доход. Поэтому будущие расходы и экономию пересчитаем в сегодняшнюю стоимость. Такой пересчет называется дисконтированием. Для нашего примера возьмем условную реальную ставку 10% годовых — без инфляционной составляющей. При этой ставке 110 рублей через год в расчете равноценны 100 рублям сегодня. Все суммы будем считать в сегодняшних ценах, без добавления инфляции. Ежегодные расходы и экономию учтем в конце каждого года. Налоги для простоты не моделируем. Выручки от продажи оборудования в конце периода тоже нет: дополнительные серверы в этом примере арендованы.

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

Приведенная стоимость расходов, в миллионах рублей:

3 + 2,4 / 1,1 + 2,4 / 1,1² + 2,4 / 1,1³ ≈ 8,97.

Приведенная стоимость уменьшения потерь:

4,4802 / 1,1 + 4,4802 / 1,1² + 4,4802 / 1,1³ ≈ 11,14 млн ₽.

При этих условиях ожидаемый эффект превышает расходы примерно на 2,17 млн рублей за три года.

Однако вывод меняется вместе с частотой отказов:

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

Результат зависит не только от частоты аварий. Например, если при суточном сбое магазин окончательно потеряет 30% покупок вместо 60%, общий ущерб снизится с 24 до 15 млн рублей. Если остальные числа оставить прежними, трехлетний результат проекта изменится с +2,17 млн до −2,08 млн рублей. Это еще один условный расчет, который показывает, почему оценку потерянных покупок тоже необходимо проверять.

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

Нужно ли платить за еще более быстрое восстановление

Для дополнительного сравнения предположим, что при ускорении до 15 минут частота аварий и риск неудачного переключения останутся прежними. Неудачный исход по-прежнему означает сутки простоя. Тогда ускорение с часа до 15 минут дает: ускорение с часа до 15 минут дает:

0,2 × 0,95 × (420 000 − 70 000) = 66 500 ₽ дополнительного ожидаемого эффекта в год.

Это дополнительный ожидаемый эффект по четырем направлениям, до вычета расходов на ускорение. Отдельной сметы 15-минутного восстановления у нас пока нет. Поэтому 66 500 рублей позволяют оценить пользу ускорения, но не доказывают его выгодность. Более строгий SLO, другие виды отказов или более тяжелые последствия могут изменить решение.

Для Orbita первый приоритет — подготовленный часовой резерв. Дальнейшее ускорение требует отдельного обоснования.

Какую долю бюджета выделить

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

5,4 млн / 1 млрд × 100% = 0,54% годового IT-бюджета.

В следующие годы при прежних условиях:

2,4 млн / 1 млрд × 100% = 0,24% годового IT-бюджета.

Это доля дополнительных расходов на защиту общего платежного сервиса. Содержание трех ЦОД, существующая защита данных и остальные проекты надежности в нее не входят.

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