Кто пользуется базой и кто за неё отвечает?
Начните со списка всего, что читает данные из базы или записывает их туда: приложения, интеграции, регулярные отчёты, выгрузки в другие системы. Без такого списка легко ускорить базу для одной программы и сломать её для другой. Этот же список — отправная точка для разработки баз данных и интеграций. Часто в таком списке обнаруживаются забытые интеграции и отчёты, о которых никто уже не помнит, но которые продолжают нагружать базу.
Опишите ключевые сущности — то, на чём держится ваш бизнес: клиентов, заказы, платежи, — вместе с их идентификаторами и бизнес-правилами, которые должны соблюдаться. Запишите, кто управляет доступом, какие версии используются и поддерживаются ли они ещё, какое обслуживание требуется и кто его выполняет. Отметьте и то, когда нагрузка наибольшая: часы пик, закрытие месяца или ночные загрузки часто объясняют проблемы, которых не видно на разовом снимке.
Затем посмотрите на медленные или ненадёжные места со стороны приложения: на какие экраны, отчёты или операции жалуются пользователи. Не исходите из того, что виновата только база данных. Сеть, неэффективные запросы, которые формирует приложение, и медленные внешние сервисы тоже влияют на то, что видят пользователи, и аудит базы данных, который их не учитывает, рискует исправить совсем не то.
Как исследовать базу под рабочей нагрузкой?
Используйте инструменты мониторинга, которые поддерживает ваша СУБД, чтобы изучить статистику запросов и использования ресурсов. В PostgreSQL, например, накопительная статистика, описанная в официальной документации, показывает, как используются таблицы и индексы и какие процессы сейчас выполняются. Посмотрите на связи в схеме, на места, где может пригодиться индекс, и на шаблоны, которые создают дорогую работу: повторные сканирования больших таблиц, запросы внутри циклов, соединения, которые растут вместе с данными.
Каждое предлагаемое изменение проверяйте в подходящей среде на данных, близких к рабочим, прежде чем оно попадёт в рабочую систему. Изменение, которое помогает на маленькой тестовой копии, может вести себя совсем иначе при реальном объёме и распределении данных. Перед каждым изменением сделайте исходный замер, чтобы потом показать эффект тем же методом, без оценки на глаз.
Не добавляйте индексы и не перестраивайте таблицы только потому, что так советует какой-то общий чек-лист. Каждый индекс ускоряет часть чтений, но замедляет запись и занимает место, а каждое изменение структуры потом нужно сопровождать. Любая рекомендация должна опираться на факты о вашей собственной нагрузке, а не на общее правило. Если рекомендация не подкреплена замером, её разумнее отложить.
Сможете ли вы восстановить сервис и безопасно его изменить?
Вместе с руководителем со стороны бизнеса определите, сколько данных компания может позволить себе потерять и как долго сервис может быть недоступен, — это и есть ваши цели восстановления. Затем проверьте, что порядок резервного копирования и восстановления действительно им соответствует. Единственный надёжный способ это узнать — провести тестовое восстановление и засечь время.
Для запланированных изменений проверьте права доступа, шаги миграции и то, можно ли откатить изменения, если что-то пойдёт не так. Миграция без проверенного пути назад — это риск, и он должен быть виден тем, кто её утверждает. Включите в проверку и доступы: кто может подключаться к базе, с какими правами и не остались ли активными учётные записи бывших сотрудников или отключённых интеграций.
Назначьте ответственных за наблюдение и дальнейшие шаги после аудита. Результатом должны стать собранные факты, рекомендации, расставленные по важности, и критерии приёмки для каждого изменения. И помните: наличие файла резервной копии ещё не означает, что сервис можно восстановить. Пока восстановление не проверено на практике, у вас есть только надежда.
Чек-лист: аудит базы данных
- Составьте карту приложений, ключевых сущностей и людей, отвечающих за базу данных.
- Исследуйте запросы, опираясь на данные о типичной рабочей нагрузке.
- Проверяйте предлагаемые изменения вне рабочей системы, прежде чем применять их.
- Проверьте восстановление на практике и решите, кто занимается дальнейшими шагами.
Пример: тяжёлый отчёт в часы пик
Отчёт строится запросом, который снова и снова соединяет растущую таблицу с другими, — и запускается как раз тогда, когда клиенты активнее всего, и приложение начинает тормозить. Команда изучает фактический план выполнения запроса и нагрузку, проверяет новый подход вне рабочей системы и измеряет эффект, прежде чем что-то менять в работающем сервисе. Изменение переносят в рабочую систему только после того, как замер подтвердил улучшение.
Проверка восстановления из резервной копии и приёмка миграции остаются отдельными пунктами аудита: исправление медленного отчёта ничего не говорит о том, удастся ли восстановить сервис после сбоя.
