Возможность оптимизации инфраструктуры: процесс управления, основанный на спецификациях ITIL/COBIT — переход со стандартизованного уровня на рационализированный

  • Статья
На этой странице

Введение Введение
Требование: процессы управления, оптимизации и изменения Требование: процессы управления, оптимизации и изменения

Введение

Для получения максимальной выгоды необходимо определить оптимальные процессы выполнения каждой задачи, входящей в модель оптимизации инфраструктуры. В приведенной ниже таблице указаны высокоуровневые проблемы, способы их решения и преимущества перехода на рационализированный уровень процесса управления, основанного на спецификациях ITIL/COBIT.

Проблемы

Решения

Преимущества

Проблемы бизнеса

Соглашения об уровне обслуживания не формализованы либо только подразумеваются

Неформализованное управление конфигурациями включает только базовые контрольные списки и таблицы

Проблемы ИТ

Управление выпусками не формализовано

Проекты

Реализация управления уровнями обслуживания для ИТ-операций

Реализация передовых способов управления выпусками

Оптимизация процессов администрирования сетей и систем

Реализация передовых способов планирования заданий

Преимущества для бизнеса

Упреждающее выполнение ИТ-операций позволяет решать проблемы раньше, предотвращая снижение производительности работы пользователей

Преимущества для ИТ-отдела

Автоматизация работы служб и средств освобождает ресурсы для внедрения новых служб или оптимизации использования имеющихся

Формализованные соглашения об уровне обслуживания способствуют объединению ИТ и бизнеса, улучшая репутацию ИТ-отдела

Рационализированный уровень оптимизации требует, чтобы в организации были определены процедуры управления инцидентами и проблемами, поддержки пользователей, а также управления конфигурациями и изменениями.

Требование: процессы управления, оптимизации и изменения

Аудитория

Ознакомьтесь с этим разделом, если в организации отсутствуют процессы управления уровнями обслуживания, управления выпусками, администрирования систем и сетей, а также планирования заданий.

Обзор

Оптимизация инфраструктуры не ограничивается продуктами и технологиями. В значительной мере уровень развития ИТ-служб организации определяют люди и процессы. В области управления ИТ-службами существуют определенные стандарты и рекомендации, ориентированные на работу с людьми и процессами. Платформа Microsoft® Operations Framework (MOF) включает многие сведения из библиотеки IT Infrastructure Library (ITIL) и стандарты COBIT, делая их доступными клиентам корпорации Майкрософт.

Этап 1: оценка

Целью этапа оценки при управлении операциями является оценка текущих возможностей и проблем организации. Для поддержки процесса оценки операций корпорация Майкрософт разработала решение Service Management Assessment (SMA) как часть системы постоянного улучшения Microsoft Operations Framework (MOF), а также его упрощенную сетевую версию — средство самостоятельной оценки MOF.

Рис. 16. Цикл постоянного совершенствования MOF

Рис. 16. Цикл постоянного совершенствования MOF

Решение MOF Service Management Assessment предназначено для повышения эффективности работы пользователей и процессов управления ИТ-службами, а также внедрения технологий, обеспечивающих выгоду для бизнеса. Все рекомендации, предоставляемые решением SMA, подробны и экономически обоснованы. Также предоставляется детальная схема улучшения служб с указанием ключевых индикаторов производительности, позволяющих следить за реализацией улучшений.

Этап 2: определение

Этап определения базируется на результатах оценки, выполненной с помощью средства MOF SMA. Средство оценки часто информирует о возможности улучшения в нескольких областях ИТ-операций. На этапе определения рассматриваются эти результаты и устанавливается приоритет проектов улучшений на основе требований бизнеса. Определить приоритеты этих улучшений помогают средства и рекомендации, предоставляемые схемой постоянного улучшения MOF.

Этап 3: ознакомление и планирование

Этап ознакомления и планирования при совершенствовании операций отражает установленные области улучшения и их приоритет. Осуществлять работу на этом этапе помогает программа улучшения служб MOF. Программа улучшения служб включает две основных области: улучшение конкретных процессов MOF/ITIL и улучшение служб. Руководство по решению этих задач доступно с помощью средства, которое облегчает выявление проблем, предоставляет специализированные инструкции по их устранению и позволяет отслеживать улучшения с помощью ключевых индикаторов производительности.   

Рекомендуемые процессы перехода на рационализированный уровень

Приведенные в этом разделе рекомендации разработаны в соответствии с тем, какие проблемы часто встречаются на стандартизованном уровне и в каких областях наблюдается улучшение при переходе на рационализированный уровень. Это лишь рекомендации, и они могут различаться в зависимости от организации или отрасли.

Хотя стандартизованный уровень предполагает расширенное использование средств управления ИТ-операциями и инфраструктурой и наблюдения за ними, а также наличие среды, в которой процессы управления изменениями, конфигурациями и выпусками стандартизованы и предсказуемы, все равно остаются возможности дальнейшего совершенствования ключевых областей. Управление уровнями обслуживания осуществляется в недостаточной степени, а соглашения об уровне обслуживания при этом не формализованы или только подразумеваются. Управление конфигурациями не формализовано и обычно включает базовые контрольные списки и таблицы, а управление выпусками определено плохо и недостаточно строго.

