План обеспечения непрерывности бизнеса пример

Жизненный цикл процесса управления непрерывностью бизнеса

Инициация проекта

Проект – это деятельность, направленная на создание уникального продукта, услуги или результата.

План управления проектом / Project Management Plan – документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль.
Руководство PMBOK – Пятое издание

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

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

Стандарт / НПА	Требование	Описание	Статус
ISO/IEC 27001:2013 «Information technology – Security techniques – Information security management systems – Requirements» (Информационная технология. Методы обеспечения безопасности. Системы менеджмента информационной безопасности)	A.17 Information security aspects of business continuity management (Аспекты информационной безопасности в управлении непрерывностью бизнеса)	Непрерывность информационной безопасности должна быть встроена в систему непрерывности бизнеса компании. Для этого необходимо: – спланировать непрерывность информационной безопасности; – внедрить непрерывность информационной безопасности; – проверить, оценить непрерывность информационной безопасности.	Непрерывность информационной безопасности является одним из требований в том случае, если компания стремится получить сертификат соответствия требованиям ISO/IEC 27001:2013 «Information technology – Security techniques – Information security management systems – Requirements».
ISO 22301:2012 «Societal security – Business continuity management systems – Requirements» (Социальная безопасность. Системы менеджмента непрерывности бизнеса)	Данный стандарт посвящен непрерывности бизнеса.	В стандарте прописаны: – требования, необходимые для установления системы менеджмента непрерывности бизнеса в компании; – требования к функциям высшего руководства в системе менеджмента непрерывности бизнеса; – требования к установлению стратегических целей и руководящих принципов системы менеджмента непрерывности бизнеса; – требования к обеспечению непрерывности бизнеса, порядок разработки процедур управления в условиях инцидента.	Наличие планов BCP/DRP (данные планы рассмотрены в разделе «Разработка и внедрение планов») является обязательным условием в том случае, если компания стремится получить сертификат соответствия требованиям ISO 22301:2012 «Societal security – Business continuity management systems – Requirements».
ГОСТ Р 53647 «Менеджмент непрерывности бизнеса»	Данный стандарт посвящен непрерывности бизнеса.	Настоящий стандарт устанавливает требования к планированию, созданию, функционированию, мониторингу, анализу, проведению учений, поддержке и улучшению документированной системы менеджмента непрерывности бизнеса.	Носит рекомендательный характер.
СТО БР ИББС-1.0-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации»	8.11. Требования к организации обеспечения непрерывности бизнеса и его восстановления после прерываний	В организации банковской системы должен быть определен план обеспечения непрерывности бизнеса и его восстановления после возможного прерывания. План должен содержать инструкции и порядок действий работников организации банковской системы по восстановлению бизнеса. В частности, в состав плана должны быть включены: – условия активации плана; – действия, которые должны быть предприняты после инцидента ИБ; – процедуры восстановления; – ­процедуры тестирования и проверки плана; ­– план обучения и повышения осведомленности сотрудников; ­– обязанности сотрудников с указанием ответственных за выполнение каждого из положений плана. Также должны быть установлены требования по обеспечению ИБ, регламентирующие вопросы обеспечения непрерывности бизнеса и его восстановление после прерывания, в том числе требования к мероприятиям по восстановлению необходимой информации, программного обеспечения, технических средств, а также каналов связи.	Носит рекомендательный характер.
Приказ ФСТЭК России от 11.02.2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»	X. Обеспечение доступности информации (ОДТ)	В соответствии с Приказом ФСТЭК России от 11.02.2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» необходимо: – использовать отказоустойчивые технические средства; – резервировать технические средства, программное обеспечение, каналы передачи информации, средства обеспечения функционирования информационной системы; – контролировать безотказное функционирование технических средств; – обеспечить обнаружение и локализацию отказов функционирования технических средств; – принимать меры по восстановлению отказавших средств; – тестировать технические средства; – осуществлять периодическое резервное копирование информации на резервные машинные носители; – обеспечить возможность восстановления информации с резервных машинных носителей информации (резервных копий) в течение установленного временного интервала; – контролировать состояние и качество предоставления уполномоченным лицом вычислительных ресурсов (мощностей), в том числе по передаче информации.	В случае если система классифицирована по 1 или 2 классу защищенности, описанные в приказе требования носят обязательный характер.
Приказ ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»	X. Обеспечение доступности персональных данных (ОДТ)	В соответствии с Приказом ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» необходимо обеспечить: – контроль безотказного функционирования технических средств; ­– обнаружение и локализацию отказов функционирования; – принятие мер по восстановлению отказавших средств и их тестирование; – резервное копирование персональных данных на резервные машинные носители персональных данных; – возможность восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала.	В том случае, если для информационной системы персональных данных определен 1 или 2 уровень защищенности, описанные в приказе требования носят обязательный характер.

