Активное развитие онлайн-канала продаж для любой крупной компании и внедрение нового функционала сайта – это не только возможность роста и увеличения прибыли, но и большой вызов для служб ИТ-поддержки. Поэтому очень важно правильно готовить ИТ-систему к возрастающей нагрузке и грамотно осуществлять ее проверку в рамках самых разных рабочих сценариев. Начальник Службы архитектурного развития Департамента бизнес-технологий ТПО «Комус» Сергей Антонов в интервью NOVARDIS рассказал о том, как с такими задачами, в том числе, справляются в его подразделении.

— Сергей, почему важно при внедрении нового функционала проводить проверку систем на соответствие ключевым показателям под нагрузкой?

— Зачастую при внедрении новых систем заказчик концентрирует 100% усилий на реализации функциональных требований и к вопросам производительности и отказоустойчивости нового сервиса относится по остаточному принципу. Результатом подобного подхода, как правило, является система, непригодная для промышленной эксплуатации: функционал корректно работает лишь на ограниченном количестве пользователей. В особенности это относится к классу высоконагруженных систем, в том числе, веб-ресурсам.

Важно тщательно проработать нефункциональные требования еще на этапе концептуального проектирования и определить ключевые показатели, по которым будет оцениваться производительность системы. К ним могут относиться, например, отклик по каждому типу страниц, допустимое время простоя сервиса, перечень клиентских платформ (операционная система, веб-браузер), на который интернет-магазин должен корректно работать.

Не менее важно сразу же выработать мероприятия по контролю за выполнением требований, в частности, проведение нагрузочных тестов.

— Какая цена ошибки в данном случае?

— Существенное увеличение сроков и бюджета проекта, вплоть до отказа от дальнейшего внедрения. Далеко не всегда необходимой производительности удается достичь увеличением вычислительных мощностей, а проводить реинжиниринг программного обеспечения с целью оптимизации производительности – на порядок сложнее, чем выполнить разработку с нуля.

— Как часто нужно проводить нагрузочное тестирование или при каких обстоятельствах нужно инициировать такого рода проверки?

— Необходимо соизмерять стоимость проведения нагрузочных тестов с теми рисками, которые возникают в том случае, если их не выполнять. Это зависит от многих факторов: значимость сервиса в бизнес-процессах компании, срочность и объем внедрения изменений, уровень понимания того, каким образом изменения могут повлиять на работоспособность сервиса и т.д. Например, для нашего интернет-магазина мы планируем в обязательном порядке проводить нагрузочные тесты перед каждым плановым изменением, а перед каждым внеплановым – по результатам оценки влияния изменений на работоспособность.

— Какие подходы для выполнения нагрузочного тестирования использовались в компании ранее?

— До определенного момента мы ограничивались контролем отклика по основным функциям ключевых сервисов при проведении функционального тестирования. Нагрузочное тестирование осуществлялось при внедрении масштабных изменений – таких, как переход на новую версию СУБД, смена платформы и т.д., а также для годового планирования вычислительных мощностей. При этом использовались различные средства: open source – продукты Apache JMeter, Siege, программное обеспечение собственной разработки.

— Как вы думаете, что меняется в рамках нагрузочного тестирования при внедрении промышленных платформ?

— Внедрение промышленных систем заставляет переосмыслить подход к качеству разработки, в том числе, к организации процесса нагрузочного тестирования. В отличие от систем собственной разработки, предсказать поведение промышленной системы при различных изменениях значительно сложнее, так как во многом это «черный ящик». По этой причине важно сразу озаботиться внедрением процесса нагрузочного тестирования с индивидуальной методикой и сценариями тестирования. Как вариант – с помощью системы Yandex Tank.

— Что нужно учитывать при подготовке сценариев нагрузочного тестирования?

— В первую очередь, сценарии должны быть ориентированы на самый пессимистичный вариант развития событий, который может возникнуть в процессе промышленной эксплуатации сервиса. Это гарантирует его непрерывность в любой ситуации.

— Для чего нужно выполнять мониторинг параметров всех элементов инфраструктуры и какие потенциальные проблемы такой мониторинг может закрыть?

— Нагрузочное тестирование без отслеживания состояния ИТ–инфраструктуры не имеет смысла, так как оно не выявит потенциальных проблем. Например, мы можем получить ожидаемый отклик при загрузке страниц, но при этом утилизация вычислительных ресурсов составит 80%. Это означает, что любой, даже незначительный, всплеск посещаемости может привести к потере работоспособности сайта.

— Какое сейчас время реакции при возникновении проблемной ситуации, выявленной мониторингом, в вашей компании?