В рационализированной инфраструктуре стоимость управления компьютерами и серверами минимальна, а процессы и политики оптимизированы и играют важную роль в поддержке и расширении бизнеса. Система безопасности работает с упреждением, а реагирование на угрозы осуществляется быстро и легко контролируется. Автоматизированное развертывание снижает денежные затраты, сокращает время на внедрение решений и помогает избегать технических проблем. Используется небольшое количество образов. Участие человека в управлении компьютерами сведено к минимуму. Такие организации имеют точные сведения об используемом оборудовании и программном обеспечении и приобретают только необходимые лицензии и компьютеры. Система безопасности обеспечивает надежную защиту за счет упреждающего планирования, строгих политик и контроля над всем — от настольных компьютеров до серверов, брандмауэров и экстрасети.

Корпорация Майкрософт предлагает платформу Microsoft Operations Framework (MOF) как итеративную модель определения и улучшения ИТ-операций. MOF определяет функции управления службами (SMF) как логические операционные функции ИТ-организации. Функции SMF делятся на четыре больших группы, или квадранта: изменение, управление, поддержка и оптимизация. В этом руководстве основное внимание уделяется типичным областям улучшения в организациях, находящихся на рационализированном уровне оптимизации:

  • управлению уровнями обслуживания;

  • управлению выпусками;

  • администрированию систем;

  • администрированию сети;

  • планированию заданий.

Влияние улучшения этих функций управления службами на эффективность работы организации зависит от ее особенностей. Рекомендуется, чтобы в организации была проведена как минимум интерактивная самостоятельная оценка, а желательно — полная оценка управления службами. Это позволит выявить самые важные области, требующие улучшения процессов или служб.

Управление уровнями обслуживания

Управлением уровнями обслуживания (SLM) — это важный процесс, позволяющий согласовать требования бизнеса с качеством предоставляемых ИТ-услуг. Он предоставляет интерфейс, благодаря которому из других функций управления службами можно формировать ИТ-решения, отвечающие требованиям бизнеса при приемлемой стоимости. Главной целью при этом является успешное предоставление, обслуживание и улучшение ИТ-служб.

Управление уровнями обслуживания используется для согласования и администрирования ИТ-служб путем определения, заключения соглашений, оценки операций и обзора. Управление уровнями обслуживания включает определение ИТ-служб для организации и заключение для них соглашений об уровне обслуживания. Выполнение требований соглашений об уровне обслуживания обеспечивается с помощью усиливающих контрактов (UC) и соглашений о рабочем уровне (OLA) для внутреннего и внешнего предоставления служб. Реализация управления уровнями обслуживания не обеспечивает немедленного улучшения уровней обслуживания. На это требуется время. Сначала служба меняется незначительно, но со временем ее работа становится более эффективной по мере достижения поставленных целей и еще лучших результатов.

Если в организации требуется реализовать управление уровнями обслуживания, необходимо сначала определить, какие службы предоставляет ИТ-отдел клиентам организации и выяснить, какие заключены контракты на предоставление этих служб. В результате ИТ-отдел получит данные, зачастую впервые, обо всех службах, которые он должен предоставлять. Полученные таким образом сведения могут быть использованы для разработки и реализации процесса управления уровнями обслуживания и использования всех его преимуществ.

Управление уровнями обслуживания требует полного представления о предлагаемых службах. Реализация управления уровнями обслуживания включает следующие этапы:

  • создание каталога служб;

  • разработку соглашений об уровне обслуживания;

  • наблюдение и составление отчетов;

  • регулярное выполнение анализа уровней обслуживания.

Соглашения об уровне обслуживания разрабатываются в соответствии с требованиями и приоритетами служб, зарегистрированных в каталоге служб, требованиями, определенными при составлении соглашений об уровне обслуживания, результатами наблюдения за службами на предмет соответствия критериям соглашения, а также в соответствии с созданными отчетами и результатами анализа этих данных, помогающих выявлять и устранять проблемы с эффективностью предоставления служб.

Этап 4: развертывание (управление уровнями обслуживания)

Подготовительные действия

В начале проекта по реализации управления уровнями обслуживания следует выполнить некоторые подготовительные действия. Они помогают определить, имеется ли потребность в управлении уровнями обслуживания и достаточно ли ресурсов для его реализации. В рамках этого процесса ИТ-отдел определяет для компании базовый уровень, создавая моментальный снимок имеющихся служб и действий по управлению. Последним этапом этого процесса является анализ данных, собранных на предыдущих этапах, и использование результатов анализа для планирования реализации управления уровнями обслуживания с максимальной пользой для компании.

Создание каталога служб

В каталоге служб перечисляются все предоставляемые в текущий момент службы, приводятся сводные данные о характеристиках служб, описываются их пользователи и указываются пользователи, ответственные за повседневное обслуживание систем.

Служба определяется на усмотрение компании. Например, электронная почта и печать документов могут быть службами независимо от количества их компонентов, необходимых для предоставления этих служб конечным пользователям.

Каталог служб следует формализовать, так как это позволяет создать официальный журнал, подпадающий в организации под контроль над изменениями. Это очень важно, поскольку журнал будет ценным, только если постоянно контролируется и содержит точные данные.

