Сбой случается — отказывает сервер, затапливает офис, ключевой поставщик внезапно останавливает поставки — и компания начинает импровизировать в реальном времени, теряя часы и дни на то, что можно было продумать заранее. Пока команда решает базовые вопросы ("кто звонит клиентам", "где резервные данные", "кто временно замещает недоступного сотрудника"), критичные процессы стоят, а конкуренты и клиенты замечают проблему.
План непрерывности бизнеса пишется не для того, чтобы предсказать конкретную катастрофу, а для того, чтобы не тратить драгоценное время кризиса на изобретение базовых ответов, которые можно было продумать заранее.
Задокументированный реальный кейс, ставший эталоном практики BCP: после теракта 1993 года на Всемирном торговом центре директор по безопасности Morgan Stanley Рик Рескорла пришёл к выводу, что здание остаётся вероятной целью, и добился внедрения регулярных, дважды в год, полномасштабных учебных эвакуаций для около 2700 сотрудников компании в башнях 2 и 5 ВТЦ — вопреки скептицизму части коллег, считавших учения избыточными. 11 сентября 2001 года, сразу после удара по Северной башне, представитель управляющей компании (Port Authority) сделал официальное объявление по громкой связи с указанием сотрудникам оставаться на местах. Рескорла проигнорировал это указание, взял громкоговоритель и лично начал организованную эвакуацию сотрудников Morgan Stanley — по данным очевидцев, на прямое требование Port Authority удерживать людей на местах он ответил отказом, будучи уверен, что здание не устоит. Благодаря многолетней отработанной дисциплине эвакуации почти все сотрудники Morgan Stanley успели выйти из здания; сам Рескорла погиб, вернувшись в башню, чтобы убедиться, что все успели покинуть здание. К 9:30 утра того же дня резервная площадка компании уже была активирована, а руководство работало из нового командного центра. Это прямая иллюстрация принципа: план непрерывности бизнеса работает только тогда, когда ответственные за него люди реально натренированы действовать по собственному плану, а не по любым внешним указаниям, поступающим в момент кризиса, — и когда решение о начале эвакуации не требует согласования в момент, когда счёт идёт на минуты.
Происхождение и исследовательская база
Практика планирования непрерывности бизнеса развилась из области disaster recovery (аварийного восстановления ИТ) 1970-80-х годов и была формализована в международном стандарте ISO 22301 "Security and resilience — Business continuity management systems" (первая версия 2012 года, заменившем более ранний британский стандарт BS 25999), задающем структурированный подход к анализу воздействия сбоев на бизнес и построению планов реагирования.
Второй задокументированный кейс — из того же здания, того же дня и той же катастрофы — показывает предельно ясно, какую цену платит компания без сопоставимой готовности: облигационная брокерская компания Cantor Fitzgerald занимала этажи 101-105 северной башни Всемирного торгового центра, выше точки удара самолёта, что физически исключило возможность эвакуации для находившихся там сотрудников. Из примерно 960 сотрудников нью-йоркского офиса компании погибли 658 человек — около двух третей всего персонала, крупнейшая единовременная потеря сотрудников одной компании в истории США. В отличие от Morgan Stanley, занимавшей этажи преимущественно в южной башне ниже точки удара второго самолёта и практиковавшей регулярные, обязательные учения по эвакуации под руководством Рика Рескорлы, у Cantor Fitzgerald не было сопоставимой культуры регулярных тренировок и чётко отработанных процедур эвакуации, а физическое расположение офисов выше точки удара сделало результат трагически иным независимо от готовности самой компании. Сопоставление двух компаний в одном и том же здании в один и тот же день — Morgan Stanley потеряла 13 из примерно 2700 сотрудников южной башни, Cantor Fitzgerald — около двух третей своих 960 — стало хрестоматийным примером того, насколько драматически может отличаться результат катастрофы в зависимости от заблаговременной готовности, при том что физическое расположение офиса также остаётся фактором, который план непрерывности повлиять не в силах.
Ключевые идеи и принципы
Принцип: Анализ воздействия на бизнес (Business Impact Analysis, BIA)
Прежде чем писать план, компания оценивает, какие процессы критичны и сколько времени/данных они могут позволить себе потерять — определяются RTO (Recovery Time Objective, максимально допустимое время простоя) и RPO (Recovery Point Objective, максимально допустимая потеря данных) для каждого критичного процесса.
Принцип: Приоритизация процессов, а не защита всего одинаково
Не все процессы одинаково критичны — BCP фокусирует ресурсы на процессах с наибольшим влиянием на бизнес при сбое (обычно определяется через BIA), а не пытается одинаково защитить абсолютно всё.
Принцип: Конкретные роли и процедуры, а не общие декларации
План содержит конкретных ответственных лиц (и их дублёров на случай недоступности), пошаговые процедуры для типовых сценариев сбоя, контакты, альтернативные площадки/каналы связи — а не общую фразу "в случае ЧП действовать по обстоятельствам".
Принцип: Регулярное тестирование плана
План, который никогда не тестировался, с высокой вероятностью не сработает в реальности — регулярные учения (от настольных разборов сценариев до полноценных симуляций) выявляют пробелы до того, как реальный кризис их обнажит.
Ограничения, слепые зоны и критика
BCP не может предусмотреть абсолютно все возможные сценарии сбоя — избыточная детализация плана под конкретные катастрофы (план "на случай наводнения", план "на случай пожара") рискует пропустить сценарии, которые никто не предвидел; более устойчивый подход фокусируется на воздействии (потеря офиса, потеря данных, потеря ключевого персонала), а не на причине. План быстро устаревает без регулярного пересмотра — изменения в организационной структуре, поставщиках, ИТ-системах делают устаревший план не просто бесполезным, но потенциально вредным (даёт ложное чувство защищённости). Полноценное внедрение BCP по стандарту ISO 22301 требует значительных ресурсов, что часто непропорционально размеру малого и среднего бизнеса — компаниям стоит адаптировать глубину планирования под свой масштаб.
Даже безупречно исполненный план непрерывности не устраняет полностью риск, связанный с физическим расположением критичных ресурсов и людей, — трагическая разница в исходе между Morgan Stanley и Cantor Fitzgerald в один и тот же день частично объяснялась именно расположением офисов относительно точки удара, а не только качеством внутренних процедур; план непрерывности снижает риск, но не устраняет структурную уязвимость, связанную с физическим размещением.
Типовые ошибки
Ошибка 1: План написан, но никогда не тестировался.
Документ существует "для галочки" (например, для аудита или требования клиента), но никто не проверял, реально ли процедуры работают в условиях, близких к кризису.
Как избежать: Проводить регулярные учения — хотя бы настольный разбор сценария раз в год.
Ошибка 2: Все процессы защищены одинаково, без приоритизации по критичности.
Ресурсы распределяются равномерно, вместо концентрации на процессах с наибольшим влиянием на бизнес при простое.
Как избежать: Провести анализ воздействия на бизнес (BIA) и явно приоритизировать процессы по критичности перед распределением ресурсов защиты.
Ошибка 3: В плане нет дублёров для ключевых ролей.
Единственный человек, знающий процедуру восстановления, сам оказывается недоступен в момент кризиса (болезнь, отпуск, сам пострадал от того же сбоя).
Как избежать: Для каждой критичной роли в плане назначать минимум одного дублёра.
Ошибка 4: План не обновляется при изменениях в компании.
Организационная структура, поставщики, ИТ-системы меняются, а план продолжает ссылаться на устаревшие контакты, системы и процедуры.
Как избежать: Закрепить регулярный цикл пересмотра плана (минимум ежегодно и при значимых организационных изменениях).
Ошибка 5: Ответственные за план непрерывности не наделены полномочием действовать по собственному плану вопреки внешним указаниям в момент кризиса.
11 сентября 2001 года официальное объявление управляющей компании здания прямо предписывало сотрудникам оставаться на местах — если бы директор по безопасности Morgan Stanley не имел реальных полномочий и решимости проигнорировать это указание и начать эвакуацию по собственному плану, десятки лет отработанных учений оказались бы бесполезны в решающий момент.
Как избежать: Явно закреплять в плане, что ответственные за реагирование лица имеют полномочие принимать решение о запуске процедур BCP самостоятельно, не дожидаясь подтверждения от внешних или вышестоящих инстанций, если ситуация требует немедленных действий.
Ошибка 6: план непрерывности не учитывает сценарии, при которых сама физическая локация делает стандартные процедуры (эвакуация по обычным путям, доступ к обычным ресурсам) объективно невозможными, требующие принципиально иных резервных вариантов.
Расположение офисов Cantor Fitzgerald выше точки удара самолёта в северной башне ВТЦ сделало традиционную эвакуацию физически невозможной вне зависимости от качества внутренних процедур компании — ни одна степень готовности персонала не могла компенсировать этот структурный фактор. Аудит плана непрерывности должен явно рассматривать сценарии, где базовое предположение о доступности стандартного пути реагирования (эвакуации, резервного офиса, канала связи) может оказаться неверным именно в момент кризиса.
Как избежать
для критичных локаций и функций явно прорабатывать сценарий «а что, если стандартный путь реагирования недоступен» — альтернативные маршруты, распределённое размещение критичных функций между разными зданиями или площадками, а не сосредоточение всех сотрудников или ресурсов в одной физически уязвимой точке.
План внедрения
Месяц 1: провести анализ воздействия на бизнес (BIA) — определить критичные процессы, RTO и RPO для каждого.
Месяц 2: написать конкретные процедуры реагирования для наиболее критичных процессов с ролями и дублёрами.
Месяц 3: определить резервные ресурсы — площадки, данные, каналы связи, поставщиков. Для критичных функций отдельно оценить риск, связанный с концентрацией сотрудников или ресурсов в одной физически уязвимой точке, — и рассмотреть распределённое размещение или альтернативные пути реагирования на случай, если стандартный путь окажется недоступен, как это произошло с офисами Cantor Fitzgerald выше точки удара в северной башне ВТЦ.
Месяц 4: провести первое учение (настольный разбор сценария) и скорректировать план по итогам.
Далее: поддержание и обновление — регулярный пересмотр плана и повторные учения минимум раз в год.
Как реализовать этот план с помощью фрейма «Бизнес-план непрерывности» в OrgDevTools
Фрейм собирает план непрерывности в один реестр критичных процессов. По каждому процессу он сам проверяет, укладывается ли реальное восстановление в допустимое время простоя и хватает ли частоты резервных копий для допустимой потери данных. Он также отмечает процессы, у которых нет дублёра или учения не пройдены. Фрейм — бесплатный тренажёр: в нём удобно отработать логику BCP на своих процессах, прежде чем оформлять полноценный документ.
Вкладка «1. Критичные процессы, RTO/RPO» — Месяц 1: анализ воздействия на бизнес
Основная работа идёт здесь. Это таблица, строки добавляются кнопкой «+ процесс» и удаляются крестиком. Готовых примеров нет, реестр стартует пустым. Колонки таблицы:
название процесса;
RTO, ч — за сколько часов процесс должен заработать;
«Достижимо, ч» — сколько реально займёт восстановление сейчас;
RPO, ч — данные за сколько часов допустимо потерять;
«Бэкап раз в, ч» — фактический интервал резервного копирования;
ответственный и дублёр — текстовые поля;
«Учения» — выпадающий список: «не проводились» (серый), «пройдены» (зелёный), «провалены» (красный). У новой строки по умолчанию стоит «не проводились».
Фрейм сравнивает значения сам, но только если заполнены оба числа пары. Поле «Достижимо» краснеет, когда реальное восстановление дольше RTO. Поле «Бэкап» краснеет, когда копии делаются реже, чем допускает RPO. Совпадение с целью считается нормой. Пустое поле дублёра подсвечивается жёлтым. Строки без названия в расчётах не участвуют.
Под таблицей есть свободный список «Почему именно эти процессы критичны» — для обоснования приоритизации.
Вкладка «2. Процедуры и резервы» — Месяцы 2–3: процедуры реагирования и резервные ресурсы
На вкладке два свободных списка. «Процедуры реагирования: кто, что, в каком порядке» с подсказкой «Сценарий — первые шаги — кто объявляет». «Резервные ресурсы: площадки, данные, связь, поставщики». Фрейм здесь ничего не считает, и записи на вердикт не влияют.
Вкладка «3. Учения» — Месяц 4: первое учение и корректировка плана
Вверху фрейм выводит две строки: какие процессы не проверены, а какие провалили учения (провалы выделены красным). Статус учений берётся из таблицы на первой вкладке. Ниже — список «План учений: когда, какой сценарий, кто участвует» с подсказкой «Дата — сценарий — процесс — что проверяем».
Вкладка «Визуализация» — сводный взгляд на разрывы перед учениями
У каждого процесса своя полоса достижимого времени восстановления. Она зелёная, если процесс укладывается в цель, и красная, если не укладывается. Цель RTO показана чёрной чертой. Масштаб задаёт самое большое значение среди всех целей и достижимых сроков. Справа подпись «достижимо / цель ч», цветной кружок статуса учений и значок: 👥, если дублёр есть, или ⚠️, если его нет.
Вкладка «Итоги» — Далее: поддержание и обновление
Вердикт выдаётся по первой сработавшей проверке, в таком порядке:
Процессов нет — фрейм предлагает перечислить критичные процессы и задать для них RTO и RPO.
Не заданы RTO или RPO — предупреждение: без цели нельзя проверить, достаточен ли резерв.
Восстановление не успевает в RTO — красный вердикт с цифрами по каждому процессу и советом: нужен горячий резерв или упрощённый ручной режим.
Резервные копии делаются реже, чем допускает RPO, — красный вердикт.
Нет дублёра — предупреждение: кризис может совпасть с отпуском или болезнью.
Учения провалены — красный вердикт с просьбой исправить процедуры и повторить учения.
Учения не проводились — предупреждение «Непроверенный план — это предположение, а не план».
Иначе — зелёный вердикт с советом повторять учения при каждом крупном изменении ИТ или поставщиков.
Под вердиктом четыре счётчика: «процессов готовы» (нет разрывов, есть дублёр, учения пройдены), «разрывов RTO/RPO», «без дублёра» и «без учений». Кнопка «Создать задачу» заводит задачу «Закрыть разрывы плана непрерывности», в описание попадает текст вердикта. Кнопка появляется только у сохранённого документа.
Все правила сравнения — рабочая настройка фрейма, а не норма методики.
Чего фрейм не делает
Не хранит даты учений и не следит, проводились ли они хотя бы раз в год.
Не анализирует процедуры, резервные ресурсы и концентрацию людей в одной уязвимой точке. Вторая вкладка — только записная книжка.
Не проверяет, закреплены ли за ответственными полномочия действовать без внешнего согласования.
Не ранжирует процессы по критичности: вы сами решаете, что внести в реестр.
Работает только в часах.
Визуализирует только время восстановления, без RPO.
Если не заполнены «Достижимо» или «Бэкап», разрыв не считается. Вердикт тогда может стать зелёным, хотя счётчик «готовы» этот процесс не засчитает.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме
ISO 22301:2019 — «Security and resilience — Business continuity management systems». Международный стандарт, задающий структуру и требования к системе управления непрерывностью бизнеса.