Рассмотрение вопросов развития прикладных информационных систем, предназначенных для поддержки ключевых бизнес-процессов, на российском рынке до сих пор в основном сосредоточено вокруг возможностей перехода с одной прикладной системы на другую или замены аппаратной/программной платформы. Однако при этом упускаются из виду другие формы развития прикладных систем, направленные на повышение эффективности использования имеющегося оборудования и программных комплексов. О том, как эта проблема решается на Магнитогорском металлургическом комбинате, рассказывает его ИТ-директор Дмитрий Каплан.

Intelligent Enterprise: Будучи осведомленными об успехах комбината в развитии направления, связанного с управлением производительностью приложений, давайте начнем с самого простого вопроса: когда в подобных решениях возникает потребность в принципе? Может, это связано с некой качественной зрелостью ИТ-направления в компании, с достижением «критической массы» бизнес-систем и инфраструктурных решений, или речь идет о зрелости корпоративного управления вообще…

Дмитрий Каплан: Управление производительностью приложений, или, по-английски, Application Performance Management, APM, — это класс инструментальных систем, которые помогают выполнять требования бизнеса к прикладным ИТ-решениям, являющимся критическим компонентом важнейших бизнес-процессов. Подобные системы нужны в тех случаях, когда выполнение требований бизнеса к уровню обслуживания становится абсолютной необходимостью.

Внедрение системы класса APM всегда является проектом корпоративного уровня, который ведётся по заказу бизнес-структур компании и требует серьезного финансирования.

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

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

Но и это еще не всё. Очень часто задача повышения производительности критически важной прикладной системы решается наращиванием вычислительной мощности, и тогда вроде бы никакими APM-системами морочить голову не нужно. Такой подход является вполне удовлетворительным во многих случаях: когда удается достоверно определить «узкие места», когда требуемый апгрейд имеет приемлемую стоимость и вообще технически осуществим. Еще одно условие эффективности «апгрейдного» подхода — чтобы само приложение было не очень сложным структурно и весьма стабильным по составу и характеру поведения. И последнее: когда риски потерь при неожиданных провалах производительности критических приложений (а сроки устранения таких внезапных провалов, как правило, непредсказуемы) все же не являются чрезмерными.

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

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

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

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

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

Другая сторона подхода, реализуе­мого применением APM, — опера­тивность в решении внезапно возникающих проблем. Не секрет, что без эффективного инструментария поиск причин снижения производительности может продолжаться непредсказуемо долго. В экстренных условиях это катастрофа. Прессинг со стороны руководства еще больше усложняет ситуацию. О неприемлемых потерях бизнеса в таких случаях я уже упоминал.

Наличие инструмента, делающего «прозрачной» структуру загрузки при­ложения, позволяет «экстренный» анализ производительности приложения перевести на регламентную основу. При этом диагностика причин негативного явления может быть ограничена кон­кретным, вполне приемлемым времен­ным интервалом. Благодаря полноте информации в этом случае вы будете находить быстрые и эффективные решения, пусть иногда и временные. Весь перечисленный комплекс факторов лег в основу решения Депар­та­мента информационных технологий ММК о внедрении i3 применительно к Oracle e-Business Suite и прикладным системам производственного блока, реализованным на базе СУБД Sybase. Проект был выполнен в 2007 году с участием компании SoftBCom.

Если возможности мониторинга самых сложных ИТ-систем и анализа полученных данных столь богаты, то наверняка развиваемое вами направление можно связать с тем методологическим аппаратом, который уже довольно широко используется в отношении управления ИТ. Имеются в виду инструменты, так или иначе навеянные идеями ITIL: каталогом сервисов, уровнями их предоставления, управлением изменениями и так далее. Насколько уместно здесь говорить о подобном сопряжении?

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

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