Основными отличиями вышеперечисленных решений являются стоимость и время восстановления деятельности компании.

Наименование плана	Описание плана	Стандарт / НПА
Business Continuity Plan (BCP) – План обеспечения непрерывности бизнеса	Набор задокументированных процедур, которые разработаны, обобщены и актуализированы с целью их использования в случае возникновения инцидента, и направлены на обеспечение возможности продолжения выполнения компанией критических важных видов деятельности на установленном приемлемом уровне.	ISO 22301 «Социальная безопасность. Системы менеджмента непрерывности бизнеса»: 8.4.4 Планы непрерывности бизнеса (Business continuity plans)
Continuity of Operations Plan (COOP) – План непрерывности операций	Фокусируется на восстановлении критически важных функций компании на альтернативной площадке и на их выполнении в течение 30 дней.	–
Crisis Communication Plan – План антикризисных коммуникаций	В данном плане задокументированы процедуры и правила внешних и внутренних коммуникаций в случае чрезвычайных ситуаций.	Федеральный закон от 21.12.1994 № 68 «О защите населения и территорий от чрезвычайных ситуаций природного и техногенного характера»: Статья 14. Обязанности организаций в области защиты населения и территорий от чрезвычайных ситуаций («Организации обязаны предоставлять в установленном порядке информацию в области защиты населения и территорий от чрезвычайных ситуаций, а также оповещать работников организаций об угрозе возникновения или о возникновении чрезвычайных ситуаций»).
Critical Infrastructure Protection Plan (CIP) – План защиты критических инфраструктур	План направлен на защиту ключевых ресурсов и компонентов национальной инфраструктуры.	Указ Президента Российской Федерации от 15 января 2013 г. N 31с «О создании государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации».
Cyber Incident Response Plan – План реагирования на киберинциденты	План, описывающий процедуры реакции на инциденты, связанные с атаками хакеров, вторжения в информационную систему и другие проблемы безопасности.	ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности»; NIST 800-61 «Computer Security. Incident Handling Guide».
Disaster Recovery Plan (DRP) – План восстановления после сбоя	План восстановления инфраструктуры компании после возникновения аварии.	ISO 22301 «Социальная безопасность. Системы менеджмента непрерывности бизнеса»: 8.4.5 Восстановление (Recovery).
Information System Contingency Plan (ISCP) – План на случай непредвиденных ситуаций в информационных системах	План восстановления системы, сетей и основных приложений после аварии. Данный план необходимо разработать для каждой критической системы и/или приложения.	–
Occupant Emergency Plan (OEP) – План действия персонала в случае чрезвычайной ситуации	В данном плане определяется порядок обеспечения безопасности персонала и процедуры эвакуации в случае чрезвычайных ситуаций.	Федеральный закон от 21.12.1994 г. № 68 «О защите населения и территории от чрезвычайных ситуаций природного и техногенного характера»; Федеральный закон от 21.12.1994 № 69 «О пожарной безопасности».

Понятие «планирование непрерывности бизнеса» (Business Continuity Planning, BCP) появилось сравнительно недавно и сегодня вызывает большой интерес у топ-менеджеров отечественных компаний.

Понятие «планирование непрерывности бизнеса» (Business Continuity Planning, BCP) появилось сравнительно недавно и сегодня вызывает большой интерес у топ-менеджеров отечественных компаний. Насколько методики и технологии обеспечения непрерывности бизнеса могут быть полезны?

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

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

Планирование восстановления после происшествия

Сегодня в России стремительно растут объемы передаваемой и обрабатываемой информации в корпоративных информационных системах. В этих условиях ИТ-службы отечественных компаний так заняты освоением новых технологий, что у них не хватает времени на обеспечение бесперебойной работы и безопасности систем. Это обычная проблема в циклах постоянного освоения новых технологий. Однако по мере «взросления» компаний и их систем все большее значение приобретают такие процессы, как резервное копирование данных и способность поддержания непрерывного доступа клиентов к приложениям.

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

План восстановления после происшествия (Disaster Recovery Plan, DRP) является частью плана непрерывности бизнеса и позволяет определить необходимые процедуры восстановления в случае возникновения инцидентов.

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

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

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

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

