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