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

Итак, у нас есть проблема: база данных 1С “висит”, пользователей из базы “выкидывает”, работать невозможно. При этом, предварительный анализ показал, что сервис в запущенном состоянии, и работа предстоит долгая и упорная, с ходу не поборешь.

Руководство, мягко говоря, жутко недовольно, “стоит за дверью с вилами”, так как работа предприятия фактически парализована, и лично ваша судьба в компании висит на волоске. Самое важное в этот момент – сохранять спокойствие, не давать ложных надежд о сиюминутном результате, подготовить всех к долгому и сложному пути

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

Предпосылки: заметили всплеск количества обращений от пользователей по вопросам невозможности выполнять штатный функционал в базе данных 1С.

Влияние на бизнес: задержки в работе базы 1С приводят к несвоевременному выполнению сотрудниками своих функций(обработка заказов, сдачи отчетности, иное), а «торможения» при выполнении операций раздражают и в целом негативно сказываются на производительности сотрудников.

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

Риски проекта:

1.      Для поиска узких мест в базе данных 1С нужен «взгляд со стороны», отследить по формальным признакам зачастую – невозможно;

  1. Оптимизация - не разовая работа, а постоянный, живой, процесс повышения эффективности работы базы(можно сравнить со стройкой моста: после того как он построен, необходим регулярный его ремонт, так и в данном случае);

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

Критерий успешности проекта:

- Сокращение количества обращений пользователей по проблеме «тормозит база данных» – до Х(однозначное число) обращений в период(до оптимизации количество могло достигать нескольких сотен обращений)

- Стабилизация сроков обмена между базами данных до нормативного значения*;

- Сокращение количества аварий на объектах оптимизации до Х(однозначное число) в период (до оптимизации количество могло достигать несколько десятков в период)

*Нормативное значение определяется исходя из договоренностей с ЛПР бизнеса, либо фиксируется в матрице сервиса.

 

Этапы проекта(выносим за скобки процедуру формирования и защиты бюджета на устранение проблемы, так как у нас бизнес не может выполнять свою основную деятельность и выдает карт – бланш на решение вопроса в кратчайшие сроки).

  1. Определение состояния AS IS (Как есть сейчас) – аудит:

–       Поиск узких мест в работе баз данных

–       Выявление взаимосвязей в ошибках

–       Анализ достаточности серверных мощностей

–       Проверка длительности запросов в разных сценариях

  1. Формирование состояние TO BE (Как должно быть) и выполнение необходимы мероприятий для этого:

–       Программная оптимизация(оптимальные настройки SQL, кластера 1С, устранение долгих запросов по результатам отчета мониторинга, регулярные профилактические работы(автоматическая перезагрузка во внерабочее время, обслуживание базы данных типовыми и нетиповыми средствами), обрезка лишней информации(например, десятки миллионов неактуальных записей в регистре, что постоянно перебираются в ходе запросов и тормозят работы базы данных 1С)

–       Оптимизация логических блоков работы базы данных 1С(выявление избыточных операций, переговоры с бизнесом об отказе от них)

–       Апгрейд оборудования(важно этот пункт отработать после того, как проработаны два предыдущих, так как далеко не всегда дело в нехватке в серверных мощностях, а зачем нам лишний закуп?)

3.      После выполнения всех работ обязательно проводим опрос целевой аудитории, работающей в базе, собираем объективную обратную связь. Примеры вопросов:

- оцените скорость работы в базе данных 1С в настоящий момент

- заметили ли вы позитивные изменения(скорость работы) в базе данных 1С по сравнению с тем, как было несколько месяцев назад/до начала проекта?

- напишите, пожалуйста, отзыв, если скорость работы в базе не устраивает: какие операции в базе данных 1С вы порекомендовали бы ускорить?

После этого точечно отрабатываем замечания, или убеждаемся в том, что отныне все хорошо.

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

  1. Подготовка и заключение договора на плановые аудиты с последующей оптимизацией с компанией, специализирующейся в подобных вопросах(их масса в РФ), для организации процесса предиктивного устранения возможных проблем в работе базы данных 1С:

–       Стоимость и состав услуг

–       Стоимость аналогичных предложений с рынка

–       Примеры выполненных работ

5.      Наращивание собственной(штатной) экспертизы в области оптимизации высоконагруженных конфигураций с целью повышения безопасности бизнеса и минимизации стоимости организации сервиса. В том числе позволит более вдумчиво изменять код, не делая его менее оптимальным

Важные замечания:

А)обращаем внимание на взаимодействие базы данных 1С с иными системами(зачастую проблемы могут вызывать они, например, при заборе данных из нашей базы 1С)

