Оценить производительность системы непросто, а контролировать еще сложнее. Как сделать так, чтобы внедряемая или уже эксплуатируемая система справлялась с нагрузками? Можно ли в этом вопросе полностью положиться на разработчиков ПО или вендоров? И кто в итоге будет отвечать за все простои системы? Рассказывает Николай Марченко, директор отделения нагрузочного тестирования компании IBS.
Начать следует с того, что разбираться с последствиями возможных сбоев в любом случае придется тем, кто работает непосредственно с системой. Поэтому о вопросах производительности лучше задуматься еще на этапе внедрения.
Представим компанию, которая решила внедрить передовую систему, способную обрабатывать большие объемы информации и выполнять важную для бизнеса работу. Обычно такие внедрения заметны сразу, и от них ожидают значительных улучшений: оптимизации процессов, увеличения выручки, получения новых конкурентных преимуществ.
В процессе подготовки к внедрению разработчики, как правило, уверяют в эффективности выбранной системы, ссылаясь на выбранные технологии, собственный опыт или даже обзоры из СМИ. Например, они могут привести аргумент, что это решение уже используется более крупным клиентом. Но стоит учесть важный момент: чтобы адаптировать систему под конкретную компанию, часто требуется множество доработок. То, что работает у одного клиента, может не подойти для другого, поскольку различаются процессы, оборудование и другие условия. И эти доработки могут кардинальным образом повлиять на производительность.
После внедрения система начинает работать, функциональные ошибки исправляются, бизнес видит первые положительные результаты, и кажется, что самый сложный этап позади. Однако со временем количество пользователей — как внутренних, так и внешних — увеличивается. И вдруг наступает момент, когда система сталкивается с перегрузкой: серверы не справляются, страницы не загружаются, очереди растут. Может быть и другая ситуация, когда внешне все выглядит нормально, но половина транзакций не проходит. В итоге негативные отзывы множатся, техподдержка не успевает справляться с обращениями, а разработчик говорит, что ему нужно время, чтобы понять, в чем проблема.
В таком состоянии решать ситуацию крайне сложно. Тушить пожары, когда все уже горит и не хватает ресурсов для локализации очагов — чрезвычайно трудная задача. Что же делать? Как и в случае с пожарами, если ситуация уже произошла, нужно использовать все доступные средства. Однако лучше предпринять заблаговременные меры, чтобы в нее не попасть.
Прежде чем перейти к конкретным рекомендациям, разберемся, с чем же могут быть сложности:
Причин можно выделить гораздо больше, но основной посыл следующий: чтобы обезопасить себя и спокойно эксплуатировать систему, необходимо смоделировать нагрузку, максимально приближенную к реальной эксплуатации.
Во-первых, необходимо на уровне проектной организации создать независимую структуру для тестирования, которая будет отделена от разработки. При этом функциональные тестировщики и специалисты по автоматизации тестирования не смогут справиться с такой задачей, поскольку их области знаний существенно отличаются от нагрузочного тестирования. Оптимальным вариантом будет привлечение внешней специализированной организации. Хотя на начальном этапе можно попробовать решить проблему и собственными силами. Если система небольшая, но имеет высокую нагрузку, а расширение команды на данный момент невозможно, рекомендуется привлечь как минимум консультанта по нагрузочному тестированию.
Во-вторых, с помощью выделенных тестировщиков или консультанта нужно построить модель нагрузки. Этот процесс обычно оформляется в документе, который называется «Методика нагрузочного тестирования». Ее ключевой элемент — профиль нагрузки, описывающий, какие операции будут использоваться для тестирования, в какой пропорции, с какой интенсивностью и с какими данными.
Профиль нагрузки формируется на основе операций, которые пользователи выполняют в пиковые моменты. Например, система может быть наиболее нагружена с утра, когда на востоке страны люди еще работают, а в Москве пользователи уже начинают входить в систему. Нужно составить список операций, которые обычно выполняются в это время, и отобрать 80–90% самых частых. В дополнение к ним стоит включить редкие, но ресурсоемкие операции. Например, генерацию тяжелых отчетов.
В-третьих, крайне важно выбрать тестовый стенд, максимально приближенный к промышленному как по составу, так и по мощности. Использование менее мощного оборудования может привести к искажению данных. Лучше дополнительно арендовать облачные ресурсы и использовать их только на время тестирования, чтобы минимизировать расходы. Существует также вариант тестирования на продуктивной среде, однако такие эксперименты следует проводить только при поддержке опытных специалистов.
На четвертом этапе разрабатываются скрипты для тестирования на основе операций, выбранных из профиля нагрузки. С их помощью будут генерироваться значительные нагрузки, имитирующие действия тысяч или даже миллионов пользователей. Помимо этого, нужно добавить эмуляторы внешних систем, настроить мониторинг всех показателей и подготовить тестовые данные. Важно помнить, что если вы что-то исключаете из тестирования, нужно обязательно оценить, как это повлияет на точность создания нагрузки.
На пятом шаге выполняется непосредственно тестирование. Вы словно заглядываете в будущее: видите, что будет происходить с системой при взаимодействии с большим количеством пользователей, насколько будут загружены серверы и т. д. При этом благодаря детально построенной модели нагрузки есть уверенность, что текущие условия тестирования максимально приближены к реальной работе бизнеса.
Всегда ли нужно так тщательно подходить к тестированию? Если день простоя системы не приведет к серьезным для компании последствиям, то можно оставить ответственность за проверку производительности на разработке или поддержке. В других случаях, особенно когда речь идет о высокотранзакционных системах или критичных онлайн-сервисах, лучше уделить время тестированию. Затраты на такие проверки несравнимы с ущербом от возможных сбоев. Это точно.