Есть много способов формализации каталога служб. При выборе наиболее подходящего из них необходимо решить, как каталог служб будет просматриваться и использоваться, а также как будут создаваться отчеты на основе его данных. Каталог служб можно хранить в базе данных управления конфигурациями (CMDB) в виде одного компонента (служба каталогов) или в виде его служб. Для регистрации служб и таких подробностей, как компоненты, следствия их использования, приоритеты, соглашения об уровне обслуживания и соглашения о рабочем уровне, можно использовать приложения корпорации Майкрософт, например Microsoft Excel или Microsoft Access. Если выбранное средство позволяет включить каталог служб в базу данных CMDB, это можно использовать с выгодой, интегрировав данные каталога служб с параметром конфигурации (CI) в базе данных CMDB. Сделав это, затем можно повысить эффективность функций SMF управления изменениями и управления инцидентами, а также всех других функций SMF, использующих базу данных CMDB.

Разработка соглашений об уровне обслуживания

Соглашение об уровне обслуживания — это соглашение между поставщиком ИТ-услуг и клиентом или сообществом пользователей. В соглашениях об уровне обслуживания формализуются требования клиентов и пользователей к уровням обслуживания и определяются области ответственности всех сторон.

Создание соглашения об уровне обслуживания состоит из нескольких этапов, описанных ниже.

  • Определение типа соглашений об уровне обслуживания. Например, является соглашение внутренним или внешним, соглашением о рабочем уровне или об уровне обслуживания по нескольким услугам?

  • Определение соглашений об уровне обслуживания. Например, какие уровни обслуживания должны быть обеспечены по разным критериям, в том числе таким измеримым показателям, как доступность, оперативность реагирования, производительность, целостность, точность и безопасность?

  • Рассмотрение и утверждение соглашений об уровне обслуживания. Например, определите, возможно ли предоставление оговоренных услуг по ценам, приемлемым для ИТ-отдела и компании в целом.

  • Документирование соглашений об уровне обслуживания. Например, зафиксируйте в письменном виде согласованные условия и укажите участников, заключивших соглашение.

Сопоставление требований соглашения об уровне обслуживания, соглашения о рабочем уровне и усиливающего контракта

Усиливающие контракты (юридически обязательные контракты со сторонним поставщиком услуг, определяющие критерии выполнения соглашений об уровне обслуживания) и соглашения о рабочем уровне (внутренние соглашения, поддерживающие требования соглашений об уровне обслуживания) должны содержать метрики обслуживания, согласованные с требованиями соглашения об уровне обслуживания.

Наблюдение за уровнями обслуживания

Управление уровнями обслуживания включает цикл согласования и контроля целевых показателей работы ИТ-служб, а также адекватные действия по достижению баланса между уровнями обслуживания с одной стороны и требованиями бизнеса и расходами с другой.

После согласования и введения соглашений об уровне обслуживания в действие можно перейти к следующему этапу организации эффективного управления уровнями обслуживания — наблюдению за производительностью служб согласно критериям, определенным в целях уровня обслуживания (SLO). Есть несколько способов наблюдать за уровнями обслуживания, но суть их в главном одинакова: определение соответствия эффективности работы службы заданным критериям и того, насколько близка она к пороговому уровню.

Пересмотр соглашения об уровне обслуживания

Пересмотр соглашения об уровне обслуживания — один из четырех обзоров управления операциями MOF (OMR). Он является ключевой контрольной точкой управления и проводится через определенные интервалы времени, указанные в соглашении об уровне обслуживания. Цели пересмотра соглашения об уровне обслуживания — сравнить достигнутые показатели с целевыми и проверить, выполняется ли оно. Пересматривать соглашения об уровне обслуживания следует с участием руководителей высшего звена, при этом следует позаботиться о том, чтобы решения по поводу предоставления службы принимались с участием представителей ИТ-отдела и бизнес-отдела.

Управление выпусками

Функция SMF управления выпусками предназначена для развертывания изменений в ИТ-среде. После разработки, тестирования и включения изменений в выпуск необходимо развернуть их и обеспечить управление выпуском. Эти задачи входят в управление выпусками. Управление выпусками также обеспечивает эффективное внедрение изменений за счет объединения их в один выпуск и одновременного развертывания.

Целью управления выпусками является обеспечение успешного развертывания всех изменений в рабочей ИТ-среде с минимальным нарушением работы. Таким образом, управление выпусками охватывает следующие процессы:

  • управление стратегией выпусков, которая включает проектирование, планирование и внедрение изменений в рабочую среду совместно с комитетом по изменениям (CAB).

  • определение степени готовности каждого выпуска по ряду критериев (качество выпуска, пакет выпуска и готовность рабочей среды, планы обучения и поддержки, планы внедрения и возврата, а также план управления рисками).

Характеристики управления выпусками:

  • позволяет получить пакет, охватывающий все изменения, реализованные в рабочей среде, и развернуть только те изменения, которые были утверждены в процессе управления изменениями;

  • требует наличия средств управления изменениями для утверждения изменений и их отслеживания в процессе выпуска;

  • обеспечивает передачу сведений о внесенных изменениях функции управления конфигурациями для занесения этих сведений в базу данных CMDB;

  • требует сведений об управлении конфигурациями для создания и проверки сред тестирования на этапе разработки нового выпуска;

  • требует наличия средств управления конфигурациями для оценки влияния изменений на ИТ-среду и окончательного хранения пакета выпуска.