Б)при оптимизации долгих запросов соблюдаем принцип: штатное обновление типовыми релизами не должно серьезно усложниться

В)при проведении проекта крайне рекомендуется договориться с заказчиком о том, чтобы количество изменений в базе данных 1С в этот период было минимальным(или отсутствовало)

В)изменение культуры работы в продуктивной базе данных 1С: все изменения – только в песочнице, все тесты – только в песочнице, все права администратора – только у ответственных за ИТ сопровождение лиц

Г)оптимизация – это сложный, кропотливый процесс: никто не гарантирует вам решение всех проблем в супер сжатые сроки, это планомерная разовая работа, а после – адекватная культура внесения изменений в продуктивную систему безопасно

У меня всё, спасибо за внимание????

Надеюсь, кому – то пригодится.

И по – прежнему не забываем о том, что не всегда существуют быстрые решения, важно планомерно работать над устранением

Заранее спасибо за обратную связь, и, надеюсь, что хотя бы кому – то помог.

 

Комментарии (4)


  1. askharitonov
    08.05.2022 10:47
    +9

    Вы ведь понимаете, что открывая статью, заголовок которой начинается с «Оптимизация высоконагруженных конфигураций», читатели ожидают увидеть более-менее конкретные рекомендации или хотя бы истории успеха, но никак не статью, где будет рассказываться, что критерии успешности оптимизации — это сокращение количества обращений пользователей, уменьшение количества аварий и сокращение времени обмена данными с базой до установленных значений?


    1. avolsed Автор
      08.05.2022 11:15
      -5

      Спасибо за обратную связь, в данном случае моя история успеха именно такова, цели уходить в глубокие технические дебри не было, направлением движения поделился. Не зашло, увы, двигаемся дальше, это всего вторая моя статья за 3 дня, буду учиться на ошибках . Спасибо ещё раз за конструктив!


  1. FanatPHP
    08.05.2022 10:53
    +2

    Идеи высказаны в целом верные, но над оформлением надо работать.


    Главное, что надо помнить — картинки и мемасики не заменят конкретику.
    В целом, статьи, состоящие из общих рекомендаций, в принципе имеют право на существование. Но если они подкреплены практическими рекомендациями и реальными примерами, это идёт им сильно в плюс.
    Наличие же длинного и путанного вступления с самоповторами, а так же большого количества картинок работают в минус, и оставляют легкое ощущение "что я сейчас прочитал"?


    В целом статья оставляет впечатление сентенции "лучше быть богатым и здоровым, чем бедным и больным". Ну отлично, "поиск узких мест". А КАК их искать? "Выявление взаимосвязей в ошибках". Не очень понятно, что имеется в виду. "Анализ достаточности серверных мощностей". А это разве не входит в "поиск узких мест в БД"? Тут же ведь либо индексов не хватает, либо памяти под индексы. Если второе, то вот оно — узкое место и необходимость апгрейда — нет? "Проверка длительности запросов в разных сценариях" — опять же, это разве не тот же самый поиск узких мест? И почему бы не подключить средства самой БД, slow_query_log в mysql и аналоги в других базах?


    Отдельно хочу отметить, что хотя действительно проще застрелиться, чем победить Новый Суперэргономичный и Значительно Улучшайзенный Редактор Хабра 2.0, но старая версия всё ещё доступна по ссылке.


    1. И с помощью
      • несложного маркдауна
      • вполне можно
    2. делать аккуратные
      • вложенные
      • списки


    1. avolsed Автор
      08.05.2022 11:16
      +1

      Спасибо, в первый раз эргономику поправил модератор, в этот раз не учёл что более таких преференций не будет:) впредь буду более аккуратным по форме в том числе:) за ссылку отдельное спасибо