Инфраструктура технологичных компаний на 90% построена на решениях зарубежных поставщиков. Прекращение технической поддержки и сложности с поставкой нового оборудования ставят под удар непрерывную работу и развитие бизнеса.
Безусловно, аппаратные системы имеют определенный запас прочности, но без новых закупок дальнейшее масштабирование и развитие информационных систем может оказаться под угрозой и вынудить российские организации постепенно отказаться от разработки новых продуктов, перераспределить ресурсы в пользу критичных сервисов. Решить проблему нехватки ресурсов можно за счет оптимизации работы прикладного и системного программного обеспечения.
В последнее десятилетие при внедрении информационных систем лишь немногие компании фокусировались на том, чтобы повысить производительность систем на том же оборудовании: как правило, вместо этого дополнительно приобретались новые серверы, а потенциал действующего ПО оставался нераскрытым. Однако статистика, которую мы собрали на основе более 500 проектов по нагрузочному тестированию компании IBS, показала, что за счет оптимизации ПО удается в 80% случаев поднять производительность систем в 1,5–3 раза, что само по себе позволяет значительно сэкономить на закупке нового оборудования.
Нагрузочное тестирование позволяет смоделировать промышленную нагрузку и далее в процессе испытаний выявить узкие места, которые препятствуют дальнейшему росту производительности. Само нагрузочное тестирование строится таким образом, чтобы отразить работу системы в промышленной эксплуатации с довольно высокой точностью — не менее 80-90%, если брать в расчет самые ресурсоемкие операции. Это позволяет увидеть, как ИТ-система будет вести себя на самом деле в тех или иных условиях.
Процесс оптимизации ИТ-систем состоит из следующих шагов:
Выявить имеющуюся и потенциальную неэффективность в программном обеспечении путем проведения нагрузочных испытаний.
Провести ИТ-аудит с целью поиска причин и формирования рекомендаций по их устранению.
Исправить неэффективный код в прикладном ПО, оптимизировать работу СУБД.
Провести повторные нагрузочные испытания для подтверждения полученных эффектов.
Далее наступает этап проведения аудита ИТ-систем под нагрузкой:
Архитектурный аудит, оценка технических решений.
Поиск узких мест, приводящих к деградации производительности.
Ревью исходного кода.
Анализ статистики и оптимальности запросов к БД.
Анализ ПО на наличие санкционных рисков.
Формирование предложений по внесению изменений в программное обеспечение.
Затем выполняется оптимизация оборудования в зависимости от обнаруженных с помощью нагрузочного тестирования узких мест. Для достижения оптимизации могут быть использованы следующие меры:
Изменение прикладной архитектуры.
Разработка отдельных микросервисов.
Внедрение очередей.
Смена технологий.
Оптимизация работы БД.
После повторного проведения нагрузочного тестирования проверяется эффективность внесенных изменений, при необходимости цикл оптимизации ПО может быть повторен.
Проводить нагрузочное тестирование и далее оптимизировать производительность рекомендуется:
● для высоконагруженных систем с пользовательской нагрузкой более 500 пользователей;
● для Core-систем организаций (АБС, ДБО, CRM, ERP, МДМ, «Документооборот», BI, шины);
● если простой системы в силу отказа ПО и/или оборудования обходится бизнесу более чем в 10 млн в день;
● при репутационных издержках, связанных с отказами обслуживания;
● если отсутствует резервное оборудование;
● в случае, если оптимизация ПО никогда не проводилась и нет понимания по емкости ПО и текущего оборудования;
● при наличии инцидентов в промышленной эксплуатации, связанных с производительностью.
Таким образом, если в компании решено настроить процесс управления мощностями с целью снижения затрат на закупку оборудования и поддержку ПО, необходимо:
Определиться со списком наиболее критичных систем. Среди этих систем необходимо выделить те, которые подвержены высокой нагрузке и, самое главное, время простоя которых влияет на существенные денежные и репутационные потери организации. Для этого необходимо сопоставить, какие операционные издержки получит бизнес, если целевая система будет недоступна в течение максимального времени ее восстановления после тяжелой аварии.
Убедиться в зрелости процессов тестирования, в частности нагрузочного. Здесь сперва необходимо проработать вопрос со своей командой тестирования. Если тестировщики четко могут объяснить всем участникам проекта, как будет моделироваться нагрузка и как она соотносится с реальностью, то дальше работать можно с внутренней командой (при необходимости привлекая дополнительные внешние ресурсы). В противном случае рекомендуется прибегнуть к специализированным подрядчикам, которые на основании своего опыта и экспертизы смогут выстроить процесс нагрузочного тестирования и управления мощностями.
Определиться со сроками получения результатов и контролировать основные этапы выполнения работ (моделирование нагрузки, проведение НТ и интерпретация результатов). Важно понимать, что первичное нагрузочное тестирование занимает больше всего времени — от 2 до 4 месяцев. Повторные итерации тестирования будут проходить уже гораздо быстрее — от недели до трех в зависимости от сложности системы. На последнем этапе уже можно получить эффект оптимизации ПО. После обнаружения узких мест необходимо настроить процесс так, чтобы эти узкие места сразу исправлялись разработчиками и администраторами (это может быть как внутренняя разработка, так и внешние специалисты).
2-3 итерации тестирования приведут к существенным сдвигам в производительности. Это наиболее подходит для систем, которые ранее не тестировались либо не оптимизировались в промышленной эксплуатации.
Пройдя этот путь, уже после первого этапа тестирования можно понять, как долго связка вашего ПО и оборудования сможет беспроблемно обслуживать бизнес, сколько аппаратных ресурсов удастся высвободить после проведенной оптимизации и как новые версии ПО справятся с пользовательской активностью.