Этап 4: развертывание (управление выпусками)

Планирование выпуска

Первым этапом процесса выпуска является создание плана, определяющего действия и ресурсы, необходимые для успешного развертывания выпуска в рабочей среде. Этот план должен включать определение задач, которые необходимо выполнить, время их выполнения (график работ) и их приоритет по отношению к другим задачам. Как только это сделано, менеджер по выпускам может составить подробный график работ и выделить ресурсы для реализации проекта. При управлении выпусками менеджер по выпуску отвечает за создание плана выпуска (проекта) для каждого запроса на изменение, утвержденного в ходе управления изменениями.

Создание выпуска

После согласования плана выпуска члены группы выпуска определяют и разрабатывают процессы, средства и технологии, необходимые для его развертывания в рабочей среде. Хотя большинство выпусков (если не все) можно развернуть в рабочей среде вручную, это можно также сделать с помощью некоторых средств и технологий. Для более эффективного использования времени и ресурсов группе выпуска следует определить средства и технологии, позволяющие автоматизировать как можно большую часть развертывания.

Выбрав механизм развертывания, группа выпуска создает пакет выпуска, который включает процессы, средства и технологии, необходимые для развертывания выпуска в рабочей среде с помощью выбранного механизма, а также его удаления из рабочей среды, в случае если он станет ненужным.

В простейших случаях пакет выпуска может включать лишь документированные процедуры его установки и удаления.

Созданный пакет выпуска следует протестировать в лабораторной среде для предварительной проверки его готовности к развертыванию в рабочей среде. Если тестирование прошло успешно, выпуск и содержимое пакета выпуска передаются под контроль функции управления изменениями.

Проверка интеграции выпуска в среду

До этого момента целью тестирования была проверка выпуска и пакета выпуска в среде разработки. Проверка интеграции выпуска в среду позволяет разработчикам и представителям бизнес-отдела проверить совместную работу выпуска и пакета выпуска в среде, близкой по характеристикам к рабочей. В некоторых случаях для окончательной проверки готовности изменения к развертыванию во всей организации необходимо пилотное тестирование.

Хотя тестирование в смоделированной рабочей среде и обеспечивает некоторую уверенность в правильности выпуска, оно не гарантирует, что выпуск будет нормально функционировать в рабочей среде, где условия могут существенно отличаться. Таким образом, для проверки соответствия выпуска требованиям иногда целесообразно выполнить несколько контролируемых тестов в рабочей среде. Пробное внедрение выпуска в рабочую среду связано с риском, и выполнять его следует, только если процедуры восстановления, содержащиеся в пакете выпуска, успешно прошли испытания в среде тестирования.

Подготовка выпуска

После пилотного тестирования и проверки интеграции выпуска со средой необходимо подготовить рабочую среду к его развертыванию, выполнить подготовку и согласовать дальнейшие действия: перейти к анализу готовности выпуска или вернуть выпуск инициатору изменения или менеджеру по выпуску для доработки.

Менеджер по выпуску, менеджер по изменениям и инициатор изменения являются основными участниками анализа готовности выпуска, но в нем также могут участвовать представители других заинтересованных групп, например группы тестирования, службы поддержки и сообщества пользователей (в зависимости от природы и размера выпуска).

Если выпуск не прошел некоторые тесты в лабораторной и рабочей среде, ошибки могут быть недостаточно существенными для запрета развертывания. Даже при возникновении отклонений в рабочей среде могут иметься веские бизнес-причины, по которым необходимо развернуть выпуск.

Например, на веб-узле, служащем для делового взаимодействия между компаниями, может не работать функция автоматического входа в систему, но ее легко заменить входом вручную. Поэтому группа выпуска может предпочесть продолжить внедрение выпуска без этой функции.

Результаты тестирования, сделанные при этом выводы, а также все разработанные обходные способы решения проблемы следует документировать. Если во время тестирования найдены ошибки, затрагивающие сообщество пользователей или влияющие на уровни обслуживания, необходимо обсудить методы их обхода и возможные проблемы с представителями службы поддержки, а также проинформировать службу поддержки о методах обхода до развертывания выпуска. Для обеспечения надлежащей работы выпуска иногда требуется оформить несколько дополнительных запросов на изменение. Как бы то ни было, необходимо задокументировать в журнале изменений принятое решение и занести в него всю сопутствующую информацию.

Развертывание выпуска

Процесс развертывания выпуска в рабочей среде зависит от типа и природы выпуска, а также от выбранного механизма развертывания выпуска. В любом случае менеджеру по выпуску необходимо предоставить отчеты о состоянии и, если это необходимо, средства и технологии, позволяющие контролировать процесс развертывания. При внесении изменений в ИТ-компоненты во время развертывания необходимо соответствующим образом изменять параметры конфигурации и отношения, моделирующие эти компоненты в базе данных CMDB.

После развертывания выпуска менеджер по выпуску должен убедиться в том, что он работает правильно, прежде чем перейти к развертыванию других. Иногда сотрудники службы технической поддержки могут проверить это с помощью определенных средств и технологий, в других ситуациях они могут получить от менеджера по выпуску указание узнать мнения и комментарии отдельных пользователей.

