01

Отказоустойчивость начинается с требований бизнеса

Наличие второй реплики ещё не означает, что система выдержит отказ. Сначала команда фиксирует RTO, то есть допустимое время восстановления, и RPO, то есть допустимую потерю данных. Эти требования задаются отдельно для 1С, интеграций, отчётности и других систем, использующих SQL Server.

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

02

Что проверяем в SQL Server

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

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

Как строим мониторинг

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

  • Отставание и состояние синхронизации реплик.
  • Успешность и возраст последней резервной копии.
  • Свободное место, рост tempdb и журнала транзакций.
  • Длительные блокировки, ожидания и деградацию ключевых запросов.
  • Результат регламентных заданий и время реакции ответственного.
04

Восстановление нужно репетировать

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

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

Узнали свой процесс?

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

Разобрать проблемный участок ↗
← Вернуться к подборке статей

До результата

Автоматизация бизнеса, которая работает

Объединяем экспертизу в процессах, 1С, интеграциях, данных и эксплуатации

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

О команде и опыте →