Умный ответ ИТ на требования бизнеса в период кризиса
Вряд ли сегодня найдется крупная организация, не сталкивавшаяся с внезапным снижением производительности бизнес-приложений и связанными с этим проблемами: недовольством пользователей, репутационными издержками и прямыми убытками. К сожалению, выявить реальные причины таких ситуаций крайне непросто. Поэтому слишком часто ИТ-отделы выбирают экстенсивный путь — предлагают купить новый сервер, расширить каналы связи... Путь этот дорог. Более того, он не дает гарантированного результата. К счастью, имеется гораздо более эффективная и менее затратная альтернатива, связанная с применением особых технических средств, специальных методик и знаний. В совокупности эти инструменты формируют организационно-техническую систему управления производительностью приложений. Внедрение таких систем и оптимизация ИТ-ландшафта предприятия с их помощью — одна из наиболее эффективных точек приложения усилий в кризис. Ниже мы рассмотрим основные аспекты построения и применения таких систем.
Предпосылки появления систем управления производительностью приложений
Пока организация невелика (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, намного проще выйти на компетентного и заинтересованного разработчика которому будет интересно заняться конкретной проектной задачей, чем попробовать добиться аналогичной реакции от крупной корпорации. Т.е. в данной части при использовании свободного ПО у компаний, особенно крупных, гораздо больше пространства для маневра.
Но при этом стоит учитывать, что продукты с открытым программным кодом обновляются чаще, чем их проприетарные аналоги (исправление ошибок, новые функции), а значит и следить за выходом новых версий нужно намного пристальнее. И тогда процесс интегрированного управления ИТ с каскадом постоянных мини-аудитов и короткими итерациями, с постоянным отслеживанием изменений характеристик ИС и непрерывной оптимизацией ее производительности, подходит идеально.
Подведем итоги
Внедрение процессов по оптимизации производительности приложений, в комплексе с интегрированным управлением ИТ, позволит крупному и среднему бизнесу в сложные времена не проводить «бомбардировку по площадям» закупкой нового оборудования и ПО, а повышать эффективность использования уже имеющихся ресурсов. Безболезненно вводить новые функции, с минимальными и — что очень важно! — предсказуемыми затратами. А главное позволит расти быстрее, чем конкуренты, когда ситуация начнет налаживается.
При этом для достижения максимальных результатов основные этапы методики оптимизации производительности любого приложения (формулирование целей, аудит и оптимизация ИС с минимальной по времени точкой входа в проект, тиражирование изменений, отслеживание результатов и поддержка проекта), должны циклически повторяться, а их результаты — быть измеримыми и связанными с конкретными бизнес-процессами.
Несомненно, получат дальнейшее развитие различные методики, системы и инструменты, позволяющие систематизировать и автоматизировать значительную часть этих процессов, обеспечивать автоматическое отслеживание состояния ИС, поставлять достоверные данные необходимые для анализа, проактивно выявлять и информировать о зреющих проблемах. Но уже сегодня они находятся на таком уровне зрелости, когда их внедрение многократно окупает затраты и снижает риски организации. Поэтому их можно смело рекомендовать организациям любого профиля.