Сверхнадежность в ПО для бизнеса: необходимость или огромные убытки?

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

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

Сложности начинаются в тот момент, когда общие пожелания переходят к конкретным техническим решениям и их стоимости. Надёжность – это не двоичное состояние «работает или не работает», а шкала с множеством делений, и продвижение по ней вверх требует ресурсов.

Обеспечить доступность сервиса на уровне 99% и на уровне 99,9% – это две задачи с совершенно разным ценником, хотя на слух разница кажется ничтожной. А переход к следующим долям процента и вовсе способен умножить бюджет проекта на величины, которые невозможно обосновать никакой разумной экономикой.

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

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

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

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

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

Что означает сверхнадежность и так ли она хороша?

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

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

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

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

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

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

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

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

Второй источник – страх самого заказчика перед неопределённостью. Фраза «а вдруг» способна увеличить смету проекта сильнее, чем любой объективный расчёт. Механизм здесь простой: где-то на рынке у конкурента случился громкий сбой, об этом написали в новостях, и теперь у руководителя возникает установка – с нами такого произойти не должно ни при каких обстоятельствах.

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

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

Третий источник – слепое копирование требований, подсмотренных у крупных игроков. Работает это примерно так: команда или заказчик изучают, как устроены системы в известных компаниях – банках, маркетплейсах, стриминговых сервисах, – и переносят их стандарты на свой проект просто потому, что «так делают лидеры».

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

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

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

Из чего складывается цена надежности?

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

Зависимость между уровнем доступности системы и её стоимостью не линейна. Переход от 99% доступности к 99,9% обычно стоит умеренных вложений: где-то добавить резервный сервер, где-то настроить простое резервное копирование.

Но каждый следующий шаг – к 99,99%, а затем и к 99,999% – требует уже не добавления, а умножения. Сложность инфраструктуры растёт не по ступенькам, а рывками, и каждый рывок тянет за собой расходы не только на оборудование, но и на всё остальное.

Оборудование и вычислительные мощности

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

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

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

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

Архитектурные решения и их усложнение

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

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

Каждый добавленный посредник делает систему более устойчивой к отказам, но одновременно с этим делает её сложнее для понимания, тестирования и доработки. А сложность – это всегда время разработчиков, причём время не разовое, а растянутое на весь срок жизни продукта.

Единовременная разработка и долгосрочная поддержка

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

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

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

А поскольку требования к надёжности со временем обычно не снижаются, этот повышенный коэффициент закладывается в каждую будущую доработку. Любая новая функция в такой системе будет стоить дороже, чем в более простой, просто потому, что она должна соответствовать существующим стандартам отказоустойчивости.

Время выхода на рынок как скрытая статья расходов

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

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

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

Сравниваем стоимость простоя и стоимость его предотвращения

Пять миллионов рублей на отказоустойчивость – это много или мало? Ответ зависит только от того, сколько вы потеряете, если этой отказоустойчивости не будет. Сравнение этих двух величин и есть тот самый инструмент, который позволяет принимать решение на основе трезвого расчёта.

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

1. Считаем стоимость простоя

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

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

Дальше идут косвенные потери, которые сложнее оценить, но игнорировать их нельзя:

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

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

2. Считаем стоимость предотвращения

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

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

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

3. Сводим две цифры вместе

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

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

Три уровня надежности для разной специфики бизнеса

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

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

Первый уровень: достаточный

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

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

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

Второй уровень: деловой

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

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

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

Третий уровень: критический

Это уже зона высокой ответственности, где доступность измеряется значениями 99,99% и выше. Время простоя за год исчисляется минутами, а не часами, и даже короткий перерыв воспринимается как чрезвычайное происшествие:

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

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

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

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

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

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

Разработка ПО от 66 Бит

Всего за 10 минут вы сверхнадежно разобрались в том из чего складывается стоимость надежности для цифровых продуктов и какой уровень подходит именно вашему бизнесу. Самое время спроектировать и разработать надежную систему, а поможет в этом команда 66 Бит!

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