Здавалка
Главная | Обратная связь

Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг



Управление Мощностями определяет минимальную мощность, необходимую для продолжения ока­зания услуги в случае непредвиденных обстоятельств. Мощности, необходимые для Управления Непрерывностью ИТ-сервисов должны постоянно проверяться (пересматриваться), чтобы обеспе­чить их соответствие ежедневным изменениям в операционной среде.

Взаимоотношения с Процессом Управления Доступностью

Процессы Управления Мощностями и Управления Доступностью тесно связаны между собой. Проблемы с производительностью и мощностью могут привести к срыву работы ИТ-услуг. В дейст­вительности заказчик может считать малую производительность работы сервиса равнозначной не­доступности. Необходима эффективная координация этих двух процессов из-за их тесной взаимоза­висимости. В них используется большое количество одинаковых инструментальных средств и мето­дик, таких как анализ степени влияния сбоя компонентов (Component Failure Impact Analysis – CFIA) и анализ дерева сбоев (Fault Tree Analysis – FTA).

Виды деятельности

Ниже описываются виды деятельности в рамках Процесса Управления Мощностями с разделением по каждому подпроцессу.

Управление Возможностями Бизнеса (Business Capacity Management)

Управление Мощностями Бизнеса включает следующие виды работ:

Разработка Плана по мощностям[199]

В Плане по мощностям описываются текущие мощности ИТ-инфраструктуры и ожидаемые измене­ния спроса на ИТ-услуги, замена устаревших компонентов и планы технического развития. План по мощностям также определяет изменения, необходимые для предоставления услуг на согласованном в SLA уровне по приемлемой стоимости. То есть План по мощностям описывает не только ожидае­мые изменения, но и связанные с ними затраты. Этот план должен составляться ежегодно и прове­ряться ежеквартально для подтверждения его актуальности.

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

Моделирование

Моделирование является мощным инструментом Управления Мощностями, используемым для прогнозирования тенденций в инфраструктуре.

В рамках Процесса Управления Мощностями используется широкий диапазон инструментальных средств – от инструментариев оценки до средств всестороннего тестирования прототипов. Первые недороги и часто применимы в повседневной деятельности. Вторые обычно подходят только для крупномасштабных проектов внедрения.

Между этими двумя полюсами существует большое количество подходов, которые точнее оценок и дешевле крупных экспериментальных макетов. В порядке повышения их стоимости они включают в себя:

? анализ тенденции (самый дешевый способ);

? аналитическое моделирование;

? имитационное моделирование[200];

? тестирование в сравнении с некоторым базовым вариантом[201], также называемый бенчмаркинг (да­ет наиболее точную оценку).

Анализ тенденции может использоваться для получения информации о допустимой нагрузке, но не для предсказания времени реакции приложения. Аналитическое и имитационное моделирование имеют свои достоинства и недостатки. Например, имитационное моделирование может использо­ваться для точного предсказания производительности центрального компьютера[202], возможно, в рам­ках работ по определению необходимого размера технической платформы для работы ПО[203]. Однако этот метод связан с большими затратами времени. Аналитическое математическое моделирование обычно занимает меньше времени, но получаемая на выходе информация менее надежна. Тестирова­ние в сравнении с некоторым базовым вариантом (бенчмаркинг) означает, что создается среда с ре­альными условиями, например в вычислительном центре поставщика. Эта среда удовлетворяет тре­бованиям к производительности и используется для моделирования типа "что если" или моделиро­вания изменений. Например, таких как "что случится, если компонент приложения будет переведен на другую компьютерную систему?" или "что случится, если мы удвоим количество транзакций?".

Определение размера технической платформы для работы ПО[204]

На этом этапе происходит определение конфигурации технических средств, необходимой для рабо­ты новых или измененных приложений, например, таких, которые находятся в стадии разработки или которые могут быть закуплены по запросу заказчика. Эти расчеты содержат информацию об ожидаемом уровне производительности, необходимых аппаратных средствах и затратах. Такой порядок действий особенно актуален на начальных стадиях разработки ПО. Ясная информа­ция о требуемых аппаратных средствах и других ИТ-ресурсах, а также об ожидаемых затратах на начальной стадии представляет ценность для руководства. Это также помогает при разработке прото­типов новых Соглашений об Уровне Услуг (SLA).

Работы по определению размеров необходимой технической платформы могут потребовать значи­тельных усилий в крупных компаниях или в организациях со сложной ИТ-инфраструктурой. В на­чале в рамках Процесса Управления Мощностями происходит согласование с разработчиками Тре­бований к Уровню Сервиса, который должен быть реализован с помощью продукта. Когда продукт достигает этапа приемо-сдаточных испытаний, выполняется проверка достижения требуемого уров­ня сервиса в терминах производительности центрального процессора (CPU), устройств ввода-выво­да (I/O), сети, использования дисковой и оперативной памяти.

Одним из результатов этапа по определению размеров технической платформы являются показате­ли рабочей нагрузки. Они могут использоваться для прогнозирования необходимой мощности, на­пример, что будет, если число пользователей возрастет на 25%. Другими показателями рабочей на­грузки являются требования по мощности во времени (пиковые нагрузки в течение суток/неде­ли/года и перспективы будущего роста).







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.