48 часов на восстановление вместо четырёх: что скрывается за зелёными галочками мониторинга СУБД
Скрипт резервного копирования каждую ночь отрабатывает без единой ошибки. Мониторинг зелёный, инциденты закрываются, всё выглядит под контролем. После происходит реальный сбой, после которого восстановление занимает не 4 часа, как записано в регламенте, а двое суток. Хуже того: именно так администрирование СУБД выглядит в большинстве компаний, где базой занимаются системные администраторы «по совместительству». Чаще всего, об этом разрыве между «формально работает» и «реально работает» узнают только тогда, когда он уже стоил бизнесу денег или времени.
Ниже я привел четыре реальные истории о том, как формально исправные процедуры администрирования СУБД расходятся с их реальной управляемостью, и чек-лист, чтобы проверить, не то же самое ли происходит у вас.
Коротко, если нет времени читать всё:
- Самостоятельное администрирование СУБД силами системных администраторов или DevOps это нормальная модель на определённом масштабе.
- Она перестаёт работать не резко, а незаметно: процессы формально есть, но никто не проверял, что они дают нужный результат под нагрузкой или при сбое.
- Четыре сценария (бэкапы, мониторинг, повторяющиеся инциденты, рост нагрузки) и чек-лист из 8 пунктов для самопроверки.
В условиях оптимизации бюджетов передача администрирования баз данных штатным системным администраторам или DevOps-инженерам выглядит логичным шагом. На базовом уровне эта модель работает: СУБД функционирует, бэкапы вроде бы делаются, типовые инциденты закрываются по мере поступления.
Проблемы начинаются, когда от СУБД требуется больше: гарантированное восстановление в заданные сроки, стабильная работа под нагрузкой, отказоустойчивость, регулярное обслуживание и развитие архитектуры.
База данных – один из ключевых и наиболее критичных элементов ИТ-ландшафта, и здесь формальное наличие процедуры не равно контролю над ситуацией. Ошибки в управлении данными накапливаются незаметно месяцами, а проявляются лавинообразно, парализуя бизнес.
Резервное копирование: успешный код завершения — не то же самое, что восстановление
Исходная ситуация. В крупном ритейлере резервное копирование PostgreSQL было отдано дежурной смене DevOps. Скрипт pg_dumpall запускался через cron каждую ночь и отправлял архив в объектное хранилище S3. Мониторинг инфраструктуры фиксировал успешное завершение задачи с кодом 0.
Что обнаружили. Во время планового DR-теста (Disaster Recovery) выяснилось, что восстановление из дампа занимает более 48 часов вместо целевых 4 (!) часов. Причин было несколько: скрипт делал единый слепок без параллелизма (—jobs); файловая система временного каталога /tmp на сервере бэкапов имела жёсткий лимит в 50 ГБ, из-за чего дампы большего объёма обрезались, а контрольные суммы совпадали лишь частично. Дополнительно за полгода накопилась ошибка прав доступа к одной из схем служебных таблиц, так как часть объектов просто не попадала в архив. Формальный RPO составлял 24 часа, но из-за нестабильности процедуры реальный риск потери данных при сбое был значительно выше.
Как это выявили. Ежемесячная регламентная проверка восстановления на изолированном стенде завершилась ошибкой целостности (checksum mismatch) на этапе импорта схемы.
Что сделали. Перешли на физические базовые копии (physical base backups) через pg_basebackup с инкрементами WAL, добавили проверку размера архива и сверку количества объектов до и после копирования. Для тяжёлых баз внедрили pgBackRest с многопоточностью.
Результат. Время полного восстановления сократилось до 3 часов.
В регламенте зафиксированы фактические показатели:
- RPO — 15 минут,
- RTO — 4 часа.
- Доля успешных циклов резервного копирования и восстановления за квартал — 99,5%.
Вывод
Успешное выполнение задания бэкапа само по себе ничего не говорит о возможности восстановиться в срок. Проверять нужно весь сценарий целиком — от создания копии до работоспособной базы после восстановления.
Мониторинг СУБД: зелёные графики сервера и жалобы пользователей — разные картины
Исходная ситуация. У разработчика онлайн-сервисов инфраструктура контролировалась стандартными средствами Zabbix и Prometheus, показатели CPU, RAM и дискового I/O были в норме. При этом пользователи мобильного приложения массово жаловались на зависания при оплате счетов в 19:00–20:00.
Что происходило. Загрузка процессора редко превышала 60%, то есть по инфраструктурным метрикам проблема не выглядела как нехватка ресурсов. Причина была в ожиданиях внутри СУБД: из-за отсутствия составного индекса по полям account_id и created_at платёжный шлюз каждый вечер генерировал тяжёлые аналитические запросы для формирования чеков. Процессор простаивал в ожидании данных с диска, пока планировщик выполнял последовательное сканирование (Seq Scan) многогигабайтных таблиц транзакций.
Какие метрики помогли найти причину. Профильный DBA подключил расширенный экспортёр PostgreSQL (postgres_exporter) и проанализировал специфические для СУБД показатели: рост очереди блокировок (lock waits) именно в интервале 19:00–20:00; падение коэффициента попадания в кэш буферов (buffer cache hit ratio) ниже 85%; данные pg_stat_statements, где один неоптимизированный запрос занимал 40% общего времени выполнения системы.
Что сделали. Добавили покрывающий индекс, переписали запрос с фильтрацией по дате на стороне БД, включили журналирование долгих запросов (log_min_duration_statement) и настроили сбор метрик насыщения по методологии USE.
Результат. Обращения в техподдержку по этой проблеме упали до нуля. Время отклика платёжного API на уровне p95 снизилось с 4,2 секунды до 180 миллисекунд. Пиковые нагрузки перестали вызывать каскадные таймауты.
Вывод
Мониторинг инфраструктуры показывает состояние сервера, а не состояние СУБД. Свободный CPU не означает, что база данных не испытывает проблем с блокировками, дисковым вводом-выводом или конкретными запросами.
Повторяющиеся инциденты: перезапуск службы лечит симптом, а не причину
Исходная ситуация. В логистической компании MS SQL Server работал на пределе. Раз в две недели CRM-система падала с ошибками взаимоблокировок (deadlocks) и нехватки памяти. Штатные администраторы устраняли последствия — перезапускали службу и очищали процедурный кэш. Через 10–14 дней инцидент повторялся.
В чём была причина. Отсутствовало регламентное обслуживание индексов, а очистка версий строк (ghost cleanup) не учитывалась при эксплуатации. Фрагментация индексов достигала 90%, превращая поиск в полное сканирование страниц. Под нагрузкой биллинга механизм версионирования забивал tempdb, вызывая аллокационные блокировки всей системы.
Что сделал DBA. Вместо очередного перезапуска провели диагностику. Нашли отсутствующие индексы на внешних ключах, из-за которых блокировки эскалировались до уровня таблицы, и обнаружили избыточный уровень изоляции SERIALIZABLE там, где достаточно READ COMMITTED SNAPSHOT. Настроили регулярное ночное обслуживание: дефрагментацию индексов с фрагментацией выше 30%, обновление статистики, обслуживание tempdb и рекомендуемый режим изоляции строк.
Результат. Повторяющиеся инциденты прекратились. Потребление RAM стабилизировалось, свопинг исчез. Формирование ежемесячных отчётов для бухгалтерии сократилось с 40 до 3 минут.
Вывод
Если один и тот же инцидент устраняется одним и тем же способом раз в несколько недель — это не решённая проблема, а накапливающийся технический долг, который просто регулярно сбрасывают.
Когда своей команды становится недостаточно
Проблема с внутренним администрированием не всегда проявляется как отдельный инцидент, а иногда граница компетенций становится заметна при изменении самого ИТ-ландшафта.
Исходная ситуация. Крупный региональный производитель пищевой продукции после слияния с двумя конкурентами увеличил объём активной базы MS SQL Server с 300 ГБ до 2 ТБ за квартал, а число одновременных сессий пользователей ERP-системы на 1С — со 150 до 450. Внутренняя команда из двух универсальных системных администраторов Linux/Windows хорошо справлялась с доменной инфраструктурой и терминальными серверами, но её компетенций перестало хватать для смешанной нагрузки OLTP/OLAP на MS SQL.
Какие задачи передали ФТО:
- Лицензирование и редакция. Аудит использования CPU и ядер, обоснование перед финансовым директором перехода со Standard Edition на Enterprise — для Online Index Rebuild и In-Memory OLTP, без которых останавливалась работа склада.
- Always On Availability Groups. Настройка кластера Windows Server Failover Clustering (WSFC), распределённая группа доступности между основным ЦОД и резервным узлом с читаемой репликой для снятия нагрузки отчётности.
- Оптимизация TempDB. Устранение конфликтов PAGELATCH_EX на страницах глобального аллокатора (sys.sysmultiobjrefs), разделение файла tempdb на 8 физических файлов и выделенный SSD-том под временные объекты.
- Тюнинг специфики 1С. Секционирование тяжёлых регистров бухгалтерии по месяцам, внедрение Service Broker для асинхронного обмена данными с маркетплейсами вместо прямых синхронных вызовов.
Почему не стали решать это силами текущей команды. Здесь вопрос был не в одной недостающей компетенции, а в том, что от команды одновременно требовались производительность, отказоустойчивость, безопасность и развитие архитектуры:
- Цена простоя. Остановка проведения складских документов в прайм-тайм означала штрафы от транспортных компаний и невозможность выписки УПД. Риск блокировки таблиц на часы при ручном шринке базы или дефрагментации был финансово неприемлем.
- Сложность экосистемы Microsoft. Требовались одновременно компетенции в отказоустойчивости на уровне ОС (кворум WSFC), сетевой балансировке и внутренней архитектуре Database Engine — управлении ожиданиями LCK_M_X, PAGEIOLATCH_SH.
- Требования ИБ. Подключение нового крупного enterprise-клиента требовало аудита на соответствие ISO 27001: детализированного аудита через Extended Events для доступа к персональным данным контрагентов и прозрачного шифрования (TDE) с управлением ключами через Key Vault.
- Экономика обучения. Время, которое два инженера потратили бы на изучение нюансов Snapshot Isolation и устранение блокировок в одной системе, обошлось бы дороже полугодового контракта с профильными DBA, которые сразу приносят готовые шаблоны конфигураций.
Вывод
Рост нагрузки и усложнение требований не всегда означают нехватку одной компетенции — часто это признак того, что от инфраструктуры одновременно требуется больше, чем универсальная команда может обеспечить параллельно с остальными задачами.
Что считать сигналом к пересмотру модели администрирования
- Восстановление из бэкапа никогда не проверялось в условиях, близких к реальному отказу.
- Мониторинг показывает состояние сервера, но не объясняет проблемы на уровне запросов и СУБД.
- Один и тот же инцидент регулярно устраняется перезапуском или другой временной мерой.
- Обслуживание индексов, статистики и tempdb выполняется нерегулярно или не выполняется вовсе.
- Растут нагрузка, объём данных или число пользователей, а архитектура остаётся прежней.
- Появляются требования к высокой доступности, отказоустойчивости, восстановлению в заданные сроки.
- СУБД становится частью более сложного контура — 1С, BI, интеграций, корпоративных систем.
- К инфраструктуре предъявляются дополнительные требования по информационной безопасности.
Вместо заключения
Самостоятельное администрирование СУБД — это нормальная модель для определённого масштаба и уровня сложности. Она перестаёт быть достаточной, когда от базы данных требуется одновременно высокая производительность, отказоустойчивость, контролируемое восстановление, безопасность и развитие.
Переход на профильную DBA-экспертизу не обязательно означает полный отказ от собственной команды: часть задач может оставаться внутри компании, а внешние специалисты подключаться для регулярного сопровождения, аудита или проектных работ, требующих узкой экспертизы.
Ни один чек-лист не заменяет разбор конкретной архитектуры. Если несколько пунктов выше совпадают с вашей ситуацией, обычно есть смысл сначала понять реальный масштаб риска — что именно происходит с базой сейчас и во что это может вылиться при следующем росте нагрузки, — и только потом решать, какая модель администрирования нужна дальше. В ФТО такую диагностику мы регулярно проводим ещё до того, как предлагать что-либо менять.