Для качественного выполнения плана восстановления необходимо знать допустимое время восстановления (Recovery Time Objective), а также конечные цели восстановления (Recovery Point Objective). Стратегия технического восстановления после инцидента основывается на комбинации этих требований.

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

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

Анализ рисков и их воздействий на бизнес должен включать в себя анализ по крайней мере десяти «наихудших» потенциальных происшествий. Затем каждому бизнес-процессу и приложению/системе должен быть присвоен определенный уровень приоритетности. Цель создания такого списка — обеспечение жизнеспособного, эффективного и экономически целесообразного процесса восстановления во всех технологических областях. Важно поддерживать этот список актуальным, проводить полную инвентаризацию оборудования, помещений, поставщиков и контактных точек. Таблица 1, составленная согласно рекомендациям международного стандарта ISO 17799:2, может использоваться для классификации приложений и/или систем организации.

Классификация приложений/систем

В настоящее время подготовлено более десятка различных стандартов и спецификаций управления безопасностью, детально регламентирующих процедуры планирования и поддержки непрерывности бизнеса, среди которых наибольшую известность приобрели международные и национальные спецификации и стандарты, такие как ISO 17799-2002 (BS 7799), NIST, COOP, HIPAA Gramm-Leach-Bliley, The Expedited Funds Availability, SAS 78/94.

Определение приоритетов восстановления приложений

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

Системное время восстановления

Для оценки общего времени восстановления отдельного бизнес-процесса определяется системное время восстановления (System Recovery Time). С тем чтобы гарантировать восстановление бизнес-процесса в течение допустимого времени, необходимо планировать порядок приоритетов, в соответствии с которым и будет производиться восстановление аппаратных средств и компонентов систем. Например, согласно плану восстановления после происшествия, гарантированное восстановление хостов системы и соответствующих приложений должно начинаться в течение 15 минут. Хост-системы и связанные компоненты выполняют приложения, которые представляют бизнес-процессы. Должны быть определены компоненты инфраструктуры аппаратных средств, необходимые прикладным системам и данным, поддерживающим соответствующие бизнес-процессы. Также необходимо идентифицировать все прикладные зависимости, компоненты сетевой инфраструктуры и поддерживающий персонал.

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

Использование резервного копирования

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

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

Тестирование плана

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

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

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

Применение плана восстановления после происшествия

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

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

Программа реагирования на инциденты

Для успешного восстановления непрерывности бизнеса необходимо разработать программу реагирования на инциденты (Incident Response Program). Под инцидентом безопасности понимается неблагоприятное событие в информационной системе и/или сети или угроза того, что такое событие может произойти. Инцидентами могут быть: неавторизованный доступ, атаки злоумышленников, вирусные атаки и пр. Независимо от вероятности инцидента важно, чтобы все шаги, предложенные программой, были осуществимы.

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

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

Инструментальные средства обеспечения непрерывности бизнеса

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

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

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

1. Автономные средства оценки воздействий на бизнес. Здесь ввод данных производится вручную менеджерами и затем экспортируется в поддерживаемые средства обеспечения непрерывности бизнеса.
2. Генераторы планов непрерывности бизнеса. Эти средства представляют собой, по сути, экспертные системы с определенными базами знаний и позволяют сгенерировать актуальный план обеспечения непрерывности бизнеса компании.
3. Базы данных планирования непрерывности бизнеса. Отображают необходимую информацию о планировании непрерывности бизнеса с учетом специфики деятельности компании.
4. Средства совместного распределенного планирования непрерывности бизнеса. Эти средства позволяют реализовать некоторый корпоративный стандарт обеспечения непрерывности бизнеса в распределенной вычислительной среде.

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

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

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

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

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

Сергей Петренко — эксперт управления профессионального сервиса компании «АйТи», SPetrenko@it.ru

Ольга Ремизова — консультант управления профессионального сервиса компании «АйТи», info@it.ru

---

Поставщики решений и услуг

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