Если выпуск не соответствует требованиям или во время его развертывания обнаруживается серьезная проблема, для определения причины и диагностики проблемы, возможно, придется воспользоваться функцией управления проблемами. Если доступно соответствующее исправление или обходное решение проблемы, следует указать это в документации и оформить запрос на изменение для развертывания исправления в рабочей среде. Если необходимое исправление или обходное решение проблемы найти не удается, можно воспользоваться процедурами возврата и удалить выпуск из среды.

После развертывания выпуска следует обеспечить регистрацию всех результатов и сведений обо всех обходных способах решения проблемы или запросах на изменение. Если выпуск нужно откатить, это также необходимо зафиксировать в журнале, обосновав.

Администрирование систем

Функция администрирования систем включает управление системой безопасности, управление службами и наблюдение за ними, планирование заданий, администрирование сети, администрирование служб каталогов, управление печатью, выводом и хранением данных. Способы проектирования, разработки и реализации этой функции зависят от размера и архитектуры организации. Крупные организации используют четко определенные модели, а компании меньшего размера обычно объединяют функции для поддержания работоспособности и операционных возможностей систем.

Задачей функции SMF администрирования систем является повседневное управление вычислительной средой, включающее управление различными элементами рабочей среды и поддержку их функционирования.

Кроме того, администрирование систем включает предоставление административных служб для поддержки вычислительных сред, содержащих и централизованное, и распределенное оборудование.

Функция системного администрирования также помогает в функциональном администрировании других функций SMF, к которым она не имеет непосредственного отношения. Эта помощь может включать следующее:

  • наблюдение за производительностью и ресурсами на первом уровне для функции управления службами и наблюдения за их работой;

  • повседневное функциональное администрирование учетных записей, включая добавление, удаление или перемещение учетных записей; запросы ресурсов, например принтеров и привилегий доступа, для управления службами каталогов и системой безопасности;

  • управление ресурсами, используемыми для создания печатных отчетов и вывода данных, при управлении печатью и выводом данных;

  • выполнение административных задач, необходимых для резервного копирования и восстановления важных данных;

  • принудительное применение политики безопасности для защиты данных и общих сетевых ресурсов, в том числе файлов, папок и принтеров.

Этап 4: развертывание (администрирование систем)

Реализация модели централизованного администрирования

В модели централизованного администрирования большинство операций и функций поддержки или все они сосредоточены в одном узле или нескольких узлах. По мере развития локальных, глобальных, распределенных и клиент-серверных вычислительных систем и соответствующих сетей все больше организаций предпринимают меры по централизации поддержки установленных ресурсов, приложений и решений.

Средства связи с удаленными объектами и филиалами становятся все более доступными и дешевыми. Базовые технологии, поддерживающие работу филиалов (протоколы передачи данных, средства удаленного доступа, серверы без мониторов и т. д.), удалось усовершенствовать до такой степени, что теперь нет необходимости в присутствии сотрудников службы поддержки в каждом филиале. Благодаря этому стала более доступной возможность централизации фундаментальных функций поддержки, необходимых для обеспечения доступности и надежности, повседневной поддержки и администрирования систем, находящихся на удаленных объектах или в филиалах.

Централизованное администрирование обычно предполагает, что большинство управляемых вычислительных систем и ресурсов или все они находятся в главном здании компании. Хотя это утверждение все больше приближается к истине, встречаются случаи, когда определенные решения (собственные приложения компании, специализированные базы данных и т. д.) не централизованы в корпоративном центре данных, а распределены между ним и удаленным объектом или филиалом. Такое распределение некоторых приложений и баз данных не мешает использовать централизованный подход к администрированию.

Реализация модели централизованного и удаленного администрирования

Модель централизованного и удаленного администрирования обладает большинством преимуществ полностью централизованной модели. Большая часть административных задач все так же выполняется в центральном месте, например в главном центре данных, что обеспечивает превосходный контроль и консолидацию ресурсов, необходимых для административных функций.

Однако управление и ресурсы консолидируются не полностью из-за необходимости присутствия хотя бы минимального числа администраторов в среде удаленного центра данных для ее обслуживания. Требования к корректирующему обслуживанию распределенной системы могут включать обновление систем с перезагрузкой компьютеров, а также резервное копирование и хранение данных на лентах. Могут также предъявляться дополнительные требования к локальному администрированию, зависящие от конкретных управляемых приложений или систем. В этих случаях требуется определить, какие именно задачи необходимо выполнять для конкретных приложений.

Модель централизованного и удаленного администрирования описывает системы, распределенные между центральным и удаленными местами и управляемые преимущественно централизованно. Как уже было сказано, на удаленных или региональных объектах необходимо организовать центры данных, содержащие серверы и запоминающие устройства. Развертывание инфраструктуры центра данных включает трату средств на аренду помещения, электропитание, прокладку кабелей, отопление, вентиляцию и кондиционирование воздуха, а также компоненты обеспечения безопасности.

