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

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

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

Чем непрерывность отличается от управления кризисом?

Три понятия постоянно смешивают, и именно поэтому не выстраивают ни одно из них. Управление кризисом отвечает за то, что и кому говорят после события: клиентам, команде, иногда публично. Техническое восстановление отвечает за возврат систем, данных и доступов. План непрерывности стоит над обоими и отвечает на единственный вопрос: пока систем нет, офис закрыт, а до ключевого человека не дозвониться, каким образом работа продолжает идти?

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

Считайте последствия, а не риски

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

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

Какие процессы действительно критичны?

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

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

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

Сколько мы можем стоять и сколько данных можем потерять?

Две цифры образуют каркас плана. Первая — сколько времени процесс может не работать. Вторая — какой объём данных допустимо потерять к моменту возврата. Обе относятся не к технической службе, а к тому, кто управляет бизнесом. Сказать мы не можем потерять ни одной записи легко; когда на стол ложится стоимость такой инфраструктуры, большинство компаний признаёт, что потеря половины дня их не разрушит, и это совершенно законное решение. Плохо другое — когда решение не принимают вовсе и его по умолчанию принимает тот, кто когда-то настроил копирование. Таблица ниже иллюстративна, у вас цифры будут другими.

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

Риск простоя: помещение, связь и поставщик

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

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

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

Потеря данных: наличие копии ещё не защита

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

Готова не та компания, у которой есть резервная копия, а та, которая хотя бы раз попробовала из неё вернуться.

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

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

Риск ключевого сотрудника: вынуть знание из одной головы

В малых компаниях главный риск непрерывности — не сервер, а человек. Пароль, который знает один. Поставщик, с которым разговаривает один. Ценовые исключения, живущие только в чьей-то памяти, и устные договорённости, которых никто не записал. Всё это не задокументировано, потому что до записи руки не доходят, а человек и так всегда на месте. Ровно до того дня, когда его нет.

Здесь обычно советуют задокументировать всё, и на практике этот совет чаще всего не срабатывает. Документ верен в день написания, частично неверен через три месяца и никем не открывается через полгода. Надёжнее ротация: раз в квартал критичную задачу на неделю передают дублёру. Всё, чего в документе не хватало, всплывает именно на этой неделе, а дублёр к тому же один раз действительно сделал работу руками. Ротация — это механизм аудита документации, и если выбирать одно из двух, ротация ценнее. Письменная основа всё-таки нужна, а на каком уровне детализации фиксировать критичные потоки, мы разбираем в материале о документировании процессов и SOP.

Передача доступов и полномочий

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

В каком формате писать план?

Документ на сорок страниц в день аварии никто не откроет. Работает одна страница, читаемая с экрана телефона. В ней должно быть следующее:

• Условие запуска: при каком последствии план включается — нет помещения, нет систем, потеряны данные, нет ключевого человека; одна фраза, без предисловий.
• Порядок обзвона: кто кому звонит и в какой последовательности, кто принимает первое решение и к кому переходит право решать, если первых двух нет на связи.
• Хранилище доступов: где лежат критичные учётные данные и кто может открыть хранилище в аварии; путь к хранилищу, а не сами пароли.
• Ручной обходной путь: как принимать заказы без систем, с каким документом уходит отгрузка и как эти записи потом попадают в систему.
• Уведомление клиентов и поставщиков: кто и по какому каналу сообщает; готовый черновик текста должен лежать внутри плана, в день аварии тексты не пишут.
• Критерий возврата: кто и по каким признакам объявляет возврат к норме; без этой строки компания неделями живёт в полукризисном режиме.

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

Без учений плана не существует

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

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

Где этот подход перестаёт работать?

Планирование непрерывности — не про удвоение всего подряд. В команде из шести человек второй офис, второй канал связи и второй сервер создают нагрузку больше того риска, от которого защищают. Для маленьких команд правильный ответ чаще звучит как упрощение, а не дублирование: меньше систем, меньше ручных шагов, меньше знаний, привязанных к одному человеку. Свести клиентскую базу из пяти мест в одно даёт больше непрерывности, чем аренда второго сервера.

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

Что сделать за первые тридцать дней?

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

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

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