50. Определение времени возможных простоев.

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

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

Основные цели CFIA:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 подготовка отчетов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 наличие одного ответственного за доступность ИТ-услуг;

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

 уменьшение частоты и длительности отказов ИТ-услуг с течением времени;

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

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

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

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

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

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

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

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