• Computer Alternate Processing Sites (CAPS) — оказывает консалтинговые услуги в области непрерывности бизнеса BCP, а также анализа воздействия на бизнес.
• Hewlett-Packard Business Continuity and Recovery Services — предлагает услуги планирования и тестирования BCP.
• IBM Business Continuity and Recovery Services (бизнес-составляющая IBM Global Services) — предоставляет консалтинговые услуги, включая анализ и управление рисками, планирование и поддержку BCP, антикризисное управление, оценку и планирование восстановления; службы восстановления — включая полностью оборудованные резервные компоненты технической инфраструктуры.
• SunGuard Availability Services оказывает полный спектр услуг по обеспечению требуемого уровня непрерывности и доступности корпоративных информационных систем.
• Business Protection Systems International (BPSI) предлагает набор средств Business Protector для создания и поддержания планов непрерывности бизнеса.
• Computer Security Consultants Inc. (CSCI) предлагает программный продукт восстановления RecoveryPАС.
• LBL Technology Partners реализует программу развития BCP LBL Contingency Planner, совместимую с Microsoft Office.
• Recovery Point Systems предлагает решение по восстановлению критичных функций бизнеса Integrated Disaster Recovery Site (IDRS).
• RSM McGladrey предлагает программу планирования непрерывности бизнеса Business Continuity Planning System на основе анализа и управления бизнес-рисками.

---

Состав работ

Стандартная схема планирования непрерывности бизнеса компании может включать в себя следующие работы:

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

Пример обеспечения непрерывности бизнеса

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

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

---

Пример плана обеспечения непрерывности бизнеса

Основные положения плана обеспечения непрерывности бизнеса (актуальность, основные цели и задачи, способы решения).

Оценка воздействия на бизнес:

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

Деятельность компании в чрезвычайной ситуации:

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

Поддержание готовности к обеспечению непрерывности бизнеса:

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

Информационное обеспечение:

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

Техническое обеспечение:

• создание, поддержка и эксплуатация аппаратно-программных средств обеспечения непрерывности бизнеса;
• создание и поддержка резервного помещения.

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

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

Об эксперте: Илья Пантелеев, генеральный директор «Сиссофт»

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

Стая «черных лебедей»

Пандемию COVID-19 часто сравнивали с «черным лебедем» из теории Нассима Талеба. Новая реальность, в которой сегодня оказалась каждая российская компания, — это одновременное прибытие целой группы «черных лебедей». Перед бизнесом возникли вопросы, которые никто не мог представить себе еще полтора месяца назад, и все одновременно:

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

В этих условиях горизонты планирования сузились до нескольких недель или даже дней.

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

Кто озаботился непрерывностью заранее

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

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

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

Идентифицируем критические процессы

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

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

Отдельно стоит обратить внимание на узкие места основного процесса производства, и здесь уже начинает играть роль отраслевая специфика. Компании нужно ответить на ряд вопросов, например:

• Остановка какого оборудования может остановить весь цикл производства?
• Как быстро можно вывести резервные ресурсы на производственную мощность?
• Сколько времени необходимо на осуществление ремонта?
• Есть ли необходимый склад запасных частей для «узкого места», насколько оперативно он может быть доступен?

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

Далее нужно проанализировать, в каких именно элементах необходимо искать узкие места, которые могут привести к сбою. Если смотреть на функции в «крупную клетку», их можно найти:

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

Несколько полезных советов по обеспечению непрерывности

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

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

• План по поддержке непрерывности бизнеса нужно «обогащать» сценариями, ранее практически невозможными.

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

• Отдельно переоцените риски, связанные с привлечением сотрудников.

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

• Пересмотрите подход к финансовому планированию. В «обычные времена» для компании важно понимать, как она выполнит планы текущего года.

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

• Сейчас время для рассмотрения самых маловероятных рисков. Практика показывает, что именно они случаются с пугающей частотой.

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

На злобу дня, но про управление проектами.

Что такое Business Continuity Plan

Есть такая незаслуженно часто забываемая вещь, как Business Continuity Plan (кратко – BCP) или План обеспечения непрерывности бизнеса. Сам инструмент пришел из антикризисного менеджмента и прижился в управлении ИТ-проектами, так как при любом внедрении более-менее значимой системы  вопрос, который должен задать себе как руководитель проекта, так и тот, кто принимает эту систему – “а что, если?!!!”.  Прямо так, с тремя восклицательными знаками. Если система будет недоступна – какое влияние это окажет на бизнес? От ответа на этот вопрос будет зависеть серьезность и стоимость мер, которые необходимо предпринять как для того, чтобы а) катастрофа не произошла б) в случае, если она произойдет, был нанесен наименьший урон в) бизнес не остановился из-за катастрофы.

Вот ответ на пункт в) – это и есть Business Continuity Plan.

К слову, само понятие BCP неразрывно связано с DRP (Disaster Recovery Plan, или План восстановления после катастрофы), но про DRP подробнее как-нибудь в другой раз.

Пример из сегодняшней жизни