Следует также учитывать, что параметры SLA не являются некоторыми застывшими значениями — они могут уточняться или быть предметом определенных программ по улучшению уровня сервиса, при этом будут появляться новые параметры и удаляться утратившие актуальность. Значения этих параметров представляют собой некий баланс между действительными потребностями бизнеса и реальными возможностями информационных систем, поэтому их обоснованность с точки зрения ИТ, полная информация обо всех элементах цепочки причин, ограничивающих их значения, позволяет строить реальную программу повышения уровня обслуживания или поддержания того уровня, который достигнут, в условиях увеличивающейся нагрузки.

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

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

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

Тут возникает еще один интересный вопрос, связанный с пересечением функционала различных систем. Известно ведь, что и знаменитый HP OpenView, и CA Unicenter (о внедрении которой на ММК мы, кстати, писали отдельно) «движутся вверх», пытаясь решать вопросы не только технического мониторинга. А тут в ИТ-ландшафте появляется еще один продукт, претендующий на роль «исследователя» работы ИТ-систем. Есть ли здесь проблема, и как вы вообще могли бы прокомментировать эту ситуацию?

Здесь, я думаю, удобнее да и корректнее перевести разговор на конкретные системы. Что касается системы Precise i3 — одного из представителей семейства APM, — то ее функциональность часто обозначают словом «мониторинг», что может вызвать определённую путаницу. Ведь понятие «мониторинг» в этом случае относится к уровню приложения и лишь частично покрывает уровни ОС, сетевой инфраструктуры и т. д. То есть это мониторинг в той степени, в какой он необходим для управления производительностью именно приложений. При этом Precise i3 не подменяет функциональности таких систем, как, например, HP OpenView, IBM Tivoly или используемая на нашем комбинате CA Unicenter. Некоторая область пересечения функциональности есть, но она не является определяющей для управления производительностью приложений.

В процессе выбора решения APM мы посетили одно из крупнейших металлургических предприятий США, где познакомились с опытом использования i3. В этой компании HP OpenView применяется для комплексного оперативного мониторинга всех информационных систем, а i3 — для анализа вопросов производительности прикладной системы. При этом руководство ИТ-отдела рассматривает задачи, решаемые теми и другими системами, как совершенно разные, с ними работают различные функциональные группы специалистов.

Тем не менее существует возможность интеграции двух упомянутых подходов, т. е. включения данных мониторинга i3 в более общую картину, формируемую CA Unicenter, хотя эта задача на комбинате пока не решена. Однако задачу интеграции с другими системами управления ИТ-ресурсами надо в каждом случае рассматривать индивидуально. Скажем, контроль качества новых или усовершенствованных программных компонентов с помощью средств i3 в составе системы управления изменениями совершенно необходим, и у нас i3 так или иначе задействована в этом процессе. А механическая интеграция не связанных функционально систем вряд ли принесет какую-либо пользу.

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

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

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

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

К поддержке самостоятельного апгрейда корпоративного ПО, или, иными словами, к технологиям программной инженерии APM-системы тоже имеют отношение. И при всем том i3 не заменяет профессиональных средств разработчиков, с помощью которых они, например, производят профилирование и трассировку исполнения кода Java или решают другие задачи отладки — для них существует свой специализированный инстру­ментарий. Система i3 имеет целый набор «интеллектуальных» функций — скажем, подсказки, обращающие внимание специалистов на проблемные моменты или содержащие альтернативные варианты SQL-кода. Однако подсказки эти конечно же не заменяют дедуктивных способностей и знаний специалиста, исследующего ту или иную проблему. При этом i3 предо­ставляет в графическом режиме, в логически связанном интерфейсе подробную информацию, которая содержит и исторические данные, и позволяет исследовать влияние на производительность разнообразных факторов, в том числе проанализировать корреляцию определенных параметров и связь обнаруженных изменений с теми или иными событиями.

Можно было бы еще долго рассматривать различные грани применения таких непростых и многофункциональных систем, как i3. Но подводя итог, скажу, что системы класса APM вообще необходимы в первую очередь крупным предприятиям, где ИТ-системы решают критически важные бизнес-задачи, и потери от снижения производительности или простоев этих систем могут быть весьма весомыми. И особенно это верно в тех случаях, когда мощность ИТ-решения такова, что его простое техническое масштабирование уже не является тривиальной задачей.