Непрерывность бизнеса и Отказоустойчивость IT.
Их считают синонимами, но…
Бизнесу не нужна отказоустойчивость IT систем, ему нужна непрерывность деятельности компании и бизнес-процессов. В то же время, каждый день мы слышим от IT директоров один и тот же вопрос:
Как строить и эксплуатировать IT инфраструктуру так, чтобы она была отказоустойчивой?
И это ошибка!
Компании рассчитывают на непрерывность деятельности, а доступность IT инфраструктуры лишь одно из средств её достижения.
Их считают синонимами, но…
Бизнесу не нужна отказоустойчивость IT систем, ему нужна непрерывность деятельности компании и бизнес-процессов. В то же время, каждый день мы слышим от IT директоров один и тот же вопрос:
Как строить и эксплуатировать IT инфраструктуру так, чтобы она была отказоустойчивой?
И это ошибка!
Компании рассчитывают на непрерывность деятельности, а доступность IT инфраструктуры лишь одно из средств её достижения.
Давайте рассмотрим разницу:
Business continuity (Непрерывность бизнеса )- стратегическая и тактическая способность организации планировать свою работу в случае инцидента и нарушения ее деятельности, направленная на обеспечение непрерывности деловых операций на установленном приемлемом уровне. (ГОСТ Р ИСО 22301-2014)
Эта способность относится к бизнес-процессам, бизнес-функциям и деятельности предприятия в целом. Тут задействованы и элементы IT инфраструктуры, но не для всех бизнес-процессов нужна высоко доступная инфраструктура. Для некоторых организаций, например, отказ инфраструктуры на 24 часа незначительно влияет на бизнес.
Availability (Доступность) - свойство быть доступным и готовым к использованию по запросу авторизованного субъекта. (ГОСТ Р ИСО/МЭК 27000 - 2012)
Это относится к серверным платформам, сетевой инфраструктуре, программным средствам и другим составным частям IT в компании. Очевидно, что IT инфраструктура является фундаментом для работы всех процессов, где есть автоматизация, но прямого отношения к ожиданиям бизнеса она не имеет.
Business continuity (Непрерывность бизнеса )- стратегическая и тактическая способность организации планировать свою работу в случае инцидента и нарушения ее деятельности, направленная на обеспечение непрерывности деловых операций на установленном приемлемом уровне. (ГОСТ Р ИСО 22301-2014)
Эта способность относится к бизнес-процессам, бизнес-функциям и деятельности предприятия в целом. Тут задействованы и элементы IT инфраструктуры, но не для всех бизнес-процессов нужна высоко доступная инфраструктура. Для некоторых организаций, например, отказ инфраструктуры на 24 часа незначительно влияет на бизнес.
Availability (Доступность) - свойство быть доступным и готовым к использованию по запросу авторизованного субъекта. (ГОСТ Р ИСО/МЭК 27000 - 2012)
Это относится к серверным платформам, сетевой инфраструктуре, программным средствам и другим составным частям IT в компании. Очевидно, что IT инфраструктура является фундаментом для работы всех процессов, где есть автоматизация, но прямого отношения к ожиданиям бизнеса она не имеет.
Рассмотрим на примерах:
Ситуация 1
Требования к непрерывности избыточны.
Сервер вышел из строя и стал причиной аварии сайта-лэндинга для регистрации пользователей по промо-акции. Маркетинговый бюджет потрачен с меньшей эффективностью, но текущие клиенты и бизнес не пострадали, так как сервисы компании на других площадках продолжали работать.
Устранение нарушения в течение 24 часов будет иметь несущественное влияние.
Ситуация 2
Требования к непрерывности работы IT систем занижены.
Принятые меры не соответствуют требованиям непрерывности бизнеса.
Процессинговая компания
Работает 24 на 7
2 распределенных ЦОД
Из-за ошибки администратора, в ходе работ на системе хранения данных (СХД) происходит авария.
Останавливается работа 15 баз данных, включая критичные для бизнеса.
В момент аварии выясняется:
Бизнес готов к простою максимум 15 минут
Быстро восстановиться на резервном ЦОДе невозможно, так как текущее резервирование баз данных не обеспечивает нужного времени восстановления.
Есть BackUp, но время восстановления тома - 8 часов
Критичные виртуальные машины подняли быстро, но часть зависимостей не задокументирована, на что уходит ещё 2 часа
Под зависимости не хватает ресурсов на резервном ЦОДе и для этого перевозится дополнительное оборудование
Часть инфраструктуры размещается в публичном облаке, но из-за отпуска специалиста по сетям, процесс занимает ещё 3 часа
Спустя 13 часов после аварии система восстановлена, но работает неполноценно, включая слетевшие лицензии, на актуализацию которых уходит ещё 2 часа
Итоговое время полного восстановления работы IT систем составило 15 часов.
Последствия:
Полная потеря данных от последней резервной копии до момента устранения аварии
Остановка работы ключевых подразделений
Штрафы за простой от клиентов
Репутационные потери
Что послужило причиной продолжительного восстановления:
1) Способы резервирования систем не соответствовали требованиям бизнеса
2) Отсутствие плана действий в момент аварии
3) Отсутствие актуальной информации о достаточности ресурсов на резервной площадке
4) В процессе эксплуатации не проводились учения по выходу из аварийной ситуации
К каким выводам пришла компания:
Избыточная инфраструктура, а это 2 и более ЦОДа - не единственная мера в достижении непрерывности работы приложения
Ожидания бизнеса - больше, чем включенная инфраструктура
На практике, требуется полное восстановление бизнес-процессов
Часто, при построении инфраструктуры, IT отделы компаний не выполняют требования бизнеса и не договариваются о действиях в момент аварии. Это влечёт за собой колоссальные затраты на инфраструктуру, которая не соответствует требованиям бизнеса, не говоря о потерях во время самой аварии.
Ситуация 1
Требования к непрерывности избыточны.
Сервер вышел из строя и стал причиной аварии сайта-лэндинга для регистрации пользователей по промо-акции. Маркетинговый бюджет потрачен с меньшей эффективностью, но текущие клиенты и бизнес не пострадали, так как сервисы компании на других площадках продолжали работать.
Устранение нарушения в течение 24 часов будет иметь несущественное влияние.
Ситуация 2
Требования к непрерывности работы IT систем занижены.
Принятые меры не соответствуют требованиям непрерывности бизнеса.
Процессинговая компания
Работает 24 на 7
2 распределенных ЦОД
Из-за ошибки администратора, в ходе работ на системе хранения данных (СХД) происходит авария.
Останавливается работа 15 баз данных, включая критичные для бизнеса.
В момент аварии выясняется:
Бизнес готов к простою максимум 15 минут
Быстро восстановиться на резервном ЦОДе невозможно, так как текущее резервирование баз данных не обеспечивает нужного времени восстановления.
Есть BackUp, но время восстановления тома - 8 часов
Критичные виртуальные машины подняли быстро, но часть зависимостей не задокументирована, на что уходит ещё 2 часа
Под зависимости не хватает ресурсов на резервном ЦОДе и для этого перевозится дополнительное оборудование
Часть инфраструктуры размещается в публичном облаке, но из-за отпуска специалиста по сетям, процесс занимает ещё 3 часа
Спустя 13 часов после аварии система восстановлена, но работает неполноценно, включая слетевшие лицензии, на актуализацию которых уходит ещё 2 часа
Итоговое время полного восстановления работы IT систем составило 15 часов.
Последствия:
Полная потеря данных от последней резервной копии до момента устранения аварии
Остановка работы ключевых подразделений
Штрафы за простой от клиентов
Репутационные потери
Что послужило причиной продолжительного восстановления:
1) Способы резервирования систем не соответствовали требованиям бизнеса
2) Отсутствие плана действий в момент аварии
3) Отсутствие актуальной информации о достаточности ресурсов на резервной площадке
4) В процессе эксплуатации не проводились учения по выходу из аварийной ситуации
К каким выводам пришла компания:
Избыточная инфраструктура, а это 2 и более ЦОДа - не единственная мера в достижении непрерывности работы приложения
Ожидания бизнеса - больше, чем включенная инфраструктура
На практике, требуется полное восстановление бизнес-процессов
Часто, при построении инфраструктуры, IT отделы компаний не выполняют требования бизнеса и не договариваются о действиях в момент аварии. Это влечёт за собой колоссальные затраты на инфраструктуру, которая не соответствует требованиям бизнеса, не говоря о потерях во время самой аварии.
С целью найти ответы на эти вопросы и стать ведущими экспертами по BC и DRP, мы прошли длинный путь:
-5 лет тестировали сотни способов резервирования и восстановления IT систем, для оптимизации работ и составления инструкций для IT специалистов.
-Прошли курсы по BC на Аdviser и внедрили стандарты отрасли у себя
-Описали требования к непрерывности в своей компании, но кирпич бумаги на 350 страниц оказался не слишком применим в работе
-Прошли сертификацию у разработчиков стандартов ISO в области (EXIN.com)
-Получили сертификат Business Continuity management system (ISO 22301)
-Получили сертификат Information security managment system (ISO 27001)
-Познакомились с коллегами из большой четверки аудиторов:
Deloitte Touche Tohmatsu
PricewaterhouseCoopers
Ernst & Young
KPMG
-Узнали, как формализовать требования бизнеса
-Реализовали пилотные проекты и создали систему обеспечения BC
-Внедрили непрерывный процесс внесения изменений – развивая глубокие компетенции и внося улучшения в процесс производства
-5 лет тестировали сотни способов резервирования и восстановления IT систем, для оптимизации работ и составления инструкций для IT специалистов.
-Прошли курсы по BC на Аdviser и внедрили стандарты отрасли у себя
-Описали требования к непрерывности в своей компании, но кирпич бумаги на 350 страниц оказался не слишком применим в работе
-Прошли сертификацию у разработчиков стандартов ISO в области (EXIN.com)
-Получили сертификат Business Continuity management system (ISO 22301)
-Получили сертификат Information security managment system (ISO 27001)
-Познакомились с коллегами из большой четверки аудиторов:
Deloitte Touche Tohmatsu
PricewaterhouseCoopers
Ernst & Young
KPMG
-Узнали, как формализовать требования бизнеса
-Реализовали пилотные проекты и создали систему обеспечения BC
-Внедрили непрерывный процесс внесения изменений – развивая глубокие компетенции и внося улучшения в процесс производства
В результате, мы определили, как правильно выстроить работу IT систем и обеспечить непрерывность бизнеса:
1 этап.
BIA (Business Impact Analysis)
Метод используют для определения:
-Критичности процессов организации
-Уровня влияния на бизнес в зависимости от времени простоя
-Максимального времени простоя (RTO, RPO, MTD - Maximum Tolerable Downtime)
-Перечня задействованных ресурсов (активы, персонал, технологии, площади и информация и т.д.)
Метод помогает найти взаимосвязи между процессами, внутренними и внешними сторонами и всеми цепочками поставок.
По результатам BIA получаем требования к непрерывности работы бизнес-процессов, а также всех задействованных ресурсов, в том числе IT Систем
В частности:
RTO (recovery time objective) - период времени после нарушения, в течение которого должны быть восстановлены минимальные уровни услуг и (или) продукты, а также поддерживающие системы, прикладные программы или функции (ГОСТ Р ИСО/МЭК 27031-2012).
Этап BIA необходим для формулирования требований бизнеса к целевому времени восстановления бизнес-приложений.
2 этап.
Анализ текущей IT инфраструктуры
Выясняем, может ли обеспечить действующая инфраструктура необходимый уровень RTO:
-Соотносим все компоненты с IT системами, участвующими в организации непрерывной работы
-Проверяем архитектуру резервирования и избыточность
-Готовим перечень рекомендаций и проект новой архитектуры (если требуется)
-На основе данных мониторинга, сразу может быть проведена оптимизация ресурсов
Устранив все выявленные нарушения в IT инфраструктуре, нельзя быть уверенным в успешности выхода из аварийных ситуаций, пока не будут разработаны:
-DRP- план аварийного восстановления
-RunBook- инструкции, описывающие последовательность действий для команды восстановления
Тут компании часто упускают факт:
Время восстановления бизнес-процесса не равно времени восстановления виртуальной машины, работы сервера или ЦОДа целиком.
После восстановления инфраструктуры требуется время на возврат к стандартным бизнес-операциям. А на пути к этому могут встречаться: переиндексация баз данных, восстановление доступа пользователей, переустановка лицензий ПО и т.д. Это нужно учитывать при формировании требований к RTO и выборе технологий резервирования.
3 этап.
Составляем план Резервирования и резервного копирования.
Это эксплуатационный документ, необходимый для профилактики возникновения серьезных аварий. Он содержит способы резервирования компонент IT инфраструктуры и плановое время восстановления по каждому, а также частоту и глубину резервного копирования данных.
В результате вы должны быть уверены, что все системы будут восстановлены на резервной площадке и данные в системах будут актуальны.
4 этап.
RunBook - пошаговая инструкция для восстановления
Документ, в котором зафиксирована последовательность действий для переключения на резервную площадку в момент аварии. В нём регламентирован порядок запуска IT систем и компонент. Уровень детализации должен быть достаточным для исключения ошибок инженеров по восстановлению.
5 этап.
DRP (Disaster recovery plan) План аварийного восстановления
Этот документ отвечает на вопрос: что делать в момент аварии?
-Описывает порядок действий
-Регламентирует зоны ответственности
-Закрепляет состав команд и их ответственность
6 этап. Тестирование
Для того что бы быть уверенным в готовности к аварийной ситуации обязательно проводить процедуру тестирования, при этом делать это нужно с определенной регулярностью.
Например: 1 раз в 6 месяцев или после внесения существенных изменений в IT инфраструктуру.
7 этап. Внесение изменений
После тестирования необходимо провести «работу над ошибками» и адаптировать IT системы к новым данным, с целью исключения ошибок.
1 этап.
BIA (Business Impact Analysis)
Метод используют для определения:
-Критичности процессов организации
-Уровня влияния на бизнес в зависимости от времени простоя
-Максимального времени простоя (RTO, RPO, MTD - Maximum Tolerable Downtime)
-Перечня задействованных ресурсов (активы, персонал, технологии, площади и информация и т.д.)
Метод помогает найти взаимосвязи между процессами, внутренними и внешними сторонами и всеми цепочками поставок.
По результатам BIA получаем требования к непрерывности работы бизнес-процессов, а также всех задействованных ресурсов, в том числе IT Систем
В частности:
RTO (recovery time objective) - период времени после нарушения, в течение которого должны быть восстановлены минимальные уровни услуг и (или) продукты, а также поддерживающие системы, прикладные программы или функции (ГОСТ Р ИСО/МЭК 27031-2012).
Этап BIA необходим для формулирования требований бизнеса к целевому времени восстановления бизнес-приложений.
2 этап.
Анализ текущей IT инфраструктуры
Выясняем, может ли обеспечить действующая инфраструктура необходимый уровень RTO:
-Соотносим все компоненты с IT системами, участвующими в организации непрерывной работы
-Проверяем архитектуру резервирования и избыточность
-Готовим перечень рекомендаций и проект новой архитектуры (если требуется)
-На основе данных мониторинга, сразу может быть проведена оптимизация ресурсов
Устранив все выявленные нарушения в IT инфраструктуре, нельзя быть уверенным в успешности выхода из аварийных ситуаций, пока не будут разработаны:
-DRP- план аварийного восстановления
-RunBook- инструкции, описывающие последовательность действий для команды восстановления
Тут компании часто упускают факт:
Время восстановления бизнес-процесса не равно времени восстановления виртуальной машины, работы сервера или ЦОДа целиком.
После восстановления инфраструктуры требуется время на возврат к стандартным бизнес-операциям. А на пути к этому могут встречаться: переиндексация баз данных, восстановление доступа пользователей, переустановка лицензий ПО и т.д. Это нужно учитывать при формировании требований к RTO и выборе технологий резервирования.
3 этап.
Составляем план Резервирования и резервного копирования.
Это эксплуатационный документ, необходимый для профилактики возникновения серьезных аварий. Он содержит способы резервирования компонент IT инфраструктуры и плановое время восстановления по каждому, а также частоту и глубину резервного копирования данных.
В результате вы должны быть уверены, что все системы будут восстановлены на резервной площадке и данные в системах будут актуальны.
4 этап.
RunBook - пошаговая инструкция для восстановления
Документ, в котором зафиксирована последовательность действий для переключения на резервную площадку в момент аварии. В нём регламентирован порядок запуска IT систем и компонент. Уровень детализации должен быть достаточным для исключения ошибок инженеров по восстановлению.
5 этап.
DRP (Disaster recovery plan) План аварийного восстановления
Этот документ отвечает на вопрос: что делать в момент аварии?
-Описывает порядок действий
-Регламентирует зоны ответственности
-Закрепляет состав команд и их ответственность
6 этап. Тестирование
Для того что бы быть уверенным в готовности к аварийной ситуации обязательно проводить процедуру тестирования, при этом делать это нужно с определенной регулярностью.
Например: 1 раз в 6 месяцев или после внесения существенных изменений в IT инфраструктуру.
7 этап. Внесение изменений
После тестирования необходимо провести «работу над ошибками» и адаптировать IT системы к новым данным, с целью исключения ошибок.
По результатам исследований UpTime Institute:
34% компаний сталкивались с серьезной аварией на IT инфраструктуре за последние 12 месяцев. 50% в течении 3-х лет.
60% респондентов называют причиной аварии некачественные внутренние процессы или неверно выбранную архитектуру ИКТ.
34% компаний сталкивались с серьезной аварией на IT инфраструктуре за последние 12 месяцев. 50% в течении 3-х лет.
60% респондентов называют причиной аварии некачественные внутренние процессы или неверно выбранную архитектуру ИКТ.
Сколько стоит непрерывность бизнеса?
Для оценки обычно принимается стоимость простоя за время аварии. Однако, на практике всё намного интереснее. По оценке Gartner 76% бизнес-процессов современных компаний зависит от IT.
Подавляющее большинство предприятий зависит от информационных технологий и от непрерывной работы информационных систем, а основные потери связаны с их остановкой. Это является приоритетным фактором, но не единственным.
Для оценки обычно принимается стоимость простоя за время аварии. Однако, на практике всё намного интереснее. По оценке Gartner 76% бизнес-процессов современных компаний зависит от IT.
Подавляющее большинство предприятий зависит от информационных технологий и от непрерывной работы информационных систем, а основные потери связаны с их остановкой. Это является приоритетным фактором, но не единственным.
Для более полной оценки сделаем шаг назад и взглянем на компанию целиком.
На уровне СТРАТЕГИИ - не важна причина аварии.
Нужно обеспечить непрерывность бизнеса в любой ситуации и как можно скорее запустить его с минимальными потерями.
Тут для расчета удобнее учитывать стоимость простоя бизнес-процессов.
Снова получаем туманную методику и эфемерную величину.
Но есть и положительная сторона.
Найден критический бизнес-процесс и понятны последствия его остановки.
На этом этапе определяем, как сократить время простоя или избежать его в каждом бизнес-процессе.
Например, для сохранения поставок сырья нужно несколько источников (партнёров).
При этом, процессы не существуют сами по себе как «сферический конь в вакууме», а взаимодействуют.
А значит, остановка одного повлечет за собой проблемы или остановки в других процессах.
На этом уровне мы будем оперировать такими понятиями как:
- среднегодовой фонд оплаты труда
- численность сотрудников
- объем продаж в год
- репутация компании на рынке
- количество клиентов, которые ушли к конкурентам во время аварии
- штрафы поставщикам или покупателям
Для полноты картины необходимо учитывать ROI
(Return On Investment).
Жизненный цикл компании содержит такие периоды как:
-прохождение точки безубыточности
-развитие бизнеса
-выплата дивидендов или возврат капитала.
На уровне СТРАТЕГИИ - не важна причина аварии.
Нужно обеспечить непрерывность бизнеса в любой ситуации и как можно скорее запустить его с минимальными потерями.
Тут для расчета удобнее учитывать стоимость простоя бизнес-процессов.
Снова получаем туманную методику и эфемерную величину.
Но есть и положительная сторона.
Найден критический бизнес-процесс и понятны последствия его остановки.
На этом этапе определяем, как сократить время простоя или избежать его в каждом бизнес-процессе.
Например, для сохранения поставок сырья нужно несколько источников (партнёров).
При этом, процессы не существуют сами по себе как «сферический конь в вакууме», а взаимодействуют.
А значит, остановка одного повлечет за собой проблемы или остановки в других процессах.
На этом уровне мы будем оперировать такими понятиями как:
- среднегодовой фонд оплаты труда
- численность сотрудников
- объем продаж в год
- репутация компании на рынке
- количество клиентов, которые ушли к конкурентам во время аварии
- штрафы поставщикам или покупателям
Для полноты картины необходимо учитывать ROI
(Return On Investment).
Жизненный цикл компании содержит такие периоды как:
-прохождение точки безубыточности
-развитие бизнеса
-выплата дивидендов или возврат капитала.
Каждая компания стремится пройти точку безубыточности и приблизить период выплаты дивидендов как можно скорее.
Один из ключевых аспектов жизненного цикла – отсутствие аварий или незначительное их влияние на скорость и качество развития компании.
Среда, в которой действует любая организация, изменчива и создаёт множество инцидентов.
Каждый замедляет рост, а то и отбрасывает назад.
Статистика в данном случае не в пользу собственника.
Любая длительная остановка ключевых приложений (IT систем) – серьёзный удар по бизнесу.
И с каждым таким ударом ROI всё ниже, а дивиденды всё дальше.
Предусмотреть все аварии невозможно, но можно выполнить несложные действия по обеспечению непрерывности своего бизнеса.
В частности, для защиты информационных систем (ИС) следует:
-делать резервные копии данных, чтобы избежать их потери.
-обеспечить резервирование критичных ИС и тем самым значительно сократить время на восстановление
Это помогает значительно снизить влияние инцидентов на бизнес.
При этом, экономически правильно определять цену непрерывности через cравнение стоимости последствий наступившей аварии со стоимостью мер её предотвращения.
Сравнив стоимость потерь и стоимость решений, необходимо сделать выбор:
-согласится с рисками потерь от простоя
-предпринять действия по предотвращению аварий
Так или иначе, у каждой компании свой путь развития и своя стратегия работы с рисками, но второй путь помогает обеспечить стабильность развития бизнеса.
Один из ключевых аспектов жизненного цикла – отсутствие аварий или незначительное их влияние на скорость и качество развития компании.
Среда, в которой действует любая организация, изменчива и создаёт множество инцидентов.
Каждый замедляет рост, а то и отбрасывает назад.
Статистика в данном случае не в пользу собственника.
Любая длительная остановка ключевых приложений (IT систем) – серьёзный удар по бизнесу.
И с каждым таким ударом ROI всё ниже, а дивиденды всё дальше.
Предусмотреть все аварии невозможно, но можно выполнить несложные действия по обеспечению непрерывности своего бизнеса.
В частности, для защиты информационных систем (ИС) следует:
-делать резервные копии данных, чтобы избежать их потери.
-обеспечить резервирование критичных ИС и тем самым значительно сократить время на восстановление
Это помогает значительно снизить влияние инцидентов на бизнес.
При этом, экономически правильно определять цену непрерывности через cравнение стоимости последствий наступившей аварии со стоимостью мер её предотвращения.
Сравнив стоимость потерь и стоимость решений, необходимо сделать выбор:
-согласится с рисками потерь от простоя
-предпринять действия по предотвращению аварий
Так или иначе, у каждой компании свой путь развития и своя стратегия работы с рисками, но второй путь помогает обеспечить стабильность развития бизнеса.
Стратегии работы с рисками:
1.Стратегия уклонения - предполагает полное исключение риска.
2.Стратегия снижения - может применяться к любому риску. Нацелена на снижения вероятности наступления риска и его последствий
3.Стратегия передачи - переносит последствия наступления риска и ответственность за реагирование на третью сторону, при этом сам риск не устраняется. Передача риска предполагает финансовые затраты на передачу и получение финансовой компенсации в случае материализации риска.
4.Стратегия принятия риска:
-Активное принятие - план действий разрабатывается до наступления риска, обеспечивает резерв времени и ресурсов на устранение последствий наступившего риска
-Пассивное принятие - план устранения последствий риска будет разработан после наступления риска
Разберем пример
Предприятие с непрерывной деятельностью поставки товаров или услуг.
Штат сотрудников более 500 человек
Годовой оборот превышает 10 млрд. рублей
Непрерывная работа ключевых процессов предприятия зависит от нескольких Бизнес-приложений. Существует риск остановки работы бизнес-приложения из-за отказа ИТ инфраструктуры.
Что может нанести предприятию существенный ущерб, если длительность такой остановки превысит приемлемое время.
Какие стратегии мы можем применить?
СТРАТЕГИЯ УКЛОНЕНИЯ от данного риска неприменима, так как придется отказаться от автоматизированной обработки данных, что сделает работу предприятия нецелесообразной.
СТРАТЕГИЯ СНИЖЕНИЯ риска является самой распространенной. Но количество уязвимостей, которые могут привести к наступлению риска превышает несколько сотен и пока снижается вероятность наступления по 205-ой уязвимости, первая сотня вновь становиться актуальной и процесс становиться бесконечным.
Например: обеспечиваем избыточность ИТ инфраструктуры и моментальное переключение на дублирующую инфраструктуру в момент аварии. При этом не снижаем риск утраты основной или дублирующей инфраструктуры и/или отказ работы квалифицированного персонала.
СТРАТЕГИЯ ПЕРЕДАЧИ ОТВЕТСТВЕННОСТИ за работу бизнес-приложения. Например, любая учетная система по модели SAAS- самый простой вариант, но не всегда приемлемый из-за внутренних и внешних ограничений.
В данном случае можно передать ответственность за обеспечение работы ИТ инфраструктуры третьей стороне. При этом, дублирование могут выполнять разные поставщики сервиса. Таким образом, будет исключен риск утраты ИТ инфраструктуры.
ПАССИВНАЯ СТРАТЕГИЯ принятия риска в данном случае не целесообразна, так как стоимость простоя приложения может существенно превысить стоимость мер на снижение вероятности и последствий риска.
АКТИВНАЯ СТРАТЕГИЯ принятия риска оправдана.
Мы соглашаемся с возможностью отказа бизнес-приложения по любой причине, при этом имеем четкий план действий в момент аварии и необходимые ресурсы для восстановления работы на приемлемом уровне и в необходимое время.
Выбор стратегии должен соответствовать целям предприятия в рамках существующих ограничений.
Часто руководители ставят во главу угла экономию финансов, забывая о стоимости последствий наступления рисков, что обходится дороже.
Важно сохранять баланс:
Стоимость снижения риска не должна превышать стоимости устранения его последствий.
1.Стратегия уклонения - предполагает полное исключение риска.
2.Стратегия снижения - может применяться к любому риску. Нацелена на снижения вероятности наступления риска и его последствий
3.Стратегия передачи - переносит последствия наступления риска и ответственность за реагирование на третью сторону, при этом сам риск не устраняется. Передача риска предполагает финансовые затраты на передачу и получение финансовой компенсации в случае материализации риска.
4.Стратегия принятия риска:
-Активное принятие - план действий разрабатывается до наступления риска, обеспечивает резерв времени и ресурсов на устранение последствий наступившего риска
-Пассивное принятие - план устранения последствий риска будет разработан после наступления риска
Разберем пример
Предприятие с непрерывной деятельностью поставки товаров или услуг.
Штат сотрудников более 500 человек
Годовой оборот превышает 10 млрд. рублей
Непрерывная работа ключевых процессов предприятия зависит от нескольких Бизнес-приложений. Существует риск остановки работы бизнес-приложения из-за отказа ИТ инфраструктуры.
Что может нанести предприятию существенный ущерб, если длительность такой остановки превысит приемлемое время.
Какие стратегии мы можем применить?
СТРАТЕГИЯ УКЛОНЕНИЯ от данного риска неприменима, так как придется отказаться от автоматизированной обработки данных, что сделает работу предприятия нецелесообразной.
СТРАТЕГИЯ СНИЖЕНИЯ риска является самой распространенной. Но количество уязвимостей, которые могут привести к наступлению риска превышает несколько сотен и пока снижается вероятность наступления по 205-ой уязвимости, первая сотня вновь становиться актуальной и процесс становиться бесконечным.
Например: обеспечиваем избыточность ИТ инфраструктуры и моментальное переключение на дублирующую инфраструктуру в момент аварии. При этом не снижаем риск утраты основной или дублирующей инфраструктуры и/или отказ работы квалифицированного персонала.
СТРАТЕГИЯ ПЕРЕДАЧИ ОТВЕТСТВЕННОСТИ за работу бизнес-приложения. Например, любая учетная система по модели SAAS- самый простой вариант, но не всегда приемлемый из-за внутренних и внешних ограничений.
В данном случае можно передать ответственность за обеспечение работы ИТ инфраструктуры третьей стороне. При этом, дублирование могут выполнять разные поставщики сервиса. Таким образом, будет исключен риск утраты ИТ инфраструктуры.
ПАССИВНАЯ СТРАТЕГИЯ принятия риска в данном случае не целесообразна, так как стоимость простоя приложения может существенно превысить стоимость мер на снижение вероятности и последствий риска.
АКТИВНАЯ СТРАТЕГИЯ принятия риска оправдана.
Мы соглашаемся с возможностью отказа бизнес-приложения по любой причине, при этом имеем четкий план действий в момент аварии и необходимые ресурсы для восстановления работы на приемлемом уровне и в необходимое время.
Выбор стратегии должен соответствовать целям предприятия в рамках существующих ограничений.
Часто руководители ставят во главу угла экономию финансов, забывая о стоимости последствий наступления рисков, что обходится дороже.
Важно сохранять баланс:
Стоимость снижения риска не должна превышать стоимости устранения его последствий.
Что мешает бизнесу расти в безопасности?
По данным Gartner, бизнес всё больше зависит от информационных технологий с каждым годом.
Расходы на IT часто не структурированы и растут хаотично, незаметно раздуваясь в огромные неконтролируемые бюджеты.
Ежегодно бизнес несёт значительные финансовые потери от неорганизованности IT инфраструктуры, что приводит к задержкам в развитии компаний.
По данным Gartner, бизнес всё больше зависит от информационных технологий с каждым годом.
Расходы на IT часто не структурированы и растут хаотично, незаметно раздуваясь в огромные неконтролируемые бюджеты.
Ежегодно бизнес несёт значительные финансовые потери от неорганизованности IT инфраструктуры, что приводит к задержкам в развитии компаний.
Как бы банально не выглядели эти причины, большинство уделяет им внимание по остаточному принципу.
При этом осознавая, что применение технологий автоматизации - один из самых эффективных методов создания конкурентных преимуществ.
При этом осознавая, что применение технологий автоматизации - один из самых эффективных методов создания конкурентных преимуществ.