Некоторые реализации «тонкого клиента» не требуют локальной установки никакого изменяемого ПО, они получают доступ в сеть и загружают приложения с помощью контролирующей программы во встроенном ПО на рабочей станции. Такой подход требует минимума административных накладных расходов. Другие методы зависят от локально инсталлированной операционной системы и использования программ-эмуляторов для запуска удаленных сессий на сервере. Этот подход, следовательно, требует управления локально инсталлированным системным ПО.
9.10.3 Многоуровневые системы.
Растущее число систем состоит из ПО, которое может работать на нескольких аппаратных платформах. Обычная модель - использование серверов приложений промежуточного уровня, которые посылают запросы к данным серверных СУБД.
На Рисунке 9.10 несколько рабочих станций связаны с промежуточным сервером приложений, который обеспечивает доступ к данным в двух различных
Рисунок 9.10 - Пример многоуровневой конфигурации.
серверных СУБД. В этом примере допускается, чтобы развертывание прикладного ПО происходило на трех уровнях: рабочей станции, сервере приложений и сервере баз данных.
Управление релизами должно обеспечить координацию Изменений в приложении на всех этих платформах как единого целого наряду со всеми сопутствующими изменениям в АО.
9.10.4 Интернет-приложения.
Разновидности многоуровневой модели часто используются, чтобы обеспечить интернет-доступ к системам, эксплуатируемым в организации, для существующих внутренних Пользователей, использующих обычные рабочие станции, на которых установлены версии одних и тех же или похожих приложений с Графическим интерфейсом пользователя (Graphical User Interface, или GUI). Часто встречающаяся модель - развертывание веб-серверов, подключенных к интернету, для Пользователей с веб-броузерами. Эти серверы обычно подключены через брандмауэр, чтобы ограничить возможность неавторизованного доступа ко всей внутренней сети организации.
Рисунок 9.11 - Пример конфигурации для веб-доступа.
На Рисунке 9.11 добавлено несколько областей, которые следует контролировать в дополнение к указанным в многоуровневой модели:.
■ Подключение к сети интернет. Необходимо регулировать установки в маршрутизаторах на каждом конце соединения и пропускную способность интернет-канала. Новый Релиз приложения может потребовать выделение дополнительной пропускной способности для поддержки дополнительного количества параллельно работающих Пользователей.
■ Файрволл. Часто эту роль выполняет выделенный сервер, который нужно настроить и поддерживать. Возможно, понадобится модернизация аппаратного обеспечения для поддержки дополнительных требований мощности и устойчивости.
■ Веб-сервер. Этот сервер обычно содержит веб-страницы, на которые Пользователь может перейти через интернет. Так же, как и для.
Изменений в АО и ПО, связанных с поддержкой дополнительных мощностей или устойчивости, вероятно, что для новых приложений потребуется разместить новые или измененные веб-страницы на этом сервере.
Понятно, что Управление релизами играет все более важную роль в обеспечении изменений во всех компонентах ИТ-услуг при координации с интернетприложениями. Единственное, что для работы этого типа приложений потребуется взаимодействие различных частей ИТ-подразделения (или даже некоторые Пользователи). Например, группа управления сетью - для подключения и брандмауэра, веб-мастер - для веб-сервера, серверная группа для сервера приложений, группы средних или мейнфрейм-систем - для серверных СУБД. Роль Управления релизами - помочь беспрепятственно собрать эти действия воедино.
9.10.5 Обновления ПО через интернет.
Поставщики коммерческого ПО все более часто предоставляют доступ к загрузке временных решений и обновлений своего ПО через интернет. Существует большое количество законченных приложений, которые могут быть загружены и инсталлированы.
Следует заметить, что, несмотря на привлекательность возможностей самосопровождающихся приложений, есть ряд опасностей:.
■ все учетные записи, которые централизованно хранятся в CMDB и содержат информацию о том, что инсталлировано на какой-либо рабочей станции, быстро теряют актуальность, если они не контролируются системой Управления изменениями и не проверяются с помощью аудита Управления конфигурациями;.
■ вероятно, что эти модернизации ПО не прошли полного тестирования, и почти наверняка ни для одной из них не проводилось регрессионное тестирование. Следовательно, существует риск появления сбоев;.
■ любая контролируемая среда тестирования становится неактуальной, поскольку она уже не отражает среду эксплуатации;.
■ не всегда можно правильно обнаружить зависимости АО или системного ПО;.
■ если не выполнять нужные процедуры, то возможно заражение вирусами;.
■ неавторизованное Изменение в среде эксплуатации может сделать Изменения в ПО или АО недействительными, если перед этим не проводился очень тщательный аудит ПО и АО для выявления изменений и проверки наличия известных предварительных условий.
В общем, такая практика должна использоваться только персоналом службы поддержки в контролируемой среде тестирования как часть конструирования следующего официального Релиза. Настойчиво рекомендуется не использовать такую опцию на рабочих станциях, находящихся в эксплуатации.