Эффективное планирование ресурсов

Введение

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

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

Эффективное управление ресурсами требует понимания меры потребления бизнесом IT сервисов, а также компонентов, составляющих IT сервисы. Для этой цели полезна концепция Peak Hour Load (Загрузки Пикового Периода) в качестве единицы измерения.

Анализ Peak Hour Load (далее PHL) обеспечивает понимание нынешних потребностей бизнеса в ресурсах («загруженность»), а также предоставляет основу для прогнозирования загруженности в будущем («потребности»).

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

Эффективное планирование загрузки мощностей

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

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

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

Ресурсные мощности – это измерение и наблюдение за всеми компонентами IT сервисов. На практике это означает отслеживание использования отдельных компонентов, таких как маршрутизаторы, линии связи, серверы и так далее.

Сервисные мощности – требуют удовлетворения IT сервисами целей, заявленных в Service Level Requirement (SLR) согласно Service Level Agreements (SLA). На практике это означает измерение и наблюдение за работой и производительностью IT сервисов. Очевидно, что сервисные мощности являются функцией от ресурсных мощностей.

Бизнес мощности – это, прежде всего, планирование и внедрение IT сервисов, направленное на будущие потребности бизнеса. На практике это означает анализ тенденций и прогнозирование проектируемого насыщения, основное на данных о сервисных мощностях.

Эти три аспекта в совокупности дают полную картину, необходимую для понимания использования IT сервисов. Управление ресурсными мощностями предоставляет детальные сведения о загрузке производственных мощностей

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

Требования для эффективного планирования загрузки мощностей

Общей характеристикой для IT сервисов и их компонентов является их ограниченная способность эффективно работать. Способность к эффективной работе называют «мощностью», объем уже проделанной работы – «загруженностью».

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

Анализ «загруженности»

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

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

Рассмотрим в качестве примера использование такого средства передачи, как сеть Wide Area Network (WAN). Если мы проведем измерения загруженности в разные моменты времени, мы получим несколько результатов, каждый из которых будет верным. Если измеряемый период времени достаточно короткий, то степень загруженности может оказаться достаточно высокой. Если же интервал более длинный, то и результат может оказаться несколько меньше. Поэтому для того, чтобы измерения были корректны, необходимо брать определенные равные промежутки времени. Кроме того, следует проводить серии измерений, так как это позволит отслеживать тенденции в использовании сервисов и элементов конфигурации.

Пиковая загруженность

Поскольку мы говорим сейчас только об IT сервисах, мы можем получить информацию о загруженности в наиболее оживленный период. Это называется пиковая загруженность – т.е. измерение использования сервисов и компонентов в «худшем случае».

В бизнесе люди часто работают по собственному графику, нередко – в любое время дня и ночи. Поэтому вопрос о пиковой загруженности становится чрезвычайно важным.

Однако не стоит думать, что пиковая загруженность тождественна просто максимальному зафиксированному использованию. Например, для центрального процессора максимальная загруженность может быть равна и 100%. Однако отметка в 100% может быть достигнута всего лишь на какое-то мгновение, и по сути дела не отражает реальной загруженности процессора.

Что же требуется для понимания пиковой загруженности? Прежде всего, необходимо принимать во внимание использование элемента конфигурации с течением времени. Вопрос следует сформулировать таким образом: «какова пиковая загруженность ежечасно»? С учетом фактора времени, информация о пиковой загруженности может быть чрезвычайно ценной.

PHL показывает, какой час в течение всего рабочего времени наиболее оживленный. Если мощности удовлетворяют требованиям пиковой загруженности – значит, у вас достаточно ресурсов.

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

Следует прежде всего использовать данные о загруженности пикового периода для определения степени занятости элемента конфигурации. Затем необходимо сделать так, чтобы мощность элемента несколько превосходила загруженность пикового периода. Разница между двумя этими показателями отражает растущий потенциал элемента.

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

Как избежать проблем в будущем

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

