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

Понятно, что определять мощность конкретного оборудования для бизнес-приложения необходимо на основании оценки количества будущих пользователей системы и числа бизнес-операций, с учетом перспективы развития. Все крупные производители серверов имеют обоснованные методики расчета конфигурации своего оборудования, необходимого для работы основных бизнес-приложений. Эти методики должны помочь оптимальную конфигурацию оборудования, основываясь на количестве пользователей, а также на данных об объеме и сложности различного вида транзакций, которые предполагается обрабатывать с помощью, например, ERP-системы.

Рассчитать практически невозможно

Это теория. Однако многие ИТ-директора говорят, что заранее рассчитать необходимую производительность оборудования практически невозможно. Несмотря на все усилия, определить необходимый уровень производительности системы не удается. "Выбор оборудования для mySAP Business Suite - это отдельный вопрос, - говорит Андрей Володин из "Евросети". - Я не знаю случаев, когда кто-то угадал с этим оборудованием". В результате при запуске в промышленную эксплуатацию система начинает захлебываться.

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

В интервью многие ИТ-директора российских предприятий говорили о том, что тех оценок производительности, которые предоставляют производители оборудования и бизнес-приложений, совершенно недостаточно. Реальная производительность иногда оказывается более чем на 30% меньше. Одна из причин недостаточности вендорских методик расчета конфигураций - это кастомизация пакетной системы и функциональность системы, которая была подвергнута наибольшей доработке. Увы, зачастую эта же функциональность оказывается и самой критичной для заказчика. "Реальные требования со стороны ERP-системы зачастую существенно отличаются от стандартных (учтенных в программах расчета нагрузки на систему) из-за доработки ее стандартной функциональности, - говорит Виктор Горбунов, директор по консалтингу группы "Борлас". - Расчеты не учитывают влияния доработок системы под специфику деятельности предприятия. Реальные требования может оценить только сам "внедренец"".

Другая причина неудач с предварительной оценкой необходимой производительности - в ведении проекта. Кроме того, многие ИТ-менеджеры пренебрегают описанными в любой методике мерами по нагрузочному тестированию системы. В плане проекта должны быть выделены работы, связанные с проведением тестирования производительности системы (нагрузочного тестирования). Такие работы обычно включают: подготовку среды тестирования (с учетом исторических данных), определение наиболее критичных тестовых критериев (время отклика интерфейсов, время формирования отчетов, время выставления счетов, время закрытия периода и т. д.), проведение нагрузочного тестирования (в ряде случаев - с использованием специального программного обеспечения).

"Необходимо применять различные методы аналитического и имитационного моделирования нагрузки на серверы приложений и баз данных, обеспечивающих работу ERP-системы, - говорит Александр Савинов, руководитель направления бизнес-приложений компании КРОК. - В первом случае мы рассчитываем характеристики оборудования исходя из имеющихся сведений о пользователях, их профиле, структуре ЛВС заказчика, апеллируя как к собственному накопленному опыту, так и к опыту производителей ERP-систем и аппаратных платформ. Во втором случае уточняется перечень ключевых пользовательских бизнес-процессов, определяется последовательность шагов пользователя в системе для их имитации, формируются соответствующие этим шагам наборы типовых тестовых сценариев и данных. Далее проводится автоматизированное нагрузочное тестирование путем имитации работы заданного числа пользователей с определенными бизнес-процессами".

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

Грамотное планирование и партнер

Грамотное планирование нагрузочных тестов и роста мощности оборудования - залог решения будущих проблем с производительностью. "Да, эта проблема есть, и мы были научены опытом многих других компаний, - говорит руководитель проекта по вредрению mySAP ERP в крупном российском промышленном холдинге. - Мы запускались в январе, а проблемы производительности системы начали появляться в мае. Но сильного урона они не нанесли, потому, что мы были готовы к ним. У нас был разработан план модернизации оборудования под систему, мы четко представляли необходимые объемы хранения, мощность процессоров и т. д. Конечно, предугадать необходимую производительность очень сложно, но мы ошиблись всего на всего на 10-15%. Это было достигнуто за счет хорошего планирования. Чтобы просчитать необходимую в будущем производительность оборудования были привлечены специальные ресурсы. Мы привлекали нашего генерального подрядчика, работали с контролем качества, делали прогнозы по наполнению базы данных во время тестов, собирали статистику по росту базы данных. В результате в районе февраля-марта мы уже имели адекватное представление, сколько потребуется оборудования, и насколько мы загрузим процессорные и дисковые мощности. Исходя из этого мы и сформировали план модернизации оборудования под систему".

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