Если в результате развития технологий использование данной модели становится невозможным (то есть она больше не отвечает условиям соглашения об уровне обслуживания) или экономически невыгодным, возможно, стоит реализовать модель распределенного администрирования. В этой модели вычислительные и человеческие ресурсы физически находятся на удаленном объекте. Она описана в следующем разделе.

Реализация модели централизованного и делегированного администрирования

Эта модель сочетает лучшие характеристики моделей централизованного и удаленного администрирования, обеспечивая все их возможности и преимущества, и при этом делает доступными некоторые преимущества модели распределенного администрирования. Эти преимущества достигаются за счет делегирования сравнительно небольшого и специализированного подмножества административных задач и областей ответственности локальным филиалам и удаленным объектам компании.

Как и в случае централизованной модели, основные административные функции выполняются в корпоративном (главном) центре данных, там же работает большинство администраторов. Все административные указания поступают из этого центра. Централизованные ресурсы управляют централизованными сетевыми серверами и службами, расположенными в центре данных, и администрируют службы по сети, где это возможно, доступно и имеет смысл.

Иногда необходимо распределить те или иные службы, серверы и ресурсы. В таких случаях может оказаться целесообразным делегировать часть административных задач персоналу региональных или удаленных объектов. Тогда удаленным ресурсам выдаются узкоспециализированные права. Под "узкоспециализированными правами" следует понимать небольшое подмножество административных прав и прав доступа, позволяющих администраторам на местах выполнять строго определенные задачи.

Реализация модели распределенного администрирования

В отличие от других моделей, модель распределенного администрирования основана на использовании ресурсов удаленных объектов и филиалов, обеспечивающих полную поддержку администрирования. Ресурсы удаленных филиалов выполняют фундаментальные и критически важные функции поддержки, необходимые для поддержания работоспособности, доступности и надежности систем.

Могут иметь место определенные требования бизнеса к обслуживанию систем на удаленных объектах. Некоторые из этих требований могут быть связаны с производительностью, масштабируемостью, определенным типом приложений, а также стоимостью или доступностью пропускной способности сети, обеспечивающей поддержку централизованного решения.

Вычислительные и человеческие ресурсы в этой модели полностью распределены между удаленными офисами и филиалами. В результате организация может добиться более высокой производительности определенных приложений на местах.

Реализация модели распределенного администрирования централизованных центров данных

Пятый вариант администрирования систем, называемый здесь "следование за солнцем", также можно назвать моделью распределенного администрирования централизованных центров данных.

"Следование за солнцем" в данном контексте означает глобальное круглосуточное предоставление поддержки, основанное на передаче ответственности за нее региональным офисам по всему миру: когда один офис закрывается в конце рабочего дня, функции поддержки берет на себя офис в другом регионе.

Эта модель в чем-то уникальна и используется не так часто, как четыре предыдущие. Тем не менее многие компании пытались или пытаются реализовать эту модель.

Администрирование сетей

Суть функции SMF администрирования сетей заключается в управлении сетями — компонентами инфраструктуры, с помощью которых компьютерные системы и общие периферийные устройства обмениваются данными друг с другом. Это базовый уровень ИТ-инфраструктуры, поскольку без сети можно вести речь только о наборе отдельных компьютеров, но никак не об инфраструктуре.

Целью функции SMF администрирования сетей является обеспечение надежной основы для выполнения процессов повседневного администрирования сетевой среды. Это предполагает управление различными элементами рабочей среды и обеспечение их поддержки. Функция SMF администрирования сетей включает предоставление служб планирования и развертывания для расширения имеющихся сетей, а также служб поддержки для поиска и устранения неполадок в сетевой среде. Успешная реализация функции администрирования сетей позволяет:

  • улучшить развертывание сетевой инфраструктуры;

  • улучшить процессы поиска и устранения неполадок и связанные с ними процессы управления инцидентами;

  • повысить надежность сети;

  • повысить доступность ИТ-решений и служб.

Типичная сеть включает оборудование (кабели, маршрутизаторы, коммутаторы, концентраторы, физические серверы и другие компоненты) и программное обеспечение или микропрограммы, контролирующие использование оборудования. В сетевой модели OSI типичная ИТ-инфраструктура делится на уровни, начиная с базовых компонентов внизу стека, которые используются всеми службами, и заканчивая специализированными приложениями вверху.

Модель OSI включает нижеперечисленные уровни (сверху вниз).

  1. Прикладной уровень

  2. Уровень представления

  3. Сеансовый уровень

  4. Транспортный уровень

  5. Сетевой уровень

  6. Канальный уровень

  7. Физический уровень

При администрировании сетей обычно приходится иметь дело с тремя нижними уровнями, которые имеют отношение преимущественно к оборудованию. Администрирование сетей и администрирование систем некоторым образом пересекаются на транспортном уровне, который включает протоколы связи и сетевые протоколы, позволяющие передавать данные из одной точки в другую. В контексте MOF управление такими службами, как DNS, WINS и DHCP предоставляет базовые возможности разрешения имен, необходимые полнофункциональным ИТ-службам. В некоторых организациях эти базовые службы также могут быть включены в функции обслуживания сети. Поскольку службы DNS, WINS и DHCP запускаются на серверах, сетевые серверы иногда включаются в число аппаратных компонентов, управляемых функцией SMF администрирования сетей.