Насыщение происходит в тот момент, когда использование компонента приближается к его максимальной мощности. Совершенно необходимо, чтобы уровень использования компонента был ниже уровня его мощности. Можно привести простой бытовой пример: обычная хорошая машина может развить скорость в 200 км/ч, но тем не менее лучше всего она ездит на скорости примерно в 100-120 км/ч. Примерно то же самое происходит и с сервисами, оптимальный режим работы компонента всегда ниже его потенциальной мощности.

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

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

Использование этого метода позволит вам определить срок прогнозируемого насыщения. Однако этого еще недостаточно. Важнейшим элементом в прогнозировании насыщения является оценка продолжительности жизненного цикла сервиса, а именно ответ на вопрос, сколько времени займет обновление сервиса. Это время обязательно нужно учитывать. Например, если обновление занимает 30 дней, а по вашим подсчетам насыщение наступает через 90 дней, то начать заниматься обновлением нужно не позже чем через 60 дней.

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

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

Как сократить убытки

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

Еще один способ сэкономить – это реорганизация активов. Например, изначально для определенных целей требовался большой, быстрый и хорошо оборудованный сервер. Но со временем потребности изменились, и дорогостоящее имущество стало мало использоваться. Если какое-либо другое приложение нуждается в подобном сервере, целесообразно будет перенести малоиспользуемый сервер в другое место, а на первоначальном месте заменить его менее дорогим и крупным.

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

Как уравновесить требования

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

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

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

Каждый конкретный случай следует анализировать отдельно, в данном случае универсальных рекомендаций быть не может. Когда такая загруженность происходит по объективным причинам, следует пойти навстречу пользователям и провести обновления сервисов с увеличением их мощности. А в других случаях определенные административные меры вполне оправданны, комфортны для всех и, в итоге, приводят к желаемому результату.

Балансирование использования одного компонента нередко влияет на пиковую загруженность других.

Зачастую это «уравновешивание» предоставляет возможности уменьшения затрат через сокращение, удаление или задержку обновлений для некоторых элементов.

Эта стадия планирования, несомненно, очень важна в эффективном планировании. IT менеджер, используя эти рекомендации, может значительно снизить расходы организации и одновременно повысить качество и производительность работы. Однако для принятия подобных мер необходимо множество различной информации и тщательный ее анализ. Следует изучить использование элементов конфигурации по дням и бизнес процессы внутри организации. Кроме того, еще одна сложность состоит в том, что необходимо иметь возможность санкционировать административные изменения внутри компании. Поэтому можно сказать, что этот этап столь же эффективен, сколь и сложен в реализации.

Работая на успех

IT сервисы используют множество компонентов, каждый из которых обладает ограниченными возможностями хранения, обработки и передачи информации. Как только использование компонента достигает своего максимума, компонент становится камнем преткновения или, если угодно, «узким местом» в работе других сервисов и приложений, сколь бы эффективны и совершенны они ни были сами по себе. А это, в свою очередь, отражается крайне негативно на бизнес процессах и удовлетворенности потребителей.

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

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

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

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

Подводим итоги

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

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

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

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

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

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

Что со сроками?

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

Месяц 1

  • Создайте каталог загруженности сервисов и компонентов (как пиковой, так и средней)

  • Оцените качество работы сервисов, основываясь на возможностях потребителей нормально работать (задержки в работе)

  • Определите те компоненты, которые становятся «камнем преткновения» в работе других элементов

    Месяц 2

  • Используя каталог, найдите компоненты, которые используются слишком мало или, наоборот, чрезмерно

  • Попробуйте спрогнозировать изменение потребностей в будущем

    Месяц 3

  • Прежде чем появятся новые проблемы и ошибки, попытайтесь поддерживать текущие мощности в нормальном режиме

  • Устраните, сократите или замените мало используемые компоненты, чтобы сократить расходы

  • Балансируйте требования к компонентам, у которых график использования носит характер «бума»

  • При необходимости, повторите всю последовательность действий.

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

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

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

    Обсудить на форуме | опубликовано: 29.01.07