9.11.1 Управление конфигурациями.
1.
Автоматизировать аудит ПО и АО и сравнить действительные данные с информацией в Конфигурационной базе данных учетных элементов (CMDB).
2.
Навязать жесткие правила ведения записей и контроля устройств защиты ПО («аппаратные ключи защиты»), поскольку они представляют собой ценные активы, которые часто невозможно заменить. Иметь в запасе оборудование для непредвиденных ситуаций.
3.
Минимизировать количество вариантов АО и ПО, существующих в среде эксплуатации. Это облегчит поддержку и увеличит надежность. Вести список официально утвержденного АО и ПО.
4.
Обеспечить механизмы определения Пользователями версий инсталлированного ПО и информации об аппаратном обеспечении. Другими словами, учредить функцию «Справка о программе/оборудовании» для всей рабочей станции в целом, а не только для отдельных приложений.
5.
Проверять критические файлы на их целостность перед запуском, например, с помощью контрольных сумм.
6.
Избегать продолжения оплаты за обслуживание АО или сопровождение ПО, которое стало лишним после очередного развертывания. В дополнение к этому можно использовать услуги аудита Управления конфигурациями для выполнения проверки на наличие инсталлированных нелегальных копий ПО. Это можно проделать как часть действий по распространению и при последующем аудите. Для эффективного проведения такого аудита необходима достаточная степень автоматизации.
7.
Навязать жесткий контроль за рабочими станциями путем установления правил в рамках операционной системы, тем самым, уменьшив шансы изменения целевых платформ конечными пользователями. Следует заметить, что разработчики ПО для выполнения своих задач обычно требуют более открытого доступа или даже двух рабочих станций.
8. Уменьшить количество официально поддерживаемых разновидностей целевой платформы в рамках организации.
9.11.2 Управление изменениями.
1.
С помощью программного контроля ограничить Изменения, которые Пользователи могут проводить для конфигурации своего ПК.
2.
При планировании перехода на новую систему эксплуатации провести серию встреч со всеми сторонами, участвующими в разработке, внедрении и поддержке предлагаемых Изменений.
9.11.3 Управление релизами.
1.
Убедиться, что для всего ПО, устанавливаемого в среду эксплуатации, есть исходный код, сохраняемый с помощью контролируемых процедур управления сборкой. При этом обеспечивается автоматизация действий по его сохранению и жесткий контроль версий файлов программного кода.
2.
Провести пилотное внедрение новых Изменений в «типичном офисе» в среде эксплуатации. Эти работы может проводить небольшое число реальных Пользователей через одну - две недели после их обучения.
3.
Автоматически определять необходимость обновления ПО при запуске и инициировать их при необходимости. Это позволит уменьшить риск эксплуатации устаревших версий ПО.
4.
Автоматизировать сборку, распространение и внедрение большей части или всего ПО, инсталлированного на рабочих станциях. В идеале это должно проводиться на основе «модели» (которая хранится в центре), чтобы обеспечить точность спецификаций инсталлируемого ПО.
5.
Определить постоянное оборудование для проведения сборки для платформ, которые могут быть выделены какому-либо проекту или группе схожих приложений.
6.
Иметь типичную, соответствующую требованиям, тестовую среду, которая как можно точнее повторяет аппаратную и программную среду эксплуатации.
9.11.4 Вопросы проектирования приложений.
Проектирование приложений может повлиять на задачи Управления релизами.
При анализе проектов приложений следует принять во внимание следующие.
рекомендации:.
1.
Местоположение прикладного ПО (локальное или центральное - см. следующий раздел) должно контролироваться.
2.
Если важно, чтобы обновления ПО инсталлировались своевременно, то может понадобиться ограничить время работы приложения, чтобы не допустить его использования после определенной даты. Это особенно важно для ПО, которое выпускается в неконтролируемую среду (например, за пределы организации).
3.
Там, где части приложения разделены и выполняются на разных компьютерах (например, в системах клиент-сервер или в многоуровневых системах), важно обеспечить совместимость всех программных компонентов. Можно встроить проверки, выполняемые во время работы программы для подтверждения совместимости интерфейсов, например, при выявлении устаревшей версии компонента на другой платформе будет выдаваться ошибка.
4.
Рассмотрите все варианты размещения данных, например, распределенные данные или распределенные приложения. Может понадобиться, например, распространять и/или реплицировать данные, которые хранятся в центре и, возможно, принимать обратно сделанные в них Изменения. Более простой сценарий - распространение статических контролируемых данных, например, справочников или баз данных почтовых адресов.
5.
Если требуется подготовить приложение для использования во всем мире (включая различные языки, местоположения и часовые пояса), возможно, понадобится спроектировать приложение таким образом, чтобы почти все распространяемые файлы были общими для всех стран и только несколько файлов отличались для каждой страны. Лучший вариант - минимальное количество параметров конфигурации.
9.11.5 Расположение программного обеспечения: что и где следует устанавливать.
Рассмотрите возможность минимизации количества программ, установленных на клиентских рабочих станциях путем развертывания выполняемого ПО на серверах. Это уменьшит усилия, требуемые для распространения изменений в ПО, однако это может привести к увеличению загруженности сети. Крайний случай минимизации ПО на клиентских рабочих станциях - модель «тонкого клиента», описанная в параграфе 9.10.2.
Многие приложения требуют инсталляции некоторых файлов на каждом клиентском ПК, обычно в общих папках. Следует тщательно управлять этими поддерживающими файлами, поскольку может потребоваться их обновление вместе с новыми версиями приложений, которые их используют. Управление такими обновлениями может вызвать особые трудности, если эти файлы являются общими для нескольких приложений.
Существует утверждение, что благодаря резкому снижению цен на жесткие диски и увеличению их объема, можно инсталлировать все ПО на каждой рабочей станции (при условии, что у вас есть средства для удаленного распространения ПО и управления рабочими станциями). Тем не менее, некоторые организации успешно управляют ситуацией, когда любой работник может использовать любой ПК. Этот подход обладает рядом преимуществ. Например, это значительно упрощает «горячую замену» оборудования на неисправных рабочих станциях. Такой подход может быть достигнут путем комбинации технических методов, например:.
■ данные хранятся не на локальных рабочих станциях, а только на центральных файловых серверах;.
■ максимальное использование динамической загрузки программ через локальную сеть;.
■ использование умного «кэширования» для уменьшения загруженности локальной сети.
Даже если внедрены сложные утилиты для распространения ПО, может быть проще обновлять данные на относительно небольшом количестве серверов, по сравнению с синхронизованными обновлениями кода на тысячах ПК. Простого решения этой проблемы не существует. Однако рекомендуется, чтобы организации рассмотрели возможность хранения кода неустойчивых приложений на центральных серверах. Несмотря на то, что для закупленных приложений такие действия могут быть неосуществимы, многие программные пакеты допускают такой вариант инсталляции, и разработчикам ПО настоятельно рекомендуется рассмотреть эти вопросы для всех новых приложений.
Другими словами, организации должны определить свой подход к этому вопросу и четко указать его в политике Релизов.