Этап 4: развертывание (администрирование сети)

Обслуживание сети

Управление сетевой инфраструктурой в основном заключается в наблюдении за ее производительностью, сравнении ее показателей с целевыми и формировании рабочих элементов для поиска и устранения неполадок в случае снижения производительности. Большинство аппаратных компонентов сети должны работать без участия оператора в течение среднего времени наработки на отказ с соблюдением критериев производительности, определенных изготовителями компонентов. Входящая в MOF функция SMF управления ресурсами предоставляет подробные данные для планирования ресурсов, что помогает группе проектирования сети оптимизировать ее производительность.

Однако серверные компоненты сети все же требуют периодического обслуживания. Для них необходимо регулярно выполнять резервное копирование (если это уместно) и оценивать требования к хранению данных или ресурсам в соответствии с функцией SMF управления хранением данных.

Поддержка сети

Поддержка сети тесно связана с действиями из квадранта поддержки, особенно с функциями SMF управления инцидентами и управления проблемами. С помощью процесса разрешения инцидентов, который описан в функции SMF управления инцидентами, специалисты по сетям устраняют ошибки в сетях, разрабатывают обходные способы решения проблем и снижают риск возникновения неполадок в сетях. Общий процесс разрешения инцидентов описан в "Руководстве по функции SMF управления инцидентами", однако некоторые специфические процессы диагностики и устранения неполадок в сетях описаны в последующих разделах.

Планирование заданий

Функция SMF планирования заданий предназначена для обеспечения эффективной обработки данных в заранее определенные сроки в установленной последовательности для достижения максимального использования системных ресурсов и сведения к минимуму нарушений работы пользователей. Пакетный процесс — это последовательное взаимодействие системы с базой данных, которая работает в фоновом режиме, без участия конечного пользователя. Пакетные процессы могут запускаться автоматически или вручную. Обычно они запускаются в нерабочее время, когда пользователи практически не взаимодействуют с системой.

Пакетные процессы обычно должны иметь собственную архитектуру, поскольку в большинстве случаев они требовательны к ресурсам и выполняются долго и часто. Пакетный процесс обычно считывает большие объемы данных из базы данных, обрабатывает их и возвращает результаты в базу данных. Этот процесс выполняется с помощью сценариев.

В число типов пакетных заданий входят следующие:

  • составление отчетов об управлении финансами;

  • составление отчетов о маркетинге;

  • составление отчетов об управлении поставками;

  • составление отчетов об инвентаризации;

  • составление отчетов о счетах-фактурах;

  • обработка счетов клиентов (выставление ежемесячного счета и т. д.);

  • автоматизированное резервное копирование данных системы и приложений;

  • подготовка сводных данных о работе систем и составление отчетов о планировании ресурсов.

Этап 4: развертывание (планирование заданий)

Архитектура пакетов

Архитектура пакетов состоит из процессов и компонентов, используемых для эффективного управления их обработкой. Целью определения архитектуры пакетов является оптимизация обработки (снижение времени отклика и повышение эффективности использования ресурсов) за счет выполнения пакетных запусков в периоды непиковой нагрузки. Архитектура должна предоставлять менеджеру по ресурсам простой пользовательский интерфейс и возможность использовать стандартный централизованный подход к планированию и контролю пакетов, управлению ими, а также устранению ошибок. Архитектура должна иметь высокую масштабируемость для удовлетворения будущих требований организации. Она также должна иметь высокую доступность и сводить к минимуму время простоя и нарушения интерактивных операций, которые обычно выполняются параллельно с пакетными операциями. В некоторых организациях для обеспечения выполнения всех критически важных пакетных заданий используются компоненты резервного копирования, такие как сервер событий.

Базовые компоненты архитектуры пакетов — сервер управления, база данных ресурсов (CDB), монитор, принтер, серверы приложений и базы данных. Кроме сервера управления, мониторы должны быть подключены и к каждому серверу приложений для наблюдения за локальной обработкой пакетов. Это также облегчает анализ ошибок на локальном уровне.

Пакетная обработка

Перед обсуждением пакетных запусков по расписанию следует разобраться с иерархией пакетного процесса и содержимым пакетного сценария. Пакетный запуск состоит из нескольких независимых пакетных заданий, которые периодически выполняются согласно расписанию. В крупных организациях при наличии необходимых ресурсов в течение дня могут выполняться несколько пакетных запусков. Каждое пакетное задание состоит из нескольких этапов, определяющих конкретные действия при его выполнении.

Обычно в организациях выполняется большое количество пакетных заданий. Для обеспечения согласованности подхода к выполнению каждого задания следует разработать схему пакетного задания, содержащую стандартизованный код для каждого задания. Данные, специфичные для него, должны быть закодированы в специально отведенной области схемы. Схема также упрощает требования к разработке и обслуживанию за счет стандартизации содержимого и структуры сценария каждого задания. Например, все типы стандартизованных действий, таких как уведомление об успешном или неудачном выполнении пакетного задания, архивация и удаление данных транзакции, должны быть включены в код каждого выполняемого сценария.

Пакетные запуски по расписанию инициируются средством планирования в заданные интервалы времени, обычно когда активность пользователей в системе минимальна. После программирования средства планирования вмешательства менеджера по ресурсам во время пакетных запусков не должно требоваться, если только не возникает ошибка, после которой средство не может восстановиться.

