Текст книги "ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL"

Автор книги: Jan van Bon

сообщить о нарушении

Текущая страница: 15 (всего у книги 18 страниц)

? План восстановления работы;

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

? План руководства на случай кризисной ситуации и связь с общественностью (PR).

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

? План размещения и оказания услуг;

? План по вычислительным системам и локальным сетям;

? План по телекоммуникациям (доступ и каналы связи);

? План обеспечения безопасности (целостность данных и сетей);

? План по персоналу;

? Финансовые и административные планы.

13.4.6. Применение превентивных мер и способов восстановления

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

? Использование бесперебойных источников питания и резервных источников электропитания;

? Использование отказоустойчивых систем[227]227
  Fault-tolerant Systems.


[Закрыть];

Использование удаленных систем хранения данных и RAID-массивов и т. д.

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

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

? поддержка и оснащение средств восстановления;

? закупка и установка резервного аппаратного обеспечения (неактивированные договоры);

? управление неактивированными ("дремлющими") договорами.

13.4.7. Разработка планов и процедур восстановления

Планы должны быть разработаны в деталях и стать официальными документами, т. к. Планы восстановления требуют поддержки, и все изменения в них должны согласовываться заинтересованными сторонами. Эта информация также должна доводиться до сведения всех участников. Основные проблемы связаны с изменениями в инфраструктуре и Изменениями Уровней Сервиса. Например, переход на новую платформу среднего класса[228]228
  Midrange Platform.


[Закрыть] может привести к тому, что не будет эквивалентного оборудования в резервном центре «теплого», внешнего старта. По этой причине Процесс Управления Конфигурациями играет важную роль в мониторинге базисных конфигураций с учетом Плана восстановления. В плане также должны быть определены процедуры, необходимые для его выполнения.

План восстановления

План восстановления должен включать все виды деятельности по восстановлению бизнес-активности и ИТ-услуг:

? Введение – описание структуры плана и предполагаемых средств восстановления.

? Обновление – описание процедур и соглашений по поддержке актуальности плана и отслеживанию изменений в инфраструктуре.

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

? Начало восстановления – описание времени и условий начала действия плана.

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

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

? Администрация – как и когда вводить план в действие, какие руководители и специалисты участвуют в нем, где находиться центр управления?

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

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

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

? Площадки восстановления – информация о договорах, персонале с указанием конкретных функций, системе безопасности и транспорте.

? Возврат к нормальным условиям – процедуры восстановления нормальной инфраструктуры (например, здания), условия, при которых начинают действовать эти процедуры и соответствующие неактивированные ("дремлющие") контракты.

Процедуры

Процедуры разрабатываются на основе Плана восстановления. Они должны быть эффективными[229]229
  Effective.


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

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

? восстановление приложений, баз данных и других данных.

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

13.4.8. Начальное тестирование

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

13.4.9. Обучение и осведомление

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

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

13.4.10. Анализ и аудит

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

13.4.11. Тестирование

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

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

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

13.4.13. Обеспечение гарантий[230]230
  Assurance.


[Закрыть]

Обеспечение гарантий работоспособности процесса означает проверку соответствия качества процесса (процедур и документации) бизнес-потребностям компании.

13.5. Управление Процессом

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

13.5.1. Отчеты для руководства

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

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

13.5.2. Критические факторы успеха и ключевые показатели качества

Успех Процесса Управления Непрерывностью ИТ-сервисов зависит от следующих факторов:

? наличия эффективного Процесса Управления Конфигурациями;

? поддержки процесса всеми в компании;

? наличия современных эффективных инструментальных средств;

? проведения специального обучения для всех участников данного процесса;

? регулярного тестирования плана восстановления без предварительного уведомления.

Ключевыми показателями качества являются:

? количество выявленных ошибок в планах восстановления;

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

? стоимость процесса.

13.5.3. Функции и роли

Задачи Руководителя Процесса Управления Непрерывностью ИТ-сервисов состоят во внедрении и обеспечении поддержки процесса ITSCM для постоянного выполнения всех требований по Управлению Непрерывностью Бизнеса (ВСМ) и представлении функций ИТ-сервисов в рамках процесса ВСМ.

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

