Рубрики

Технологическая экспертиза крупных внедрений и консультирование

Статьи по теме:

Решения включенные в каталог IBM Global Solutions Directory:

Для чего это нужно?

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

  • Программа будет работать гораздо медленнее, чем ожидалось (ожидание проведения документа может достигать 5 минут и более);
  • Возникновение непонятных ошибок:
    Превышение времени ожидания блокировки
    Взаимоблакировка

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

Из-за чего возникают такие ситуации? При крупных внедрениях всегда используется клиент-серверный вариант 1С. Это означает, что 1С передает свои команды системе управления базами данных (СУБД). Для 1С обычно используется СУБД Microsoft SQL. Профессиональный программист во время написания программы может не знать обо всех тонкостях хранения данных в СУБД, а также серверной архитектуры, влиянии отдельных составляющих аппаратных средств на общую производительность системы. Более того, это не входит в его непосредственные обязанности. Соответственно, механизмы взаимодействия 1С и СУБД могут работать далеко не оптимально, может быть недостаточной мощность серверов, или, наоборот, серверы могут использоваться с неполной нагрузкой.

В результате, после внедрения, параллельная работа некоторого числа пользователей в системе может оказаться невозможной (система проводит операции очень медленно, пользователю выводятся сообщения о таймаутах и взаимоблокировках и т.п.). Желательно эти результаты определить еще до внедрения программного продукта. Оценить, найти и устранить подобные «узкие места» – непосредственная обязанность Эксперта по технологическим вопросам.

Когда возникает потребность в обращении к Эксперту по технологическим вопросам?

схема-1

Для того, чтобы это понять, нужно хорошо представлять этапы «Жизненного цикла» прикладного решения (схема №1).

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

Как правило, основная работа эксперта начинается на этапе нагрузочного тестирования. Для заказчика, а тем более для пользователя видна только верхушка айсберга - эта та программа, в которой он работает. На самом деле, система "1С:Предприятие" имеет специальные механизмы взаимодействия с СУБД. СУБД отвечает за хранение данных и многопользовательский доступ к ним. Ее задача – обеспечить чтение и запись в базу непротиворечивой информации в режиме, когда много пользователей записывают данные (проводят документы). Какие же проблемы могут при этом возникнуть?

Возможность проведения документа зависит от считанной информации (например, наличие остатков на складе для расходной накладной). Соответственно, система должна обеспечить неизменность прочитанных данных на время записи документа (в нашем примере, чтобы другая накладная не списала этот же остаток товара), то есть запись документов, затрагивающих эти же данные, должна быть приостановлена до окончания операции. Это является необходимой блокировкой данных, то есть блокировкой, которая обеспечивает правильность работы приложения. Платформа 1С неявно передает команды управления данными СУБД, а она уже, используя свои внутренние механизмы, обеспечивает необходимые блокировки данных. Однако при программировании решения в среде 1С затруднительно учитывать взаимодействие с СУБД, так как оно является сложным и неоднозначным. На одну и ту же команду 1С СУБД может отреагировать по-разному, в зависимости от ситуации. В результате могут возникнуть необоснованные, излишние блокировки, которые могут существенно снизить быстродействие при работе большого количества пользователей или просто парализовать работу системы.

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

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

Насколько оправдано привлечение экспертной службы на этапе разработки проекта?

Использование экспертной технологической оценки проекта влечет за собой дополнительные затраты со стороны заказчика. Это связано с созданием адекватной модели тестирования, которая смогла бы максимально приблизиться к реальной работе предприятия. Разработка такой модели требует определенного времени. Чем крупнее проект и больше механизмов и объектов в нем предусмотрено, тем больше потребуется времени на создание модели. Однако работа экспертов по нагрузочному тестированию на стадии разработки проекта существенно сократит в дальнейшем расходы на исправление вероятных ошибок.

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

схема-2

