От автора: на момент событий какая либо система мониторинга ресурсов отсутствует. Тестовый стенд поднимется через год.

ИТ-инфраструктура компании встретила меня суровым пейзажем: 12 серверов баз данных, разбросанных по разным географическим площадкам. Два из них были собраны в «недокластер» (базовый отказоустойчивый Windows-кластер без современных механизмов синхронизации данных). Четких планов обслуживания баз не существовало, как и понимания, зачем они вообще нужны. Резервное копирование (бэкап) делалось по старинке: раз в сутки ночью сохранялась полная копия баз и делались технические выгрузки для систем 1С. В обновлениях программ и графиках технических работ царил полный беспорядок. Спасибо можно было сказать разве что службе нормативно-справочной информации (НСИ): они хотя бы внедрили единый стандарт для наименований баз и шифрования данных. Наведение порядка я разбила на несколько этапов: 1. Уравниловка. Первым делом пришлось провести ревизию версий СУБД (SQL Server) и обновить их все до единого стандарта. Исключение сделали только для старой программы расчета зарплаты (ЗИК) — её оставили на стабильной связке 2008 операционки и SQL Server . 2. Анализ нагрузки. Мы подсчитали максимальное количество пользователей в пиковые часы. Выяснилось, что некоторым серверам банально не хватает «железа» — туда оперативно добавили процессорные мощности и оперативную память. 3. Дипломатия и графики. Начался долгий переговорный процесс с отделом поддержки 1С и промышленной автоматизации. Нужно было поминутно выяснить, когда выгружаются данные, и рассчитать планы бэкапов для каждой базы и её «журнала транзакций» (лога — места, куда записывается каждое действие пользователя). Приходилось на пальцах доказывать коллегам прописные истины: например, что увеличение базы на фиксированный объем (в мегабайтах) и увеличение в процентах — это абсолютно разные вещи с точки зрения нагрузки на диски и сервер. Через неделю первый комплексный план бэкапов был готов. Сначала резервное копирование настроили через систему DPM, затем перешли на более мощный Veeam. Мы постоянно корректировали графики, добавляли новые базы и серверы. Но тут руководство решило закупить Cyber Backup. Для DBA это означало одно: всю систему резервного копирования нужно перестраивать заново. В итоге мы пришли к гибридной схеме: журналы действий (логи) бэкапились непрерывно по внутреннему расписанию самого SQL-сервера, а полные тяжелые копии баз забирал Cyber Backup. Раз в три месяца эти планы пересматривались, так как базы стремительно росли. Когда система бэкапов стала стабильной, пришло время заняться скоростью работы. Я потратила три месяца на вычисление «тяжелых» и неоптимизированных запросов к базе данных, которые тормозили всю компанию, и передала этот список программистам 1С на переработку. Позже в компании появилась команда бизнес-аналитиков, и жить стало еще «веселее». Их тоже пришлось взять под плотный контроль, так как их сложные аналитические запросы на выборку данных без должной оптимизации могли легко «уронить» производительность любого сервера. Что получил бизнес в результате этой масштабной работы? • Стабильность 1С: Работа высоконагруженных баз полностью стабилизировалась. Общая надежность системы выросла, а время случайных технических простоев свелось к минимуму. • Порядок в регламентах: Серверы теперь останавливаются только по графику — для установки плановых обновлений. • Здоровье «железа»: Популярная ранее процедура «шринка» (принудительного сжатия файлов базы, которая сильно изнашивает диски и замедляет работу) теперь применяется только в самых крайних, форс-мажорных случаях. До этого её зачем-то гоняли каждый день. Финальным штрихом я написала собственную небольшую базу данных, которая собирает статистику и динамику роста всех рабочих баз холдинга. Теперь мы не ждем, когда закончится место на дисках, а точно прогнозируем время добавления ресурсов и вовремя меняем планы обслуживания, проводим общий тюнинг производительности. Именно поэтому у хорошего DBA всегда есть четкий и оптимальный план. План обслуживания. #админскиеистории #личныйопыт