Сейчас отовсюду мы слышим новости о том, что сайты и ресурсы ведомств “легли” под DDos-атакой. Из вчерашнего – по всему интернету разлеталась новость о том, что якобы была взломана система электронного документооборота Росавиации, уничтожены все файлы и вообще произошел тот самый Disaster с большой буквы. Что делает Росавиация? Правильно, идет в инструкцию по делопроизводству, где написано, что вообще-то Росавиция использует электронный документооборот, но где обязательно есть раздел “А чего мы будем делать, если?!” (называется он, конечно, по-другому, но смысл такой). Вот там и написано, при каких условиях происходит переход – по решению генерального директора, при недоступности системы ЭДО более 4 часов, при уведомлении от госорганов о внешней киберугрозе и т.д.

Соответственно, Росавиация находит в реестре возможных катастроф ту, которая происходит сейчас (что бы это ни было – реальный взлом, угроза, перестраховка, сгоревший сервер и т.д.), читает там, что нужно сделать и делает – направляет во все российские авиакомпании и аэропорты уведомление через сеть АФТН о переходе на бумажный документооборот через телеграммы, курьеров и почту.

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

Кстати, кто не знает, АФТН – это специализированная российская телеграфная сетка для передачи сообщений гражданской авиации. Дорогая, медленная, но своя. Мне тут по долгу работы последнее время пришлось погрузиться в тематику авиации, пока ничего непонятно, но очень интересно. Телеграмма точно подлинная, подлинный ли взлом – так и непонятно.

Как разработать план обеспечения непрерывности

Вообще BCP все оформляют в меру своих талантов, какого-то универсального общепринятого шаблона нет. В минимальной “комплектации” BCP обычно следующие блоки:

1. Сценарии катастрофы (описание, степень влияния, триггеры и т.д.) – что теоретически может произойти, так как в зависимости от типа катастрофы способ обеспечения непрерывности бизнеса может отличаться. Если сгорел сервер – бежим поднимать на соседний из бэкапа, если ломают снаружи – перекрываем сеть и меняем пароли и т.д.
2. Целевые показатели – сколько бизнес может простаивать при каком из типов катастрофы. Потому что, например, Росавиация не может не отправлять и не принимать данные, но может пару суток протянуть без доступа к историческим данным.
3. Целевое действие – способ обеспечения непрерывности для каждого типа катастрофы со ссылкой на детальную инструкцию по претворению его в жизнь.
4. Ответственные – хорошая практика – указать такового как со стороны ИТ, так и со стороны владельца системы.

Это прямо минимум, но он может сэкономить много нервных клеток, если катастрофа все-таки случится. В максимуме в этом же документе могут быть прописаны контрольные точки обеспечения непрерывности, поминутный тайминг, контакты, процесс координации, процесс принятия решения об откате BCP и еще сотня пунктов. Самый большой BCP, который я видела, содержал 226 страниц.

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

Как и с любым инструментом управления проектами – BCP нужно применять только по показаниям, а именно – для решений, остановка которых несет реальную проблему для бизнеса и будет для него болезненна. Поэтому, например, какая-нибудь системка управления корпоративными рассылками точно не требует BCP на 100+ страниц, а вот любая ERP – точно требует. Причем ERP ERP рознь – представьте, что будет, если, например, SAP перестанет работать у какой-нибудь Северстали на 4 часа? Да ничего не произойдет, ну придется потом нагнать пропущенное время, неприятно, но не смертельно. А теперь – если SAP встанет в X5? И по всей РФ встанут все продажи во всех Перекрестках и Пятерочках (там онлайн все)? Вот поэтому BCP у них будут отличаться, и отличаться сильно.

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

Более бытовой пример – дети имеют свойство пачкать и мочить одежду, а ходить без куртки в -20 или в мокрой куртке из-за того, что она не успела высохнуть – это вполне тянет на катастрофу с последующим воспалением легких. BCP – иметь второй комплект одежды или сушильную машину дома. У нас есть и то, и другое, двойное резервирование!

Пример плана обеспечения непрерывности или Business Continuity Plan

Скоро будет:)

Делаете BCP и DRP для своих проектов? Расскажите!

In this article, you’ll find the most useful free, downloadable business continuity plan (BCP) templates, in Microsoft Word, PowerPoint, and PDF formats. Customize the templates to fit the needs of your business, ensuring you maintain critical operations at all times.

Included on this page, you’ll find a business continuity plan template, a small business continuity plan template, a business continuity framework template, and more.