Для ответа на этот вопрос заказчик должен хорошо представлять методику приемки внедрения (схема №2):

  • Как заказчик планирует проверять продукт? Для проверки ресурсами заказчика придется останавливать рабочий процесс или в нерабочее время привлекать к тестированию сотрудников автоматизируемых в проекте участков. В противном случае, при начале работы с программой, основная работа предприятия может быть парализована.
  • Смогут ли привлеченные сотрудники обеспечить достаточную нагрузку на систему? Смогут, при условии привлечения всех сотрудников автоматизированного участка. При этом пользователи должны уже уметь хорошо работать в новой системе. В противном случае проверка будет не полной и «узкие места» при многопользовательской работе выявлены не будут.
  • Сможет ли тестирование ресурсами заказчика симулировать пиковые нагрузки? В бухгалтерии, например, в конце месяца может очень существенно вырасти объем вводимой документации. Если это не учесть при проверке, то в самые ответственные периоды, при сдаче отчетности, например, могут возникнуть проблемы.
  • Как заказчик планирует симулировать нагрузку на систему при запланированном росте предприятия? Как правило, при разработке системы закладывается определенный запас надежности с учетом роста предприятия. В соответствии с этим планируется порядок увеличения объёма информационной базы.
  • Сможет ли заказчик в случае необходимости повторно привлечь к тестированию продукта сотрудников в не рабочее время? Как показывает практика, одного тестирования для проверки системы не достаточно. Если будут найдены ошибки, необходимо будет проводить повторное тестирование. В этом случае, повторный вызов персонала в нерабочее время обернется дополнительными затратами для работодателя и неудобствами для персонала.

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

схема-3

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

Что делать, если система уже внедрена?

Если во внедренной системе возникли проблемы с производительностью, специалист экспертной службы может произвести анализ всех «узких мест» с ранжированием их по уровню значимости. Подобный анализ в дальнейшем сэкономит время на устранение недостатков. Проведение анализа (схема №3) позволит исключить ошибки и гарантирует безупречную работу системы.

Особенности задач, стоящих перед 1С:Экспертом:

Не всегда понятно, с чем связано замедление работы системы. Типичный случай: программист обнаруживший "ошибку", в течение длительного времени ее исправляет, но от этого система быстрее не работает. После чего вновь происходит поиск "ошибки", но исправление следующий найденной ошибки, также не приводит к увеличению быстродействия. И так далее. Это связано с тем, что в большой системе может присутствовать до нескольких десятков ошибок и быстро определить наиболее критичные довольно проблематично.

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

Сфера деятельности 1С:Эксперта:

Для ответа на этот вопрос нужно знать уровни функционирования прикладных решений (схема №4).

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

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

схема-4

Обычному программисту очень трудно удержать в голове команды одного, например, нижележащего уровня, транслирующегося в команды вышестоящего. Особенно, когда это касается межуровневого взаимодействия, начиная с платформы 1С:Предприятие (Уровень 3) и заканчивая уровнем операционной системы и оборудования (Уровень 5). Умение хорошо разбираться в межуровневом взаимодействии и есть основная задача Эксперта по технологическим вопросам.

Какие работы мы выполняем в рамках данного направления?

  • Консультирование на этапе разработки
  • Нагрузочное тестирование
  • Комплексное обследование уже внедренных систем, включая мониторинг работающих систем
  • Выявление «узких мест» в порядке значимости, создание перечня рекомендаций с целью их исправления прикладными программистами (как на этапе разработки, так и для внедренных систем)
  • Диагностика достаточности аппаратных средств и создание рекомендаций по их дальнейшему развитию
  • Оптимизация прикладного решения на основе составленных рекомендаций

Наши специалисты осуществляют работы с помощью таких средств, как «1С:Корпоративный инструментальный пакет 8», «SQL Server Profiler», «Системные счетчики производительности» и других специализированных инструментов.

Почему именно Трейд Софт?

Наша компания имеет опыт работы с системами разной сложности на протяжении 10 лет, включая многопользовательские многофилиальные системы, призванные в режиме реального времени обрабатывать огромные массивы данных. Кроме того, компания занимает достойное место во всех рейтингах фирмы «1С». Ну и наконец, мы на третьем месте по числу сертифицированных специалистов 1С:Эксперт в России.

 
ГК Трейд Софт, Москва
Автор: Ведущий специалист Глебов Илья
Дата публикации: 25.08.2008 г.
(0.031 c.)

Мы Вам перезвоним

*
*
 

Нажимая кнопку, я принимаю условия Оферты по использованию сайта и согласен с Политикой конфиденциальности