События октября показали, что даже крупная распределённая инфраструктура может одновременно столкнуться с несколькими серьёзными отказами. Для бизнеса практический вывод простой: критичные сервисы нужно заранее подготовить к работе в условиях, когда облачная площадка, канал связи или внешняя интеграция временно недоступны.
Это не повод срочно переносить все системы или отказываться от облаков. Задача руководителя и IT-специалиста состоит в другом: понять, какие процессы остановятся при сбое, проверить резервные копии и доступы, назначить ответственных и провести пробное восстановление. Тогда нештатная ситуация превращается из кризиса в управляемый сценарий.
Ниже разберём, что известно об инцидентах, и дадим практический чек-лист для проверки инфраструктуры компании.
Что произошло с дата-центрами Яндекса
По официальной информации Яндекса, в период с 7 по 11 октября 2026 года были затронуты три дата-центра:
- в ночь с 7 на 8 октября серьёзно пострадал дата-центр в Сасове, его работа была полностью остановлена;
- утром 9 октября была повреждена часть инфраструктуры дата-центра в Калуге;
- в ночь на 11 октября остановилась работа дата-центра во Владимире.
Яндекс сообщил, что в Сасове, Калуге и Владимире люди не пострадали. Причиной компания назвала атаки беспилотных летательных аппаратов. В сообщении от 11 октября Яндекс отмечал, что сроки полного восстановления оборудования оценить сложно.
Инциденты повлияли на работу облачной платформы и отдельных сервисов.
Yandex Cloud сообщал о недоступности зон, частичной доступности вычислительных ресурсов и баз данных, ограничениях на запись в объектное хранилище и других последствиях.
Пользователям рекомендовали задействовать альтернативные площадки и планы аварийного восстановления.
По состоянию на утро 13 октября платформа продолжала работать в ограниченном режиме, а восстановительные работы продолжались.
Что важно уточнить про Битрикс24
Основной облачный Битрикс24, платформа Битрикс24 Вайбкод и REST-приложения представляют разные части экосистемы, поэтому их статус нельзя объединять в одну формулировку.
По уточнению Битрикс24, переданному партнёрам после инцидента, данные облачных Битрикс24 сохранились, массового отключения порталов не было. Инцидент затронул инфраструктуру Битрикс24 Вайбкод. Данные этой платформы находятся в резервных копиях и подлежат восстановлению. Работа REST-приложений временно ограничивалась на несколько часов.
Открытая статус-страница Битрикс24 подтверждает сложности в работе Вайбкод с 8 октября. Она также фиксирует отдельное замедление некоторых Битрикс24 8 октября с 15:40 до 16:05 по московскому времени. Это важно учитывать, чтобы не делать категоричный вывод о полной недоступности всех порталов. Публичная страница не содержит полной хронологии ограничений REST-приложений, поэтому длительность этого ограничения приводится как уточнение Битрикс24.
В документации Битрикс24 указано, что облачные порталы резервируются ежедневно, а копии хранятся семь дней. Для серверов Битрикс24 Вайбкод предусмотрены полные снимки диска, включая код, базу данных, файлы и настройки. Наличие резервной копии снижает риск потери данных, но само по себе ещё не гарантирует быстрое восстановление конкретного бизнес-процесса. Для этого нужны понятный порядок действий, доступы и проверенный сценарий запуска на резервной площадке.
С чего начать проверку устойчивости
Сначала составьте короткий список процессов, без которых компания теряет заявки, деньги или возможность обслуживать клиентов. Для большинства компаний в него входят:
- сайт и интернет-магазин;
- CRM и телефония;
- корпоративная почта и мессенджеры;
- 1С и обмен между 1С, сайтом и CRM;
- рабочие файлы, регламенты и инструкции;
- интернет-эквайринг и другие способы приёма платежей;
- интеграции, роботы, вебхуки и REST-приложения.
Для каждого пункта ответьте на три вопроса: сколько времени процесс может быть недоступен, сколько последних данных допустимо потерять и кто принимает решение о переключении. Эти ответы помогают определить приоритеты. Если сайт может подождать четыре часа, а новые заказы нельзя терять дольше десяти минут, планы восстановления для них будут разными.
- Проверьте резервные копии данных
- 1С, включая информационные базы, настройки обмена и связанные файлы;
- коробочного Битрикс24 и других систем, размещённых на собственных серверах;
- критичных данных облачного Битрикс24, которые можно выгружать штатными средствами: CRM, справочников, отчётов и документов;
- файловых хранилищ, договоров, шаблонов, инструкций и регламентов;
- конфигураций сайтов, приложений, интеграций, телефонии и почты;
- исходного кода и зависимостей собственных приложений.
- Храните копию вне основной площадки
- Проведите пробное восстановление
- какая версия данных восстановилась;
- сколько времени занял запуск;
- какие ключи, лицензии и пароли потребовались;
- заработали ли интеграции и фоновые задания;
- кто подтвердил корректность данных со стороны бизнеса.
- Проверьте управление доменом и DNS Даже готовая резервная площадка не поможет, если никто не может перенаправить на неё сайт или почту. Системный администратор должен знать:
- у какого регистратора находится домен;
- где управляются DNS-записи;
- кто владеет учётной записью и как восстановить доступ;
- включена ли двухфакторная аутентификация и где хранятся резервные коды;
- какие записи отвечают за сайт, почту и проверку внешних сервисов;
- сколько времени обычно занимает изменение маршрутизации.
- Подготовьте резервные каналы связи с клиентами
- Проверьте способы приёма платежей
- резервного эквайера или альтернативную платёжную ссылку;
- оплату по счёту и корректность реквизитов;
- доступ ответственных к кабинетам банков и платёжных сервисов;
- порядок ручного подтверждения оплаты;
- последующую сверку платежей, чтобы избежать дублей и потерянных заказов.
- Опишите штатные и нештатные сценарии
- Соберите комплект для восстановления инфраструктуры
- актуальная схема инфраструктуры и перечень критичных сервисов;
- адреса площадок, параметры серверов и сетевые настройки;
- доступы к домену, DNS, облакам, хостингу и репозиториям;
- резервные коды двухфакторной аутентификации;
- дистрибутивы, лицензии и инструкции по развёртыванию;
- описание интеграций, вебхуков, очередей и фоновых заданий;
- контакты провайдеров и ответственных сотрудников;
- последняя проверенная копия и журнал тестовых восстановлений.
В резервирование стоит включить не только базы данных и серверы. Проверьте копии:
Для облачных систем сначала выясните, что именно резервирует поставщик, на какой срок хранятся копии и как подать запрос на восстановление.
Отдельно определите, какие данные компания должна экспортировать самостоятельно.
Например, Битрикс24 создаёт ежедневные копии облачных порталов, но восстановление выполняется через техническую поддержку и доступно с учётом условий тарифа.
Копия на том же сервере не защищает от отказа сервера. Копия в том же дата-центре может оказаться недоступной вместе с основной системой. Минимальная рабочая схема предусматривает независимую копию в другом месте и с отдельным контуром доступа.
Это может быть второй дата-центр, другой облачный провайдер, защищённое объектное хранилище или подготовленная локальная площадка. Важно, чтобы единичный инцидент не затронул одновременно основную систему и все копии.
Хранение копии на рабочем компьютере допустимо только как дополнительная временная мера. Такой файл должен быть зашифрован, доступ к нему нужно ограничить, а срок хранения определить заранее. Рабочий компьютер может выйти из строя, заразиться вредоносной программой или попасть к постороннему человеку, поэтому делать его единственным резервным хранилищем нельзя.
Успешное сообщение «резервная копия создана» ещё не доказывает, что систему можно восстановить. Копия может оказаться неполной, повреждённой или зависеть от доступа, который уже недоступен.
Проведите тест на отдельной площадке. Зафиксируйте:
После существенных изменений инфраструктуры тест нужно повторять. Для критичных сервисов полезно проводить такие проверки по регулярному графику.
Доступы лучше хранить в корпоративном менеджере паролей с разграничением прав. В аварийной инструкции достаточно указать место хранения и ответственных. Сами пароли не нужно копировать в открытый документ или общий чат.
Проверьте почту, телефонию и мессенджеры как единый процесс общения с клиентом. Если виртуальная АТС связана с CRM, отказ одной системы может одновременно убрать звонки, карточку клиента и историю обращения.
Для каждого канала определите резервный вариант и порядок переключения. Подготовьте короткий текст уведомления для сайта, почты и мессенджеров: что временно недоступно, как связаться с компанией и когда ждать следующее обновление. Клиенту важнее получить понятный рабочий контакт, чем подробное техническое объяснение.
Резервный мессенджер или личный телефон сотрудника можно использовать только в рамках утверждённого компанией сценария. Нужно заранее определить, какие данные разрешено передавать по такому каналу, как фиксировать договорённости и кто потом переносит их в CRM.
Сбой платёжного шлюза, банка или интеграции с сайтом напрямую влияет на выручку. Компания должна понимать, можно ли быстро предложить клиенту другой законный и согласованный способ оплаты.
Проверьте:Резервный способ оплаты должен быть заранее проверен бухгалтерией и службой безопасности. Импровизация во время сбоя создаёт дополнительные финансовые и юридические риски.
Для каждого критичного сервиса нужна короткая инструкция, которую сотрудник сможет выполнить без совещания и поиска нужного человека.
Например:
Если недоступна CRM
Менеджер принимает обращение по резервному каналу, записывает контакт, суть запроса и согласованное действие в утверждённую форму. После восстановления ответственный переносит запись в CRM и проверяет отсутствие дублей.
Если недоступна корпоративная почта
Сотрудники переходят на заранее согласованный резервный канал. Клиентам отправляется уведомление с временным адресом или номером. Полученные обращения фиксируются в общем реестре.
Если недоступна телефония
Включается переадресация на резервные номера или используется альтернативная линия. На сайте и в автоответчике публикуется актуальный способ связи.
Если недоступна 1С
Операции, которые нельзя безопасно провести без учётной системы, приостанавливаются. Для разрешённых операций используется согласованный ручной документ. После восстановления бухгалтерия проводит сверку и вводит данные в систему.
Ручные таблицы, документы и звонки помогают пережить несколько часов простоя. Они должны иметь владельца, единый формат и правила последующего переноса данных. Иначе после восстановления команда получит потерянные обращения и противоречивые версии документов.
Резервные копии полезны только вместе с информацией, необходимой для запуска. Системному администратору или специалистам Соль могут понадобиться:
Такой комплект не стоит хранить одним открытым архивом. Документируйте местонахождение секретов, распределяйте права и предусмотрите экстренный доступ с контролем действий.
Что сделать в ближайший рабочий день
Если полноценного плана аварийного восстановления пока нет, начните с короткой проверки:
- Назначьте владельца проверки и соберите список критичных сервисов.
- Убедитесь, что по каждому сервису есть свежая копия вне основной площадки.
- Проверьте вход в панели домена, DNS, хостинга, почты и телефонии.
- Выберите резервные каналы связи и оплаты.
- Напишите по одной странице инструкций для менеджеров, бухгалтерии и IT-специалиста.
- Проведите учебное переключение одного некритичного сервиса и запишите результат.
Даже этот базовый набор заметно сокращает время реакции. Следующий шаг заключается в полноценном аудите зависимостей, требований к времени восстановления и регулярных тренировках.
Соль проводит аудит IT-инфраструктуры и рабочих процессов: собирает карту систем и доступов, проверяет резервирование, находит единые точки отказа и готовит сценарии действий при сбоях.
Частые вопросы
Если сервис работает в облаке, нужны ли компании свои резервные копии?
Нужно проверить модель ответственности конкретного сервиса. Провайдер может резервировать платформу, но у бизнеса остаются собственные риски: ошибочное удаление, недоступная интеграция, ограниченный срок хранения копий и отсутствие быстрого экспорта. Критичные данные и порядок их восстановления нужно описать отдельно.
Где лучше хранить резервные копии?
Хотя бы одна копия должна находиться вне основной площадки и не зависеть от тех же учётных записей и оборудования. Конкретная схема зависит от объёма данных, требований закона, допустимого времени простоя и бюджета.
Можно ли хранить копию на компьютере сотрудника?
Только как дополнительную временную меру. Файл нужно шифровать, ограничивать доступ и удалять по регламенту. Рабочий компьютер не подходит на роль единственного резервного хранилища.
Как часто проверять восстановление?
Периодичность зависит от критичности системы и частоты изменений. Проверку стоит проводить регулярно, а также после переноса инфраструктуры, крупных обновлений, изменения интеграций или ответственных сотрудников.
Что должна содержать инструкция для менеджера?
Признаки сбоя, ответственного за решение, резервный канал связи, форму фиксации обращения, допустимые ручные действия и порядок переноса данных после восстановления. Инструкция должна помещаться на одной странице и быть доступной без основной CRM.
Главное
Устойчивость бизнеса определяется не только надёжностью поставщика. Важны независимые копии, доступ к управлению инфраструктурой, резервные каналы связи и оплаты, а также понятные действия сотрудников. Эти меры помогают продолжать обслуживать клиентов и сохранять выручку, пока технические команды восстанавливают основные сервисы.
Если вам нужно собрать доступы, проверить инфраструктуру и подготовить рабочий план восстановления, закажите аудит у Соль. Мы поможем определить приоритеты и подготовить компанию к нештатным ситуациям без лишнего усложнения процессов.
