Не работает 1С, пропал интернет, офис недоступен или единственный специалист не может выйти на связь. Техническая команда занимается восстановлением, но у бизнеса уже есть заказы, сотрудники и обязательства. Непрерывность бизнеса — это подготовленный порядок, который помогает сохранить критичные операции во время нарушения и управляемо вернуться к обычной работе.
Понятно, что продолжать
Определены нужные операции, допустимые ограничения и приоритеты, а не только список серверов.
Понятно, кто действует
Есть ответственные, замещение, доступные контакты и заранее проверенные варианты работы.
Непрерывность бизнеса, BCP и аварийное восстановление
| Понятие | Главный вопрос | Что входит |
|---|---|---|
| Непрерывность бизнеса | Как сохранить критичные процессы при нарушении? | Люди, помещения, поставщики, связь, данные, временный порядок и возврат |
| BCP — Business Continuity Plan | Какие согласованные действия выполняет компания? | Условия запуска плана, роли, процедуры, ресурсы и проверки |
| DR — Disaster Recovery | Как вернуть ИТ-сервисы и данные? | Технические процедуры восстановления инфраструктуры и приложений |
Копии данных и резервные серверы — важные части подготовки. План также должен отвечать, как сотрудники работают, пока восстановление не закончено. Разделение и связь планов непрерывности, коммуникаций и ИТ-восстановления описаны в материалах Ready.gov.
В этой статье — практический подход к организации работы компании. Примеры не являются обязательным нормативным регламентом или подтверждением сертификации.
С чего начать: процессы и последствия остановки
Попросите владельцев процессов описать, что произойдёт при остановке на разные периоды и в разное время. Приём заказов, отгрузка и закрытие месяца могут зависеть от одной системы, но иметь разные приоритеты.
Нужный результат
Какие операции должны сохраняться и кто ими пользуется? «Работает сервер» слишком мало для оценки процесса.
Влияние остановки
Какие заявки, поставки и решения задерживаются? Когда последствия становятся неприемлемыми?
Ресурсы и связи
Кто, какие сведения, устройства, приложения и поставщики нужны для минимальной работы?
Допустимый временный режим
Что можно выполнять ограниченно, что отложить и кто разрешает такой порядок?
Такой разбор называют BIA — анализом влияния на бизнес. Его использование для определения критичных функций и активов раскрывает NIST IR 8286D. Начать можно с одного важного процесса, затем проверить его зависимости.
Цели возврата сервиса и данных согласуйте отдельно. Их различия и расчёты разобраны в статье о RTO и RPO. Временный порядок должен позволять работать до восстановления, а не скрывать, что цель уже превышена.
Как связать временную работу и восстановление
Ответственный вводит согласованный временный режим, назначает исполнителей и сообщает ограничения.
Техническая команда выполняет процедуру восстановления, проверяет данные и готовность приложения.
Участники переносят накопленные сведения, исключают дубли и подтверждают обычную работу.
Если заказы временно фиксировали отдельно, после запуска системы они не появятся там автоматически. Нужны правила нумерации, ответственный за перенос и сверка. Иначе техническое восстановление закончится, а ошибки в рабочем процессе продолжатся.
Первые действия: кто останавливает хаос
Предположим, менеджеры одновременно сообщают: «Не открывается 1С». Несколько человек уже перезагружают компьютеры, склад звонит директору, а клиенту обещают отгрузку. До выяснения причины нужен единый порядок действий.
| Шаг | Действие | Результат |
|---|---|---|
| Подтвердить масштаб | Проверить затронутые операции, подразделения и зависимости; записать время начала | Понятно, что остановилось и что продолжает работать |
| Назначить координацию | Определить одного координатора, технического ответственного и представителя бизнеса | Задачи не дублируются, решения фиксируются |
| Ограничить изменения | Согласовывать действия, способные повлиять на восстановление; при признаках атаки включить реагирование на инцидент | Понятно, кто и что меняет; случайные действия не ухудшают ситуацию |
| Ввести временный порядок | Сообщить разрешённые операции, место регистрации запросов и время следующего обновления | Сотрудники продолжают доступную работу по одним правилам |
Это порядок решений, а не универсальный норматив «уложиться в первые десять минут». Полномочия и условия запуска плана нужно согласовать заранее: ожидание единственного директора может само стать причиной длительной остановки.
Сценарий 1. Оптовая компания: 1С недоступна, заказы идут
Исходная ситуация: менеджеры получают заявки по телефону и почте, склад собирает заказы через 1С, а остатки меняются в течение дня. Приложение перестало отвечать. Ниже — модель рабочего сценария, а не клиентский кейс.
Что делает бизнес
- Руководитель продаж вводит единый временный журнал вместо нескольких личных таблиц.
- Менеджер присваивает обращению уникальный номер, записывает время, состав запроса, контакт и ответственного.
- Клиент получает подтверждение приёма заявки. Наличие и срок отгрузки обещают только по доступным проверенным сведениям.
- Склад отделяет уже подтверждённые задания от новых; изменения статуса фиксируются в том же согласованном порядке.
Что делает ИТ
- Проверяет, где отказ: приложение, СУБД, хранилище, сеть или служба входа.
- Оценивает пригодную точку данных и вариант восстановления, сообщает известные ограничения.
- Восстанавливает сервис по отдельной процедуре и проверяет связи с обменами.
- Передаёт владельцу процесса результат проверки и сведения о периоде возможной потери изменений.
Возврат: ответственное лицо объявляет момент завершения временной регистрации. Операторы проверяют, не появился ли заказ в восстановленной базе, затем создают или связывают его с временным номером. Склад сверяет фактические сборки и отгрузки с учётными документами.
Контрольный заказ проходит согласованный путь от регистрации до нужного этапа исполнения; временные записи имеют статус, ответственного и связь с системой. Необработанное выделено в отдельную очередь.
Что ломает план: временная таблица находится на том же недоступном сервере; у менеджеров разные версии остатков; после восстановления заказы вводятся повторно. Приём заявки — ограниченный режим, а не доказательство, что отгрузка восстановлена.
Сценарий 2. Файловый сервер: проекты и документы недоступны
Исходная ситуация: отдел работает с чертежами, договорами и шаблонами на общей папке. Сервер недоступен. Часть сотрудников открыла локальные копии и уже начала редактирование.
- Определить важное: владелец процесса выбирает папки и документы, без которых останавливается ближайшая работа. Восстановление всего архива не всегда должно предшествовать возврату критичного проекта.
- Назначить рабочую версию: согласовать доступное временное хранилище и ответственных за изменения. Если достоверной версии нет, ограничить редактирование до сверки.
- Вернуть данные: ИТ восстанавливает нужное состояние в подготовленную среду; проверяет владельцев, файловые ACL, разрешения общего ресурса и путь подключения.
- Сверить изменения: локальные и временные версии не копируются поверх восстановленных автоматически. Ответственные сравнивают их и принимают итоговый вариант.
Что можно продолжить
Работу с проверенными доступными материалами и разрешённые подготовительные операции. Для новых редакций нужен один понятный порядок учёта.
Что подтверждает готовность
Нужный сотрудник открывает и сохраняет документ по рабочему пути; посторонний доступа не получает; согласована актуальная версия.
Что ломает план: восстановить файлы, но забыть права; раздать папку всем для ускорения; собрать несколько несовместимых версий договора. Успешная проверка одной папки не подтверждает готовность всего файлового сервера. Параметры выбора места и восстановления ACL описаны в документации Windows Server; конкретная процедура зависит от используемого средства копирования.
Сценарий 3. Связь: резервный интернет есть, приложения не работают
Исходная ситуация: основной канал пропал. Маршрутизатор переключился на резерв, сайты открываются, но сотрудники не входят в облачную 1С, а телефония работает нестабильно.
- Проверить цепочку: рабочее место → локальная сеть → шлюз → DNS/VPN → приложение. Наличие интернета не подтверждает работоспособность всей цепочки.
- Проверить условия подключения: при смене внешнего адреса могут затронуться разрешения по IP, VPN и настройки внешних сервисов. Такие зависимости нужно учитывать при проектировании резерва.
- Разделить нагрузку: согласовать приоритет критичных приложений; перенос больших файлов и необязательные загрузки отложить, если резервный канал ограничен.
- Назначить рабочий вариант: часть сотрудников может перейти на заранее проверенные удалённые места. Это требует устройств, связи и штатных способов входа, а не подключения к первому доступному Wi-Fi.
Если отказало устройство: второй провайдер не заменит сломанный маршрутизатор или коммутатор. Понадобятся совместимый резерв, актуальная внешняя копия настроек, схема портов, доступ к управлению и проверка VLAN, DNS и маршрутизации.
Сотрудник с рабочего места открывает нужное приложение, выполняет контрольную операцию; для телефонии проверены входящий и исходящий звонки. Указаны ограничения по числу пользователей и нагрузке.
Что ломает план: оба канала зависят от одного ввода или питания; резервный VPN никогда не проверяли; конфигурация хранится только на сломанном устройстве. Возврат на основную схему тоже планируют: переключение не должно оборвать текущие операции без согласования.
Сценарий 4. Шифровальщик: копии есть, доверенной среды нет
Исходная ситуация: обнаружены зашифрованные файлы и подозрительные действия в нескольких системах. Возвращать данные в ту же среду без разбора опасно: причина и доступ атакующего могут сохраниться.
- Реагирование: ответственные специалисты определяют затронутые системы, координируют изоляцию и сохраняют необходимые сведения для расследования.
- Коммуникации: используют согласованный альтернативный канал, если обычной инфраструктуре нельзя доверять.
- Восстановление: определяют пригодные копии и чистую среду, устраняют причины компрометации, проверяют доступы и средства контроля.
Принципы изоляции, сохранения свидетельств и приоритетного восстановления в чистой сети приведены в CISA #StopRansomware Guide. Это не предложение сотрудникам самостоятельно отключать всю сеть или менять все пароли без координации.
Что делает бизнес
Устанавливает доступные операции и ограничения, приостанавливает использование подозрительных источников данных, ведёт согласованную очередь запросов и готовит сообщения через уполномоченных участников.
Когда возможен возврат
Проверены восстановленные данные и рабочие операции; ответственные за реагирование разрешили подключение, а владелец процесса принял ограничения и результат.
Что ломает план: резервные копии доступны теми же скомпрометированными полномочиями; свежая копия уже содержит последствия атаки; заражённые рабочие места сразу подключают к восстановленным сервисам. Успешное чтение резервного файла само по себе не означает, что среда готова к работе.
Люди и помещение: два резерва, о которых забывают
Офис недоступен
Проверьте не только удалённое подключение, но и место хранения ноутбуков, инструкций и средств подтверждения входа. Всё необходимое не должно оказаться внутри того же закрытого помещения.
Резервное место должно позволять выполнить нужную операцию: одного доступа к веб-почте недостаточно, если процесс зависит от специального оборудования или документов.
Специалист недоступен
Заместитель должен иметь собственные согласованные полномочия, актуальную инструкцию и контакты поставщиков. В упражнении он проходит маршрут без подсказок автора.
Если при каждой развилке всё равно нужен звонок единственному администратору, замещение ещё не работает. Общий пароль вместо управляемых прав не решает проблему.
Если ситуация угрожает людям, первоочередны безопасность и указания ответственных служб. ИТ-план не заменяет порядок действий при чрезвычайной ситуации.
Что должно быть в рабочем плане
- Границы: процесс, подразделения и рассматриваемые события.
- Условия запуска: кто оценивает ситуацию и вводит временный режим.
- Результат: какие операции сохраняются и с какими ограничениями.
- Ресурсы: сотрудники, замещение, устройства, сведения, площадка и поставщики.
- Процедуры: понятные действия, зависимости и способы проверки.
- Коммуникации: кому, через какой канал и кто сообщает обновления.
- Возврат: приёмка сервиса, сверка накопленных данных и отмена временного порядка.
- Актуальность: владелец документа, версия, доступная копия и пересмотр.
Контакты и инструкция должны оставаться доступны при том отказе, для которого они написаны. План только на недоступном файловом сервере бесполезен; при этом резервную копию документа тоже нужно хранить с подходящими правами и обновлять.
Связь процедур, технических мер и альтернативных способов выполнения операций описана в материалах NIST по планированию восстановления. Состав конкретного плана определяется задачами организации.
Рабочее место и связь → нужные службы сети и входа → доступное хранилище и СУБД → сервер приложения → обмены и рабочая операция. Конкретная цепочка зависит от размещения и настроек; это не обязательный порядок запуска всех систем.
Для каждого звена укажите владельца, способ проверки и альтернативу. Если резервная 1С зависит от того же недоступного DNS или контроллера домена, запуск её виртуальной машины ещё не вернёт пользователям работу.
Кто принимает решения и кто выполняет работу
| Роль в плане | За что отвечает | Что подготовить |
|---|---|---|
| Координатор и заместитель | Собирает состояние, запускает согласованный порядок, связывает участников | Полномочия, контакты, признаки эскалации и журнал решений |
| Владелец процесса | Задаёт приоритеты, ограничения и подтверждает рабочий результат | Критерии приёмки, допустимые операции и порядок сверки |
| ИТ, исполнители и поставщики | Возвращают сервисы и выполняют назначенные действия | Инструкции, доступы, ресурсы, контакты и границы ответственности |
Это пример распределения обязанностей. В небольшой компании один человек может совмещать роли, но ему всё равно нужны полномочия, замещение и понятные действия. Участие внешнего подрядчика не отменяет решений владельца бизнес-процесса.
Что сообщать сотрудникам и клиентам
Отсутствие информации быстро порождает повторные обращения и противоречивые обещания. Заранее определите источник обновлений и резервный канал на случай недоступности обычной почты или мессенджера.
- Подтверждённый факт: какие функции затронуты и что известно сейчас.
- Рабочий порядок: что можно делать, куда направлять запросы и какие ограничения действуют.
- Ответственность: кто принимает вопросы и передаёт их исполнителям.
- Следующее обновление: когда и где появится новая информация.
Не подменяйте неизвестное время восстановления неподтверждённым обещанием. Можно сообщить время следующего обновления, даже если точный срок окончания ещё не установлен. Внешнее сообщение должно быть согласовано уполномоченным участником и не раскрывать лишние технические сведения.
Пример сообщения сотрудникам
«Доступ к 1С нарушен. Новые заявки записывайте в утверждённый временный журнал. Подтверждение отгрузок — через руководителя склада. Ответственный за координацию назначен; следующее обновление — в 11:00 в резервном канале».
Пример сообщения клиенту
«Ваш запрос зарегистрирован под временным номером. Возможность и срок исполнения уточняем. Ответственный менеджер сообщит статус до согласованного времени. Повторно отправлять заявку не требуется».
Это образцы формулировок. Канал, ответственного и время обновления нужно реально назначить, а не просто скопировать текст в рассылку.
Возвращение к обычной работе — отдельный этап
- Проверить сервис: данные, зависимости, операции и необходимую нагрузку.
- Обозначить переход: определить момент прекращения временной регистрации и сообщить участникам.
- Сверить накопленное: перенести сведения, разобрать дубли, пропуски и незавершённые задачи.
- Проверить ограничения: отозвать больше не нужные временные права и ресурсы по согласованному порядку.
- Подтвердить результат: владелец процесса принимает обычный режим, а отклонения получают ответственных.
При переносе данных важно сохранить связь с временными идентификаторами. Для сложных обменов может понадобиться отдельная процедура сверки. Решение о возврате не должно зависеть только от сообщения «сервер запущен».
Почему запуск сервера не убирает очередь заказов
Учебный расчёт: в компанию поступает 60 заявок в час. Два часа их только регистрировали, а обработку отложили. Накопилось 120 заявок. После восстановления команда обрабатывает 80 заявок в час, но новые продолжают приходить со скоростью 60 в час.
| Показатель | Расчёт | Результат |
|---|---|---|
| Накопленная очередь | 60 × 2 | 120 заявок |
| Ресурс для уменьшения очереди | 80 − 60 | 20 заявок в час |
| Время разбора очереди | 120 ÷ 20 | 6 часов после восстановления |
При такой постоянной нагрузке и производительности без перерывов очередь будет разобрана за шесть часов, а не за полтора часа по формуле 120 ÷ 80. Если команда обрабатывает только 60 заявок в час, очередь при том же притоке не уменьшается. При меньшей производительности она растёт.
Что подготовить
- Приоритеты просроченных и новых обращений.
- Дополнительных исполнителей с нужными правами и знаниями.
- Порядок сверки и защиты от дублей.
- Реалистичное информирование клиентов об очереди.
Что измерять после запуска
- Поступление и обработку за одинаковый период.
- Размер и возраст накопленной очереди.
- Ошибки переноса и повторные обращения.
- Ограничения нагрузки приложения и команды.
Цифры условные и не являются статистикой AVG IT. Фактические заявки различаются по трудоёмкости; план строят по своим замерам. Восстановление сервиса и разбор накопленной работы фиксируют раздельно, чтобы не скрыть ни технический простой, ни оставшиеся последствия для бизнеса.
Как проверить план без формальной галочки
Разбор за столом
Участники проходят сценарий: кто узнаёт о событии, кто решает, где инструкция, что сообщают и как подтверждают результат.
Практическое упражнение
В согласованной среде проверяют резервный доступ, восстановление, временную регистрацию или работу заместителя.
Техническое упражнение должно иметь границы воздействия и способ возврата. Для важных зависимостей одной беседы недостаточно: проверка восстановления данных и реального переключения имеет собственный объём. Результат относится к условиям испытания, а не автоматически ко всем авариям.
После проверки зафиксируйте наблюдение, влияние, ответственного и следующий шаг. Изменились процессы, люди, поставщик или архитектура — пересмотрите связанные части плана. Практический шаблон организации участников, стратегий и упражнений есть у Ready Business; его нужно адаптировать к своей компании.
В согласованной тестовой среде основной сервис считается недоступным. Участники регистрируют три условные заявки: новую, повторную и с изменением состава. После возврата сервиса проверяют, что каждая учтена ровно один раз, изменение сохранено, ответственный известен, а клиентское сообщение соответствует фактам. Затем упражнение повторяет заместитель координатора.
Две формы для подготовки и упражнения
Карточка непрерывности процесса
Критичные операции, временный порядок, зависимости, ответственные и условия возврата.
Скачать карточку · TXTПротокол упражнения
Сценарий, решения, проверенные действия, отклонения и план доработки.
Скачать протокол · TXTНачните с одного процесса и одного понятного сценария. После проверки распространите подход на связанные операции; заполненная форма сама по себе не подтверждает готовность.
Минимум для временного журнала: уникальный номер, время поступления, канал, необходимые контактные сведения, содержание запроса, ответственный, статус, история изменения и номер записи в основной системе после переноса. Доступ и объём сведений ограничьте рабочей необходимостью.
Подготовить ИТ-часть непрерывности бизнеса
ИТ-аутсорсинг: связать действия и ответственность
- Разобрать зависимости важных сервисов.
- Подготовить технические процедуры и контакты.
- Проверить доступы и замещение.
- Запланировать восстановление и упражнения.
Состав сопровождения и участие ответственных со стороны компании согласуем по задаче.
Обсудить подготовку ИТОблачные ресурсы: оценить резервные варианты
- Обсудить ресурсы для восстановления.
- Разобрать удалённый доступ и зависимости.
- Уточнить хранение копий и подключения.
- Проверить запуск согласованного сценария.
Конфигурация, доступность ресурсов, условия аренды и границы поддержки подтверждаются отдельно.
Обсудить облачные ресурсыВопросы о непрерывности бизнеса
Достаточно резервного копирования?
Копирование помогает вернуть данные. Для продолжения работы нужны также люди, доступы, ресурсы, понятный временный порядок и проверка рабочих операций.
BCP нужен только большой компании?
Объём подготовки зависит от процессов и последствий остановки. Небольшая компания может начать с одного критичного процесса, ответственных и проверенного сценария.
Кто должен писать план — руководитель или администратор?
Владелец процесса определяет рабочий результат и ограничения; технические специалисты готовят ИТ-часть, а координатор связывает действия. Без участников бизнеса план рискует описывать только запуск оборудования.
Два интернет-провайдера обеспечивают непрерывность?
Это один из возможных элементов. Нужно проверить общие зависимости, переключение, ёмкость резервного канала и доступ к приложениям. Остальные риски процесса требуют своих решений.
Облако автоматически решает задачу?
Оно может дать варианты размещения и восстановления, но необходимо определить доступы, подключения, копии, приложение и ответственность. Возможности выбранной схемы подтверждают проверкой.
Когда план можно считать рабочим?
Когда участники понимают роли, нужные сведения и ресурсы доступны, сценарий проверен, а ограничения и отклонения известны. Готовность поддерживают актуализацией и повторными упражнениями.