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

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

Что настроить до сбоя: план действий

Главная ошибка — надеяться на авось и верить, что «в этот раз пронесёт». Подготовка начинается не в момент падения, а за месяцы до него. Вот конкретные шаги, которые стоит внедрить.

  • Инвентаризация критичных сервисов. Составьте список всех облачных систем, которые используются в компании, и отметьте, какие из них действительно останавливают работу при простое. Например, почта может быть не критична, если есть возможность переключиться на локальный клиент, а вот CRM или система документооборота — жизненно важны. Для каждого критичного сервиса определите максимально допустимое время простоя.
  • Резервные каналы связи и доступы. Убедитесь, что у сотрудников есть альтернативные способы связи (мобильные телефоны, мессенджеры), а у ИТ-службы — доступ к инфраструктуре провайдера через резервный канал. Например, если основной интернет-канал идёт через того же провайдера, что и облако, при аварии вы можете остаться без связи. Настройте резервного провайдера или используйте мобильный интернет для администрирования.
  • Локальные копии критичных данных. Регулярно выгружайте наиболее важные данные (например, базы 1С, документы, конфигурации) на локальный сервер или в другое облако. Это не заменит полноценного резервного копирования, но позволит продолжить работу, пока основное облако недоступно. Важно: выгрузка должна быть автоматической и проверяться.
  • Документированные сценарии действий. Напишите простые инструкции для сотрудников: что делать, если не работает почта, CRM, файловое хранилище. Кто отвечает за коммуникацию с провайдером, как оповещать клиентов. Эти инструкции должны быть доступны вне облака — например, на локальном вики или в распечатанном виде.
  • Тестирование сценариев. Хотя бы раз в квартал проводите учебную тревогу: отключите доступ к облачному сервису на час и посмотрите, как команда справляется. Это поможет выявить узкие места и обновить инструкции.

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

Что уже бесполезно делать во время сбоя

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

  • Панические звонки провайдеру. Если у провайдера массовая авария, поддержка перегружена. Вместо того чтобы звонить каждые пять минут, лучше следить за официальными каналами оповещения (статус-страница, Telegram-канал) и не дублировать запросы. Исключение — если у вас персональный менеджер и авария затронула только ваш аккаунт.
  • Попытки «починить» облако своими силами. Если проблема на стороне провайдера, вы не сможете на неё повлиять. Не тратьте время на перезагрузки, переустановки и изменение конфигураций — это может усугубить ситуацию после восстановления.
  • Массовые рассылки сотрудникам с требованием «срочно всё сделать». В стрессе люди и так дезориентированы. Лучше дать чёткие инструкции из заранее подготовленного плана.
  • Запуск новых проектов и изменение инфраструктуры. Во время сбоя любые изменения могут привести к дополнительным проблемам. Дождитесь восстановления.

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

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

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

  • Оцените стоимость простоя. Посчитайте, сколько компания теряет за час без того или иного сервиса. Если потери велики, есть смысл вложиться в резервный контур (например, держать локальную копию или использовать второго провайдера).
  • Определите допустимое время восстановления (RTO) и допустимую точку восстановления (RPO). RTO — сколько времени вы готовы ждать, RPO — какой объём данных можете потерять. Для бухгалтерии RPO может быть 1 час, для корпоративной почты — 4 часа. Исходя из этого, выбирайте частоту резервного копирования и способ резервирования.
  • Используйте гибридный подход. Не обязательно переносить всё обратно в локальную инфраструктуру. Можно держать критичные данные локально, а остальное — в облаке. Или использовать мультиоблачную стратегию, когда данные реплицируются между двумя провайдерами. Но помните: мультиоблако сложнее в управлении и требует дополнительных компетенций.
  • Проверяйте провайдера. Изучите SLA, историю сбоев, наличие статус-страницы, скорость реакции поддержки. Если провайдер часто падает и не компенсирует потери, возможно, стоит задуматься о смене.

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

Что делать после восстановления

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