▼ Закупка Установка.

▼ Поддержка аппаратных средств и приложений.

▼ Резервное копирование и другие базовые услуги.

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

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

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

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

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

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

Процесс принятия решения.

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

Уровень отсчета.

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

Анализ затрат и результатов.

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

Форма реализации ресурсной модели.

Для реализации ресурсного подхода к ИТ существует три основных пути. «Внутренний аутсорсинг». Внутри ИТ-службы компании создается собственная частная ресурсная служба для удовлетворения определенных потребностей бизнеса.

Частная ресурсная служба под внешним управлением. Ресурсная служба организуется не собственной ИТ-службой компании, а независимым провайдером услуг.

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

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

Решение руководства.

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

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

План проекта.

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

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

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

В следующих главах эти шаги обсуждаются более подробно.

Определение базового уровня.

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

Инвентаризация ИТ-активов.

Перечень ИТ-активов — это просто список оборудования и программного обеспечения, которыми владеет предприятие. Для каждого элемента в списке должны быть указаны:.

Физическое размещение Возраст.

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

Уровень поддержки (по контракту, собственными силами, без поддержки и т.п.).

▼ Владельцы, пользователи и обслуживающий персонал.

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

▼ Первоначальный покупатель.

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

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

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

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

Преодоление сопротивления.

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

К счастью, у нас есть недавний прецедент радикального изменения в методах оказания ИТ-услуг. В течение 1998-1999 гг. практически все предприятия провели инвентаризацию своей ИТ-инфраструктуры в ожидании т.н. «проблемы 2000 года». В процессе выявления и замены устаревших и не отвечающих предъявляемым требованиям активов неизбежно происходили изменения в методах оказания ИТ-услуг. Хотя пользователи первоначально противились этим изменениям, в конечном счете в результате выявления и замены устаревших систем операционная эффективность и качество сервиса повысились. Переход на ресурсную модель должен иметь подобные же побочные выгоды; проблема в том, чтобы донести эти выгоды до сознания пользователей.

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

Понимание корпоративной культуры.

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

Кто инициировал проекты, представляющие собой хорошие кандидатуры для перехода (руководители, сами пользователи, ИТ-подразделение)? Кто обычно формулирует требования к новым информационным сервисам? Насколько квалифицированны эти люди?.

На каком этапе жизненного цикла проекта происходит выделение финансирования? Кто имеет полномочия тратить выделенные бюджетные средства?.

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

Какие «проблемные» пользователи имеют обыкновение выступать в последний момент с новыми запросами или часто менять требования к проекту?.

Хорошо ли разграничены роли и ответственности разрабатывающей и эксплуатирующей сторон (это особенно важно для предприятий с большим количеством удаленно работающих сотрудников)?.

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

Формирование услуг ресурсной ИТ-службы.

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

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

Карты сбалансированных показателей ресурсной службы.

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

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

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

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

Пользовательская карта сбалансированных показателей.

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

Как ИТ-сервисы соотносятся с целями и задачами предприятия? Отвечают ли ИТ-сервисы целевым показателям готовности, производительности и простоты использования?.

Какое планирование и другая подготовка необходимы для использования ИТ-сервисов?.

Можно ли улучшить ИТ-сервисы в каких-то аспектах?.

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

Карта сбалансированных показателей ИТ-службы.

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

Чтобы оценить, в какой мере ИТ-услуги уже следуют ресурсной модели, полезно дать ответ на две группы вопросов. Первая группа вопросов относится к инфраструктуре.

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

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

Насколько изолированы или интегрированы ресурсы, используемые разными пользователями и приложениями? Используются ли совместно разными приложениями серверы, емкости хранения и сети? Используют ли приложения ысовместно и обмениваются ли они данными? Можно ли при необходимости обособить совместно используемые приложениями ресурсы?.

Насколько сложны рабочие процессы ИТ-службы? Сколько приложений поддерживается этими ресурсами? Чтобы определить важность конкретных приложений для предприятия, стоит собрать данные о том, сколько людей используют эти приложения или зависят от них.

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

Вторая группа вопросов относится к взаимодействию ИТ-службы с пользователями.

Заключает ли ИТ-служба SLA с пользователями и соблюдаются ли они? Отслеживается ли производительность по сравнению с SLA и доводятся ли результаты до пользователей?.

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

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

Использование результатов инвентаризации.

Готовые результаты инвентаризации ИТ-систем необходимо проанализировать, чтобы определить, какие сервисы будущая ресурсная служба может предложить и в каком порядке. Цель такого анализа — выработать минимальный набор сервисов, который будет обслуживать максимальное число пользователей. Существующие сервисы следует проанализировать с точки зрения возможного объединения. Например, при анализе сервисов резервного копирования можно было бы рассмотреть следующие вопросы: Сколько различных способов резервного копирования данных применяется в организации и какому количеству реально различных уникальных требований они соответствуют?.

