Крупный бизнес и госкомпании зависят от ИТ-систем не меньше, чем от электричества. Когда система падает, останавливаются продажи, платежи, логистика, документооборот и многое другое. В 2024–2025 годах средний критический простой обходился компании примерно в 2 млн рублей, а непрямые потери (упущенная прибыль, штрафы, отток клиентов) могли превышать стоимость владения ИТ-активами в два-три раза. При этом почти половина российских компаний не имеет актуальной ИТ-стратегии, а 26% вообще не тестируют восстановление данных.
В статье покажем, какие пять регулярных внутренних проверок на отказоустойчивость могут спасти бизнес, если его деятельность сильно зависит от работоспособности его ИТ-инфраструктуры (а таких компаний сейчас становится всё больше).
Проверка первая: имитация настоящих отказов (хаос-инжиниринг)
Хаос-инжиниринг (или инъекция отказов) — это управляемое внесение сбоев в работающую систему, чтобы посмотреть, как она себя поведёт. Например, для этого выключают сервер, обрывают сетевой канал, задерживают ответ базы данных и смотрят, переживёт ли система это без участия человека. В 2025 году на конференции «Перфоманс Конф» спикеры отдельно обсуждали хаос-инжиниринг и обеспечение отказоустойчивости как рабочий инструмент SRE-команд. Единственное отличие от реальных сбоев в том, что они тщательно продумываются заранее, а команда технарей при этом следит за обстановкой. Если что-то сломается по-настоящему, они быстро возвращают ситуацию в нормальное русло.
Зачем эта проверка крупному бизнесу. В монолитной системе сбой одного компонента часто тянет за собой всю цепочку. Имитация отказов показывает, что именно может уронить всё и сразу. Например, если при падении сервера аутентификации перестают работать все внутренние сервисы, вы это увидите в контролируемых условиях, а не в середине рабочего дня. Госкомпаниям этот метод полезен ещё и потому, что позволяет проверять устойчивость без остановки промышленной эксплуатации: сбои вносятся в тестовый контур или в отдельный сегмент продакшена с ограниченным влиянием.
Что проверять в первую очередь:
-
Отказ одного узла кластера.
-
Потерю связи между дата-центрами.
-
Недоступность внешнего сервиса (например, платёжного шлюза, СМЭВ или системы маркировки).
-
Переполнение очереди сообщений.
Каждый из этих сценариев должен заканчиваться каким-то измеримым результатом. Это может быть время восстановления, доля потерянных запросов, сработали ли автоматические переключения или любой другой параметр, который поможет оценить степень критичности компонента.
Проверка вторая: восстановление из резервной копии
Наличие бэкапа не равно возможности восстановиться — старое ИТ-правило, которое появилось с первой долговременной памятью, и которое работает до сих пор (но о котором многие, к сожалению, забывают).
Исследование 2025 года показало: 25% организаций не реализуют правило «3–2–1» (три копии, два носителя, одна копия вне площадки), а 26% не тестируют восстановление данных. Ещё хуже цифры по регулярности проверок: только 8% компаний тестируют восстановление раз в квартал, тогда как 89% кибератак в 2025 году были направлены именно на резервные копии.
Что это значит на практике. Если бэкап хранится на том же диске (или сервере), что и основная база, шифровальщик уничтожит обе копии. Если резервная копия делается раз в сутки, а система пишет данные каждую минуту, при восстановлении потеряются данные за последние 24 часа. И классика: если никто не пробовал развернуть копию на чистом железе, в момент аварии часто выясняется, что не хватает драйверов, лицензий или паролей.
Как проверять:
-
Взять последнюю резервную копию критичной системы (ERP, биллинга, базы клиентов — что угодно) и развернуть её на изолированном стенде.
-
Замерить время от начала восстановления до момента, когда система снова принимает запросы.
-
Сравнить результат с целевым показателем RTO (время восстановления) и RPO (точка восстановления).
-
Если расхождение больше допустимого, пересмотреть частоту копирования, схему хранения или сам процесс восстановления.
Проверка третья: нагрузочное тестирование на пределе
Нагрузочный тест отвечает на вопрос: что произойдёт, если число пользователей вырастет в два, три, пять или сколько угодно раз. В 2025 году Tantor XData и партнёры провели нагрузочное тестирование «1С:ERP» на 30 тысячах одновременно работающих пользователей. Тест длился 11 часов непрерывной работы, средняя загрузка процессора на сервере СУБД не превышала 30–40%, дисковая подсистема показывала время чтения порядка одной–двух миллисекунд. Интегральная оценка производительности по методике APDEX составила 0,859 — уровень «Хорошо».
Почему это важно. Госкомпания или крупный бизнес часто запускает систему сразу на десятки тысяч сотрудников. Без нагрузочного теста нельзя понять, выдержит ли инфраструктура пиковую нагрузку, например, в день закрытия отчётного периода или во время выплат зарплат и премий под новый год. Тест показывает как средние значения, так и поведение системы на пике: растут ли очереди, появляются ли таймауты, деградирует ли время отклика и т.д.
Что смотреть в отчёте по тесту:
-
Время отклика на 95-м и 99-м процентиле (средние цифры не покажут полную картину, когда проблемы появляются у части пользователей, но среднее их сглаживает).
-
Количество ошибок при нагрузке выше расчётной.
-
Поведение системы после снятия нагрузки: она восстанавливается сама или требует перезапуска.
-
Наличие точек насыщения: при каком числе пользователей время отклика начинает расти нелинейно (и сколько таких точек получится).
Проверка четвёртая: географическое резервирование
Более 75% мощностей коммерческих ЦОД в России сосредоточены в Московском регионе. Это создаёт концентрационный риск: авария в московском энергоузле, повреждение магистрального кабеля или крупный сбой на площадке одного оператора затронет сразу сотни организаций. В 2025 году операторы начали переносить новые проекты в регионы, но основная масса действующих систем по-прежнему размещена в Москве и Подмосковье.
Что проверять:
-
Есть ли у критичной системы резервная площадка в другом регионе.
-
Синхронизированы ли данные между основной и резервной площадками в реальном времени (или с задержкой).
-
Сколько времени займёт настоящее переключение на резервный ЦОД (например, запустить систему на резервной площадке, перевести на неё часть трафика и убедиться, что пользователи не замечают разницы).
Проверка пятая: учения по плану аварийного восстановления
План аварийного восстановления — это документ, который описывает, кто, что и в какой последовательности делает, когда система упала. Но такие планы часто остаются только на бумаге и, к сожалению, никогда не проверяются. Исследование 2026 года показало: формализованная стратегия DR, которая регулярно тестируется, есть лишь у 20% российских компаний. Ещё 41% респондентов никогда не проводили тестирование планов восстановления на практике.
Как проводить учения:
-
Выбрать один из вероятных сценариев: отказ основного ЦОД, шифрование базы данных, массовый сбой обновления или нарушение работы оборудования.
-
Назначить время и не предупреждать участников заранее.
-
Фиксировать время каждого шага: как быстро собралась команда, как быстро нашли резервную копию, как быстро переключились на резервную площадку (логирование инцидентов — очень полезная вещь на разборах, помогает увидеть критически слабые точки в процессе восстановления).
-
После учений обновить план: убрать шаги, которые не сработали, добавить контакты, которых не хватало.
Заключение
По отдельности каждая проверка важна, потому что закрывает свой участок риска. А вместе они создают полную картину: где система уязвима, сколько времени нужно на восстановление, какие действия нужно ещё предпринять заранее, чтобы в следующий раз (даже в учебном сценарии) было легче.
Инъекция отказов, восстановление из бэкапа, нагрузочный тест, географическое резервирование и учения по DR — вот минимальный набор действий, который мы рекомендуем проводить как минимум раз в полгода (лучше — раз в квартал).