— Время реакции (от выявления инцидента системой мониторинга до того момента, когда специалист приступил к его устранению) – 5-10 минут. В наших условиях этого достаточно.

— Как часто возникают проблемные ситуации, требующие вмешательства персонала ИТ?

— Проблемы возникают нечасто, о чем свидетельствуют высокие показатели доступности наших ключевых сервисов. Их достижение основано на двух основных принципах. Первый: наши усилия направлены на скорейшее восстановление работоспособности сервисов. Если мы не можем сходу найти причину возникновения проблемы, то концентрируем наши усилия на реализации обходного решения. И второй: проблема считается закрытой только в том случае, если найдена и устранена корневая причина ее возникновения. Критерием того, что причина найдена, является возможность ее воспроизвести.

— Какие меры можно предпринять, чтобы предотвратить повторение проблемных ситуаций?

— Ответ очевиден – проблему необходимо решать. Я бы переформулировал данный вопрос – каким образом минимизировать проблемы? Для начала, необходимо принять тот факт, что проблемы неизбежны. Идеальных информационных систем не бывает. Ситуация меняется ежедневно: растет объем информации, меняется число пользователей и т.д. Ошибки и просчеты в проектировании, которые до поры до времени не давали о себе знать, могут проявиться в самых неожиданных ситуациях. Важно научиться проблемами управлять. Как говорил известный персонаж Владимира Высоцкого: «Правопорядок в стране определяется не количеством воров, а умением властей их обезвреживать». Эффективно управлять проблемами можно, грамотно выстраивая и развивая ИТ-процессы. Важно только не переусердствовать: уровень развития ИТ-процессов должен соответствовать объему вашего ИТ-хозяйства, иначе ресурсы будут тратиться впустую.

Кроме того, важно не замыкаться в себе. Вокруг нас целый мир, и наверняка кто-то уже сталкивался с аналогичными проблемами и решал их. Не надо изобретать велосипед – необходимо учиться эффективно перенимать чужой опыт. В этом плане один из ключевых вопросов – стандартизация ИТ-активов: нельзя допускать «зоопарка» оборудования, системного и прикладного программного обеспечения, все это в итоге приводит к росту проблем.

— Какие требования сейчас предъявляются к быстродействию систем, используемых в компании?

— Производительность систем должна соответствовать регламентам выполнения бизнес-процессов и учитывать планируемые объемы операций.

— На основании чего данные требования формировались?

Требования формируются, исходя из потребностей бизнеса.

Какие пути возможны для достижения целевых показателей производительности?

— В первую очередь необходимо правильно расставить приоритеты этих самых целевых показателей. Не надо превращать их в самоцель, каждый показатель должен быть наполнен практическим смыслом. Далее нужно спланировать совместные скоординированные усилия разработчиков программного обеспечения и социалистов по ИТ-инфраструктуре.

— Как определить границы возможной оптимизации системы?

— C точки зрения ИТ-инфраструктуры – путем проведения стресс-тестирования, анализа узких мест и планирования изменений. К сожалению, как я уже говорил ранее, не всегда вопросы производительности можно решить масштабированием вычислительных мощностей. При разработке прикладного программного обеспечения – за счет контроля качества кода и четкого понимания, какие операции являются наиболее ресурсоемкими.

Коротко о Сергее Антонове:

• Программированием увлекся еще в школьные годы – учился в физико—математической школе, и в 9-10 классах начал изучать языки программирования.
• В 1994 г. окончил Московский государственный институт радиотехники, электроники и автоматики по специальности «Прикладная математика».
• Свою трудовую деятельность начал в 1996 г. в финансовых компаниях группы «Интеррос»: сначала в «ОНЭКСИМ-банке», затем в «Росбанк», где занимался автоматизаций систем корпоративного кредитования и налогового учета и вырос до главного специалиста отдела разработки программного обеспечения.
• В 2006 г. пришел в компанию «Комус» на должность начальника отдела интеграции информационных систем.
• С 2008 г. – начальник службы архитектурного развития «Комус», отвечал за развитие ИТ-инфраструктуры и интеграцию прикладных информационных систем. В 2014 г. в компетенции службы вошли вопросы контроля качества прикладного программного обеспечения. В период с 2010 по 2012 гг. в состав службы входил отдел веб-разработки, принятый в нее из бизнес-подразделения. Именно в это время была осуществлена интеграция интернет-магазина в единое информационное пространство компании и реализован ряд ключевых сервисов (личный кабинет, автозаказ и т.д.). Далее веб-разработка была передана в профильное подразделение – службу развития бизнес-технологий (где, собственно, находится вся разработка собственного программного обеспечения).