О том, как за счет применения специальных программных систем и методологий можно повысить производительность прикладных информационных систем, нам удается рассказать не так часто. В российской практике подобных внедрений очень мало даже в крупных компаниях. Сегодня на эту тему мы беседуем с Вадимом Феоктистовым, директором «ММК-Информсервис», входящего в группу ММК (Магнитогорский металлургический комбинат).
Intelligent Enterprise: Вы уже давно используете системы управления производительностью приложений. К каким конкретно прикладным системам, функционирующим на ММК, сейчас применяется процедура?
Вадим Феоктистов: Мы используем систему Precise (ранее она называлась Symantec I3), которая изначально предназначалась для мониторинга производительности эксплуатационных серверов КИС, серверов приложений и сервера базы данных. На этой инфраструктуре функционируют Oracle E-Business Suite и ряд других приложений, охватывающих все основные направления деятельности предприятия. Перечислю только главные их них: бухгалтерия, закупки и продажи, производственный модуль, кадры и зарплата, ремонты.
Скажите, удалось ли накопить какую‑то статистику типичных проблемных ситуаций? Иными словами, где в основном возникают узкие места? При доступе к БД, при выполнении тех или иных вычислительных процедур, в случае интенсивного ввода-вывода вообще? В связи с какими типичными ситуациями в бизнесе компании (например, годовая отчетность, время заключения крупных договоров или построение стратегических прогнозных моделей) они возникают?
Говорить, что есть типичные проблемные ситуации, было бы неправильно. Каждая проблемная ситуация имеет свои характерные признаки и разбирается отдельно в каждом конкретном случае. Для конечного пользователя важнейший показатель качества любого сервиса — время реакции системы, которое измеряется от момента подачи запроса в систему до момента получения конечного результата. На этом промежутке можно выделить типичные временные ожидания, которые возникают при эксплуатации любой системы. Это коммуникационные ожидания, ожидания на уровне фиксации транзакции, ожидания на уровне операционной системы, а также связанные с блокировками на уровне приложений. Также важно учитывать ожидания действий ввода-вывода, работы центрального процессора и ожидания, возникающие из‑за внутренних блокировок в базе данных.
Система КИС, которая эксплуатируется на ОАО ММК, достаточно сбалансирована. Под балансом подразумевается, что того количества процессоров, которое используется на сервере базы данных, объективно достаточно для обрабатываемых задач, а ввод-вывод обеспечивает доступ к данным без существенных задержек. Этот баланс помогает обеспечить программное обеспечение Precise. В результате нам удалось поддержать загрузку основного сервера базы данных КИС на уровне 50% в межотчетный и 80% в отчетный период. При этом за три года эксплуатации системы Precise общая загрузка сервера не увеличилась, хотя за это время размер базы вырос с 1,5 Tb до 3,5 Tb.
Можно ли сейчас говорить о некоторых методических наработках в сфере повышения производительности?
На текущий момент, наверное, можно говорить, что наработана методика по управлению производительностью. Хотя, пожалуй, правильнее это назвать системным подходом, который заключается в том, что на регулярной основе аналитики по производительности анализируют работу системы и указывают разработчикам процессы, которые загружали систему больше всего за определенный промежуток времени. Сигналом к анализу может быть и жалоба на медленную работу какой‑то формы либо приложения. С помощью системы Precise проводится детальный анализ работы такой компоненты, и ее разработчикам сообщают, на что нужно обратить внимание. Ну и как всякая система, эта методика должна предусматривать обратную связь. То есть аналитик должен видеть, что изменения в системе были сделаны и действительно улучшили работу рассматриваемой компоненты. На текущий момент, к сожалению, такая обратная связь пока не обрела четкой организационной формы. Но с помощью системы мониторинга производительности Precise всегда можно точно сказать, была ли произведена работа по оптимизации формы либо приложения, и оценить ее качество и эффективность Кстати, как нам известно, аналогичный подход по управлению производительностью, заключающийся в постоянном контроле и оптимизации самых «тяжелых» прикладных компонент, практикуется во многих организациях, использующих Precise. Такой подход радикально уменьшает риски возникновения самопроизвольно возникающих проблем производительности и, по сути, реализует в этом смысле упреждающую стратегию.
Мы рассматриваем управление производительностью в первую очередь как операционную активность. У нас нет каких‑то специальных методических наработок по его использованию для управления изменениями, хотя контроль трендов, анализ изменений общих системных потребностей мы осуществляем постоянно. Очевидно, что данные, накапливаемые системой Precise, могут быть эффективно использованы при планировании и тестировании изменений. Но в течение последних трех лет, когда использовалась система Precise, необходимости в принятии радикальных решений — например, по выбору между проведением мероприятий по глубокой оптимизации и апгрейдом оборудования — у нас не возникало. Как я уже упоминал, постоянный контроль параметров работы приложений и оперативное выполнение «локальных» шагов по оптимизации позволяет поддерживать качество работы прикладной системы на требуемом уровне. По опыту могу сказать, что такой подход существенным образом отодвигает необходимость кардинальных мер по апгрейду аппаратуры.
Относительно того, что оптимизация одних компонент может вызвать деградацию производительности других: если рассматривать такую возможность совсем в общем плане, то решением было бы построение какой‑то глобальной модели прикладной системы, включающей эмуляцию нагрузки, и проведение для такой среды анализа what-if. Это задача, далекая от реальности. На практике сфера влияния разных компонент в общей среде наших приложений в целом достаточно хорошо нам известна и позволяет смело выполнять большую часть мероприятий по оптимизации. При этом некоторые из них действительно нуждаются в аналитической проработке с последующим контролем реальных результатов на «живой» системе. А что касается такой актуальной темы, как, например, взаимосвязь влияния индексов в сложных структурах БД, — в Precise есть средства проведения анализа what-if для оценки эффективности предстоящих изменений, и эти инструменты мы используем в необходимых случаях.
Какой самый типичный «набор» инструментов вы бы выделили из тех, что в принципе способны помочь организовать описанный выше полный цикл управления изменениями?
Здесь, наверное, можно говорить о том, что у нас есть, и о том, что еще хотелось бы видеть на нашем предприятии. На текущий момент имеется система оперативного контроля работы серверных ресурсов, позволяющая контролировать и оповещать администраторов о нештатных ситуациях. Причиной выдачи сигнала может служить наличие блокировки в базе или недоступность сервера, невыполнение своевременного резервного копирования базы или переполнение очереди отправки сообщений на почту клиентам — это система Oracle Grid Control. Есть также система, которая позволяет указать источники загрузки и узкие места в приложении, работающем на данном сервере. Это упомянутая система Precise. Для мониторинга сетей и аппаратной инфраструктуры используется CA Unicenter, в эксплуатации находится также ряд других систем, которые в той или иной степени поддерживают или могли бы поддерживать разные фазы полного цикла управления изменениями. Но как единый замкнутый и полный механизм система поддержки изменений на ММК пока отсутствует.
Являются ли средства управления производительностью прикладных систем в том числе и инструментом, полезным в кризисной ситуации?
Я думаю, что средства управления производительностью полезны в любом случае. Но поскольку они позволяют снизить операционные расходы и капитальные затраты, в кризис их ценность возрастает многократно. Ситуацию, когда в результате внедрения системы управления производительностью апгрейд оборудования откладывается на несколько лет, можно назвать как раз классической. Не говоря уже о нашем случае, есть другие многочисленные примеры внедрения решения Precise, которые это демонстрируют (к сожалению, в основном за рубежом — в России это система пока мало распространена).
Что касается эффекта внедрения Precise, то здесь я бы выделил два типа получаемых результатов. Первый — это выявление диспропорций в нагрузке, случаев некорректного использования приложения, ошибок в настройке, и прочих проблем, внешних или внутренних по отношению собственно к приложению. Эти проблемы могут быть решены немедленно, дав значительный и при этом мгновенный эффект в виде снижения общей загруженности приложения и в приросте производительности (скажем, в два раза: по моему опыту, такой результат внедрения системы вполне реален). Как раз этот, «первичный» эффект от внедрения можно назвать «антикризисным» в том смысле, что результат может быть получен в кратчайшие сроки.
Но более важен «вторичный» эффект — результат системного, планомерного подхода к управлению производительностью, которого я касался в самом начале, поскольку только в этом случае можно говорить, что в управлении работой приложения появляется эффективная обратная связь, а функционирование приложения становится «прозрачным». Такой «вторичный» эффект может существенно превосходить «первичный», однако он проявляется не сразу, а оказывается результатом целенаправленных и постоянных усилий.
И еще о балансе между апгрейдом и оптимизацией: в ряде случаев никакая модернизация оборудования не может быть столь же эффективной, как оптимизация ПО. Пример из практики: некий отчет выполнялся два часа. Если мы сделаем обновление оборудования и увеличим производительность условно в два раза, то получим уменьшение времени работы данного отчета на один час, но оптимизация позволила уменьшить время выполнения этого отчета в 15 раз, то есть до 8 минут. Нечего и говорить, что стоимость оптимизации оказалась многократно ниже, чем цена возможного апгрейда аппаратуры. Система управления производительностью указала на столь мощный потребитель ресурсов и помогла найти эффективный подход к оптимизации.
Средства управления производительностью прикладных систем до сих пор внедряются в практику работы отечественного бизнеса не так активно. Существуют ли какие‑то отраслевые задачи или особенности построения и развития ИТ-архитектуры в вашем случае, которые бы заставляли вас смотреть на подобные системы чуть более активно, чем предприятия других отраслей?
Система КИС на ММК очень сильно завязана на производственный процесс, с ней работает очень много пользователей. Любые задержки, например с документами на отгрузку или по бухгалтерскому учету, в конечном счете могут привести к большим финансовым потерям. И таких примеров, касающихся работы нашего комбината, можно привести множество. Действительно, есть определенные задачи, особенности архитектуры системы ИТ и условия ее использования, которые делают применение средств управления производительностью особенно актуальным. Попробую их перечислить:
Все это имеет самое прямое отношение к нашему комбинату. Однако существует множество других предприятий, и в совсем других отраслях, где сочетаются перечисленные факторы. Более того, практически все предприятия по мере роста их бизнеса и достижения определенной зрелости попадают в зону действия таких факторов.
Есть два ключевых слова, которые, может быть, более точно определяют условия и степень необходимости использования подобных систем: это эффективность и управление рисками.
Про эффективность можно рассуждать очень долго. Но один пример: посмотрите сегодня на место нашего комбината среди других предприятий — как по параметрам капитализации, так и по многим другим показателям. Наша лидирующая позиция как раз таки характеризует тот уровень эффективности, который достигнут в значительной степени благодаря стратегии развития и достигнутому уровню эффективности ИТ комбината. И если говорить о системе управления производительностью, то решение об анализе возможности применения этой технологии было принято на самом высоком уровне бизнес-руководства комбината еще в начале 2006 г.
Относительно управления рисками: это отдельная тема, которой у нас уделяется огромное внимание. Если же говорить о многих других предприятиях, даже государственной важности, да и вообще об укоренившемся у нас отношении к возможным катастрофическим случайностям или неизбежностям, то даже события всего нескольких последних месяцев характеризуют его в достаточной степени.
Эксплуатация такой системы несомненно имеет свои особенности и требует определенной квалификации и знаний от специалистов. Сама система подвержена изменениям, что возвращает нас к вопросу об управлении изменениями…
Внедрение и освоение системы в принципе мало отличается по своему характеру от внедрения других ИТ‑систем корпоративного уровня. Все та же история: источником компетенции во всех новейших областях являются вендоры, лидирующие западные поставщики технологий, и их местные представители и партнеры.
Как и во многих подобных случаях, с системой работают два типа специалистов: администраторы, управляющие ее работой (система Precise ведь тоже может считаться некоторым приложением, требующим обычного набора операций по контролю и управлению), и пользователи, осуществляющие контроль работы целевых приложений КИС. Первоначальное обучение проводили на рабочих метах представители российской технологической компании «СофтБиКом», внедрявшей систему и до настоящего времени осуществляющей ее локальную поддержку.
Система Precise, несомненно, требует наличия постоянной поддержки вендора и его представителей, поскольку при своей непростой архитектуре она, как и положено, постоянно обновляется. Запланирован переход на ожидаемую версию 9, в которой будет много принципиально нового. Основной вектор развития системы — большее внимание мониторингу транзакций в контексте многоуровневой архитектуры (прямая информация для бизнеса об уровне выполнения SLA, в том числе в разрезе бизнес-транзакций), и непосредственное соединение результатов такого контроля с руководящими указаниями и детальной информацией, которые система предназначает непосредственно специалистам, ответственным за анализ и оптимизацию.
С точки зрения управления изменениями управление самой системой Precise имеет целый ряд задач, связанных, прежде всего, с накопленной статистикой о работе приложения, хранящейся в специальной базе данных — репозитории. Следует контролировать, чтобы при апгрейдах его содержимое не было случайно утеряно или как‑то искажено, а также следить, чтобы сроки этапов жизненного цикла хранящейся в нем информации (ступени обобщения/сжатия, в конечном счете — удаления) являли собой баланс между потребляемым объемом дисковой памяти и уровнем детальности данных, сохраняемым определенное время (принятый у нас срок хранения данных в репозитории составляет три года).
