Что должно быть, чтобы система не остановила бизнес при сбое

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

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

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

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

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

Разберём, как это устроено на практике.

Отказ компонента и остановка бизнеса — разные события

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

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

Поэтому начинать проектирование отказоустойчивости нужно не с выбора серверов, а с карты бизнес-зависимостей.

Рассмотрим упрощённый процесс обработки заказа.

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

Если ERP недоступна, компания должна заранее определить:

• › Можно ли продолжать принимать заказы?
• › Можно ли подтверждать покупателю наличие товара?
• › Где сохраняются операции, которые не удалось передать?
• › Как исключить повторное резервирование или дублирование заказа?
• › Кто и по каким признакам поймёт, что обмен остановился?
• › Как система вернётся к нормальной работе после восстановления ERP?

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

Полезно различать три вида связей.

Сначала определить допустимый ущерб, затем выбирать архитектуру

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

Для этого определяют два показателя: RTO и RPO.

Здесь есть важный нюанс: RTO и RPO — не обещания, которые автоматически обеспечиваются выбранной технологией. Это требования, которые необходимо подтвердить испытаниями.

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

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

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

Не все процессы требуют одинакового уровня защиты

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

Резервирование: как найти общую точку отказа

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

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

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

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

Что необходимо проверить при проектировании резервирования

• › Есть ли общая база данных, очередь, сеть или хранилище, отказ которых блокирует все экземпляры?
• › Размещены ли резервные компоненты независимо от критичных общих ресурсов?
• › Сохраняется ли работоспособность при потере целого узла, зоны или площадки, если такой сценарий входит в требования?
• › Может ли резервная среда выдержать реальную нагрузку?
• › Сохраняются ли корректные роли компонентов после переключения?
• › Не возникает ли ситуация, когда два узла одновременно считают себя основными и принимают конфликтующие записи?

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

Три подхода к резервированию

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

База данных: доступность не должна достигаться ценой потери целостности

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

Здесь необходимо разделять три задачи:

• › Обеспечить доступность данных при отказе узла.
• › Сохранить возможность восстановить данные после повреждения или ошибочного изменения.
• › Гарантировать корректность бизнес-состояния после переключения и восстановления.

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

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

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

Почему репликация не заменяет резервную копию

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

Для критичных систем необходимо определить:

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

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

Интеграционный контур: как пережить отказ зависимой системы

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

Представим, что CRM передаёт заказ в ERP. ERP сохраняет заказ, но ответ теряется из-за сетевого сбоя. CRM не знает, была ли операция выполнена, и отправляет запрос повторно.

Если ERP создаёт новый заказ при каждом запросе, появляется дубль.

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

Как должна выглядеть обработка интеграционной операции

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

Что делать, если системы не могут завершить операцию одновременно

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

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

Вместо попытки представить весь процесс как одно мгновенное действие нужно явно моделировать его этапы и переходы.

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

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

Очередь сообщений — не гарантия надёжной интеграции

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

Нужно учитывать:

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

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

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

Управляемая деградация: что система должна продолжать делать при отказе

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

Иногда безопаснее временно запретить определённые операции, чем продолжать работу с недостоверными данными.

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

Пример матрицы поведения

Здесь важно различать приём запроса и подтверждение бизнес-обязательства. Возможность сохранить заказ ещё не означает, что можно подтвердить наличие товара, оплату или дату отгрузки.

Для каждой критичной зависимости необходимо определить:

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

Не допустить вторичного отказа

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

Для предотвращения такого сценария применяют ограничение скорости обработки, очереди, управление параллелизмом, backpressure и другие механизмы, соответствующие архитектуре.

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

Мониторинг: обнаруживать нарушение процесса, а не только падение сервера

Мониторинг инфраструктуры необходим, но он отвечает лишь на часть вопросов.

Сервер может быть доступен, API — возвращать успешные ответы, а бизнес-процесс — фактически не завершаться.

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

Чтобы обнаруживать такие ситуации, мониторинг должен охватывать несколько уровней.

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

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

Почему возраст очереди иногда важнее её размера

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

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

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

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

Оповещение должно содержать контекст

Уведомление «API недоступен» сообщает технический факт, но не объясняет последствия.

Для принятия решения полезнее знать:

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

Восстановление: вернуть не только доступность, но и согласованное состояние

Рассмотрим сквозной сценарий.

CRM передала заказ в ERP. ERP сохранила его, но подтверждение не дошло. Затем интеграционный сервис перезапустился. После восстановления он повторно отправил запрос.

Если архитектура не сохраняет идентификатор операции и не умеет определять её фактическое состояние, возникает риск создания второго заказа.

Даже если дублирование предотвращено, могут остаться другие вопросы: был ли зарезервирован товар, отправлено ли событие в складскую систему, дошло ли подтверждение оплаты?

Поэтому восстановление нельзя сводить к повторному запуску сервиса.

Правильная последовательность восстановления

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

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

Сверка данных — самостоятельная часть архитектуры

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

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

Это упрощённая логика. В реальной реализации решение зависит от бизнес-правил, идентификаторов и достоверности данных.

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

Регламенты и испытания: как доказать, что система готова к сбою

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

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

Но документация сама по себе недостаточна. Её нужно проверять на практике.

Минимальный набор испытаний

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

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

Какие показатели фиксировать

• › фактическое время обнаружения отказа;
• › время восстановления требуемого уровня сервиса;
• › объём потерянных или требующих восстановления данных;
• › количество незавершённых и спорных операций;
• › поведение системы при повторной обработке;
• › время нормализации очередей и бизнес-процессов;
• › соответствие фактического результата RTO и RPO.

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

Типичные архитектурные ошибки

Практический чек-лист готовности системы

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

Заключение

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

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

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

Именно эти вопросы отличают резервирование инфраструктуры от полноценной архитектуры непрерывности бизнеса.

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

Главный критерий надёжности — не отсутствие сбоев, а способность системы сохранять управляемость при отказе, защищать бизнес-данные и предсказуемо возвращаться к нормальной работе.

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).