Совет директоров	Инициация процесса ВСМ Выделение персонала и ресурсов Выработка политики Определение полномочий в рамках процесса	Руководство действиями в кризисной ситуации Принятие корпоративных/бизнес-решений
Высшее руководство	Управление Процессом ITSCM Утверждение планов, отчетов о тестировании и т. д. Коммуникации в компании и создание осведомленности в компании Интеграция процесса ITSCM в процесс ВСМ	Координация и арбитраж (принятие окончательных решений) Предоставление персонала, ресурсов и финансовых средств
Руководство	Проведение анализа рисков Определение, какие должны быть результаты работы Составление проектов договоров Руководство тестированием, оценкой и составлением отчетов	Приведение в действие механизмов восстановления и обеспечения Руководство командами непрерывности Составление отчетов
Руководители команд и члены команд	Проработка способов достижения результатов работы Ведение переговоров по предоставляемым услугам Проведение тестов, оценок и составление отчетов	Разработка и внедрение процедур Реализация плана восстановления

Таблица 13.1. Примеры видов ответственности в рамках Процесса Управления Непрерывностью ИТ-сервисов

13.6. Проблемы и затраты

13.6.1. Затраты

Основные затраты, связанные с реализацией Процесса Управления Непрерывностью следующие:

? затраты времени и средств на инициацию, разработку и внедрение процесса ITSCM.

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

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

? повторяющиеся операционные расходы на тестирование, аудит и корректировку планов.

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

13.6.2. Проблемы

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

? Ресурсы – организация должна предоставить дополнительные мощности проектной команде для разработки и тестирования плана.

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

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

? Оценка потерь – некоторые потери, такие как потеря репутации, нельзя измерить в денежном выражении.

? Составление бюджета – не всегда удается добиться понимания необходимости в дорогих средствах восстановления функциональности, иногда происходит сокращение Планов восстановления.

? Отсутствие обязательств со стороны бизнес-руководителя – это ведет к неудаче в разработке процесса ITSCM, хотя заказчик может полагать, что все необходимое сделано.

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

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

? ИТ-подразделение – в своей работе должно руководствоваться действительными пожеланиями и требованиями бизнеса, а не своими предположениями.

? Знание бизнеса – важно, чтобы бизнес поддерживал разработку процесса ITSCM путем определения основных направлений работы.

? Отсутствие осведомленности в компании – необходимо, чтобы вся организация знала о значимости процесса ITSCM. Без информирования персонала и его поддержки процесс обречен на неудачу.

Глава 14 Управление Доступностью

14.1. Введение

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

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

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

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

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

Доступность

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

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

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

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

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

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

Надежность[231]231
  Reliability.


[Закрыть]

Надежность, в контексте данного процесса, означает доступность сервиса в течение согласованного периода времени без каких-либо сбоев. Эта концепция включает в себя понятие устойчивости[232]232
  Resilience – устойчивость: способность сервиса сохранять доступность при себе одного или нескольких ИТ-компонент. – Прим. ред.


[Закрыть]. Надежность сервиса будет возрастать, если предпринимать превентивные меры против возникновения простоев. Надежность сервиса является статистическим показателем и определяется сочетанием следующих факторов:

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

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

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

Обслуживание[233]233
  Maintainability.


[Закрыть]

Понятия "обслуживание" и "способность к восстановлению"[234]234
  Recoverability.


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

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

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

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

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

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

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

Предоставление сервиса внешними поставщиками[235]235
  Serviceability.


[Закрыть]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14.3. Процесс

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

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

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

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

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

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

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

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

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

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

Выходы:

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

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

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

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

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

? план обеспечения доступности[236]236
  Availability Plan.


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

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

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

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

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

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

? проектирование систем для достижения требуемой способности восстановления[237]237
  Recoverability.


[Закрыть];

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

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

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

? Мониторинг

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

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

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

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

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

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

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

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

? рабочие часы заказчика;

? соглашения об "окнах" для планового обслуживания.

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

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

Следует как можно раньше выявить различные виды уязвимости, влияющие на доступность. Это позволит избежать неоправданно высокой стоимости разработки, незапланированных расходов на более поздних этапах, наличия Единой точки сбоя[238]238
  Single Points of Failures – SPOF.


[Закрыть] (SPOF), дополнительных затрат по счетам поставщиков и задержек с выпуском релизов

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключить с поставщиками эффективные договоры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента[239]239
  Component Failure Impact Analysis – CFIA.


[Закрыть] (CFIA – см. раздел 14.4.9) для выявления отказов, вызванных наличием SPOF, методика CCTA по анализу и Управлению Рисками[240]240
  CCTA Risk Analysis and Management – CRAMM.


[Закрыть] (CRAMM – см. главу «Управление Непрерывностью ИТ-сервиса») и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучший путь – попытаться внести соответствующие усовершенствования в проект. В обеспечении соответствия стандартам может помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или изменение процесса проектирования.

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

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

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