Всем привет. Много лет назад потребность обеспечения высокой производительности баз данных стала в разы актуальней, однако до сих пор отнюдь не всегда подобные вопросы получается легко решить, в связи с чем попытаюсь изложить свое видение по данному вопросу, исходя из личного опыта.
Итак, у нас есть проблема: база данных 1С “висит”, пользователей из базы “выкидывает”, работать невозможно. При этом, предварительный анализ показал, что сервис в запущенном состоянии, и работа предстоит долгая и упорная, с ходу не поборешь.
Руководство, мягко говоря, жутко недовольно, “стоит за дверью с вилами”, так как работа предприятия фактически парализована, и лично ваша судьба в компании висит на волоске. Самое важное в этот момент – сохранять спокойствие, не давать ложных надежд о сиюминутном результате, подготовить всех к долгому и сложному пути
Ставим цель: повышение стабильности и скорости работы базы данных 1С за счет изменения конфигурации оборудования и баз данных, конечно же в рамках проекта.
Предпосылки: заметили всплеск количества обращений от пользователей по вопросам невозможности выполнять штатный функционал в базе данных 1С.
Влияние на бизнес: задержки в работе базы 1С приводят к несвоевременному выполнению сотрудниками своих функций(обработка заказов, сдачи отчетности, иное), а «торможения» при выполнении операций раздражают и в целом негативно сказываются на производительности сотрудников.
Еще раз повторюсь: достижение цели должно происходить с холодной головой, пусть все вокруг кричат и топают ногами, но мы планомерно шаг за шагом будем двигаться вперед, не предпринимая резких и необдуманных решений
Риски проекта:
1. Для поиска узких мест в базе данных 1С нужен «взгляд со стороны», отследить по формальным признакам зачастую – невозможно;
Оптимизация - не разовая работа, а постоянный, живой, процесс повышения эффективности работы базы(можно сравнить со стройкой моста: после того как он построен, необходим регулярный его ремонт, так и в данном случае);
-
Найти все узкие места(в том числе даже при помощи самых современных систем мониторинга) сразу нельзя, так как часть из них может возникать только в случае определенных событий и сценариев.
Критерий успешности проекта:
- Сокращение количества обращений пользователей по проблеме «тормозит база данных» – до Х(однозначное число) обращений в период(до оптимизации количество могло достигать нескольких сотен обращений)
- Стабилизация сроков обмена между базами данных до нормативного значения*;
- Сокращение количества аварий на объектах оптимизации до Х(однозначное число) в период (до оптимизации количество могло достигать несколько десятков в период)
*Нормативное значение определяется исходя из договоренностей с ЛПР бизнеса, либо фиксируется в матрице сервиса.
Этапы проекта(выносим за скобки процедуру формирования и защиты бюджета на устранение проблемы, так как у нас бизнес не может выполнять свою основную деятельность и выдает карт – бланш на решение вопроса в кратчайшие сроки).
Определение состояния AS IS (Как есть сейчас) – аудит:
– Поиск узких мест в работе баз данных
– Выявление взаимосвязей в ошибках
– Анализ достаточности серверных мощностей
– Проверка длительности запросов в разных сценариях
Формирование состояние TO BE (Как должно быть) и выполнение необходимы мероприятий для этого:
– Программная оптимизация(оптимальные настройки SQL, кластера 1С, устранение долгих запросов по результатам отчета мониторинга, регулярные профилактические работы(автоматическая перезагрузка во внерабочее время, обслуживание базы данных типовыми и нетиповыми средствами), обрезка лишней информации(например, десятки миллионов неактуальных записей в регистре, что постоянно перебираются в ходе запросов и тормозят работы базы данных 1С)
– Оптимизация логических блоков работы базы данных 1С(выявление избыточных операций, переговоры с бизнесом об отказе от них)
– Апгрейд оборудования(важно этот пункт отработать после того, как проработаны два предыдущих, так как далеко не всегда дело в нехватке в серверных мощностях, а зачем нам лишний закуп?)
3. После выполнения всех работ обязательно проводим опрос целевой аудитории, работающей в базе, собираем объективную обратную связь. Примеры вопросов:
- оцените скорость работы в базе данных 1С в настоящий момент
- заметили ли вы позитивные изменения(скорость работы) в базе данных 1С по сравнению с тем, как было несколько месяцев назад/до начала проекта?
- напишите, пожалуйста, отзыв, если скорость работы в базе не устраивает: какие операции в базе данных 1С вы порекомендовали бы ускорить?
После этого точечно отрабатываем замечания, или убеждаемся в том, что отныне все хорошо.
Для отчета об окончании комплексной оптимизации представляем аналитику по выполнению долгих запросов было – стало.
Подготовка и заключение договора на плановые аудиты с последующей оптимизацией с компанией, специализирующейся в подобных вопросах(их масса в РФ), для организации процесса предиктивного устранения возможных проблем в работе базы данных 1С:
– Стоимость и состав услуг
– Стоимость аналогичных предложений с рынка
– Примеры выполненных работ
5. Наращивание собственной(штатной) экспертизы в области оптимизации высоконагруженных конфигураций с целью повышения безопасности бизнеса и минимизации стоимости организации сервиса. В том числе позволит более вдумчиво изменять код, не делая его менее оптимальным
Важные замечания:
А)обращаем внимание на взаимодействие базы данных 1С с иными системами(зачастую проблемы могут вызывать они, например, при заборе данных из нашей базы 1С)
Б)при оптимизации долгих запросов соблюдаем принцип: штатное обновление типовыми релизами не должно серьезно усложниться
В)при проведении проекта крайне рекомендуется договориться с заказчиком о том, чтобы количество изменений в базе данных 1С в этот период было минимальным(или отсутствовало)
В)изменение культуры работы в продуктивной базе данных 1С: все изменения – только в песочнице, все тесты – только в песочнице, все права администратора – только у ответственных за ИТ сопровождение лиц
Г)оптимизация – это сложный, кропотливый процесс: никто не гарантирует вам решение всех проблем в супер сжатые сроки, это планомерная разовая работа, а после – адекватная культура внесения изменений в продуктивную систему безопасно
У меня всё, спасибо за внимание????
Надеюсь, кому – то пригодится.
И по – прежнему не забываем о том, что не всегда существуют быстрые решения, важно планомерно работать над устранением
Заранее спасибо за обратную связь, и, надеюсь, что хотя бы кому – то помог.
Комментарии (4)
FanatPHP
08.05.2022 10:53+2Идеи высказаны в целом верные, но над оформлением надо работать.
Главное, что надо помнить — картинки и мемасики не заменят конкретику.
В целом, статьи, состоящие из общих рекомендаций, в принципе имеют право на существование. Но если они подкреплены практическими рекомендациями и реальными примерами, это идёт им сильно в плюс.
Наличие же длинного и путанного вступления с самоповторами, а так же большого количества картинок работают в минус, и оставляют легкое ощущение "что я сейчас прочитал"?В целом статья оставляет впечатление сентенции "лучше быть богатым и здоровым, чем бедным и больным". Ну отлично, "поиск узких мест". А КАК их искать? "Выявление взаимосвязей в ошибках". Не очень понятно, что имеется в виду. "Анализ достаточности серверных мощностей". А это разве не входит в "поиск узких мест в БД"? Тут же ведь либо индексов не хватает, либо памяти под индексы. Если второе, то вот оно — узкое место и необходимость апгрейда — нет? "Проверка длительности запросов в разных сценариях" — опять же, это разве не тот же самый поиск узких мест? И почему бы не подключить средства самой БД, slow_query_log в mysql и аналоги в других базах?
Отдельно хочу отметить, что хотя действительно проще застрелиться, чем победить Новый Суперэргономичный и Значительно Улучшайзенный Редактор Хабра 2.0, но старая версия всё ещё доступна по ссылке.
- И с помощью
- несложного маркдауна
- вполне можно
- делать аккуратные
- вложенные
- списки
avolsed Автор
08.05.2022 11:16+1Спасибо, в первый раз эргономику поправил модератор, в этот раз не учёл что более таких преференций не будет:) впредь буду более аккуратным по форме в том числе:) за ссылку отдельное спасибо
- И с помощью
askharitonov
Вы ведь понимаете, что открывая статью, заголовок которой начинается с «Оптимизация высоконагруженных конфигураций», читатели ожидают увидеть более-менее конкретные рекомендации или хотя бы истории успеха, но никак не статью, где будет рассказываться, что критерии успешности оптимизации — это сокращение количества обращений пользователей, уменьшение количества аварий и сокращение времени обмена данными с базой до установленных значений?
avolsed Автор
Спасибо за обратную связь, в данном случае моя история успеха именно такова, цели уходить в глубокие технические дебри не было, направлением движения поделился. Не зашло, увы, двигаемся дальше, это всего вторая моя статья за 3 дня, буду учиться на ошибках . Спасибо ещё раз за конструктив!