[196].
    Взаимоотношения с Процессом Управления Релизами
   Процесс Управления Мощностями поддерживает планирование распространения релизов при ис­пользовании компьютерных сетей для их тиражирования автоматическими и ручными средствами.
    Взаимоотношения с Процессом Управления Конфигурациями
   Между Базой Данных Мощностей [197](CDB) и Конфигурационной Базой Данных (CMDB) существу­ет тесная взаимосвязь. Информация, предоставляемая Процессом Управления Конфигурациями, существенно необходима для разработки эффективной базы данных мощностей.
    Взаимоотношения с Процессом Управления Уровнем Услуг
   Процесс Управления Мощностями дает рекомендации Процессу Управления Уровнем Услуг по воп­росу реалистичности обсуждаемых Уровней Сервиса (например, скорости реакции приложения). Управление Мощностями осуществляет измерение и мониторинг производительности и предостав­ляет контрольную информацию для проверки исполнения согласованного Уровня Сервиса, а при необходимости и инициирует изменение Уровня Услуг и составляет необходимые отчеты.
    Взаимоотношения с Процессом Управления Финансами ИТ
   Управление Мощностями поддерживает составление плана инвестиций, анализ соотношения дохо­дов и расходов [198]и принятие решений по инвестициям. Кроме того, этот процесс предоставляет важ­ную информацию для выставления счетов по услугам, связанных с предоставлением мощностей, на­пример, выделение сетевых ресурсов.
    Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг
   Управление Мощностями определяет минимальную мощность, необходимую для продолжения ока­зания услуги в случае непредвиденных обстоятельств. Мощности, необходимые для Управления Непрерывностью ИТ-сервисов должны постоянно проверяться (пересматриваться), чтобы обеспе­чить их соответствие ежедневным изменениям в операционной среде.
    Взаимоотношения с Процессом Управления Доступностью
   Процессы Управления Мощностями и Управления Доступностью тесно связаны между собой. Проблемы с производительностью и мощностью могут привести к срыву работы ИТ-услуг. В дейст­вительности заказчик может считать малую производительность работы сервиса равнозначной не­доступности. Необходима эффективная координация этих двух процессов из-за их тесной взаимоза­висимости. В них используется большое количество одинаковых инструментальных средств и мето­дик, таких как анализ степени влияния сбоя компонентов (Component Failure Impact Analysis – CFIA) и анализ дерева сбоев (Fault Tree Analysis – FTA).
    12.4. Виды деятельности
   Ниже описываются виды деятельности в рамках Процесса Управления Мощностями с разделением по каждому подпроцессу.
    12.4.1. Управление Возможностями Бизнеса (Business Capacity Management)
   Управление Мощностями Бизнеса включает следующие виды работ:
    Разработка Плана по мощностям [199]
   В Плане по мощностям описываются текущие мощности ИТ-инфраструктуры и ожидаемые измене­ния спроса на ИТ-услуги, замена устаревших компонентов и планы технического развития. План по мощностям также определяет изменения, необходимые для предоставления услуг на согласованном в SLA уровне по приемлемой стоимости. То есть План по мощностям описывает не только ожидае­мые изменения, но и связанные с ними затраты. Этот план должен составляться ежегодно и прове­ряться ежеквартально для подтверждения его актуальности.
   В определенном смысле План по мощностям является самым важным выходным документом Про­цесса Управления Мощностями. В выходные данные часто включают годовой план, согласованный по срокам с бюджетом или инвестиционным планом, долгосрочный план и ежеквартальные планы с подробной информацией о запланированных изменениях мощностей. Совместно это представляет собой комплект связанных между собой планов, где уровень детализации повышается с приближе­нием сроков планирования.
    Моделирование
   Моделирование является мощным инструментом Управления Мощностями, используемым для прогнозирования тенденций в инфраструктуре.
   В рамках Процесса Управления Мощностями используется широкий диапазон инструментальных средств – от инструментариев оценки до средств всестороннего тестирования прототипов. Первые недороги и часто применимы в повседневной деятельности. Вторые обычно подходят только для крупномасштабных проектов внедрения.
   Между этими двумя полюсами существует большое количество подходов, которые точнее оценок и дешевле крупных экспериментальных макетов. В порядке повышения их стоимости они включают в себя:
   ? анализ тенденции (самый дешевый способ);
   ? аналитическое моделирование;
   ? имитационное моделирование [200];
   ? тестирование в сравнении с некоторым базовым вариантом [201], также называемый бенчмаркинг (да­ет наиболее точную оценку).
   Анализ тенденции может использоваться для получения информации о допустимой нагрузке, но не для предсказания времени реакции приложения. Аналитическое и имитационное моделирование имеют свои достоинства и недостатки. Например, имитационное моделирование может использо­ваться для точного предсказания производительности центрального компьютера [202], возможно, в рам­ках работ по определению необходимого размера технической платформы для работы ПО [203]. Однако этот метод связан с большими затратами времени. Аналитическое математическое моделирование обычно занимает меньше времени, но получаемая на выходе информация менее надежна. Тестирова­ние в сравнении с некоторым базовым вариантом (бенчмаркинг) означает, что создается среда с ре­альными условиями, например в вычислительном центре поставщика. Эта среда удовлетворяет тре­бованиям к производительности и используется для моделирования типа "что если" или моделиро­вания изменений. Например, таких как "что случится, если компонент приложения будет переведен на другую компьютерную систему?" или "что случится, если мы удвоим количество транзакций?".
    Определение размера технической платформы для работы ПО [204]
   На этом этапе происходит определение конфигурации технических средств, необходимой для рабо­ты новых или измененных приложений, например, таких, которые находятся в стадии разработки или которые могут быть закуплены по запросу заказчика. Эти расчеты содержат информацию об ожидаемом уровне производительности, необходимых аппаратных средствах и затратах. Такой порядок действий особенно актуален на начальных стадиях разработки ПО. Ясная информа­ция о требуемых аппаратных средствах и других ИТ-ресурсах, а также об ожидаемых затратах на начальной стадии представляет ценность для руководства. Это также помогает при разработке прото­типов новых Соглашений об Уровне Услуг (SLA).
   Работы по определению размеров необходимой технической платформы могут потребовать значи­тельных усилий в крупных компаниях или в организациях со сложной ИТ-инфраструктурой. В на­чале в рамках Процесса Управления Мощностями происходит согласование с разработчиками Тре­бований к Уровню Сервиса, который должен быть реализован с помощью продукта. Когда продукт достигает этапа приемо-сдаточных испытаний, выполняется проверка достижения требуемого уров­ня сервиса в терминах производительности центрального процессора (CPU), устройств ввода-выво­да (I/O), сети, использования дисковой и оперативной памяти.
   Одним из результатов этапа по определению размеров технической платформы являются показате­ли рабочей нагрузки. Они могут использоваться для прогнозирования необходимой мощности, на­пример, что будет, если число пользователей возрастет на 25%. Другими показателями рабочей на­грузки являются требования по мощности во времени (пиковые нагрузки в течение суток/неде­ли/года и перспективы будущего роста).
    12.4.2 Управление Возможностями Сервисов и Управление Мощностями Ресурсов
   Эти подпроцессы включают одинаковые виды деятельности, но с акцентом на различные аспекты. Управление Возможностями Сервисов обращается к предоставлению ИТ-услуг, а Управление Мощ­ностями Ресурсов – к технологическим аспектам их предоставления. Виды деятельности показаны на рис. 12.2.
 
   
   Рис. 12.2. Управление Производительностью Ресурсов и Сервисов (источник: OGC)
 
    Мониторинг
   Мониторинг компонентов инфраструктуры ведется с целью гарантии выполнения согласованных Уровней Сервисов. Примерами ресурсов, в отношении которых может проводиться мониторинг, яв­ляются использование процессоров (CPU), диска, сети, числа лицензий (т. е., например, существует только десять свободных лицензий) и т. д.
    Анализ
   Данные мониторинга необходимо анализировать. Для прогнозирования будущего использования можно применять анализ тенденций. Результаты анализа могут привести к началу работ по повышению рациональности использования или к приобретению дополнительных ИТ-компонентов. Ана­лиз деятельности требует глубокого знания всей инфраструктуры и бизнес-процессов компании.
    Настройка
   Настройка выполняется с целью оптимизации систем для текущей или ожидаемой рабочей нагруз­ки на основе результатов анализа и интерпретации данных мониторинга.
    Внедрение
   Целью внедрения является ввод измененной или новой мощности. Если это связано с изменением, то внедрение вовлекает Процесс Управления Изменениями.
    Управление Спросом
   Управление Спросом нацелено на вопросы потребления ИТ-мощностей. Управление Спросом зани­мается изучением влияния различных факторов на спрос. Простой пример: пользователь запускает плохо написанный SQL-отчет в середине дня, преграждая другим пользователям доступ к базе дан­ных и создавая непомерный трафик. Руководитель Процесса Управления Мощностями предлагает запускать задание по составлению отчета ночью, так, чтобы пользователь получал результат на сво­ем столе утром.
   Проведем различие между Управлением Краткосрочным и Долгосрочным Спросом:
   ? Управление Краткосрочным Спросом – в случае, если в ближайшем будущем есть угроза повторя­ющейся нехватки мощностей ИТ-средств и если доступ к дополнительным мощностям затруднен;
   ? Управление Долгосрочным Спросом – если не удается обосновать стоимость модернизации, хотя в определенные периоды времени (например, между 10:00 и 12:00) может возникать недостаток мощности.
   Управление Спросом предоставляет важную информацию для составления, мониторинга и, возмож­но, корректировки как Плана по мощностям, так и Соглашении об Уровнях Сервиса. Управление Спросом может также использовать дифференцированную тарификацию (т. е. различ­ные тарифы в пиковое и не пиковое время) для воздействия на заказчика.
    Заполнение Базы Данных Мощностей (CDB)
   Создание и заполнение базы данных CDB означает сбор и обновление технической, бизнес- и любой другой информации, относящейся к Управлению Мощностями. Может быть, нереально хранить всю информацию по мощностям в одной физической базе данных. Руководители по сетевым и компью­терным системам могут использовать свои собственные методы. Часто база данных CDB содержит ссылки на различные источники информации по мощностям ИТ-систем.
 
   
 
   Рис. 12.3. Источники информации для базы данных CDB.
 
    12.5. Контроль процесса
   Процесс Управления Мощностями наиболее эффективен в случае, если он тесно связан с другими процессами планирования, такими как Управление Доступностью, и с деятельностью по разработке приложений. Такая взаимосвязь способствует использованию проактивного подхода в работе Про­цесса Управления Мощностями.
    12.5.1. Отчеты для руководства
   Представляемые процессом отчеты для руководства содержат, с одной стороны, информацию об Уп­равлении Процессом в терминах показателей Плана по мощностям, ресурсов, используемых для ре­ализации процесса, и деятельности по совершенствованию процесса; а с другой стороны отчеты об отклонениях по таким вопросам как:
   ? расхождения между фактическим и плановым использованием мощностей;
   ? тенденции в расхождениях;
   ? воздействие на Уровни Сервиса;
   ? ожидаемое увеличение/уменьшение использования мощностей в краткосрочной и долгосрочной перспективе;
   ? пороговые значения, при достижении которых потребуется приобретение дополнительных мощ­ностей.
    12.5.2. Критические факторы успеха и Ключевые Показатели Эффективности (КPI)
   Управление Мощностями зависит от следующих критических факторов успеха:
   ? точной оценки бизнес-планов и ожиданий заказчиков;
   ? понимания ИТ-стратегии и планирования, а также точности планирования;
   ? оценки ведущихся технических разработок в компании;
   ? взаимодействия с другими процессами.
   Следующие параметры могут служить Ключевыми Показателями Эффективности (KPI) работы Процесса Управления Мощностями:
   ? Предсказуемость потребностей заказчика: определение изменений рабочей нагрузки и тенден­ций, а также точность Плана по мощностям.
   ? Технология: различные варианты измерения производительности ИТ-сервисов, темпы внедрения новых технологий и возможность постоянно выполнять Соглашения об Уровне Услуг (SLA) даже при использовании старых технологических средств.
   ? Затраты: уменьшение числа срочных закупок, сокращение ненужных или дорогих избыточных мощностей и составление планов инвестиций на ранней стадии.
   ? Операционная деятельность ИТ [205]: уменьшение количества инцидентов из-за проблем с произво­дительностью, возможность удовлетворить спрос заказчика в любое время и степень серьезности в отношении компании к Процессу Управления Мощностями.
    12.5.3. Функции и роли
   Роль Руководителя Процесса Управления Мощностями заключается в руководстве процессом и в обеспечении разработки и поддержания Плана по мощностям, а также в гарантии актуальности базы данных мощностей (CDB).
   Менеджеры систем, сетей и приложений также играют важную роль в Процессе Управления Мощ­ностями. Они не только являются ответственными за оптимизацию производительности, от них так­же ожидается использование их профессиональных знаний для преобразования потребностей биз­неса в профили [206]загрузки систем и определения на их основе необходимых мощностей ИТ-средств.
    12.6. Проблемы и затраты
    12.6.1. Проблемы
   Потенциальные проблемы Процесса Управления Мощностями могут быть следующими:
   ? Нереалистичные ожидания – разработчики [207], руководители и заказчики часто имеют нереа­листичные ожидания из-за недостаточного понимания технических возможностей приложе­ний, компьютерных систем и сетей. Одной из задач Процесса Управления Мощностями явля­ется направление этих ожиданий, например, путем осведомления разработчиков о воздействии их разработок (например, базы данных) на мощности ИТ-средств и их производительность. Эффект от работы Процесса Управления Мощностями также может переоцениваться, особенно в отношении настройки системы и составления графика рабочей нагрузки. Если ра­бота системы требует значительной настройки, то, скорее всего, причина в недостатках дизай­на приложения или базы данных. В целом, настройка не может быть использована для дости­жения более высокого уровня производительности, чем тот, на который система была рассчи­тана изначально. Большинство крупных ИТ-систем имеют алгоритмы планирования загрузки, которые обычно более эффективны, чем вовлечение системных менеджеров. И конечно, суще­ствуют и затраты, связанные с настройкой: для высокооплачиваемого инженера не имеет смысла тратить недели на достижение 3%-го улучшения характеристик, если расширение па­мяти за 100 долларов даст улучшение на 10%. Еще более дорого обойдется Управление Систе­мами, которые не являются "простыми, как дважды два". Чрезмерное "дергание" параметров на различных блоках, приложениях или базах данных может повлечь непреднамеренные последствия и увеличит задержку всех процессов сервис-менеджмента, а также обслуживание и поиск неисправностей.
   ? Недостаток соответствующей информации – часто бывает трудно получить необходимую ин­формацию, например, для Плана по мощностям. Могут возникнуть затруднения в получении дос­товерной информации об ожидаемой рабочей нагрузке, так как планы заказчика неизвестны или почти неизвестны, в особенности в деталях. Это также вызывает трудности у заказчика, так как жизненный цикл продукта становится все короче. Единственное решение – это делать наилучшие возможные оценки и периодически обновлять их при получении большей информации.
   ? Информация от поставщика – при отсутствии информации о предыстории вопроса (например, когда закупается новая система), Управление Мощностями становится зависимым от информа­ции, предоставляемой поставщиками. Поставщики обычно используют результаты тестов [208]для предоставления информации об их системах, но из-за больших различий в методах тестирования часто бывает трудно сопоставить информацию, и она может ввести в заблуждение о действитель­ной производительности системы.
   ? Внедрение в комплексных ИТ-средах - внедрение в сложных распределенных средах является трудной задачей, так как значительное количество технических интерфейсов создает большое число взаимозависимостей параметров производительности.
   ? Определение подходящего уровня мониторинга – инструменты для мониторинга часто имеют много опций и могут провоцировать на чрезмерно подробные исследования. При покупке и ис­пользовании этих инструментов необходимо заранее решить, на каком уровне детализации дол­жен проводиться мониторинг.
   Эти проблемы являются актуальными дня Управления Мощностями компьютерных систем, а также сетей, больших принтерных центров и телефонных АТС-систем [209]. Это может вызвать еще больше за­труднений, если за эти области отвечают несколько подразделений, что может привести к конфлик­там в ответственности за Управление Мощностями.
    12.6.2. Затраты
   Затраты на ввод в действие Управления Мощностями должны быть определены при подготовке вне­дрения процесса. Эти затраты можно разделить на следующие группы:
   ? закупка аппаратных и программных средств, таких как инструменты мониторинга, база данных мощностей (CDB), инструменты моделирования для имитационного моделирования и статисти­ческого анализа и инструменты генерации отчетов;
   ? затраты на Управление Проектом по внедрению процесса;
   ? затраты на персонал, обучение и поддержку;
   ? помещение и т. д.
   После запуска процесса остаются текущие расходы на персонал, контракты на обслуживание и т. д.
    Глава 13 Управление Непрерывностью ИТ-сервисов
    13.1. Введение
   Многие руководители считают Процесс Управления Непрерывностью ИТ-сервисов (IT Service Con­tinuity Management – ITSCM) роскошью, на которую у них нет средств. Однако, как показывает статистика, чрезвычайные ситуации стали часто встречающимся явлением.
   Чрезвычайная ситуация (бедствие, катастрофа) – это событие, которое оказывает такое негативное воздействие на функционирование сервиса или системы, что требуются значительные усилия для восстановления изначального Уровня Производительности.
   Как следует из данного определения, чрезвычайная ситуация намного серьезнее инцидента. Чрезвы­чайная ситуация – это приостановка бизнеса. Это означает, что весь бизнес или его часть будет на­ходиться "вне бизнеса" после возникновения чрезвычайной ситуации. Известны такие примеры чрезвычайных ситуаций, как пожары, удары молнии, наводнения, кражи, вандализм и акты насилия, широкомасштабное нарушение электроснабжения и сбои в работе аппаратного обеспечения. Атаки террористов, например, нападение на Всемирный торговый центр в Нью-Йорке, становятся реаль­ностью. Чрезвычайные ситуации возможны также и в Интернете, например, отказ сервиса (DoS) [210]может разрушить связь внутри всей организации. Некоторые организации могли бы предотвратить серьезные проблемы, если бы в свое время разработали План обеспечения непрерывности бизнеса. Бизнес все больше и больше зависит от ИТ-услуг, а это означает, что последствия потери сервиса становятся все более ощутимыми и все менее допустимыми. Фактически, сейчас во многих органи­зациях ведение бизнеса эквивалентно использованию информационных технологий (ИТ), и без них бизнес едва ли будет существовать. Поэтому необходимо решать, как защитить непрерывность биз­неса. Со времени опубликования модуля Планирование на случай чрезвычайных обстоятельств (Contingency Planning Module) ассоциацией CCTA многое изменилось в области информационных технологий и в том, как они используются в организациях. Ранее это планирование касалось только ИТ. В настоящий момент информационные технологии уже значительно интегрированы во многие аспекты бизнеса. Если раньше традиционный процесс планирования непрерывности работы и восстановления функционирования в основном носил реактивный характер (что делать в случае воз­никновения чрезвычайной ситуации), то теперь Процесс Управления Непрерывностью ИТ-серви­сов выполняет превентивную роль, т. е. работает над предотвращением катастроф.
    13.2. Цель процесса
   Цель Процесса Управления Непрерывностью ИТ-сервисов — оказывать поддержку Процессу Упра­вления Непрерывностью Бизнеса (Business Continuity Management – ВСМ). Такая поддержка озна­чает, что необходимая инфраструктура и ИТ-услуги, включая службу поддержки и службу Service Desk, могут быть восстановлены за заданный период времени после возникновения чрезвычайной ситуации. У данного процесса может быть и ряд других целей. Поскольку процесс ITSCM является составной частью Процесса Управления Непрерывностью Бизнеса, сфера действия Процесса Управ­ления Непрерывностью ИТ-сервисов (ITSCM) должна определяться, исходя из целей бизнеса. В ре­зультате при оценке рисков можно потом определить, попадают ли они в сферу действия данного процесса.
    Преимущества использования процесса [211]
   Поскольку бизнес во все большей степени зависит от ИТ-услуг, определить, во что может обойтись недостаточное планирование непрерывности предоставления ИТ-услуг и какие преимущества даст должное планирование этих вопросов, можно только с помощью анализа рисков. После того, как оп­ределен возможный риск для бизнеса, а не только для ИТ-сервиса, можно выделять средства для принятия превентивных мер и мер по борьбе с чрезвычайными ситуациями, например, разработка Плана восстановления после катастрофы.
   Если чрезвычайная ситуация все же произошла, то использование процесса ITSCM даст бизнесу следующие преимущества:
   ? возможность управлять восстановлением своих систем;
   ? уменьшить простои в работе;
   ? свести к минимуму перерывы в ведении бизнеса.
    13.3. Процесс
   Процесс Управления Непрерывностью ИТ-сервисов отвечает за:
   ? оценку воздействия нарушений в работе ИТ-сервисов после возникновения чрезвычайной ситу­ации;
   ? определение критичных для бизнеса сервисов, которые требуют дополнительных превентив­ных мер;
   ? определение периода времени, в течение которого сервис должен быть восстановлен;
   ? принятие мер по предотвращению, обнаружению, подготовке к чрезвычайным ситуациям или по уменьшению степени их воздействия;
   ? определение общего подхода к восстановлению услуг;
   ? разработку, тестирование и поддержку плана восстановления с достаточным Уровнем Детализа­ции, который поможет пережить чрезвычайную ситуацию и восстановить нормальную работу за заданный период времени.
   Поскольку наблюдается все большее взаимопроникновение бизнес-операций и информационных технологий, то эти две области вместе описываются в рамках ITIL:
   ? Процесс Управления Непрерывностью Бизнеса (Business Continuity Management – ВСМ) обес­печивает анализ и Управление Рисками, что позволяет организации во все времена гарантировать сохранение минимально требуемых производственных мощностей и Уровня Сервисов. Процесс ВСМ помогает уменьшить степень риска до приемлемого уровня и разработать Планы восстанов­ления бизнес-деятельности на случай, если она пострадает во время чрезвычайной ситуации.
   ? Процесс Управления Непрерывностью ИТ-сервисов (ITSCM) – это процесс, предназначенный для противодействия на случай чрезвычайных обстоятельств, затрагивающих ИТ-услуги, и вос­становления сервисов, необходимых для возобновления бизнес-операций.
   Процесс Управления Непрерывностью ИТ-сервисов является частью общего процесса Управления Непрерывностью Бизнеса, и он зависит от информации, которую предоставляет процесс ВСМ. Дос­тупность ИТ-сервисов обеспечивается благодаря сочетанию мер по уменьшению степени риска (на­пример, использование высоконадежных систем) и способов восстановления (например, запасные и параллельно работающие системы). Для успешной реализации процесса требуются поддержка со стороны всей организации, твердое намерение руководства реализовать данный процесс и участие всего персонала.