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

ТУПИК: ЗАИМСТВОВАНИЕ ТРАДИЦИОННОГО ОПЫТА И ПЛАНИРОВАНИЕ РЕСУРСОВ «ВСЛЕПУЮ»

Прямое копирование опыта, приобретенного ИТ-специалистами при работе с традиционными ИТ-инфраструктурами и сервисами, не помогает улучшить работу приложений при их перемещении в облако. Ресурсы в IaaS приобретаются крупными кусками, а уж об их оптимальном распределении и речи нет. В результате даже критичные приложения работают из рук вон плохо: продавцы постоянно жалуются на «подвисания» CRM, бухгалтеры и финансисты — на «задумчивость» «1С: Предприятия» и автоматизированных систем на базе этого ПО.

К тому же слепое копирование прежнего подхода не позволяет полноценно использовать ключевые преимущества IaaS: возможность купить ресурсов ровно столько, сколько нужно, не переплачивая, и сократить цикл их планирования до одной-двух недель. Ситуация, когда востребованы 400 ядер из 800, а оплачиваются все, — скорее правило, чем исключение. А о коррекции объема используемых ресурсов раз в квартал, месяц или даже две недели и речи не идет!

Чтобы оптимизировать расходы, во-первых, необходимо организовать масштабный сбор и анализ объективных данных (степень утилизации многих тысяч компонентов, их пропускная способность, очередь назначенных каждому компоненту запросов, время отклика компонента при выполнении запросов к конкретному приложению и пр.). Выбрать же или создать единую методику, подходящую для анализа каждого приложения, в IaaS или смешанной ИТ-инфраструктуре крайне непросто. Во-вторых, процесс оценки ресурсов должен быть автоматическим или автоматизированным, так как невозможно вручную исследовать производительность сотен виртуальных машин по 200–300 показателям. Но на практике дело обстоит еще хуже: для объективного и простого анализа достаточности ресурсов все еще нет универсального, то есть доступного любому предприятию, инструментария.

Однако компания все же может улучшить качество работы приложений, избежать падения их производительности и одновременно оптимизировать расходы на закупку ресурсов таким образом, чтобы сократить затраты на 50–70%.

ВЫХОД: МЕТОДОЛОГИИ USE И APDEX ПЛЮС АВТОМАТИЗИРОВАННЫЙ АНАЛИЗ ОБЪЕКТИВНЫХ ДАННЫХ

Выходом из описанного тупика может стать внедрение ИТ-решения, которое базируется на комбинации двух различных подходов к оценке достаточности ресурсов.

С одной стороны, это применение методологии контроля загруженности, перегруженности и ошибок (Utilization Saturation and Errors Method, USE), разработанной Бренданом Греггом в 2011 году и адаптированной экспертами центра компетенции нашей компании для массового использования. Она помогает понять, соответствует ли нагрузка на все компоненты системы (например, серверы или СХД) заданным формальным правилам, и позволяет максимально быстро выявить узкие места или ошибки в планировании ресурсов.

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

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

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF