|

Масштабируемость и высокая доступность становятся всё более популярными с увеличением спроса на надежные и производительные инфраструктуры, предназначенные для обслуживания критически важных систем. Уменьшение времени простоя и устранение единых точек отказа – такие же важные проблемы, как и обработка повышенной нагрузки на систему. Высокая доступность (high availability) – качество инфраструктуры, способное устранить их.

Данная статья рассказывает, что именно значит термин «высокая доступность» и как это качество может сделать инфраструктуру более надёжной.

Высокая доступность

В программировании термин «доступность» (availability) используется для описания интервала времени, в течение которого сервис доступен, а также времени, необходимого системе для ответа на запрос пользователя. Высокая доступность – это качество системы или компонента, которое обеспечивает высокий уровень эксплуатационных характеристик за определенный период времени.

Измерение доступности

Доступность часто выражается в процентах, что обозначает уровень аптайма, который ожидается от конкретной системы или компонента за конкретный период времени. В таком случае 100% доступности значит, что система никогда не выходит из строя; соответственно, система, которая обеспечивает 99% доступности в течение одного года, может иметь до 3,65 дней простоя (1%).

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

Как работает высокая доступность?

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

Когда необходима высокая доступность?

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

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

Что делает систему высоко доступной?

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

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

В данной ситуации веб-сервер не является единой точкой отказа, потому что:

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

Но что если из строя выйдет балансировщик нагрузки?

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

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

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

Для обнаружения и устранения сбоев в инфраструктуре должен существовать специальный компонент.

Обнаружение и устранение сбоев можно реализовать методом top-to-bottom: верхний слой отслеживает сбои нижнего слоя. Вернёмся к нашему примеру; в таком кластере балансировщик нагрузки – это верхний слой. Если один из веб-серверов (нижний слой) станет недоступным, балансировщик нагрузки перестанет перенаправлять на него запросы.

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

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

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

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

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

Какие компоненты необходимы для поддержки высокой доступности?

Для настройки высокой доступности необходимо установить несколько системных компонентов. Однако гораздо сильнее высокая доступность зависит от таких факторов:

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

Какое программное обеспечение необходимо для высокой доступности?

Каждый слой системы с высокой доступностью будет иметь разные потребности. На уровне приложения балансировка нагрузки является неотъемлемым компонентом в системе с высокой доступностью.

(High Availability Proxy) – популярное средство для настройки балансировки нагрузки, так как позволяет обрабатывать нагрузку на нескольких уровнях, а также для различных видов серверов, включая серверы баз данных.

Также в системный стек важно внедрить надёжное средство для точки входа в приложение. Чтобы устранить единую точку отказа, как упоминалось ранее, необходимо реализовать кластер балансировки нагрузки с гибкими IP-адресами. Для создания таких систем используются Corosync и Pacemaker.

Заключение

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

Tags:

Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.

Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:

Доступность	Время простоя в месяц	Время простоя в год
90%	3 дня	37 дней
98%	14,6 часов	7,3 дня
99%	7,3 часа	3,7 дней
99,8%	1,5 часа	18 часов
99,9%	44 минуты	8.8 часов
99,99%	4.4 минуты	53 минуты
99,999%	26 сек	5,3 минуты

Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.

Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.

Наверное, существуют интернет-проекты, которые могут пережить и 37 дней простоя в год (больше месяца!). Но всё-таки большинство интернет-магазинов, порталов и сайтов (в особенности тех, чьи транзакции проходят через сайт) не могут себе позволить такой роскоши, как даже 18 часов в год. Репутацию восстановить сложно всегда, а если она теряется по причинам “у системного администратора выходной” это и вовсе обидно.

“Пять девяток” — вот, что такое высокая доступность

Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.

Высокая доступность нужна всем

Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.

Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.

Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.

Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.

Немного о том, из чего складывается высокая доступность

Доступность может быть сетевая и сервиса.

Сетевая доступность — это когда ваш сервер доступен по сети.
Доступность сервиса — это когда ваш сервер может обслуживать клиентов.

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

Доступность сервиса зависит от:

• сетевой доступности вашего сервера
• скорости реакции вашего админа на проблему
• скорости реакции поддержки дата-центра на проблему
• скорости замены неисправного железа в дата-центре

Недоступность складывается из:

• проблем сетевой доступности
• проблем с “железом”
• проблем с нагрузкой на сервере (“тормозит”, не справляется)
• программных ошибок (“косяки” программистов)

И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.

Если вам нужна гарантированная доступность выше 99,8%, необходимо заниматься отказоустойчивостью. И сервер должен быть не один. Но это тема отдельного разговора.

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

В третьей версии ITIL-процессы управления доступностью и непрерывностью ИТ-услуг рассматриваются вместе (далее процесс). Важнейшими ключевым понятиями этого совместного процесса являются:

доступность - способность ИТ-услуги или ее компонентов выполнять свои функции в определенный период времени;

надежность - способность ИТ-услуги или ее компонентов выполнять заданные функции при определенных условиях эксплуатации;

восстанавливаемость - способность ИТ-услуги или ее компонентов к восстановлению своих эксплуатационных характеристик, утраченных частично или полностью в результате сбоя;

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

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

Планирование и разработка ИТ-услуг с учетом требований бизнеса к уровню доступности;

Оптимизация доступности ИТ-услуг путем проведения эффективных с точки зрения затрат усовершенствований;

Сокращение количества и продолжительности инцидентов, влияющих на доступность ИТ-услуг.

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

Планирование

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

При проектировании доступности ИТ-услуг проводится анализ ИТ-инфраструктуры с целью определения наиболее уязвимых компонентов, не имеющих резерва и способных в случае сбоя оказать негативное влияние на предоставление ИТ-услуг. В терминологии ITIL подобные компоненты называются Single Point of Failure (SPOF), и для их определения используется метод «Анализ влияния сбоев компонентов инфраструктуры» (Component Failure Impact Analysis, CFIA). Данный метод применяется для оценки и прогнозирования воздействия отказов ИТ-компонентов на ИТ-услугу. Основные цели CFIA таковы:

Определение точек сбоев, влияющих на доступность;

Анализ влияния сбоя компонентов на бизнес и пользователей;

Определение взаимосвязи компонентов и персонала;

Определение времени восстановления компонентов;

Определение и документирование вариантов восстановления.

Для анализа рисков используется метод анализа и управления рисками (CCTA Risk Analysis and Management Method, CRAMM), в котором анализируются возможные угрозы и зависимости ИТ-компонентов, проводится оценка вероятности возникновения нестандартных ситуаций или чрезвычайных событий.

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

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

Еще один аспект планирования - определение времени простоя. Все ИТ-компоненты должны быть объектами стратегии обслуживания. В зависимости от применяемых ИТ, критичности и важности поддерживаемых конкретным ИТ-компонентом бизнес-функций частота и уровень обслуживания могут различаться. В случае необходимости предоставления услуги в режиме 24х7 следует найти оптимальный баланс между требованиями по обслуживанию ИТ-компонентов и потерями для бизнеса от простоя услуги. Утвержденные расписания обслуживания должны быть зафиксированы в соглашениях об уровне обслуживания (Service Level Agreement, SLA).

Улучшение доступности ИТ-услуг

Зачем нужно улучшать доступность? Причин может быть множество: несоответствие качества ИТ-услуг требованиям SLA; нестабильность предоставления ИТ-услуг; тенденции к снижению уровня доступности ИТ-услуг; недопустимо большие сроки восстановления; запросы со стороны бизнеса на увеличение уровня доступности.

Улучшение доступности требует обоснованных дополнительных финансовых затрат, и для установления возможности улучшения ИТ-услуг используются определенные методы и технологии, среди них анализ дерева отказов (Fault Tree Analysis, FTA) и анализ системных простоев (Systems Outage Analysis, SOA).

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

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

Определение основных причин сбоев предоставления ИТ-услуг;

Определение эффективности поддержки ИТ-услуг;

Подготовка отчетов;

Инициирование программы по исполнению принятых рекомендаций;

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

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

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

Измерение доступности ИТ-услуг

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

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

Роли и ответственности

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

Внедрение процесса

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

Как и любой проект, внедрение процесса начинается с создания проектных команд, разработки документов по управлению проектом, составления плана проекта и т.д. На этапе «предпроектных» работ проводятся маркетинговые мероприятия по ознакомлению представителей бизнеса с технологиями и рекомендациями ITIL и обоснованию необходимости для бизнеса внедрения процесса управления доступностью ИТ-услуг.

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

Эффект и проблемы

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

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

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

Отказ от внедрения процесса по причине того, что текущая доступность ИТ-услуг считается приемлемой;

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

Сопротивление централизации в управлении ИТ-инфраструктурой со стороны ИТ-менеджеров;

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

Евгений Булычев ([email protected]) - консультант отделения «Ай-Теко Бизнес Консалтинг» (Москва).

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

Рис. 14.6. Формула доступности (источник: OGC)

Достигнутое время работоспособности системы равно разнице между согласованным временем работоспособности и случившемся временем простоя. Например: если была достигнута договоренность о 98% доступности сервиса в рабочие дни с 7.00 до 19.00 и в течение это периода был двухчасовой отказ сервиса, то достигнутое время работоспособности (процент доступности) будет равен:

(5x12- 2)/(5 х 12) х 100% = 96,7%

Анализ простоев системы (SOA)

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

Характеристики метода SOA:

Широкая сфера действия: он не ограничивается инфраструктурой и охватывает также процессы, процедуры и аспекты корпоративной культуры;

Рассмотрение вопросов с точки зрения заказчика;

Совместная реализация метода представителями заказчика и ИТ-организации (команда метода SOA).

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

Пост технического наблюдения (ТОР)

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

Расчеты доступности сервиса

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

Программное обеспечение автоматизации процессов itil

1. Bmc software
2. Computer associates
3. Hewlett-packard
4. Microsoft

Bmc software

Компания BMC Software - всемирно известный разработчик и поставщик средств администрирования сетей, приложений, баз данных, ERP- и CRM-систем, повышающих доступность, производительность и восстанавливаемость критических бизнес-приложений и данных. Продукты BMC доступны для широкого спектра платформ, включая различные реализации и версии UNIX, Windows, OS/2, OS/390, OpenVMS и NetWare. Из характерных для продуктов BMC особенностей в первую очередь следует отметить ориентацию на поддержку соглашений об уровне обслуживания пользователей (Service Level Agreement, SLA) и построение модели функционирования, направленной на реализацию такого соглашения, а также их высокую производительность (рис. 1). Компания предлагает следующие семейства продуктов для управления ИТ-инфраструктурой:

• BMC Application Management - средство предназначено для управления производительностью и доступностью бизнес-приложений (включая приложения компаний Oracle и SAP) и серверных продуктов (таких, как Microsoft Exchange и J2EE-серверы BEA WebLogic, IBM WebSphere и др.);
• BMC Database Management - средство для администрирования, управления производительностью и восстановлением баз данных, управляемых СУБД ведущих производителей - Oracle, IBM, Microsoft, Sybase;
• BMC Infrastructure Management - средство для управления операционными системами серверов и мэйнфреймов, хранилищами данных, сетями, аппаратным обеспечением, ПО промежуточного звена, а также для оптимизации производительности указанных категорий программного обеспечения;
• BMC Operations Management - средство для выполнения рутинных операций по расписанию и для составления отчетов о событиях в сети;
• BMC Remedy Service Management - средство для поиска, обнаружения, моделирования сбоев в приложениях и реагирования на них;
• BMC Security Management - средство для управления правами доступа пользователей к приложениям и корпоративным ресурсам.

Данные приложений BMC могут храниться в базе данных о конфигурациях BMC Atrium CMDB (Configuration Management Database), обладающей удобными средствами визуализации данных.

Bmc software

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

Рис. 1. Области управления ИТ-инфраструктурой, охватываемые продуктами BMC

Computer associates

Семейство продуктов Unicenter для управления ИТ-инфраструктурой компании Computer Associates (CA) можно адаптировать для применения практически в любой вычислительной среде.

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

• Unicenter Asset Management - инструмент для автоматизации управления ИТ-активами предприятия, с помощью которого осуществляется комплексный учет и контроль ИТ-ресурсов. Функциональность системы Unicenter Asset Management способствует повышению качества управленческих решений, связанных с ИТ-активами предприятия, и уменьшению сопутствующих рисков. Unicenter Asset Management обеспечивает мониторинг использования приложений на серверах, персональных компьютерах и других клиентских устройствах. Кроме того, этот продукт позволяет автоматизировать процессы управления ИТ-активами, включая учет и инвентаризацию программных и аппаратных средств, работающих в сети предприятия, обслуживание различных составляющих ИТ-инфраструктуры, администрирование лицензий и формирование отчетов в гетерогенных средах (рис. 2);

Рис. 2. Области интегрированного управления ИТ-инфраструктурой, охватываемые продуктами Computer Associates

• Unicenter Software Delivery - обеспечивает автоматизацию процессов развертывания и обновления программного обеспечения на настольных, мобильных и карманных компьютерах, а также на серверах в гетерогенных сетевых средах, включая доставку приложений, распространение исправлений и обновлений, управление системными конфигурациями и откат инсталляций на различных программных и аппаратных платформах. Данный продукт создает условия для повышения оперативности работы ИТ-служб и снижения расходов на информационную поддержку бизнеса за счет автоматизации ИТ-процессов и внедрения каталогов приложений с развитыми возможностями самообслуживания. Одним из ключевых преимуществ Unicenter Software Delivery является высокая степень автоматизации процессов установки и обслуживания ПО и гибкое и детальное управление разрешениями на доставку приложений;
• Unicenter Remote Control - это надежная и защищенная корпоративная система удаленного управления Windows-компьютерами. Перечень задач удаленного управления включает обслуживание удаленных сервисов, таких как сетевые приложения, администрирование серверов и удаленное управление компьютерами конечных пользователей (например, при оказании технической поддержки). Эта система является одним из лучших отраслевых решений в своем классе и обеспечивает централизованное обслуживание систем, управление на основе политик, разграничение прав доступа, аудит сеансов и развитые возможности администрирования. Unicenter Remote Control полностью отвечает запросам крупных предприятий в части удаленного управления и позволяет оператору одновременно выполнять сразу несколько задач: копировать файлы на удаленный компьютер, общаться с пользователем, запускать приложения, наблюдать и фиксировать пользовательские действия, а также управлять параметрами настройки и безопасности. Отметим, что при разработке Unicenter Remote Control особое внимание было уделено сокращению сроков внедрения и освоения системы.

Hewlett-packard

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

Портфель программных решений HP OpenView состоит из нескольких семейств продуктов (рис. 3), среди которых средства управления серверами и приложениями, хранением данных, сетями, Интернет-технологиями и телекоммуникационным оборудованием (существует спектр продуктов HP OpenView, предназначенный специально для телекоммуникационных компаний, и сегодня НР является наиболее известным поставщиком средств управления телекоммуникационным оборудованием). Отдельно отметим наличие в портфеле решений HP средств управления ИТ-услугами.

Рис. 3. Портфель программных решений HP OpenView для ИТ-подразделений

К средствам управления серверами и приложениями следует отнести в первую очередь HP OpenView Operations for Windows и HP OpenView Operations for Unix . Эти продукты предназначены для мониторинга и управления производительностью приложений, а также для осуществления контроля событий в сети и приложениях. HP OpenView Operations for Windows интегрируется со средствами управления сетевой инфраструктурой HP OpenView Network Node Manager , что позволяет производить автоматический поиск новых серверов, добавленных в сеть, а затем выполнять автоматическое развертывание требующихся компонентов и политик на основе результатов поиска сервисов.

Hewlett-packard

Для управления производительностью приложений в состав указанного семейства входят средства HP OpenView Performance Manager и Performance Agents , позволяющие с помощью единого интерфейса осуществлять централизованный мониторинг, анализ и прогнозирование использования ресурсов в распределенных и неоднородных средах, а также HP OpenView Performance Insight, помогающий осуществлять мониторинг событий в сети и приложениях, анализировать их. Решения HP OpenVew Report Packs и HP OpenView Reporter предназначены для создания отчетов о работе распределенной IT-инфраструктуры предприятия на основе данных, полученных от приложений HP OpenView.

Для управления идентификацией и доступом к ИТ-ресурсам в состав семейства HP OpenView входят продукты HP OpenView Select Identity, HP OpenView Select Access и HP OpenView Select Federation , а для управления резервным копированием и восстановлением данных серверных СУБД - HP OpenView Storage Data Protector . Последний из названных продуктов является решением корпоративного уровня для защиты данных и восстановления систем в чрезвычайных ситуациях, реализующим технологию мгновенного восстановления, а также альтернативные варианты аварийного восстановления для устранения внеплановых простоев, что позволяет восстановить работоспособность информационной системы за несколько минут.

Отметим также наличие в данном семействе продуктов, предназначенных для осуществления взаимодействия с конечными пользователями с целью улучшения качества их обслуживания, - HP OpenView Service Desk , а также средства мониторинга бизнес-процессов HP OpenView Business Process Insight и средства управления архитектурой, ориентированной на сервисы, - HP OpenView Service Oriented Architecture Manager .

Hewlett-packard

Для управления Интернет-сервисами в данном семействе продуктов предусмотрено решение HP OpenView Internet Services , позволяющее осуществлять внешнее зондирование прикладных служб, Интернет-сервисов и протоколов посредством моделирования запросов пользователей к каталогам, почтовым службам, веб-службам, сервисам удаленного доступа (в том числе коммутируемого и беспроводного доступа).

Семейство продуктов IBM Tivoli, предназначенных для управления приложениями предприятий различного масштаба, основано на наборе базовых компонентов, из которых строится решение для конкретного предприятия. Главной отличительной особенностью данного семейства продуктов является так называемое упреждающее управление IT-инфраструктурой, способное выявлять и устранять неисправности еще до их возникновения. Продукты семейства Tivoli доступны для платформ AIX, HP-UX, Sun Solaris, Windows, Novell NetWare, OS/2, AS/400, Linux, z/OS, OS/390. Отметим, что в последнее время IBM рекомендует внедрять продукты семейства Тivoli с целью следования методикам библиотеки ITIL (Information Technology Infrastructure Library), сместив акцент в позиционировании своих продуктов с управления ИТ-ресурсами и системами на управление ИТ-услугами (рис. 4).

Рис. 4. Некоторые из программных продуктов Tivoli, поддерживающих ITIL-процесс управления услугами

Семейство продуктов Tivoli включает решения для управления конфигурацией и операционной поддержки:

• IBM Tivoli Configuration Manager - позволяет управлять установкой и обновлением ПО, в том числе и на карманные компьютеры;
• IBM Tivoli License Manager - предназначено для инвентаризации программного обеспечения;
• IBM Tivoli Remote Control - позволяет устанавливать политики для управления IT-ресурсами предприятия и удаленно администрировать настольные системы;
• IBM Tivoli Workload Scheduler - дает возможность автоматизировать рабочие нагрузки.

Помимо средств управления конфигурациями, семейство продуктов Tivoli включает решения для управления производительностью и доступностью:

• IBM Tivoli Monitoring - для осуществления распределенного мониторинга различных систем, автоматического обнаружения и устранения проблем и анализа тенденций;
• IBM Tivoli Monitoring for Databases (поддерживаются СУБД производства IBM, Oracle и Microsoft) и Tivoli Manager for Sybase - для централизованного управления серверами и базами данных;
• IBM Tivoli Monitoring for Web Infrastructure - для управления web-серверами и серверами приложений;
• IBM Tivoli Monitoring for Applications - для управления бизнес-приложениями SAP;
• IBM Tivoli Analyzer для Lotus Domino 6.0 и IBM Tivoli Monitoring for Transaction Performance - для обнаружения проблем производительности систем, основанных на серверных продуктах самой IBM;
• IBM Tivoli Web Site Analyzer - для анализа трафика посетителей, статистики посещаемости страниц, целостности информационного наполнения web-сайта;
• IBM Tivoli Service Level Advisor - для обеспечения упреждающего управления и прогнозирования отказов посредством количественного анализа производительности;
• IBM Tivoli NetView - для управления сетью;
• IBM Tivoli Switch Analyzer - для обнаружения и заполнения всех коммутаторов сетевого уровня;
• IBM Tivoli Enterprise Console - для многоуровневого поиска причин неисправностей и анализа событий.

Кроме того, имеется ряд решений для автоматизированного управления распределением ИТ-ресурсов и пиковыми нагрузками.

В состав семейства Tivoli входят также продукты для обеспечения безопасности:

• IBMDirectory Server - для синхронизации данных о безопасности в масштабе всех используемых приложений;
• IBM Directory Integrator - для интеграции идентификационных параметров, содержащихся в каталогах, базах данных, системах коллективной работы и бизнес-приложениях;
• IBM Tivoli Identity Manager и IBM Tivoli Access Manager for Operating Systems - для управления доступом к приложениям и операционным системам;
• IBM Tivoli Risk Manager - для централизованного управления защитой сети.

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

Microsoft

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

Основное назначение средств Microsoft Microsoft Systems Management Server (SMS) и Microsoft Operations Manager (MOM), а также средств администрирования, доступных пользователям последних версий серверных операционных систем Microsoft (таких, как Automated Deployment Services, Remote Installation Services, Microsoft Group Policy Management Console, Microsoft Windows Update Services), - управление программным обеспечением, автоматическая установка операционных систем Microsoft и предназначенных для них приложений, автоматическая доставка обновлений, управление доступом и правами пользвателей (рис. 5).

Рис. 5. Управление информационными системами с помощью Microsoft Operations Manager и Microsoft Systems Management Server

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

Microsoft

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

Рис. 6. Мониторинг состония серверов с помощью Microsoft Operations Manager

Для управления ИТ-инфраструктурой небольших компаний или специализированными группами серверов (до 10 шт.) предназначен продукт Microsoft Operations Manager 2005 Workgroup Edition . Он позволяет выявить потенциальные опасности в функционировании программного обеспечения и благодаря встроенным средствам анализа предотвратить перерастание их в серьезные проблемы, повысить эффективность ИТ-операций, упростить поддержку гетерогенных платформ и приложений, а также создавать собственные пакеты обновления.

Кроме того, существуют отдельные решения для управления произвоительностью и для анализа событий для компонентов ИТ-инфраструктуры, основанной на серверных продуктах Microsoft, такие как Active Directory Management Pack - для отслеживания состояния службы каталогов Active Directory, Exchange Management Pack - для управления сервисами обмена сообщениями и хранилищами данных Exchange, а также ряд других продуктов. Для обеспечения взаимодействия со средствами управления ИТ-инфраструктурой производства других компаний имеется продукт MOM Connector Framework , позволяющий осуществлять двунаправленную трансляцию предупреждений и синхронизацию данных с помощью web-служб.

Управление иб

1. Cobit - «цели контроля для информации и связанных с ней технологий»

• Читать раздел 1

Microsoft operational framework

• Читать раздел 1

Модель команды mof

• Читать раздел 1

Модель управления рисками mof

• Читать раздел 1

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

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

Стандарт CobiT включает в себя следующую серию книг:

1. Краткое изложение для руководства.

2. Основы.

3. Цели контроля (детализированных целей - 318 штук)

4. Руководство по управлению.

5. Руководство по проведению аудита.

6. Методики внедрения.

Стандарт CobiT выделяет 34 ИТ-процесса, объединенные в четыре следующие группы (рисунок 1.1):

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

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

Cobit - «цели контроля для информации и связанных с ней технологий»

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

4. Контроль – процессы управленческого надзора и независимой оценки с привлечением внутреннего и внешнего аудита или других источников.

Для каждого из 34 ИТ-процессов определена одна цель контроля уровня ИТ-процессов (намерение или желаемый результат, который достигается посредством внедрения процедур контроля в ИТ-деятельность). Данные цели контроля в дальнейшем разбиваются на детализированные цели контроля. Таких детализированных целей в стандарте CobiT определено 318.

Рисунок 1.1. ИТ-процессы CobiT

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

1. Полезность – информация является актуальной и соответствует БП, своевременно поставляется, непротиворечива и пригодна для использования.

2. Эффективность – предоставление информации на основе оптимального использования ресурсов.

3. Конфиденциальность – защита информации от НСД.

4. Целостность – точность и полнота информации в соответствии с бизнес-ценностями и ожиданиями.

5. Доступность – информация доступна по требованию БП в настоящее время и в будущем.

6. Соответствие требованиям – соответствие требованиям законодательства, регулирующих органов и договорных обязательств, которым подчиняются БП.

7. Достоверность – обеспечение руководства необходимой информацией для осуществления управления организацией и исполнения им обязанностей в отношении финансовой деятельности и представления отчетности регулирующим органам.

Cobit - «цели контроля для информации и связанных с ней технологий»

Цели контроля ИТ-процессов могут обеспечивать выше перечисленные требования к информации и быть основными либо второстепенными.

CobiT определяет также ИТ-ресурсы, которые задействованы в обеспечении выше указанных требований к информации. Выделено 5 классов ИТ-ресурсов:

1. Данные – информационные объекты в широком смысле, в том числе неструктурированные, графика, звук.

2. Приложения – совокупность ручных и программных процедур.

3. Технология – аппаратное обеспечение, ОС, СУБД, сети, мультимедиа, и т.д.

4. Инфраструктура – все ресурсы для размещения и поддержки ИС.

5. Персонал – включает в себя персонал и его навыки, осведомленность и умение планировать, организовывать, приобретать, поставлять, обслуживать и контролировать ИС и услуги.

Цели контроля ИТ-процессов, связь их с требованиями к информации и ИТ-ресурсами представлены на рисунке 1.2.

Рисунок 1.2. Цели контроля ИТ-процессов

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

В книге CobiT «Руководство по управлению» вводится модель уровня развития процессов организации с оценкой уровня развития от 0 (не существующего) до 5 (оптимизированного). Данная модель зрелости в дальнейшем используется при проведении аудитов ИТ-процессов и ответа на вопрос – в какой степени ИТ-процессы соответствуют необходимым требованиям. С этой точки зрения CobiT имеет хорошие точки соприкосновения с банковским стандартом России.

В CobiT для каждого из 34 процессов вводятся ключевые показатели достижения цели. Они определяют контрольные показатели, которые постфактум сигнализируют руководству о достижении процессом ИТ требований бизнеса. Эти контрольные показатели обычно выражены такими требованиями к информации как:

Cobit - «цели контроля для информации и связанных с ней технологий»

Доступность информации необходимой для обеспечения потребностей бизнеса.

Отсутствие рисков для целостности или конфиденциальности.

Рентабельность процессов и эксплуатации.

Подтверждение надежности, полезности и соответствия требованиям.

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

Для каждого из 34 ИТ-процессов определена качественная шкала (0-5), которая указывает – в каком случае процесс нужно относить к определенной модели уровня развития.

В книге CobiT «Руководство по проведению аудита», для каждого из 34 процессов определено, каким образом оценивать уровень его соответствия установленным требованиям. Для каждого из них определены:

1. Лица организации, которых следует опросить при проведении аудита.

2. Информация и документы, которые нужно получить от опрашиваемых лиц.

3. Факторы, которые требуется оценить (вида опросного листа).

4. Факторы, которые требуется протестировать (проверить).

В книге CobiT «Методики внедрения» говорится о том, на кого надо повлиять для внедрения COBIT в организации, дается план мероприятий по внедрению COBIT. Даются опросные листы для персонала, используемые на этапе внедрения, для внутренней оценки корпоративного управления ИТ, внутренней диагностики руководства. Приведены формы по аудиту и оценке риска.

Ветеринарно – санитарные требования к качеству воды (СанП и Н), гигиена поения. Расчеты в потребности воды.

высшего профессионального образования. «Российский государственный университет сервиса»

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

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

14.1.1. Основные понятия

На рис. 14.1 схематично представлены базовые понятия процесса Управления Доступностью.

Рис. 14.1. Концептуальные понятия процесса Управления Доступностью (источник: OGC)

Доступность

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

Сложности ИТ-инфраструктуры;

Надежности компонентов;

Способности быстро и эффективно реагировать на сбои;

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

Качества и границ компетенции процессов операционного управления.

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

Надежность компонентов, используемых для предоставления сервиса;

Способность сервиса или его компонентов эффективно функционировать, несмотря на сбой одной или нескольких подсистем (устойчивость);

Профилактическое обслуживание для предотвращения простоев.

Понятия «обслуживание» и «способность к восстановлению» предполагают выполнение работ по обеспечению функционирования сервиса и его восстановлению после сбоев, а также проведение профилактического обслуживания и регламентных (плановых) проверок, а именно:

Принятие мер по предотвращению сбоев;

Своевременное обнаружение сбоев;

Проведение диагностики, включая автоматическую самодиагностику компонентов;

Ликвидация сбоев;

Восстановление функционирования после сбоя;

Восстановление сервиса.

Предоставление сервиса внешними поставщиками

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

14.2. Цели процесса

Целью Процесса Управления Доступностью является обеспечение рентабельного и согласованного Уровня Доступности ИТ-сервиса, который поможет бизнесу в достижении поставленных целей. Такое определение цели процесса означает, что потребности заказчика (бизнеса) должны соответствовать тому, что могут предложить ИТ-инфраструктура и организация. Если имеется расхождение между спросом и предложением, тогда Процесс Управления Доступностью должен предложить выход из такой ситуации. Более того, данный процесс гарантирует оценку достигнутых Уровней Доступности и их дальнейшее совершенствование в случае необходимости. Это означает, что в рамках процесса выполняются как проактивные, так и реактивные виды деятельности. При разработке процесса следует исходить из следующих предпосылок:

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

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

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

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

14.2.1. Преимущества использования процесса

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

Создание единой точки контактов по вопросам доступности продуктов и услуг и наличие одного человека, отвечающего за эти вопросы;

Гарантируется соответствие новых продуктов и услуг предъявляемым к ним требованиям и согласованному с заказчиком стандарту доступности;

Уровень Затрат поддерживается на приемлемом уровне;

Постоянный мониторинг стандартов доступности и их совершенствование по мере необходимости;

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

Уменьшение количества отказов в доступе к системам и сокращение периода недоступности сервиса;

Смещение акцентов с исправления дефектов на улучшение сервиса;

Простота обоснования добавочной стоимости для ИТ-организации.

Процесс Управления Доступностью связан со следующими процессами ITIL.

Управление Уровнем Сервиса

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

Управление Конфигурациями

Процесс Управления Конфигурациями располагает информацией об инфраструктуре и может предоставлять ценную информацию Процессу Управления Доступностью.

Управление Мощностями

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

Управление Непрерывностью Сервиса

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

Управление Проблемами

Процесс Управления Проблемами непосредственно участвует в обнаружении причин существующих и потенциальных проблем в сфере доступности сервиса и в их устранении.

Управление Инцидентами

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

Управление Безопасностью

Процесс Управления Доступностью тесно связан с Процессом Управления Безопасностью, в котором основными вопросами являются:

Конфиденциальность;

Целостность;

Доступность.

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

Управление Изменениями

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

14.3. Процесс

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

Рис. 14.2. Входы и выходы Процесса Управления Доступностью (источник: OGC)

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

Входами для Процесса Управления Доступностью являются (рис. 14.2):

Требования бизнеса к доступности;

Оценка влияния на все бизнес-процессы, поддерживаемые ИТ;

Требования к доступности, надежности и обслуживанию ИТ-компонентов инфраструктуры;

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

Данные о конфигурациях услуг и их компонентах и данные мониторинга;

Достигнутые Уровни Сервиса в сравнении с согласованными уровнями для всех услуг, оговоренных в соглашении о предоставлении сервиса.

Выходы :

Критерии разработки архитектуры для обеспечения доступности и восстановления новых и улучшаемых ИТ-услуг;

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

Гарантии доступности, надежности и обслуживания компонентов инфраструктуры, необходимые для предоставления ИТ-сервиса;

Отчеты о достигнутых Уровнях Доступности, надежности и обслуживания;

Требования к мониторингу доступности, надежности и обслуживания;

План обеспечения доступности для проведения проактивного улучшения ИТ-инфраструктуры.

14.4. Виды деятельности

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

Планирование

Определение требований к доступности сервиса;

Проектирование систем для достижения требуемого Уровня Доступности;

Проектирование систем для достижения требуемой способности восстановления ;

Вопросы безопасности;

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

Разработка Плана Доступности.

Мониторинг

Проведение измерений и составление отчетов.

Ниже дается описание основных видов деятельности.

14.4.1. Определение требований к доступности сервиса

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

Ключевые бизнес-функции;

Согласованный период простоя ИТ-сервиса;

Количественная оценка требований к доступности сервиса;

Количественная оценка воздействия незапланированного простоя на бизнес-функции;

Рабочие часы заказчика;

Соглашения об «окнах» для планового обслуживания.

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

14.4.2. Проектирование систем для достижения требуемого Уровня Доступности

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

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключить с поставщиками эффективные договоры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента (CFIA – см. раздел 14.4.9) для выявления отказов, вызванных наличием SPOF, методика CCTA по анализу и Управлению Рисками (CRAMM – см. главу «Управление Непрерывностью ИТ-сервиса») и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучший путь – попытаться внести соответствующие усовершенствования в проект. В обеспечении соответствия стандартам может помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или изменение процесса проектирования.

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

14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания

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

14.4.4. Ключевые вопросы безопасности

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

Среди вопросов могут быть следующие :

Определение лиц, имеющих право доступа в защищенные области;

14.4.5. Управление Обслуживанием

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

Обслуживание следует проводить в такие периоды, когда степень его воздействия на предоставление услуг является минимальной. Это значит, что необходимо заранее определить цели обслуживания, период его проведения, и какие работы при этом будут выполняться (для этого можно использовать метод Анализа влияния отказа компонентов – CFIA). Такая информация об обслуживании очень важна для Процесса Управления Изменениями и для других процессов.

14.4.6. Проведение измерений и составление отчетов

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

Если вы не измеряете, вы не можете управлять.

Если вы не измеряете, вы не можете улучшать.

Если вы не измеряете, вам, вероятно, все равно.

Если вы не можете влиять, то не стоит и измерять.

Цикл жизни инцидента включает в себя следующие этапы:

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

Обнаружение : поставщик сервиса проинформирован о сбое. Инцидент получает статус «Сообщено». Затраченное на это время известно как время обнаружения.

Реагирование : поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполнение ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.

Ремонт : поставщик сервиса восстанавливает компоненты, которые вызвали сбой.

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

На рис. 14.3 показаны периоды времени, которые поддаются измерению.

Рис. 14.3. Измерение доступности (источник: OGC)

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

В Процессе Управления Доступностью, как правило, используются следующие метрики:

Среднее время ремонта (Mean Time to Repair – MTTR) : среднее время между возникновением сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления и обслуживаемость .

Среднее время между сбоями (Mean Time Between Failures – MTBF) : среднее время между восстановлением после одного сбоя и возникновением другого, также известное как «период работоспособного состояния» (uptime). Данная метрика относится к надежности сервиса.

Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI) : среднее время между двумя последовательными инцидентами. Данная метрика представляет собой сумму двух метрик MTTR и MTBF.

Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбоев или было несколько серьезных нарушений в работе.

В отчеты о доступности сервиса могут быть включены следующие метрики:

Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;

Общее время работоспособного состояния и время простоя;

Количество сбоев;

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

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

14.4.7. Разработка Плана Обеспечения Доступности

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

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

14.4.8. Инструментальные средства

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

Определение времени простоя;

Фиксация исторической информации;

Создание отчетов;

Статистический анализ;

Анализ воздействия.

Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.

14.4.9. Методы и методики

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

Анализ влияния отказа компонентов (CFIA)

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

Пример матрицы CFIA на рис. 14.4 показывает, что Конфигурационные Единицы, которые для многих услуг помечены символом «X», являются важными элементами ИТ-инфраструктуры (анализ по горизонтали) и что услуги, часто отмечаемые символом «X», являются комплексными и подвержены сбоям (анализ по вертикали). Этот метод также можно применять для изучения степени зависимости от сторонних организаций (усовершенствованный метод CFIA).

Конфигурационная единица	Услуга А	Услуга Б
PC № 1	B	B
PC № 2		B
Кабель № 1	B	B
Кабель № 2		B
Разъем № 1	X	X
Разъем № 2		X
Сегмент сети Ethernet	X	X
Маршрутизатор	X	X
Канал глобальной сети (WAN)	X	X
Маршрутизатор	X	X
Сегмент	X	X
Сетевой информационный центр	A	A
Сервер	B	B
Системное программное обеспечение	B	B
Приложения	B	B
База данных	X	X

X – сбой/дефект означает, что услуга недоступна

А – безотказная конфигурация

В – безотказная конфигурация, с переключением

« » – нет воздействия

Рис. 14.4. Матрица CFIA (