Консалтинг и ИТ-решения
Повысить имидж вашей компании и расширить возможности международного сотрудничества
Консалтинг
и ИТ решения
Подробнее
Курсы в Москве

SCHEDULE Расписание курсов

ITSS Курс «Управление стратегией ИТ-услуг на основе ITIL®»

AJAB Курс «Настройка и администрирование jira Software, настройка функциональности для работы по Scrum и Kanban»

ITILF Курс «Основы ITIL®»

COBIT5F «Основы COBIT 5»

PRINCE2F Курс «Основы управления проектами в соответствии с PRINCE2®»

MLF Курс «Основы машинного обучения»

OSA Курс «Service Desk и процессы оперативного управления ИТ-услугами в соответствии с ITIL®»

DMLF Курс «Основы глубокого машинного обучения»

ITPM Курс «Инструменты управления ИТ-проектами»

RCV Курс «Проведение изменений в ИТ в соответствии с ITIL®»

MSA Курс «Микросервисная архитектура»

PPO Курс «Оптимальное проектирование ИТ-услуг в соответствии с ITIL®: информационная безопасность, мощность, доступность, непрерывность»

ITHR Курс «Управление ИТ-персоналом»

COBIT-ICS Курс «Система внутреннего контроля ИТ по модели COBIT(COBIT Internal Control System)»

DevOps Курс «Основы DevOps»

SOA Курс «Управленческие инструменты организации отношений ИТ с бизнесом на основе ITIL®»

AWS Курс «Мастерская проектирования ИТ-решений»

BCH Курс «Технология блокчейн»

MALC Курс «Управление жизненным циклом услуг»

ITAM Курс «Управление ИТ-активами. Основы и практики»

ITILP Курс «ITIL Practitioner. Практические подходы для успешной работы»

ITAMP Курс «Практики управления ИТ-активами»

BAF Курс «Основы бизнес-анализа»

BASRM Курс «Бизнес-анализ. Управление требованиями к ПО»

QA Курс «QA и тестирование программного обеспечения»

BPA Курс «Моделирование, анализ и оптимизация бизнес-процессов»

SYSA Курс «Системный анализ»

CMMP Курс «Модель CMMI Development V2.0 — руководство к действию»

RISK Курс «Практические подходы управления ИТ-рисками»

AGILE: Гибкие методы управления

ITSO Курс «Эксплуатация услуг по модели ITIL®»

MSA4ITSM Курс «Управление ИТ в условиях применения микросервисной архитектуры»

ITLM Мастер-класс «Разработка карты ИТ‑ландшафта»

ITSD Курс «Проектирование услуг по модели ITIL®»

ITST Курс «Преобразование услуг по модели ITIL®»

CSI Курс «Постоянное совершенствование услуг по модели ITIL® (ITIL Continual Service Improvement)»


Наш канал на youtube
Здесь вы найдёте записи вебинаров и других видео наших экспертов на тему ITIL и не только
Тренажер подготовки к экзамену ITIL Foundation
Страховой сертификат повторной сдачи экзамена
  • 31243

    Количество выданных сертификатов

  • 2754

    Количество проведенных игр и семинаров

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

Отказ одного компонента системы может привести к отказу всей системы / всего сервиса, или привести к частичному отказу системы/сервиса, или не привести к отказу вовсе. Как получить наглядную картинку, демонстрирующую влияние отказа компонентов на доступность сервиса?

CFIA – один из вариантов ответа на этот вопрос. CFIA – это Component Failure Impact Analysis, метод анализа влияния отказа компонента.

Изначально разработанная компанией IBM, а затем ставшая частью библиотеки ITIL®, методика CFIA чаще всего используется в процессе управления доступностью. Например, в ITIL® v3, CFIA рассматривается как часть проактивной составляющей процесса управления доступностью. Основные возможности методики CFIA:

Давайте разберемся как в несколько шагов реализовать CFIA:

Если сбой КЕ не влияет на доступность сервиса, оставьте поле пустым.

В итоге получится матрица CFIA, где основное внимание требуется уделить значениям Х и М

КЕ \ ИТ-сервисы

Сервис 1

Сервис 2

Приложение 1

X

Приложение 2

X

Кабель 1

M

M

Кабель 2

M

M

Кабель 3

M

M

Диск

A

A

ПК 1

X

ПК 2

X

Сервер

X

X

Маршрутизатор

A

UPS

X

M

матрица CFIA

Чем больше сервисов затрагивает сбой КЕ, тем больше значимость этой КЕ, которая в случае наличия отметки Х будет являться единой точкой отказа (SPOF). Чем больше КЕ в составе сервиса помечены отметкой Х, тем больше уязвимость данного сервиса.

Задумайтесь над следующими вопросами:

  • Является ли эта КЕ единой точкой сбоя (SPOF)?
  • Как влияет отказ данной КЕ на работу сервиса? Ведет к полной остановке сервиса? Приводит к неработоспособности нескольких пользователей? Какие потери бизнеса возможны при сбое?
  • Какова вероятность выхода из строя данной КЕ? Что можно сделать, чтобы этого избежать?
  • Могут ли изменения привести к сбою данного компонента? Может ли пользователь явиться причиной сбоя?
  • Стоит ли задуматься о мерах избыточности? Сколько это будет стоить?

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

  • Как мы реагируем на сбой КЕ?
  • Каким процедурам мы следуем? Они документированы? Они могут быть улучшены? Они могут быть автоматизированы?
  • Следует ли дополнительно обучить персонал?
  • Следует ли использовать новые инструменты и техники?

Хорошо организованная методика CFIA на любом уровне (инфраструктура, процесс, организация) будет являться наглядным источником информации для принятия решений и анализа RFC (Request for Change – запросов на изменение), не требуя при этом высокой зрелости процессов или дорогостоящих средств автоматизации.

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

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

Подробнее эта тема обсуждается на следующих курсах:

Вверх