Рекомендации по Управлению конфигурациями

Рекомендации по Управлению конфигурациями

Существует три аспекта Управления конфигурациями, по которым можно дать определенные рекомендации.
7.11.1 Уровень контроля.
Многие организации начинают с определения обобщенных УЭ. Тем не менее, полезно начать работы по Управлению конфигурациями с идентификации критичных услуг и их компонентов. Некоторые элементы могут являться критическими в определенный период дня или года. Примеры критических УЭ или УЭ с высокой степенью риска:.
■ источники энергоснабжения для серверных и машинных комнат;.
■ маршрутизаторы и коммуникации для основных мест нахождения офисов;.
■ связь, компьютеры и программные приложения для руководящего состава;.
■ элементы, которые могут повлиять на соответствие организации законодательству;.
■ связь с участками и системами с повышенными требованиями по безопасности;.
■ элементы, отвечающие за безопасность;.
■ EDI и подача данных (например, о зарплате) между базами данных;.
■ внешние интерфейсы для торговых партнеров, поставщиков,.
Заказчиков и бизнес-партнеров;.
■ интерфейсы с филиалами, использующими системы работы с Заказчиками;.
■ элементы, использующие новые технологии, за которыми первоначально требуется наблюдение.
Некоторые организации увлекаются слишком детальными описаниями. Они предполагают, что если сделано описание с высркой степенью детализации в одной части структуры, то такой же уровень детализации требуется и во всех других конфигурациях. Несмотря на то, что это может помочь в сохранении однородности данных и облегчить их понимание, такой подход приведет к ослаблению контроля над данными, из-за возможной нехватки ресурсов для сопровождения всех этих данных. Чтобы вернуть соответствующий уровень контроля, могут потребоваться действия по повторному планированию с использованием данных из CMDB. Другой подход - провести чистку конфигурации или списание для удаления устаревших или повторяющихся элементов. При этом также будет устранена необходимость поддержания контроля над подробными данными.
Обобщив вышесказанное, целью является максимум контроля при минимуме записей.
7.11.2 Версии или варианты?.
Несмотря на то, что одни и те же УЭ не могут быть использованы в более чем одном месте одной ИТ-инфраструктуры, вполне возможно использовать несколько измененную версию того, что может считаться тем же самым УЭ. Эта другая версия будет иметь другой номер. Такие УЭ называются «вариантами».
Чтобы понять, насколько полезно использовать варианты, рассмотрите компьютер с двумя дисководами, обозначенными как А и Б, которые первоначально используют версию 1.1. Если дисковод Б изменен для увеличения его мощности и скорости обмена данными, он становится версией 1.1.1. Дисковод А может быть оставлен без модификаций для сохранения обратной совместимости. Если в дисководе А найдена и затем исправлена ошибка проектирования (при этом версия А изменяется на 1.2.), то это Изменение должно быть передано на дисковод Б (при этом версия Б изменяется на 1.2.1.). А и Б могут рассматриваться как различные, несвязанные УЭ. Тем не менее, может быть полезно рассматривать их как различные варианты, поскольку они обладают большим количеством одинаковых компонентов. Другой очень популярный пример использования вариантов - когда «стандартная» система «дорабатывается» для какого-либо приложения.
Обычно принимается компромиссное решение. Использование вариантов может привести к меньшему количеству УЭ и облегчить идентификацию элементов для выполнения общих для них задач, будь то обработка ошибок или внедрение Изменений. Однако использование вариантов повлечет дополнительные сложности для системы Управления конфигурациями и для других систем (например, для системы Управления проблемами), работа которых зависит от нее.
Общие рекомендации: если УЭ может рассматриваться как незначительно отличающийся от другого сходного УЭ, и Проблемы, которые влияют на один из этих УЭ, также, вероятно, будут влиять и на другой УЭ, или Изменения, проведенные в одном из этих элементов, также, вероятно, потребуется провести и в другом элементе, то в этом случае следует рассмотреть использование вариантов. В других случаях следует использовать отдельные УЭ.
7.11.3 Выбор средств Управления конфигурациями.
Многие поставщики ПО включают в свои продукты некоторую функциональность по Управлению активами или Управлению конфигурациями. Такую функциональность важно учитывать в существующих или предлагаемых услугах или средствах управления системой, чтобы избежать повторений или неучтенных УЭ. Например, некоторые средства поддерживают только два уровня УЭ, что может создать чрезмерные ограничения.
Поскольку организации все больше зависят от программного обеспечения, способность управлять всеми типами ПО и контролировать их становится все более важной задачей. Необходимо с особой тщательностью подходить к выбору программных средств Управления конфигурациями ПО, чтобы удостовериться в том, что может поддерживаться весь перечень платформ, используемых в организации, иначе вашей организации придется закупать отдельное ПО для каждой используемой платформы. Способность контролировать файлы программного обеспечения может сэкономить время и уменьшить количество ошибок. Длина кода идентификатора крайне важна для программного обеспечения, поскольку часто возникают повторения в названиях файлов в разных частях структуры.