Инструментарий

Инструментарий

Поскольку основными преимуществами внедрения ресурсного подхода в компании Flossco считались возможности автоматизации и учета затрат, было важно реализовать планирование услуг и автоматизировать процесс эксплуатации. Команда разработчиков решила, что для этих целей наиболее подходят системы на базе серверов, а не на основе устройств хранения данных или сетевых устройств, управляющие возможности которых обычно ограничены непосредственным окружением. Команда рекомендовала использовать четыре категории программных средств:.
Мониторинг. В эту категорию были внесены базовые средства для контроля использования ресурсов процессоров, так и устройств ввода-вывода, подобные тем, которые входят в состав большинства операционных систем, средства определения долгосрочных тенденций, таких как увеличение средней загрузки процессора и устройств ввода-вывода, а также средства анализа для соотнесения тенденций и событий в различных частях распределенной системы и проведения анализа первопричин. Для автоматического перераспределения ресурсов и учета потребления услуг необходимы развитые средства контроля, поэтому вложенные в эту сферу финансовые средства должны были дать значительную отдачу.
Автоматизация. Средства автоматизации происходят из различных источников, поэтому определить эту категорию оказалось труднее всего. Например, средства виртуализации ресурсов хранения (RAIDсистемы, менеджеры томов и интеллектуальные коммутаторы) обычно могут находить новые диски, конфигурировать их и развертывать в соответствии с заданными алгоритмами. С другой стороны, серверы обычно развертываются с использованием одних наборов средств (например, VERITAS OpForce), а эксплуатируются с использованием других (ПО кластеризации). Разработчики ИТ-архитектуры компании Flossco решили, что автоматическое хранение данных целесообразно для компании, но для настройки и распределения ресурсов, по меньшей мере в ближайшей перспективе, могут потребоваться специальные средства и участие операторов.
Учет потребления. При нормально поставленном сборе данных о производительности и использовании услуг задача учета потребления сводится к повседневному анализу и обработке данных. Поскольку эта задача не представляет собой сложной технологической проблемы, учет потребления не требует скрупулезного проникновения во все процедурные детали. Обычно оказывается экономически более эффективно закупить разработанные и обслуживаемые на профессиональном уровне средства, чем создавать самим (что неявно предполагает — и постоянно обслуживать) собственные специальные средства — если это вообще возможно! В компании Flossco разработчики выбрали средства контроля, обладающие богатыми возможностями анализа и создания отчетов.
Рабочие процессы. Поставщик ресурсных услуг должен в конечном счете вести учет своей деятельности с коммерческой точки зрения. В частности, необходимо самым тщательным образом отслеживать запросы услуг, чтобы потребности пользователей удовлетворялись безотказно и вовремя. Повторим: учет потребления не является сложной технологической проблемой, но требует внимания к деталям и координации с другими средствами, например, бухгалтерскими системами, чтобы пользователям, например, можно было выставлять счета за запрошенные разовые и консультативные услуги. Компания Flossco выбрала систему управления рабочими процессами, способную поддерживать как запросы ресурсных услуг, так и запросы разовых и консалтинговых услуг и обращения в справочную службу.
График перехода.
Команда разработчиков предложила поэтапный план перехода на ресурсные принципы: начав с сетевых служб, перейти затем к устройствам хранения данных, а в конце концов преобразовать серверные службы. При этом необходимым условием перехода к каждому следующему этапу они поставили стабильную работу ресурсной службы в течение трех месяцев в рамках предыдущего этапа. Такой подход преследовал две цели:.
Обнаружить недостатки в организации поставки новых введенных ресурсных услуг, поскольку ИТ-подразделение было бы не в силах искать и устранять неполадки в одном наборе услуг при одновременном вводе других услуг.
Постепенно приучить пользователей к ресурсной поставке услуг и тем самым повысить вероятность принятия ресурсной схемы в долгосрочной перспективе.
Помимо всего вышесказанного, команда разработчиков предложила в течение шести месяцев сразу после внедрения не производить в сформированной среде никаких изменений. В этот период сама ИТ-организация должна была убедиться в гладкости взаимодействия различных компонентов ресурсной службы, надлежащей эффективности операционных процедур и т.п. Команда рекомендовала также в течение этого периода оценить работу ресурсной службы на предмет дальнейшего улучшения эффективности путем добавления новых средств или альтернативных операционных процедур. Идея состояла в том, что по истечении шести месяцев пользователи привыкнут к ресурсной модели поставки услуг, и последующие внутренние улучшения можно было бы производить прозрачным для них образом.
Результаты.
Переход компании Flossco на ресурсную модель ИТ-услуг был в основном успешным. Произошло, правда, несколько непредвиденных событий, но в целом переход прошел гладко и планирование внедрения дополнительных и модернизированных ИТ-услуг идет полным ходом. Ниже мы опишем как ожидаемые, так и непредвиденные последствия перехода компании Flossco на ресурсную модель вычислений.
Нестандартные услуги.
При развертывании услуги хранения данных был период, когда внедрение еще не завершилось, а для работы приложений требовались новые или дополнительные устройства хранения данных. В ряде случаев в ходе развертывания услуги устройства хранения данных были установлены таким образом, что их пришлось бы позднее переконфигурировать для использования в рамках стандартных сервисов. Однако, это было скорее мелким досадным недоразумением, чем серьезным препятствием для дальнейшего развития.
Хотя «золотая«, «серебряная» и «бронзовая» услуги были разработаны специально для того, чтобы удовлетворить широкий спектр потребностей пользователей, все же остались пользователи, чьи потребности не были удовлетворены. Для этих пользователей наиболее подходящим был бы «золотой» уровень функциональности, но их программное обеспечение не поддерживало услуги этого уровня. Чтобы у таких пользователей был стимул перейти на стандартизованные услуги, разработчики предложили соответствующим образом модифицировать систему ценообразования.
Распределение затрат.
Разработчики с самого начала осознавали, что справедливое распределение затрат — дело очень непростое. На самом деле оценка реальной стоимости поставляемых пользователям услуг оказалась даже труднее, чем ожидалось. Например, дисковые массивы могли использоваться не одним подразделением, при этом часть установленной емкости хранения данных была доступна для использования, а другая (потенциальная) емкость была еще не установлена в шасси. Очевидно, что каждый пользователь должен был платить за занимаемую его данными емкость, но как взимать плату за установленную, но неиспользуемую емкость и как поделить плату за ту часть шасси, в которую еще не установлены дисковые накопители?.
Разработчики решили, что простое пропорциональное распределение суммарной стоимости представляет собой наиболее простой и вместе с тем самый справедливый способ оплаты за совместно используемые емкости. Однако, такая схема оплаты означала, что в бюджете самого ИТподразделения значительную часть по-прежнему должна была составлять оплата неиспользуемой части оборудования. Разработчики понимали, что.
с течением времени использование оборудования станет более полным и вместе с этим уменьшится доля оплаты аппаратного обеспечения для ИТподразделения.
Для разработчиков было ясно, что с течением времени оплата подразделениями потребляемых ими ИТ-услуг приведет к составлению более точных краткосрочных прогнозов. Сначала использование нового оборудования будет высоким, и, следовательно, доля затрат, приходящаяся на долю ИТ-организации, будет небольшой. Дополнительные емкости будут вводиться в эксплуатацию по мере необходимости.
Одобрение пользователей.
Одной из непредвиденных трудностей на пути перехода оказалась задача действительного перехода пользователей на ресурсную схему поставки услуг. Команда разработчиков полагала, что поскольку компания Flossco в целом отдала предпочтение концепции ресурсных услуг вместо частных систем, подразделения-пользователи услуг перейдут на использование стандартных услуг по ресурсному принципу, как только эти услуги станут доступны. Но не тут-то было! Даже несмотря на соглашения об уровне поставляемых услуг (SLA), которых ранее не было и в помине, пользователи крайне неохотно переходили на новую модель. Пользователи выражали сомнение в том, что обещанные ресурсы будут поставлены, производительность будет достаточной, а предложенное наращивание будет произведено. Было просто необходимо, чтобы доверие пользователей резко повысилось, но такие вещи мгновенно не происходят.
Трехмесячные периоды между этапами внедрения ресурсных вычислений оказали неоценимую помощь в завоевании доверия к ресурсной схеме. Пользователи, которые совсем недавно были в нерешительности, вдруг обнаружили, что к ним относятся как к полноценным клиентам, и их запросы на услуги удовлетворяются быстрее, чем когда бы то ни было. Постепенно весь коллектив пользователей поверил в концепцию совместного использования аппаратных ресурсов, и доверие стало расти быстрее. Как только большинство пользователей приняли идею ресурсной поставки, администрация компании увидела, что благодаря совместному использованию ресурсов повысилась эффективность, и стала более охотно выделять финансовые средства на развитие ресурсных служб. Все эти факторы вместе взятые ускорили процесс повсеместного внедрения ресурсных услуг.
Сроки внедрения.
Ожидалось, что одним из преимуществ ресурсного подхода будет уменьшение сроков внедрения новых приложений. Именно так и произошло. Предлагая пользователям выбрать виртуальные ресурсы из заданного перечня вместо того, чтобы разрабатывать собственное решение для каждого приложения, разработчики сделали возможным во многих случаях вместо закупки и установки новых компонентов использовать существующие ресурсы (аппаратное обеспечение, лицензии на программное обеспечение, сетевые порты и пропускную способность). Даже в ситуациях, когда требовалось приобретать дополнительное оборудование, переконфигурировать существующие компоненты было значительно быстрее, чем выбирать, оплачивать, устанавливать и настраивать новое оборудование. Более того, с приобретением ИТ-организацией все большего опыта предоставления стандартизованных услуг стало все проще наращивать, настраивать, обеспечивать ресурсами и устранять неполадки.