Сильно ли отличается ежедневное инкрементное резервное копирование с полным еженедельным от ежедневного инкрементного резервного копирования с полным каждые четыре дня?.

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

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

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

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

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

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

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

▼ Материальные и человеческие активы.

Информационные услуги и приложения, необходимые для поддержки работы предприятия.

Общие ИТ-сервисы, лежащие в основе этих услуг.

Предложения пользователей о том, как можно улучшить ИТ-услуги.

или повысить их эффективность.

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

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

Формирование новых сервисов ресурсной ИТ-службы.

На определение сервисов ИТ-службы оказывают влияние три ключевых фактора:.

Затраты на предоставление сервиса Требования к готовности сервиса Требования к производительности сервиса.

Затраты.

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

Готовность.

Готовность информационных услуг — это сложная проблема, которая подробно освещается в книгах The Resilient Enterprise

и Blueprints for High Availability

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

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

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

Производительность.

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

Стоимость услуги была пропорциональна ее ценности для предприятия.

Производительность можно было измерить и сравнить со спецификациями SLA.

Многие ИТ-службы измеряют производительность приложений только в ответ на жалобы пользователей. При определении ресурсных услуг архитекторам следует быть реалистичными, задавая производительность в реально измеримых показателях. На начальных этапах процесса перехода, подобного показанному на Рис. 5-1, задаются уровни сервиса компонентного уровня. По мере укрепления ресурсной службы возможности измерения и анализа производительности должны развиваться, создавая условия для перехода от SLA компонентного уровня к SLA уровня приложений.

Анализ результатов.

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

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

По мере возникновения потребностей в новом оборудовании его можно закупать для предприятия в целом, а не для индивидуальных приложений. Можно использовать серверы и системы хранения корпоративного класса, если это оправданно экономически; можно перейти на «массовые» серверы и простейшие устройства хранения, если это имеет смысл с точки зрения бизнеса. Наконец, сократив количество поставщиков до одного-двух на каждый тип компонентов, предприятие может получить шанс добиться лучших цен и условий поставки и обслуживания аппаратного и программного обеспечения. Снижение операционньх издержек. Более эффективное использование активов означает снижение операционных издержек. Эксплуатация меньшего количества серверов и систем хранения требует меньших расходов. С увеличением числа одинаковых компонентов требуется меньше типов эксплуатационных навыков (а качество обслуживания возрастает благодаря тому, что люди лучше осваивают часто выполняемые операции).

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

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

Экономия средств от сокращения простоев приложений может быть весьма значительной. Например, если сервер дает сбой четыре раза в год, а каждое восстановление занимает 95 минут, это дает 380 минут простоя приложений в год. Перенос приложения на кластер может сократить время простоя для каждого инцидента до пяти минут и менее, что соответствует общему времени простоя 20 минут в год. Таким образом, ценность кластера эквивалентна стоимости шести часов простоя бизнеса.

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

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

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

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

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

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

План перехода.

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

Перевод ИТ-сервиса на ресурсные принципы происходит в три перекрывающихся по времени этапа:.

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

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

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

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

Капитальное оборудование и логистика.

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

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

Обучение и изменение корпоративной культуры.

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

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

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

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

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

Жесткость и гибкость.

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

экономической ситуации приводит к отсрочке запланированных капитальных расходов.

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

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

Выводы.

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

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

ИТ-сервисы можно подразделить на базовые инфраструктурные, ресурсные, сервисы по требованию и консультативные.

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

«Не ходи туда, куда ведет тебя дорога, иди туда, где нет пути, и оставь свой след».

Ральф Уолдо Эмерсон.

Темы этой главы:.

Четыре этапа внедрения ресурсной ИТ-службы.

Выбор поставщиков и партнеров и управление взаимоотношениями.

с ними.

Внутренние цели для ИТ-подразделений.

После того как определен базовый уровень, получена поддержка на уровне руководства, выполнен анализ затрат и результатов и составлен план проекта, можно начинать создание ресурсной ИТ-службы. Переход от традиционного центра обработки данных к ресурсной модели неизбежно включает четыре этапа, показанных на Рис. 6-1 (повторяет Рис. 5-1), независимо от того, выделены ли они в плане внедрения.

Создание ресурсной инфраструктуры.

▼ Сопровождение управления ресурсами.

▼ Управление сервисами.

▼ Ресурсная модель.

Этапы реализации ресурсной ИТ-службы.

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

Каждый из четырех этапов перехода, перечисленных на Рис. 6-1 (повторение Рис. 5-1), приносит пользователям определенный положительный результат. Большинство предприятий предпочитает делать между этапами паузы, чтобы удостовериться, что процесс внедрения не привел к нежелательным побочным эффектам, и дать пользователям возможность адаптироваться к переменам и оценить их преимущества. В следующих разделах эти четыре этапа перехода рассматриваются более подробно.