Вряд ли сегодня найдется крупная организация, не сталкивавшаяся с внезапным снижением производительности бизнес-приложений и связанными с этим проблемами: недовольством пользователей, репутационными издержками и прямыми убытками. К сожалению, выявить реальные причины таких ситуаций крайне непросто, поэтому слишком часто наши ИТ-отделы выбирают экстенсивный путь: предлагают купить новый сервер, расширить каналы связи… Подобные варианты довольно дороги, к тому же не гарантируют положительного результата. К счастью, у нас имеется гораздо более эффективная и менее затратная альтернатива, связанная с применением особых технических средств, специальных методик и знаний. В совокупности все эти инструменты формируют организационно-техническую систему управления производительно
стью приложений. Внедрение таких систем и оптимизация ИТ-ландшафта предприятия с их помощью – одна из наиболее эффективных точек приложения усилий в период экономического кризиса.
Предпосылки появления систем управления производительностью приложений
Пока организация невелика (50–100 сотрудников), мало кто задумывается о том, как сделать так, чтобы критичные для бизнеса приложения работали быстро и потребляли минимум ресурсов. Но при количестве рабочих мест от 200 и выше нагрузка на бизнес-приложения (почту, корпоративный портал, внешний сайт, платформу «1С:Предприятие», CRM-решение, BI-систему) возрастает. И наконец наступает такой момент, когда производительность приложений, на которые опирается основная деятельность предприятия, вдруг начинает падать. А вместе с этим снижается эффективность работы целых отделов, начинают буксовать и сквозные бизнес-процессы. Если проблему не решить вовремя, она вырастет сначала до уровня ключевых подразделений, например бухгалтерии или отдела продаж, а потом и всей организации.
Сложности в выявлении проблем с производительностью приложений зачастую связаны с тем, что они возникают на стыке элементов инфраструктуры, отдельных программных компонентов или бизнес-процессов, из-за чего носят скрытый характер. Такие проблемы могут существовать годами, а незаметные ручейки малых издержек, вызванных трудностями в работе, скажем, приложений на платформе «1С:Предприятие» или BI-системы, в совокупности наносят предприятию серьезный репутационный и финансовый урон, достигающий иногда десятков миллионов рублей.
Чтобы не оказаться в подобной ситуации и заранее снизить потери на ее выравнивание, бизнесу необходимо внедрять процессы управления производительностью и оптимизации быстродействия приложений, сделав их неотъемлемой частью системы управления ИТ. Поэтому каждому крупному и среднему предприятию нужно интегрировать в состав своих ИС специализированную подсистему, которая сможет автоматически отслеживать их состояние и поставлять достоверные данные, необходимые для своевременного выявления назревающих проблем. Эта система также создаст надежный фундамент для проактивной оптимизации производительности за счет выявления и устранения узких мест в работе приложений и всей ИТ-инфраструктуры.
Факторы, усложняющие определение и ликвидацию узких мест
Немалую сложность в выстраивании управления производительностью приложений представляют задачи своевременной и всесторонней регистрации состояния системы, накопления и автоматизированной обработки таких данных,особенно в многоуровневых, распределенных и гетерогенных приложениях.
И здесь нам приходится сталкиваться с множеством факторов, усложняющих эту задачу:
- многообразие компонентов (аппаратные ресурсы, функции, процессы), подлежащих контролю. Ресурсы центрального процессора (ЦП), оперативной памяти, системы хранения данных, среды передачи данных, инфраструктурное ПО (ОС, СУБД и др.) и бизнес-процессы с реализующим их программным кодом;
- различные подходы к измерению характеристик использования компонентов и разная природа получаемых показателей (единицы измерения). Подходы касаются измерения степени использования/утилизации компонентов, пропускной способности компонентов (абсолютная/относительная), очереди запросов/активностей, времени отклика компонента при выполнении запросов/активностей, времени выполнения функций;
- разный вклад компонентов в общую производительность;
- взаимное влияние компонентов, которые нужно контролировать.
APDEX как общий знаменатель для поступающих данных
По нашему опыту, для корректного объединения всех вышеперечисленных данных целесообразно использовать стандарт оценки производительности корпоративных приложений – APDEX. Он дает возможность привести к одной шкале множество разнородных фактов. Кроме того, отслеживаемые операции ранжируются по приоритетности для бизнеса, что позволяет правильно акцентировать внимание при мониторинге и оптимизации большого количества операций. APDEX оперирует понятными для бизнеса критериями оценки: «отлично», «хорошо» и т. д., в итоге поставляя понятную бизнес-заказчикам информацию о том, насколько пользователи довольны работой каждого приложения («довольны», «удовлетворены», «разочарованы»). Важно, что индекс производительности приложений основывается на реальных данных, полученных средствами мониторинга инфраструктуры и приложений, и получение этих данных происходит в реальных условиях, т. е. при работе в приложениях всех пользователей.
Сбор, накопление и анализ данных о производительности и использовании отдельных компонентов удобнее всего вести как с помощью специализированных инструментальных средств (Performance Counters, SNMP, WBEM, SQL Server DMV, DTrace, Process Monitor, VTune, Valgrind и др.), так и путем интеграции в приложения специализированных сенсоров. При этом данные должны поступать в непрерывном режиме, создавая постоянное поле для анализа состояния приложений в любой момент времени. А процесс оптимизации работы приложений должен быть не разовым, а непрерывным.
Методика выявления, определения и расшивки узких мест
Предлагаемая методика в комплексе с правильными инструментами – применением стандарта APDEX для оценки производительности приложений (в том числе на платформе «1С:Предприятие 8»), а также специализированными инструментальными средствами и комплексными системами мониторинга позволяет сделать процесс совершенствования приложений постоянным, эффективным и недорогим, в частности за счет циклических переключений между уровнями «пирамиды оптимизации» (включает в себя инфраструктуру, программный код и бизнес-процессы). Частота и скорость переключений зависят от внутренних и внешних факторов, влияющих на бизнес.
Методика состоит из следующих этапов, выполняемых один за другим.
- Формулирование измеримых, конкретных, достижимых, ориентированных на бизнес-процесс целей оптимизации.
- Идентификация всех имеющихся компонентов (аппаратные ресурсы, функции, процессы и др.).
- Проверка на наличие ошибок в работе или конфигурации каждого компонента.
- Сбор данных и оценка производительности приложения и отдельных компонентов.
- Обнаружение проблем и их приоритезация в зависимости от степени влияния на бизнес.
- Поиск решений и устранение обнаруженных недостатков.
- Объективная оценка результатов оптимизации.
- Разработка мер по недопущению повторения подобных проблем.
Если поставленная цель оптимизации труднодостижима (повышение производительности системы коммерческого учета на «1С» в два раза), стоит разбить традиционный проект на несколько более мелких микропроектов. На первом этапе, который будет длиться 1,5 недели (а не 1,5–3 месяца, как в стандартных проектах), производительность приложения можно повысить на 20–25%, на втором – еще на 20–25% и, наконец, на третьем – еще на 20%. В противном случае получится долгострой с непредсказуемым конечным результатом. Более того, при существующих высоких темпах изменения внешних условий (рынок) и внутренней ситуации в компаниях, когда даже государственные структуры вынуждены менять ключевые бизнес-процессы, тратить на оптимизацию быстродействия учетной системы 4,5–9 месяцев – непростительная роскошь.
Система мониторинга – основной инструмент методики, а Zabbix – его наилучший «свободный» вариант
Комплексная система мониторинга – обязательный инструмент методики, обеспечивающий непрерывный сбор и первичный анализ состояния системы на всех уровнях: аппаратном, инфраструктурном, на уровне программного кода и бизнес-процессов (см. рисунок), причем с обязательной возможностью регистрации тенденций (система стабильна в последние шесть месяцев; показатели быстродействия снижаются; есть резкие улучшения или ухудшения после внесения изменений и пр.).
Кроме того, система мониторинга должна обеспечивать возможность установки граничных значений для состояния ИС. Следует отметить, что необходимы как простые выражения для одного контролируемого параметра (время выполнения ключевой операции, утилизация ЦП), так и сложные критерии, охватывающие несколько взаимосвязанных показателей (обращений менее 100 и время выполнения ключевой операции более одной секунды). Такой подход позволяет переводить количественные показатели в качественные. Например, путем оценки времени отклика СХД или другого показателя можно установить следующие градации: «отлично» (< 5 мс), «хорошо» (< 10 мс), «нормально» (<2 0 мс) и т. д.
Благодаря этому эксперт, время которого дорого, сразу видит проблемные места и находит способы их устранения: ему больше не нужно тратить силы на рутинный ручной контроль сотен или тысяч параметров. Он быстро оценивает, насколько четко поддерживается важный для компании бизнес-процесс, например обмен данными центра с филиалами, который происходит не реже раза в час (если реже, нарушается управление филиалами).
Для нашего департамента системой мониторинга, которая обладает всеми требуемыми свойствами, после тщательного отбора и тестирования стал Zabbix. Во-первых, это по-настоящему открытый продукт. Он не только имеет открытый код без всяких исключений в виде дополнительных платных модулей, но и спроектирован так, что сам подталкивает ИТ-специалистов к расширению его возможностей. А простые API и протоколы обеспечивают удобные инструменты интеграции с различными системами. Во-вторых, указанный продукт хорошо развивается сообществом, не расколотым конфликтами. В-третьих, отсутствуют лицензионные платежи, что может стать серьезным аргументом на проектах для крупных заказчиков.
Совместно с Zabbix мы используем решения на базе InfluxDB (сбор и обработка плохо структурированной информации, дополнительная функциональность для анализа данных), Grafana (визуализация данных InfluxDB), «1С:Центр контроля качества» (в проектах по оптимизации приложений, построенных на платформе «1С:Предприятие»).
Совместная экспертиза – необходимый элемент проектов по оптимизации приложений
Важно уметь правильно выбрать вектор приложения усилий, не тратя ресурсы и время на проработку заведомо неэффективных решений. Поэтому сильная экспертиза на проектах по оптимизации производительности приложений – еще один неотъемлемый компонент системы управления производительностью приложений. Требуемый уровень экспертизы может обеспечить команда, состоящая из специалистов, не только глубоко понимающих свои процессы (инфраструктуру, код, бизнес-процессы), но и обладающих знаниями в смежных областях. В противном случае трудно рассчитывать на результативную работу.
Хорошим вариантом будет привлечение на проект внешнего подрядчика. Ведь создание подходящей команды внутри самой компании – непростая задача. А, скажем, специалисты из смежных департаментов зрелой компании-интегратора вполне могут не только совмещать все необходимые качества, опыт и компетенции (аудит ИТ-инфраструктуры, аудит кода, общее с заказчиком понимание бизнес-процессов), но и привнести свежий взгляд на основные вопросы.
И наконец, о важности нюансов (инфраструктура, приложения, OpenSource-приложения), на которые обязательно стоит обращать самое пристальное внимание. Это помогает избегать затягивания проектов оптимизации по срокам.
Инфраструктура: каскад ИТ-аудитов с опорой на данные мониторинга
Анализ состояния ИТ-инфраструктуры – это нулевой (предварительный) этап, который позволяет качественно пройти первый слой «пирамиды оптимизации», т. е. быстро выявить явные ошибки и дисбаланс ресурсов, привести в порядок наиболее проблемные/важные для заказчика части ИТ-инфраструктуры.
Ведь если исключить объективные причины снижения производительности приложений (увеличение объемов обрабатываемых данных, количества пользователей, внедрение новых функций), то основным фактором снижения производительности часто являются именно узкие места в инфраструктуре, которые не позволяют полностью реализовать имеющийся потенциал ИС. Их устранение дает максимальный результат с минимальными затратами.
Например, неверные настройки СУБД исключают возможность использовать всю доступную память или из-за нехватки вычислительной мощности практически простаивают СХД и сеть, при хорошо сбалансированной инфраструктуре в центре используются слабые и ненадежные каналы связи в регионах. Такие ИТ-казусы часто не видны, поскольку они складываются исторически: из-за неправильного планирования или неверного масштабирования ИТ-инфраструктуры, отсутствия контроля над ее состоянием и производительностью приложений.
На этапе обязательного «нулевого» аудита можно обойтись без частого для многих исполнителей завышения стоимости по причине того, что «плохо может быть везде – нужно подстраховаться». Качественный «нулевой» аудит четко показывает проблемные места и позволяет безошибочно определять направления дальнейшей работы.
При этом не стоит ограничиваться таким аудитом, как это бывает на стандартных проектах, а в рамках интегрированного управления ИТ осуществлять в ходе оптимизации инфраструктуры непрерывный цикл микроаудитов, которые всегда будут опираться на данные из системы мониторинга и регистрировать влияние на ИС даже самых небольших изменений, фиксируя новое состояние системы, раз в один-три дня или в неделю в зависимости от задач.
Благодаря каскаду аудитов базовое состояние системы всегда остается актуальным, и больших временных затрат на вход в новый проект по оптимизации не потребуется. Еще один плюс микроаудитов – возможность разбить работы по оптимизации на небольшие этапы, что позволяет четко видеть, как идет прогресс, и не плодить неверные или неоптимальные решения. Ведь возможны и такие ситуации, когда нужно не новый этап начинать, а «откатить» систему назад, так как изменения «не прошли».
Приложения: оптимизация, совмещенная с Agile-подходом
Выделение коротких итераций в процессах управления производительностью приложений также хорошо совмещается с набирающими популярность гибкими (Agile) методиками разработки приложений. Их главный принцип – внесение изменений малыми порциями и получение на выходе каждой итерации готового бизнес-результата, который заказчик может использовать «здесь и сейчас».
Подобный подход часто применяют при разработке веб-приложений, онлайновых торговых площадок, B2B-приложений для среднего и крупного бизнеса. Уровень конкуренции на этом рынке предъявляет высокие требования к скорости оптимизации имеющихся функций и срокам внедрения новых. Более того, в кризисные времена даже тяжелые ERP-системы (СЭД в фармацевтических компаниях, системы консолидации финансовых и кадровых данных на крупных государственных предприятиях) поворачиваются в сторону максимально быстрой доработки и оптимизации функций.
При такой интенсивной разработке масштабных приложений наличие систем непрерывного мониторинга и управления производительностью ПО становится жизненно необходимым элементом, так как они обеспечивают возможность оценивать влияние на систему даже мелких изменений и своевременно реагировать на возникающие отклонения, не дожидаясь разрастания масштабов проблемы, что позволяет сэкономить и исполнителям, и заказчикам массу времени и сил.
OpenSource: доработка решений легче, но ответственность за результат – выше
Стоит отметить и некоторые особенности оптимизации производительности приложений на проектах, основанных на использовании OpenSource-решений. Открытый исходный код предоставляет очень широкие возможности как для интеграции сенсоров, обеспечивающих сбор необходимой для анализа информации, так и для оптимизации кода на всех уровнях.
При необходимости оптимизировать работу важной для бизнеса функции, скажем в PostgreSQL, намного проще выйти на компетентного и заинтересованного разработчика, которому более интересно заняться конкретной проектной задачей, а не пытаться добиться аналогичной реакции от крупной корпорации. То есть в этой части при использовании свободного ПО у компаний, особенно крупных, гораздо больше пространства для маневра.
Но здесь стоит учитывать, что продукты с открытым программным кодом обновляются чаще, чем их проприетарные аналоги (исправление ошибок, новые функции), а значит, придется постоянно следить за выходом новых версий. И тогда процесс интегрированного управления ИТ с каскадом постоянных миниаудитов и короткими итерациями, с постоянным отслеживанием изменений характеристик ИС и непрерывной оптимизацией ее производительности подходит идеально.
Подведем итоги
Внедрение процессов оптимизации производительности приложений в комплексе с интегрированным управлением ИТ позволит крупному и среднему бизнесу в сложные времена не проводить «бомбардировку по площадям» закупкой нового оборудования и ПО, а повышать эффективность использования уже имеющихся ресурсов и безболезненно вводить новые функции с минимальными и (что очень важно!) предсказуемыми затратами. А главное, это обеспечит возможность расти быстрее, чем конкуренты, когда ситуация начнет налаживаться.
В целях достижения максимальных результатов основные этапы методики оптимизации производительности любого приложения (формулирование целей, аудит и оптимизация ИС с минимальной по времени точкой входа в проект, тиражирование изменений, отслеживание результатов и поддержка проекта) должны циклически повторяться, а их результаты – быть измеримыми и связанными с конкретными бизнес-процессами.
Несомненно, получат дальнейшее развитие различные методики, системы и инструменты, позволяющие систематизировать и автоматизировать значительную часть этих процессов, обеспечивать автоматическое отслеживание состояния ИС, поставлять достоверные данные, необходимые для анализа, проактивно выявлять зреющие проблемы и информировать о них. Но уже сегодня указанные инструменты находятся на таком уровне зрелости, когда их внедрение многократно окупает все затраты и снижает риски для организации. Поэтому их можно смело рекомендовать предприятиям и организациям любого профиля.
