Читайте также:
|
Описанный выше процесс может задокументировать множество различных стандартов и политик в каждой данной категории. Некоторые из них могут перекрываться или вступать в конфликт; в других областях, существующие стандарты могут иметь пробелы. Целью этого обзора стандартов является выработка единого взгляда на существующие стандарты и их сравнение с желаемым уровнем стандартизации, оговоренном выше. В процессе работы группа обзора может применять информацию, полученную от экспертов, представляющими группу владельцев, для выработки подходящих рекомендаций. Целью этой процедуры является выявление:
· Устаревших стандартов для исключения или обновления.
· Конфликтных стандартов для устранения или слияния.
· Стандартов, выходящих за рамки для устранения из дальнейшего рассмотрения.
· Пробелов, для заполнения новыми стандартами.
Обзор предполагаемых изменений для категории
В предыдущем разделе, мы по существу развивали план относительно того, как нужно объединить и модернизировать существующие стандарты IT и политику. Теперь необходимо, испытать эту концепцию, исследуя любые изменения предусматриваемые для скорейшего внедрения, вне зависимости разрабатываются ли они или находятся в стадии внедрения в рамках процесса управления изменениями.
Новые инициативы могут предусматривать переход от одной технологии или продукта, например программного обеспечения к другой, например миграцию к Microsoft Windows® XP или от Lotus Notes к Microsoft Outlook®. Могут осуществляться новые проекты, например, объединение всех настольных компьютеров на одну версию программного обеспечения или оборудования, либо переход в новый офис, используя беспроводную технологию.
Процесс управления изменениями вместе с CMDB выявляет системные изменения в каждой категории. На этом этапе полезно определить являются ли эти изменения долгожданными или появились недавно, так как изменения могут стать бесполезными, если уже принято решение использовать определенную политику или стандарт в данной категории. Например, может быть так, что запрошено разрешение, но еще не получено, на переход на новую технологию печати. Одновременно, анализ показывает, что 90 процентов организации использует другую технологию. Этой информации может быть достаточно для перевода запроса на изменение в «очередь»вплоть до формирования окончательного решения.
Другим примером может быть разработка политики внутри службы контроля сервисов с целью наблюдения над определенными функциями сети и написания набора политик для этого, только для того чтобы обнаружить, что такие политики становятся устаревшими после установки Management Pack для Microsoft Operations Manager (MOM). Проверка на соответствие будущим проектам позволяет избежать потерь на разработку стандартов и политик для компонентов инфраструктуры, претерпевающим сильные изменения. Если выясняется, что категория находится на стадии планирования перехода на новую систему, например, лучше отложить приготовления по контролю данной категории.
Цикл разработки тоже может помочь указать, через процесс управления изменениями, все изменения в инфраструктурной категории, которые находятся в разработке, исследования или первоначальной задумки, или ожидают скорейшего релиза. Эта информация позволяет IE построить картину для каждой категории, показывающую, что происходит не только сейчас, но и что ожидается в короткой и средне-срочной перспективе. Чем больше информации оказывается доступно, тем легче принять решение, куда двигаться дальше. Одобрения как часть процесса управления изменениями должны обеспечить затратную обоснованность и хорошую документированность представленных изменений до тех пор, пока изменения авторизуются к выполнению.
Обзор стратегии и планирования категории
В дополнении к обзору изменений и разрабатываемых проектов, также полезно рассмотреть стратегию развитие на будущее. Например, коммерческие организации могут иметь стратегию оутсорсить отдел телемаркетинга за 3 года. Это повлияет на стандарты, применяемые к дальней связи и хранению данных. Эта стратегия может потребовать обновления средств телефонной связи. Аналогично, решение прейти на беспроводные технологии, в связи с 40 процентным увеличением штата, выдвинет новые требования к сетевому оборудованию и соответствующее уменьшение инвестиций в офисные компьютеры в пользу мобильных решений.
Основная роль IT, и IE в особенности, состоит в том, чтобы гарантировать способность IT поддерживать бизнес развитие и обеспечивать функциональность, позволяющую использовать рыночные возможности когда бы это не потребовалось. Отслеживание стратегических решений такого типа требует, чтобы IE воспринималась как основной участник стратегическими бизнес и IT руководителями в организации. По мере того как выгоды от эффективного IE процесса становятся очевидными, оказывается проще получить соответствующее расположение на высоком уровне для распространения этой информации.
Определение стандартов и политики для категории
Как только возникает понимание существующих, будущих, и стратегических влияний на категорию инфраструктуры, появляется возможность определить стандарты и политику для этой категории.
В предыдущем разделе определены процедуры, позволяющие разобраться какие стандарты и политика, если таковые вообще имеются, уже существуют в настоящее время. Это также позволяет высветить на первый план обнаруженные несоответствия и необходимые обновления или удалениях. Записи об изменениях и планы развития определяют будущее для категории на средний срок, в то время как стратегические планы бизнеса определяют требования для категории в долгосрочной перспективе.
Определенные стандарты и политика, становятся инструментами IE, используемые для того, чтобы прогрессировать от текущего до желательного состояния.
Что такое стандарт?
Стандарт обычно описывает объекты в пределах категорий. Стандарты устанавливаются властью, как модель, пример, или правило для компонентов инфраструктуры или категории. Например, стандарт для категории управления изменениями мог бы быть минимальной документацией, необходимой для RFC, включая формат представления. Стандарт для управления продажами мог быть шаблоном контракта, а стандарт для программного обеспечения COTS может определять минимальные требования для совместимости с другими продуктами компании. Типичные стандарты в пределах организации включают спецификации аппаратных средств и конфигурацию для серверов центра данных или настольных компьютеров. Пример стандарта сервера содержится в Приложении F.
Стандарты для каждой категории, вероятно, будут более многочисленными, чем политика для каждой категории, потому, что они являются более тактическими. Стандарты созданы, имея в виду текущую окружающей среду, и с прицелом на будущее. Например, стандартное требование для рабочего компьютера, могут принимать во внимание все то, что уже необходимо в настоящее время, однако могут также содержать функциональность беспроводной технологии, в том случае если информация от стратегической группы указывает на то, что эта технология будет развиваться в будущем. Стандарты обеспечивают структурированный подход, к эксплуатации, изменению, поддержке, и оптимизации категорий в инфраструктуры организации.
Что такое политика?
Политика отличается от стандарта тем, что политика является определенным принципом управления или методом действия, направляющим или определяющим настоящие и будущие решения. Политика создается, чтобы охватить общие цели и приемлемые процедуры организации. Политика может быть общекорпоративной, например, “Никакие политические электронные письма не будут отсылаться, используя корпоративные ресурсы,” или определенной для отдела, например, “Все заказы на поставку оборудования более чем на 20 000 $ должны быть одобрены генеральным директором.”
Политика в IE, в простых терминах, описывает процессы, применяемые в пределах категорий. Например, политика для процессов управления изменениями предписывает, как эти процессы используются в организации; политика по управлению продажами определяет, как процессы управления продажи используются в организации; и политика программного обеспечения COTS определяет, как использовать программное обеспечения COTS в организации. Эта политики связаны с категориями инфраструктуры, для которых они были определены и выполняют роль предопределенных действий управления для наилучшего контроля инфраструктуры. Политики создаются в соответствии с требованиями инфраструктуры в настоящее время и в будущем. Примеры типичной политики приводятся в Приложении D.
Определение лучших стандартов
Как описано выше, стандарты отвечают на следующие тактические вопросы для категории инфраструктуры: “Каковы принципы работы категории в нашей инфраструктуры, и как мы можем гарантировать, что функции в этой категории управляются и контролируются так, как мы ожидаем?”
Каждая категория, вероятно, с самого начала будет содержать множественные стандарты, например, безопасность требует стандартов для того, чтобы иметь дело с безопасностью пользователей, данных, сети, инфраструктуры, определенных решений и услуг, и определенных местоположений. Стандарты могут существовать уже в пределах SMF или других функций, уже развернутых в организации. Все эти стандарты выделяются во время фазы исследования; в этой фазе процесса, принимается решение, какие политики и стандарты, если таковые вообще имеются, будут сохранены или изменены. В некоторых случаях, похожие стандарты от дополнительных организаций могли бы быть слиты. В других случаях, специфическое местоположение может потребовать отдельного стандарта, который применялся бы в местном масштабе, хотя эти решения должны быть основанными на осторожном анализе, чтобы гарантировать, что несоизмеримый стандарт не приведет в конечном счете к дополнительным расходам и оверхедам. Таблица 3 показывает некоторые примеры стандартов, которые могут применяться в пределах категорий, связанных с Кластером Ролей Инфраструктуры MOF.
Table 3. Примеры стандартов для определенных инфраструктурных категорий
| MOF Кластер командных ролей | Инфраструктурная категория | Стандартные примеры |
| Инфраструктура | Управление персоналом | Описание работы и требования для отдельных позиций Модель премирования системных инженеров |
| Планирование ресурсов | Формат отчетов тестирования и приемки | |
| Управление мощностями | Стандартная топология тестирования мощностей; конфигурация агента MOM для отчета о производительности | |
| Управление непрерывности IT сервисов | Требования бэкапа для сервера почты и файлов спецификации оборудования для магнитных носителей |
Процесс исследования, возможно, определяет совокупность стандартов, применяемых в одной категории. В этом случае, ключевые участники должны определить какие из них являются лучшими стандартами, чтобы примениться сейчас и в будущем. Также вероятно обнаружит промежутки, где стандарты и политика в настоящее время не существуют, но были бы желательны. Такие стандарты должны создаваться экспертами предмета в этой области с привлечением практических советов и лучших известных методов и деловой стратегии для использования данной категории инфраструктуры.
Microsoft IT и стандартные серверные платформы
В некоторых случаях, стандарты применяются не как ряд спецификаций, но как полное ориентируемое на клиента решение. Например, внутренняя ИТ организация Microsoft приняла эффективный подход к стандартизации центров данных. Через недавнюю инициативу стандартов платформы, группа IT развивает, тестирует, и поставляет, стандартизированные платформы, основанные на сервере Microsoft под названием IPAKs (Служебные пакеты IT Microsoft). Они созданы как для Сервера Windows Microsoft ™ 2003, так и для Сервера SQL. IPAKs выпускаются каждые пол года, и объединяют текущую версию программного обеспечения сервера со всем потоком hotfixes и апгрейдами. Эти конфигурации полностью проверены группой IT и обеспечивают полную надежность после установки. Для клиентов, это значительно уменьшает сложность регулярного обновления.
IT Microsoft предлагают скользящий масштаб поддержки внутренним клиентам Microsoft, в зависимости от уровня, на которомуклиент принял стандарты IPAK. Между выпусками, IT Microsoft обеспечивают полную поддержку клиентов, управляющим любым из двух новых выпусков IPAK. Старшие версии поддержаны по принципу "лучшего усилия".
Исправления и установки в промежуточный период между выпусками IPAK, объединены в последующие выпуски IPAK. Пользователи могут ждать до нового выпуска IPAK или могут включить одобренные автономные обновления в их собственный сервер. В любом случае, группа IT обеспечит полную поддержку в полном соответствии с соглашением уровня обслуживания.
В любом случае, стандарты создаются в соответствии с рекомендациями от функциональных экспертов области, групп ролей Модели Команды MOF, полагаясь на независимые тесты, где это возможно, а так же на потребности бизнеса и затраты. Никакой элемент инфраструктуры не существует в одиночку; каждый стандарт должен принимать во внимание взаимодействующие инфраструктуры в рамках стратегической картины. Таким образом, все элементы инфраструктуры эффективно соединяются для поддержки бизнеса, дополняя и усиливая его.
Определение лучшей политики
Как уже упомянуто выше, политики должно определяться меньше чем стандартов в данной категории, так как политика имеет тенденцию работать на более высоком уровне чем больше стандартов. Иногда необходима больше чем одна политика для данной категории, например, там где множественные области в пределах одной организации используют различных стратегических партнеров для продукта, могла бы быть различная политика для проведения закупок в каждой из областей. Точно так же географически отделенные ветви могут требовать, чтобы различная политика чтобы приспособиться к изменениям в правительственных инструкциях или эксплуатационных требованиях. Тем не менее, цель состоит в том, чтобы создать объединенный и стратегический набор решений и слишком большое разнообразие в политике не должно поощряться, так как это могло бы затронуть потенциальные снижения затрат и воспроизводимость решения.
В определении лучшей политики для организации, нужно рассмотреть следующие моменты:
· Существующая политика и документация
· Новая информация, которая могла бы стать доступной через процессы управления изменениями или инициативы развития
· Стратегическая информация для долгосрочного плана
· Информация и рекомендации от экспертов предмета, внутренняя и иногда внешняя
· Другие SMF или ролевые группы, которые, возможно, должны быть информированы
Посредством консолидации и сопоставление всей этой информации IT SMF, создает наилучшую-пригодную политику для контроля категории или частей категории. Лучшее-пригодное решение должно отражать следующее:
Бюджет: оправдание и одобрение затрат.
Шкала времени: Настоящее и будущее.
Потенциал рисков и проблемы выбора политики.
Технология: Воздействия на категорию, для которой предназначаются, и на другие связанные технологии в пределах инфраструктуры.
Люди: навыки и ресурсы, доступные для развития, внедрения, и поддержки определенной политики; выгоды людям от использования политики; и то как люди будут реагировать на политику.
Процесс: процесс или процессы, к которым применяется политика и которые взаимодействует с другими процессами.
Процесс принятия решения для определения лучшей политики может использовать любые стратегические инструменты и методы принятия решения, находящиеся в распоряжении организации. Table 4 provides examples of some specific standards and policies that might be implemented within operations categories. Similar tables should be developed to plan the development of standards and policies in the other categories established for your organization.
Table 4. Примеры политик
| MOF Ролевой кластер команд | Категория инфраструктуры | Примеры политики |
| Operations | Сетевое администрирование | Объявления о профилактике Использование компьютеров в личных целях Назначение IP адресов Обработка проблем Закупка оборудования |
| Расписание работ | Применение расписания работ | |
| Управление хранением данных | Поддержка хранения данных Соглашения об именах файлов |
Уровень усилия, примененного для развития политики, отражает важность ее категории. Например, политика для высококлассной категории, типа целостности данных в пределах организационной структуры банка, будет требовать точного определения, может быть очень сложна, и будет требовать участия ответственных сторон отовсюду из организации. Это должно включать вклады от юридических отделов по официальным требованиям и от технического штата относительно возможностей обеспечить безопасное решение. Эта политика будет критической для всей организации. Она должно тщательно анализироваться на предмет затрат, чтобы гарантировать соответствие будущими стратегиями, и должна быть одобрена на очень высоком уровне. С другой стороны, рассмотрим политику связанную с процессом избавления от старых картриджей: это, едва ли потребует того же самого участия, хотя все равно может быть эффективно в затратах для организации в случае, если исследованы все возможности переработки и снижения стоимости. Если организация использует лучшее-пригодное решение, стратегический планирование, и оценку выгоды и затрат для выбора политики в каждой категории, организация должна получить долговременное, простое в использовании, в наивысшей степени поддерживаемое, и самое удобное в использовании решение с наилучшими функциональными возможностями. Создание и использование политики в окружающей среде инфраструктуры, вероятно, приведут к реализации, по крайней мере, некоторые, если не всех, из следующих выгод:
· Больше интегрированного стратегического планирования и сокращения постепенных контрактов.
· Лучшее принятие решения в закупке продуктов с разумными сроками годности.
· Лучшее соотношение цены и качества вложений.
· Лучше управление затратами через эффективные покупки и использование стратегических поставщиков для решения задач всего предприятия.
· Лучшее удержание квалифицированного штата, таким образом уменьшая затраты на обучение и рекрутинг.
· Улучшенная последовательность в выборе инфраструктуры. Более адекватное использование ресурсов инфраструктуры.
· Усовершенствование обслуживания через интеграцию политики управления обслуживания.
· Более высокое доверие обслуживанию и удобству использования.
· Меньшее усилие, требуемое в администрации.
· Упрощенное и повторяемое развертывание.
· Более-интегрированные приложения.
Публикация стандартов и политик для категорий
Определенные стандарты и политика только в том случае полезны для организации, если они доступны и легко понимаемы. Поэтому следует найти самый эффективный метод для того, чтобы издавать и предавать гласности стандарты и политику всем заинтересованным потенциальным клиентам. Обычным средством для публикации стандартов и политики является широко разрекламированный внутренний Вебсайт или база данных. Для того чтобы достичь максимальной выгоды от этого типа ресурса, нужно понимать, что потенциальная аудитория включает нетехнических деловых пользователей и представлять содержание в Сети так, чтобы все пользователи могли легко понимать это. Альтернативой Вебсайту может быть доступная в интернете база знаний. В случае MSN, был построен специальный интранет сайт, который не только издает одобренные стандарты, но и управляет процессом изменения для предложения, одобрения, и применения новых стандартов.
Другими альтернативами для публикации стандартов остаются распространение бумажной копии или компакт-дисков/DVD. Для всех механизмов распределения, решающее значение имеет синхронизация изданного содержания с текущей версией стандартов и политики, записанной в CMDB. Если не налажены прямые связи с CMDB для обновления содержания Вебсайтов или баз данных, то необходимо обеспечить регулярное ручное или полуавтоматическое обновление: это можно делать еженедельно, ежемесячно, или ежеквартально в зависимости от количества сделанных изменений.
Создавая стандарты и политику, доступную для всей организации, Вы создаете открытую арену и минимизируете риски, часто связанные с нехваткой понимания определенных системных требований. Также устанавливаются требования для интерфейсов среди других систем в пределах инфраструктуры. Полезно отметить, что неадекватная информация очень распространена в организациях; в этих условиях стандарты и политика представляют достоверную информацию, обнародование которой требуется людям. Как только стандарты и политика опубликованы, они, вероятно, будут широко использоваться, что, в свою очередь, делает будущие обновления и изменения, в стандарты и политику еще более вероятными.
Добавление стандартов и политики в CMDB
Как только стандарты и политика определены и приняты для публикации, они должны быть добавлены к CMDB. Это гарантирует, что зарегистрированные стандарты и политика находятся под тем же самым контролем изменения как любой другой пункт конфигурации; это также означает, что они подвергаются стандартному процессу обзора для CI.
Выгода добавления стандартов и политики к CMDB не заканчивается контролем изменения. Это позволяет обозначить отношения и связи с другими стандартами и политиками, так что эти связи могут быть применены к другому CI. Это смягчает риск обособленного действия, возможного, например, со стандартом, который может затронуть все секции политики инфраструктуры. Это демонстрирует лучший контроль над инфраструктурой и показывает выгоду принятия полного подхода управления обслуживания к организации IT.
CMDB доступен в формате только для чтения для большинства пользователей (за исключением менеджера конфигурации и администратора, которые сохраняют полные привилегии). Если CMDB является простым в обращении и понятным для бизнеса, может и не иметь смысла публиковать стандарты и политики; вместо этого, можно обеспечить доступ к CMDB всем, кто нуждается в этом. Однако, если CMDB сложен в работе, стандарты и содержание политики можно связать с интранетом или другим легко доступным источником. Это дает особую выгоду для бизнеса и организаций средств обслуживания, поскольку они, возможно, нуждаются в благоприятной для бизнеса, нетехнической ссылке на стандарты и политику, для применения в руководстве бизнес проектах и средств обслуживания.
Заключение
Следующий список суммирует важнейшие элементы этого раздела:
· Обеспечьте приоритет определению политик и стандартов на основе обеспечения максимальной выгоды для организации. Успехи в начали пути увеличивают доверие к этой работе.
· Изучите текущую инфраструктуру, включая текущие стандарты и политики, для использования в будущем.
· Рассмотрите планы и стратегии будущих проектов и инициатив, чтобы предотвратить раннее устаревание стандартов и политик.
· Сложность определения стандартов и политик связанно с их сложностью и потенциальным эффектом на организацию.
· Полагайтесь на соответствующие роли и SMEs в разработке стандартов и политики.
Применение стандартов и политики для управления инфраструктурой
Как правило, предложенные изменения развития или развертывания будут находиться в пределах норм установленных стандартов и политики; в настоящем разделе описан процесс, посредством которого они применяются. Однако существуют случаи, когда предложенное изменение требует специальных рассмотрений, приводящих к исключению для установленных стандартов и политики. В дополнение к обычному процессу, в этом разделе более подробно исследуются случаи возникновения этих исключений, а также действия, которые могут быть предприняты менеджером по техническому обеспечению для того, чтобы иметь дело с исключениями при их возникновении. На рисунке 10 показан обычный процесс применения политики и стандартов и отмечено, где исключения для процесса переходят к отдельному циклу задачи.
| Подписи к рисунку: Complete full plan applying standard and policy - Выполнение полного плана, применяющего стандарт и политику Propose infrastructure change - Предложение изменения инфраструктуры Yes - Да Review applicable standards or policies - Обзор применимых стандартов и политик Is this an exception? - Является ли это исключением? No - Нет Exception Process - Процесс исключения Apply standard or policy to change or requirement - Применение стандарта или политики для изменения или требования Full plans required? - Требуются полные планы? Complete high-level plan applying standard and policy - Выполнение плана высокого уровня, применяющего стандарт и политику |
Рисунок 10. Использование политики и стандартов для управления инфраструктурой
Предложение изменения инфраструктуры
Предложенные изменения инфраструктуры могут возникать вследствие различных причин. Microsoft solutions framework (MSF) предоставляет значительную информацию относительно процесса составления новых проектов развития и развертывания. С укреплением проектных планов группа должна рассмотреть, какие сервисы и компоненты инфраструктуры будут затронуты, и идентифицировать применимые категории стандартов и политики, на которые необходимо ссылаться.
Например, для новых проектов и инициатив развития будут применяться стандарты и политика после оценки их ограничений и возможности в контексте разработки их новых решений. Для различных средств может возникать необходимость проверки требований к минимальной мощности или политике безопасности в отношении определенных категорий инфраструктуры. Любые изменения, добавления, удаления или новые события и проекты должны будут использовать стандарты и политику для затрагиваемой ими категории инфраструктуры.
Предложенные изменения ИТ инфраструктуры осуществляются по предписанному в MOF процессу, как это описано в MOF SMF "Управление изменениями". В ходе выполнения предложенных изменений посредством данного процесса, они управляются принципами MSF для управления проектом, а также руководящими принципами MOF для гарантии того, что они будут функционировать в производственной среде. Оценка инициирования изменения MOF, основной этап MOF, является первой запланированной оценкой предложенных изменений и используется для того, чтобы гарантировать, что эти изменения соответствуют утвержденным стандартам и политике. Оценка инициирования изменения представляет собой одну из четырех Оценок управления эксплуатацией, которые более подробно описаны в документе Модель процесса MOF, доступном по адресу http: // www.microsoft.com/mof.
Оценка применимых стандартов или политики
После рассмотрения изменения инфраструктуры, к применимым политике или стандартам можно обратиться из CMDB, через IE менеджера или, что более вероятно, посредством опубликованного источника (например, вэб-страница интранета). В некоторых случаях помощь в применении стандарта для предложенного изменения могут оказать IE менеджер или определенный SME.
Является ли это исключением для стандарта или политики?
Что такое исключение? Исключение - это процесс, событие или приобретение, для которых не применяются установленные правила. Они должны возникать редко, поскольку IE менеджер гарантировал получение данных от групп изменения, развития и стратегии в течение процесса определения политики и стандартов, но могут иметь место такие ситуации, когда может произойти реальное исключение. В этом случае будет выполняться процесс исключения, показанный ниже на рисунке 11.
Применение стандарта или политики для изменения или требования
Если предложенное изменение инфраструктуры не является исключением, то процесс продолжается с интегрированием определенных стандартов в требования для предложенного изменения. Независимо от характера изменения и его возможного приложения, оно должно соответствовать стандартам и политике, установленным для данной категории инфраструктуры, несмотря на исключения.
Требуется полный план или план высокого уровня?
Степень, с которой политика и стандарты включаются в потенциальное изменение, полностью зависит от характера изменения и его релевантности возможностям регулируемой инфраструктуры. Если это изменение является незначительным или стандартным, то может потребоваться только утверждение управлением изменениями, которое подтверждает, что были использованы стандарты и политика, аналогично подтверждению того, что имела место консультация с CMDB для оценки воздействия любого предложенного изменения. Однако в случае большого изменения или проекта развития, стандарты или политика могут содержать определенные элементы разработки, конструкции или обработки, которые должны дублироваться в проектных планах.
Результаты консультации будут состоять в том, что изменение, добавление или развитие будут в действительности планироваться согласно стандартам и политике в SMF IE, хотя данная контрольная точка фактически происходит вне этой SMF в Оценке инициирования изменения.
Исключения для стандартов или политики
Как уже было сказано выше в этом разделе, существуют ситуации, в которых установленные стандарты и политика, возможно, не применяются непосредственным образом. Они являются исключениями. Хотя организация может утвердить набор стандартов или определить политику для конкретного процесса или объекта в зависимости от стадии его возникновения в жизненном цикле (например, MSN с его набором стандартов для новых, текущих и прежних технологий), иногда организация должна также установить процедуры обработки исключительных ситуаций в соответствии с принятыми стандартами и политикой.
На рисунке 11 показана блок-схема процесса, которая отражает лучшую методику обращения с исключениями, взятую из процесса MSN.
| Подписи к рисунку: Exception to standard or policy arises - Возникает исключение для стандарта или политики Is exception a result of new strategy? - Является ли исключение результатом новой стратегии? Yes - Да No - Нет Confirm strategy for infrastructure category - Подтверждение стратегии для категории инфраструктуры Is the strategy a valid exception? - Является ли стратегия допустимым исключением? Is it a valid exception on other grounds? - Существует ли допустимое исключение на других основаниях? Is it cost justified? - Являются ли исключение оправданным по затратам? Approve exception? - Исключение утверждено? Does it affect other standards or policies? - Влияет ли оно на другие стандарты или политику? Update affected standards or policies - Обновление затронутых стандартов или политики Publish standard or policy and update CMDB - Опубликование стандарта или политики и обновление CMDB Return exception to initiator - Возвращение исключения инициатору |
Рисунок 11. Процесс исключения
Возникновение исключения для стандарта или политики
Когда возникает исключение, то существует требование, которое не укладывается в рамки правил, указанных в существующих политике и стандартах. То, почему предложенное изменение является исключением, должно быть подтверждено до того, как может быть предпринято действие. Как было сказано выше, если IE SMF выполняется эффективно, а для организации были созданы прочные связи с другими SMF и группами бизнеса, развития и стратегии, то исключения должны являться редкими. В некоторых случаях исключения могут развиться в новые политику или стандарты в результате прогресса ИТ инфраструктуры на протяжении ее жизненного цикла.
Действительно ли исключение является результатом новой стратегии?
Если существует новое стратегическое направление, то оно должно показываться посредством связей между IE менеджером и соответствующей группой стратегии бизнеса. Могут иметь место случаи, когда изменение в стратегии не могло бы быть идентифицировано прежде, чем понадобится изменение.
Например, слияние или приобретение компании или же предложение о поглощении компании путем скупки акций на рынке могут затронуть политику и стандарты и изменить требования. Политическая или юридическая проблема также может привести к исключению, если содержание новой инструкции не было раскрыто до ее опубликования. Экономические и политические изменения, являющиеся внешними для организации, могут изменить политику, например, изменение обменных курсов может затронуть заграничные сервисы третьих лиц, а энергозависимый политический климат может повлиять на импорт и экспорт продуктов или сервисов.
Подтверждение стратегии для категории инфраструктуры и ее утверждение
Если исключение предлагается в качестве новой стратегии организации, то оно должно быть подтверждено представителями правления, экспертами по данному вопросу и соответствующими SMF (если требуется) и утверждено как реальное исключение существующих политики и стандартов. Если исключение оказывается недопустимым при подтверждении на более высоком уровне, то оно возвращается инициатору с объяснением причины его непринятия в качестве изменения стратегии. Могут иметь место другие причины того, почему исключение должно быть принято, но они должны быть повторно представлены IE менеджеру после отклонения правлением.
Является ли исключение допустимым на других основаниях?
Даже если запрос на исключение не является результатом направления новой стратегии, то могут иметь место другие причины для его допущения. Например, поставщик третьей стороны или партер, привлекающий третьих лиц для выполнения работ, могут выйти из бизнеса, оставив в поддерживаемой инфраструктуре разрыв, который нужно быстро ликвидировать для гарантии непрерывности сервиса. Для новой стратегии изменения могут произойти вне организации на юридическом, социальном, политическом или экологическом основании, которые не были предвидены и которые могут составить реальную причину для назначения исключения политике или процедурам инфраструктуры. На безопасность может повлиять новый вирус, а программа-заплатка, полученная от нестандартной организации, может смягчить риск. Другой пример: если реализуется требуемая новая технология, то может понадобиться новая лаборатория для работы с данной технологией, прежде чем существующие стандарты могут быть изменены, для того чтобы отразить необходимые изменения в архитектуре или требованиях к оборудованию. В этом случае, новые требования к оборудованию, лежащие за рамками существующих стандартов, могут также потребовать исключений в отношении политики приобретения и поставщиков, если оборудование не доступно при использовании установленных каналов.
Является ли исключение оправданным по затратам?
Даже если исключение является новой стратегией или экстренным исключением для существующих политики и стандартов, то все еще необходимо оценить оправданность затрат. Выгоды от допустимого исключения должны превосходить потенциальные затраты не только в отношении бюджета но также и в потенциальном риске для инфраструктуры, вызванным уходом за рамки установленных стандартов и политики. Оценка оправданности затрат выполняется аналогично тому, как это осуществлялось на начальных стадиях определения политики и стандартов, хотя она может быть быстро отслежена, если требуется, ключевыми лицами, оценивающими исключение и использующими кворум для его утверждения.
Утверждение исключения
Если исключение оправдано по затратам и принято ключевыми лицами для данной категории инфраструктуры, SMF или группы ролей, то оно может быть утверждено. Исключение может все еще нуждаться в утверждении бюджета на уровне правления для его реализации, и должно быть определено, необходимо ли обновление любых существующих стандартов или политики для отражения изменений, введенных исключением. Для исключения должна быть также назначена эффективная продолжительность, с тем, чтобы установить, насколько долго оно может использоваться и когда его следует переоценивать для рассмотрения в качестве стандартного или же для отмены. Этот процесс может быть быстро-отслеживаемым, но важно отдавать себе отчет в том, что любые вводы для экстренного исключения сейчас так же важны, как и во время создания исходных стандартов и политики. Ключевым лицам необходимо рассмотреть требование исключения и оценить, насколько оно соответствует текущей среде инфраструктуры и как оно затронет другие будущие стратегии, изменения и развития.
Влияние на другие стандарты или политику
Если в результате исключения разработана новая политика или стандарт, то необходимо воспользоваться CMDB для обращения к связанным стандартам или политике, а также к другим категориям инфраструктуры, которые могут применяться для исключенных политики или стандартов. Исключение совершенно не обязательно должно привести к обновлению стандарта или политики. Оно может быть одноразовым изолированным событием. Однако исключения могут, в конечном счете, потребовать, чтобы применимые стандарты были переписаны, а политика была пересмотрена. Например, политика использования определенного поставщика была бы изменена в том случае, если бы было потеряно доверие к этому поставщику, или же если поставщик оказался неспособен поставить продукцию без дополнительных затрат из-за различных местных причин.
Большинство воздействий, посредством которых возникают исключения, вероятно, будут внешними для организации; в противном случае их основная причина может обнаруживаться внутри взаимосвязей по оценке, изменению, развитию и стратегии, которые IE менеджер организовал с другими областями.
Опубликование стандарта или политики и обновление CMDB
Обновленный стандарт или политика публикуются, а CMDB обновляется новой версией, включая обновления связанных стандартов и политики инфраструктуры, которые, возможно, были вызваны изменением. Изменения CMDB должны выполняться согласно установленному порядку.
Итог
В приведенных ниже пунктах подводится итог важных моментов, обсуждаемых в настоящем разделе:
Поддержка стандартов и политики
В предыдущем разделе было описано, как стандарты и политика применяются к изменениям, которые происходят в ИТ среде. В настоящем разделе описано, как необходимо управлять стандартами и политикой. Стандарты и политика хранятся как конфигурационные единицы (CI) в CMDB; при изменении стандарта они будут подвержены процессу изменения, используемому для других изменений CMDB, как это описано в руководстве MOF для SMF "Управление изменениями" и "Управление конфигурациями". Однако процесс оценки стандартов и политики представлен здесь с дополнительными деталями для содействия эффективной поддержке собранных стандартов и политики.
Стандарты и политика для каждой из категорий инфраструктуры должны регулярно оцениваться. Оценки могут выполняться на основе изменения существующих стандартов и политики, типично ежедневному развитию организации, но важно также анализировать стандарты и политику, которые не были выделены или оспорены другими изменениями или проектами развития. График проверки категорий индивидуален для каждой организации и может составляться ролевым кластером, ответственным за ввод политики или стандарта, или же областью, имеющей наиболее тесную связь с категорией для стандарта. Например, стандарты и политика, касающиеся безопасности, будут оцениваться посредством SMF Администрирование безопасности и ролевым кластером Безопасность, а стандарты и политика группы поддержки будут оцениваться ролевым кластером Поддержка и, более конкретно, посредством SMF Служба поддержки.
Процесс оценки показан на рисунке 12.
| Подписи к рисунку: Review current infrastructure category standard or policy - Оценка текущих стандартов, политики или категорий инфраструктуры Review development projects, and changes for category - Оценка проектов развития и изменений для категории Review strategy and planning for category - Оценка стратегии и планирования для категории Any changes to policy or standard? - Имеются ли изменения политики или стандарта? Yes - Да No - Нет Update changes to standard or policy for category - Обновление изменений стандарта или политики для категории Update status of standard or policy - Обновление состояния стандарта или политики Publish reviewed standard or policy and add to CMDB - Опубликование оцененного стандарта или политики и добавление в CMDB |
Рисунок 12. Поддержка стандартов и политики
Оценка текущих стандартов, политики или категорий инфраструктуры
Полезно периодически оценивать существующие стандарты, политику и категории инфраструктуры, а также составлять по ним отчеты. Если политика и стандарты были подвергнуты большим изменениям и многочисленным исключениям, то полезно выполнить переоценку для определения того, являются ли они все еще уместными для организации и, если нет, то где недостатки в процессах связи привели к несоответствию. Могут существовать политика и стандарты, являющиеся недоступными или неиспользуемыми, и это может указывать на то, что они не добавляют реальную выгоду посредством их включения в модель IE управления. В этот момент полезно также проверить соответствие в пределах инфраструктуры с опубликованными стандартами, используя такие инструментальные средства как Microsoft Systems Management Server (SMS) 2003. Внезапное снижение соответствия может указывать на принятие нестандартного исправления или, возможно, на внедрение бета-версии продукта до принятия продукта в качестве стандарта. Такие оценки полезны в качестве “проверки действительности” для содержания и могут выполняться либо на запланированной основе, либо когда ролевые кластеры "Групповая модель" считают это действие соответствующим.
Оценка проектов развития и изменений для категории
С развитием SMF IE в пределах организации должны развиваться связи с функцией ИТ развития, функцией управления проектом и SMF Управление изменениями. В результате оценки этапа развития проекта должны возникнуть некоторые неожиданности, поскольку все проекты будут использовать существующие политику и стандарты для работы в процессе санкционирования изменений. Следует, однако, отметить, что если какие-либо неожиданности действительно происходят на конвейере будущих изменений и развития инфраструктуры, то это указывает на то, что, возможно, должны быть улучшены каналы связи между ответственными сторонами. Меры для этого должны быть предприняты как можно скорее, иначе организация не сможет извлечь выгоду из интегрированного подхода управления сервисом, в который она инвестировала время и ресурсы.
Оценка стратегии и планирования для категории
Как и для связи развития и изменения, должны иметь место некоторые неожиданности, являющиеся результатом стратегического планирования инфраструктуры, если IE менеджер успешно получил одобрение старшей группы и группы стратегии в отношении ценности SMF IE. Если IE процессы воспринимаются как ценные, то группа планирования стратегии должна не только их использовать, но также требовать создания новых политики и стандартов. Информация, сохраненная посредством SMF IE, может показывать стратегам, где существуют корпоративные области потенциального многократного использования, где в организации постоянно имеются различные навыки и каковы их текущие ИТ возможности. Все это может использоваться для создания рентабельных стратегий управления средой инфраструктуры. Важно помнить о том, что связь между стратегами бизнеса и IE группой должна быть двухсторонней, с предоставлением информации и руководством в обоих направлениях.
Имеются ли изменения политики или стандартов?
Если после выполнения оценки имеются изменения стандартов или политики, то эти изменения должны быть инициализированы и подвержены процессу управления изменениями для конфигурационных единиц и CMDB.
Обновление изменений стандарта или политики для категории
После того, как изменения будут разрешены и запланированы, они могут быть развернуты в соответствии с процессом управления изменениями и обновлены в CMDB.
Обновление состояния стандарта или политики
В CMDB должно быть обновлено состояние конфигурационной единицы для стандартов и политики. Предлагаемым состоянием стандартов и политики, измененных в результате процесса оценки, является "Оцененный"; рекомендуется, чтобы другие индикаторы состояния стандартов и политики соответствовали уже используемым в CMDB, например: "Текущий", "Удаленный" и "Исключение".
Опубликование оцененного стандарта или политики и добавление в CMDB
Любая оцененная политика повторно публикуется для ролевого кластера Групповая модель и для других пользователей, которые могут ее использовать. Если политика или стандарт используются регулярно и были изменены, то для регулярных пользователей важно отметить изменения, с тем, чтобы избежать любого непреднамеренного использования старого стандарта или политики.
Итог
В приведенных ниже пунктах подводится итог важных моментов, обсуждаемых в настоящем разделе:
Роли и обязанности
В настоящем разделе рассматриваются различные роли и обязанности в пределах SMF "Техническое обеспечение". Важно отметить, что роли обозначают здесь группы задач, которые должны выполняться, и не обязательно соответствуют названиям организационных работ или определенным лицам. Большинство работ по установлению стандартов, управлению ими, а также по контролированию этих стандартов в пределах инфраструктуры, будут проводиться ролевым кластером Инфраструктура MOF, с селективным использованием виртуальных групп.
Менеджер по техническому обеспечению
IE менеджер обладает координирующей ролью в SMF IE, по аналогии с ролью менеджера по изменениям в SMF Управление изменениями. Данная роль включает в себя принятие определенного технического решения для утверждения и отклонения стандартов и политики, но обычно IE менеджер не должен являться технически осведомленным обо всех областях инфраструктуры. Несмотря на то, что ИТ инфраструктура и технические навыки должны являться допустимыми квалификациями для этой роли, основной навык IE менеджера - это способность получить наилучшую информацию от групп ввода, экспертов по проблеме, ролевых кластеров Групповая модель, а также групп бизнеса и стратегии для того, чтобы прийти к согласию по наилучшему решению для бизнеса.
Для эффективного функционирования в таком обширном массиве групп и обязанностей, роль IE менеджера должна находиться на правильном уровне управления, для того чтобы быть услышанным и уважаемым в пределах организации - подобно бизнес-организациям и организациям по развитию. Лица, занимающие эту роль, должны обладать полномочием отклонения нестандартных изменений инфраструктуры или проектов развития, или же, по крайней мере, иметь определенный путь эскалации к старшим членам ИТ исполнительного комитета, если они не имеют самостоятельных полномочий. На приведенном ниже рисунке показаны ролевые кластеры Групповая модель MOF.
| Подписи к рисунку: Security - Безопасность Intellectual property protection - Защита интеллектуальной собственности Network and system security - Сетевая и системная безопасность Intrusion detection - Обнаружение вторжения Virus protection - Антивирусная защита Audit and compliance administration - Ревизия и администрирование соответствия стандартам Contingency planning -Планирование непредвиденных ситуаций Release - Релиз Change Management - Управление релизами Release Engineering - Разработка релиза Configuration control / asset management - Контроль конфигурации / управление активами Software distribution / licensing Распределение программного обеспечения / лицензирование Quality assurance - Проверка качества Service - Сервис SLA drafting/negotiation - Составление SLA / переговоры Service catalog management - Управление каталогом сервисов SLA review - Оценка SLA Service improvement initiation - Инициирование улучшения сервиса Customer relationship management - Управление отношениями с клиентом Service level management - Управление уровнем сервиса Infrastructure - Инфраструктура Enterprise architecture Infrastructure / systems engineering - Инфраструктура архитектуры предприятия / системное проектирование Capacity management - Управление мощностью Cost / IT budget management - Затраты / Управление ИТ бюджетом Resource and long-range planning - Ресурсы и долгосрочное планирование Support - Поддержка Service desk / help desk - Служба поддержки / справочная служба Production / production support - Продукция / поддержка продукции Problem management - Управление проблемами Service level management - Управление уровнем сервиса Operations - Эксплуатация Messaging operations - Эксплуатация передачи сообщений Database operations - Эксплуатация базы данных Network administration - Администрирование сети Monitoring / metrics - Мониторинг / метрики Availability management - Управление доступностью Partner - Партнер Managed service outsourcers - Управляемые внешние сервисные компании Software / hardware suppliers - Поставщики программного / аппаратного обеспечения Maintenance vendors - Поставщики обслуживания Environment support - Поддержка среды Training partners - Партеры по обучению |
Рисунок 13. Ролевые кластеры Групповая модель MOF
Ролевой кластер Инфраструктура
Ролевой кластер Инфраструктура имеет качественную цель “управления физическими средами и инструментальными средствами инфраструктуры”.
Роли в пределах этого кластера могут выполнять многие из задач, рассмотренных в настоящем руководстве по SMF. Политика или стандарты в пределах конкретной категории инфраструктуры обычно будут назначаться своей соответствующей области ответственности. Например, стандарты и политика, созданные для элементов хранения данных в инфраструктуре, будут являться частью категории хранения данных, а ответственность за ввод, обслуживание и обновление стандартов будут нести лица, активно вовлеченные в SMF Управление хранением данных и ролевой кластер Эксплуатация.
Связи с другими SMF
В этом разделе исследуются связи между SMF Техническое обеспечение и другими SMF в MOF.
Квадрант изменений
В Квадранте изменения имеются три SMF; SMF IE обеспечивает ключевой ввод в каждую из них:
Здесь полезно взглянуть на диаграмму (рисунок 14), приведенную в начале настоящего документа для иллюстрации связи между Квадрантом изменения и IE. SMF IE контролирует технические действия в пределах инфраструктуры, SMF Управление изменениями управляет средой инфраструктуры, а SMF Управление конфигурациями документирует используемые стандарты и политику.
Подписи к рисунку:
Guides and Regulates - Выдает указания и инструкции
Infrastructure Engineering - Техническое обеспечение
Policy - Политика
Standards - Стандарты
Manages - Управляет
Change Management - Управление изменениями
Рисунок 14. Связь SMF Техническое обеспечение с SMF Управление изменениями и CMDB
Управление изменениями
SMF Управление изменениями имеет тесную связь с SMF IE. Процесс санкционирования изменений, описанный в SMF Управление изменениями, стал формализованным в OMR Оценка инициирования изменений в MOF версии 3. Этот процесс, достигающий кульминации в формальной оценке, требует, чтобы инициатор изменения выполнил запрос на изменение в соответствии с требованиями для изменения данного типа и категории инфраструктуры. Для любого изменения, RFC должен либо применить существующие политику и стандарты для документации изменения, представленной в Оценке инициирования изменений, либо следовать процессу исключения. Даже исключения должны следовать процессу управления изменениями и также иметь важную общую связь с SMF Управление изменениями.
Сам по себе процесс управления изменениями является политикой. Изменения этой политики должны пройти через управление изменениями. SMF Управление изменениями обеспечивает ввод в SMF IE в терминах будущих изменений, которые могут находиться в развитии, поскольку они могут затрагивать определяемые стандарты и политику. В дополнение к этому непосредственно связанному вводу, SMF Управление изменениями будет определять конкретные стандарты и политику. Их создание формулируется посредством SMF Управление изменениями, но их согласование, администрирование и совмещение с другими SMF координируется с помощью SMF Техническое обеспечение.
Управление конфигурациями
Как показано на приведенном выше рисунке 14, SMF Управление конфигурациями хранит стандарты и политику IE в виде конфигурационных единиц в CMDB и гарантирует, что они находятся на том же самом уровне контроля и управления изменениями, что и другие конфигурационные единицы. CMDB является ключевым источником информации для SMF IE во время действий по установке, и они оба используются в сочетании друг с другом для подготовки RFC для санкционирования изменений. CMDB хранит всю информацию относительно категорий инфраструктуры, поставляемых сервисов и возможностей индивидуальных компонентов сервиса, и поэтому таким является ценным источником информации в определении возможностей и размаха среды инфраструктуры.
Она также облегчает, посредством своих относительных возможностей, отображение связей между категориями инфраструктуры, политикой и стандартами.
Управление релизами
SMF Управление релизами вносит свои собственные стандарты и политику в информацию относительно технического обеспечения по следующим категориям, помимо прочих:
Оценка готовности релиза
Эта оценка, являющаяся кульминацией процесса управления изменениями, применяет стандарты и политику технического обеспечения для подтверждения того, что в развитии релизов и изменений использовались текущие и соответствующие стандарты и политика по созданию и стандарты по релизам для различных категорий инфраструктуры.
Квадрант эксплуатации
В Квадранте эксплуатации имеются семь SMF; каждая из них вносит ценный вклад в стандарты и политику в SMF Техническое обеспечение. Все эти SMF используют стандарты и политику в своей эксплуатации среды инфраструктуры для гарантии того, что она эксплуатируется под контролем. К SMF Квадранта эксплуатации относятся:
· Системное администрирование.
· Мониторинг и контроль сервисов.
· Администрирование сети.
· Администрирование сервиса каталогов.
· Администрирование безопасности.
· Управление хранением данных.
· График работ.
Системное администрирование
SMF Системное администрирование вносит вклад в стандарты и политику SMF Техническое обеспечение в отношении повседневных административных сервисов, поддерживающих функциональность среды инфраструктуры и бизнеса. SMF Системное администрирование управляет другими SMF в Квадранте эксплуатации, а также обладает координирующей ролью в использовании стандартов и политики во время эксплуатации. В то время как SMF Техническое обеспечение в значительной степени ответственна за то, чтобы ИТ стандарты и политика использовались в разработке новых добавлений или изменений для инфраструктуры, SMF Системное администрирование выполняет подобную роль в их использовании для повседневной эксплуатации.
Менеджер системного администрирования играет ключевую роль в определении того, как в рамках среды инфраструктуры обеспечиваются и выполняются сервисы администрирования, например, определяя, является ли стандарт централизованным администрированием, удаленным администрированием, делегированным администрированием или же распределенным администрированием.
SMF Системное администрирование также использует ввод задокументированных стандартов и политики из других SMF, ролевых кластеров и категорий инфраструктуры для гарантии интеграции и эффективности своих собственных решений системного администрирования.
Мониторинг и контроль сервисов
Посредством использования процессов и технологии, SMF Мониторинг и контроль сервисов (SMC) позволяет эксплуатационному персоналу следить за состоянием ИТ сервиса в режиме реального времени. SMC создает и использует политику для мониторинга доступных сервисов и гарантирует контроль этих сервисов в пределах среды инфраструктуры. Такая активность добавляет реальную ценность функции бизнеса. Стандарты и политика, используемые SMC в функции мониторинга, включают, помимо прочего:
Она также использует стандарты и политику, связанные с другими категориями инфраструктуры для того, чтобы планировать будущие требования, изменения, и улучшения SMC.
Дата добавления: 2015-10-29; просмотров: 70 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Цель и Перспективы | | | Приложение D: Примеры политики |