ИТ Сервис-менеджмент. Введение
Шрифт:
Взаимоотношения с Процессом Управления Релизами
Процесс Управления Мощностями поддерживает планирование распространения релизов при использовании компьютерных сетей для их тиражирования автоматическими и ручными средствами.
Взаимоотношения с Процессом Управления Конфигурациями
Между Базой Данных Мощностей [197] (CDB) и Конфигурационной Базой Данных (CMDB) существует тесная взаимосвязь. Информация, предоставляемая Процессом Управления Конфигурациями, существенно необходима для разработки эффективной базы данных мощностей.
197
Capacity Database – CDB.
Взаимоотношения
Процесс Управления Мощностями дает рекомендации Процессу Управления Уровнем Услуг по вопросу реалистичности обсуждаемых Уровней Сервиса (например, скорости реакции приложения). Управление Мощностями осуществляет измерение и мониторинг производительности и предоставляет контрольную информацию для проверки исполнения согласованного Уровня Сервиса, а при необходимости и инициирует изменение Уровня Услуг и составляет необходимые отчеты.
Взаимоотношения с Процессом Управления Финансами ИТ
Управление Мощностями поддерживает составление плана инвестиций, анализ соотношения доходов и расходов [198] и принятие решений по инвестициям. Кроме того, этот процесс предоставляет важную информацию для выставления счетов по услугам, связанных с предоставлением мощностей, например, выделение сетевых ресурсов.
Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг
198
Cost/benefit analysis.
Управление Мощностями определяет минимальную мощность, необходимую для продолжения оказания услуги в случае непредвиденных обстоятельств. Мощности, необходимые для Управления Непрерывностью ИТ-сервисов должны постоянно проверяться (пересматриваться), чтобы обеспечить их соответствие ежедневным изменениям в операционной среде.
Взаимоотношения с Процессом Управления Доступностью
Процессы Управления Мощностями и Управления Доступностью тесно связаны между собой. Проблемы с производительностью и мощностью могут привести к срыву работы ИТ-услуг. В действительности заказчик может считать малую производительность работы сервиса равнозначной недоступности. Необходима эффективная координация этих двух процессов из-за их тесной взаимозависимости. В них используется большое количество одинаковых инструментальных средств и методик, таких как анализ степени влияния сбоя компонентов (Component Failure Impact Analysis – CFIA) и анализ дерева сбоев (Fault Tree Analysis – FTA).
12.4. Виды деятельности
Ниже описываются виды деятельности в рамках Процесса Управления Мощностями с разделением по каждому подпроцессу.
12.4.1. Управление Возможностями Бизнеса (Business Capacity Management)
Управление Мощностями Бизнеса включает следующие виды работ:
Разработка Плана по мощностям [199]
В Плане по мощностям описываются текущие мощности ИТ-инфраструктуры и ожидаемые изменения спроса на ИТ-услуги, замена устаревших компонентов и планы технического развития. План по мощностям также определяет изменения, необходимые для предоставления услуг на согласованном в SLA уровне по приемлемой стоимости. То есть План по мощностям описывает не только ожидаемые изменения, но и связанные с ними затраты. Этот план должен составляться ежегодно и проверяться ежеквартально для подтверждения его актуальности.
199
Capacity Plan.
В определенном смысле План по мощностям является самым важным выходным документом Процесса Управления Мощностями. В выходные данные часто включают годовой план, согласованный по срокам с бюджетом или инвестиционным планом, долгосрочный план и ежеквартальные планы с подробной информацией о запланированных изменениях мощностей. Совместно это представляет собой комплект связанных между собой планов, где уровень детализации повышается с приближением сроков планирования.
Моделирование
Моделирование является мощным инструментом
В рамках Процесса Управления Мощностями используется широкий диапазон инструментальных средств – от инструментариев оценки до средств всестороннего тестирования прототипов. Первые недороги и часто применимы в повседневной деятельности. Вторые обычно подходят только для крупномасштабных проектов внедрения.
Между этими двумя полюсами существует большое количество подходов, которые точнее оценок и дешевле крупных экспериментальных макетов. В порядке повышения их стоимости они включают в себя:
• анализ тенденции (самый дешевый способ);
• аналитическое моделирование;
• имитационное моделирование [200] ;
• тестирование в сравнении с некоторым базовым вариантом [201] , также называемый бенчмаркинг (дает наиболее точную оценку).
Анализ тенденции может использоваться для получения информации о допустимой нагрузке, но не для предсказания времени реакции приложения. Аналитическое и имитационное моделирование имеют свои достоинства и недостатки. Например, имитационное моделирование может использоваться для точного предсказания производительности центрального компьютера [202] , возможно, в рамках работ по определению необходимого размера технической платформы для работы ПО [203] . Однако этот метод связан с большими затратами времени. Аналитическое математическое моделирование обычно занимает меньше времени, но получаемая на выходе информация менее надежна. Тестирование в сравнении с некоторым базовым вариантом (бенчмаркинг) означает, что создается среда с реальными условиями, например в вычислительном центре поставщика. Эта среда удовлетворяет требованиям к производительности и используется для моделирования типа «что если» или моделирования изменений. Например, таких как «что случится, если компонент приложения будет переведен на другую компьютерную систему?» или «что случится, если мы удвоим количество транзакций?».
200
Simulation.
201
Baseline Assessment (Benchmark).
202
Host.
203
Application Sizing.
Определение размера технической платформы для работы ПО [204]
На этом этапе происходит определение конфигурации технических средств, необходимой для работы новых или измененных приложений, например, таких, которые находятся в стадии разработки или которые могут быть закуплены по запросу заказчика. Эти расчеты содержат информацию об ожидаемом уровне производительности, необходимых аппаратных средствах и затратах. Такой порядок действий особенно актуален на начальных стадиях разработки ПО. Ясная информация о требуемых аппаратных средствах и других ИТ-ресурсах, а также об ожидаемых затратах на начальной стадии представляет ценность для руководства. Это также помогает при разработке прототипов новых Соглашений об Уровне Услуг (SLA).
204
Application Sizing.
Работы по определению размеров необходимой технической платформы могут потребовать значительных усилий в крупных компаниях или в организациях со сложной ИТ-инфраструктурой. В начале в рамках Процесса Управления Мощностями происходит согласование с разработчиками Требований к Уровню Сервиса, который должен быть реализован с помощью продукта. Когда продукт достигает этапа приемо-сдаточных испытаний, выполняется проверка достижения требуемого уровня сервиса в терминах производительности центрального процессора (CPU), устройств ввода-вывода (I/O), сети, использования дисковой и оперативной памяти.