Средство планирования инициирует все пакетные запуски. Если пакет не запускается в запланированное время, средство прерывает запуск и регистрирует ошибку в журнале ошибок. Некоторые средства планирования могут поддерживать возможность повторной попытки пакетного запуска. Если инициализация запуска прошла успешно, выполняется первое пакетное задание. Планировщик управляет выполнением заданий на каждом сервере приложений, где они должны быть выполнены. Если при выполнении задания не возникло ошибок, средство регистрирует его успешное выполнение в журнале пакета и выполняет следующее задание; и т. д.

Если во время выполнения пакетного задания произошла ошибка, средство планирования прекращает его выполнение и регистрирует ошибку в журнале ошибок. Фактическое выполнение пакетного задания зависит от входной информации, которая может стать причиной ошибки при выполнении задания. Например, может требоваться входная информация о следующих факторах:

  • доступность рабочих данных;

  • выполнение задания, от которого зависит задание в очереди;

  • доступность ресурсов для выполнения задания;

  • приоритет задания и интервал выполнения пакета.

При обработке задания могут также выдаваться предупреждения, например при превышении порогового уровня использования процессора или дискового пространства на сервере приложений, на котором обрабатывается пакетное задание. Предупреждения не приводят к прерыванию пакетного задания, однако менеджеру по ресурсам следует устранять причины предупреждений как можно быстрее, поскольку они могут привести к сбоям при обработке заданий в будущем. Если выполнение задания прерывается из-за ошибки, некоторые средства планирования автоматически пытаются восстановить нормальную работу и возобновить задание с этапа, который выполнялся перед его прерыванием. Восстановление является полезной функцией при выполнении очень длительных пакетных заданий, так как при этом прерванные задания не требуется выполнять заново с самого начала. Если восстановление невозможно, необходимо перезапустить задание.

Если средство планирования не поддерживает перезапуск задания или восстановление после сбоя (или поддерживает, но только в определенных ситуациях), менеджер по ресурсам должен вручную инициировать процедуры перезапуска или восстановления.

Действия по планированию заданий

В идеале архитектура пакетов должна быть настроена так, чтобы участие менеджера по ресурсам было минимальным. Однако все равно остается достаточно много повседневных задач, которые менеджер по ресурсам должен выполнять сам. В их числе следующие:

  • наблюдение;

  • анализ;

  • настройка;

  • реализация;

  • управление событиями;

  • обработка запросов по мере необходимости;

  • изменение расписания;

  • резервное копирование;

  • архивация;

  • аудит;

  • ведение журнала управления ресурсами;

  • составление отчетов.

Все эти действия являются неотъемлемыми частями процесса планирования заданий. Наблюдение, анализ, настройка и реализация образуют итеративный процесс. Входными данными для такого процесса являются показатели использования ресурсов и пороговые значения соглашения о рабочем уровне, с которыми сравнивается архитектура пакетов при наблюдении. Эти действия выполняются в повседневном режиме, а их цели заключаются в повышении производительности и оптимизации использования архитектуры. Остальные действия выполняются в ответ на события, запросы или требования.

Ведение документации и обучение

Все политики и процедуры следует ясно документировать, чтобы менеджер по ресурсам мог использовать сведения о них при выполнении повседневных задач. В документации следует регистрировать:

  • процедуры инициирования и прерывания пакетных запусков;

  • процедуры изменения приоритета заданий;

  • процедуры обработки предупреждений и ошибок;

  • процедуры обработки распространенных ошибок;

  • процедуры анализа причин ошибок;

  • процедуры делегирования ответственности за устранение ошибок вышестоящим сотрудникам;

  • процедуры отправки запросов на изменение;

  • процедуры регистрации задач в журнале управления ресурсами;

  • процедуры определения элементов, за которыми следует наблюдать, и интервалов наблюдения;

  • процедуры обработки поступающих запросов, включая рассмотрение, тестирование и выполнение этих запросов.

Без надлежащего обучения менеджер по ресурсам не сможет выполнять действия, описанные в данном документе, своевременно реагировать на ошибки обработки и устранять их. Желательно, чтобы менеджер по ресурсам прошел курс обучения по используемому в организации средству планирования у поставщика этого средства.

Дополнительные сведения

Дополнительные сведения см. на веб-узле Microsoft Operations Framework.

Сведения о том, как специалисты ИТ-отдела корпорации Майкрософт используют Microsoft Operations Framework и передовые способы управления ИТ-службами, см. по адресу https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx.

Контрольная точка: процессы управления, оптимизации и изменения

Требование

 

Для ИТ-операций реализовано управление уровнями обслуживания.

 

Реализованы передовые способы управления выпусками.

 

Оптимизированы процессы администрирования сети и систем.

 

Реализованы передовые способы планирования заданий.

Если приведенные выше инструкции выполнены, организация отвечает минимальным требованиям рационализированного уровня модели оптимизации основной инфраструктуры в отношении процессов управления, оптимизации и изменения. Корпорация Майкрософт рекомендует следовать указаниям по управлению операциями, приведенным в дополнительных ресурсах, доступных в Microsoft Operations Framework.