Сбой Яндекса: что проверить бизнесу, если всё завязано на одном сервисе

Один сбой — и будто в каменный век. Сколько вашего бизнеса держится на одном сервисе?

Пока всё работает, очень удобно держать почту, документы, облако, платежи и другие рабочие инструменты внутри привычной цифровой инфраструктуры. А потом часть сервисов становится недоступна — и внезапно выясняется, что запасного маршрута просто нет.

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

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

Пока всё работает, зависимость почти незаметна

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

В этом нет ничего плохого. Проблема начинается тогда, когда исчезает второй вариант. Допустим, сегодня до 15:00 нужно провести обязательный платёж, а привычный финансовый сервис временно недоступен. Что делает бухгалтер? Через час менеджеру отправлять клиенту договор, а рабочее облако не открывается. Где лежит последняя версия? Команде нужно срочно связаться, но основной канал недоступен. Куда все переходят?

Если ответ каждый раз один — «ждём, пока заработает», — это уже не просто техническое неудобство. Это зависимость бизнеса от внешнего сервиса.

Дело не в Яндексе

Сегодня инфоповод связан с Яндексом. В другой ситуации это может быть банк, CRM, хостинг, телефония, облако или другой подрядчик. Поэтому я бы не строил систему на мысли: «У них такого точно не случится».

Даже Yandex Cloud во время инцидента рекомендовал клиентам использовать альтернативные варианты восстановления. И мне здесь нравится сама логика: не паниковать, не отказываться от удобных решений и не дублировать всё подряд. Нужно понимать, какие процессы для бизнеса критичны и что произойдёт, если основной инструмент временно исчезнет.

Сначала посчитайте не резерв, а цену остановки

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

Но если вместе с сервисом останавливаются продажи, платежи, обслуживание клиентов или работа команды, уже стоит сравнить две вещи: что для бизнеса дороже — резервный вариант или простой?

Это гораздо полезнее, чем пытаться страховать вообще всё.

Деньги: сегодня нужно платить. Что делаем?

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

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

Если да — хорошо. Если нет и остаётся только ждать, я бы хотя бы зафиксировал такую зависимость как риск.

Документы: где лежит то, без чего работа действительно остановится?

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

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

Не «может быть, у кого-то есть копия». А знает.

Резерв — это ещё и люди

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

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

Вот здесь технический вопрос уже превращается в управленческий.

Проведите стресс-тест

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

И напротив каждого написал: «Если этого завтра нет — что мы делаем?»

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

Удобная система и устойчивая система — не одно и то же

Удобная система отвечает на вопрос: «Как нам работать быстрее, когда всё нормально?» Устойчивая добавляет ещё один: «Как мы продолжим работать, когда что-то перестанет быть нормальным?»

И мне кажется, собственнику нужны оба ответа. Пользоваться хорошими экосистемами нормально. Хранить всё в одном удобном интерфейсе тоже нормально, если вы понимаете цену этой зависимости.

Проблема начинается, когда решение использовать один сервис постепенно превращается в решение полностью от него зависеть, хотя такого решения никто сознательно не принимал.

Поэтому после истории с Яндексом я бы не спрашивал только: «Когда всё окончательно восстановят?» Я бы посмотрел на свой бизнес и задал другой вопрос: если завтра один критичный внешний сервис исчезнет на сутки, мы продолжим работать или вся наша стратегия — ждать, пока кто-то другой вернёт нам привычную жизнь?

Если бизнес работает только пока безотказно работают все внешние сервисы, это не устойчивость. Это просто удачное стечение обстоятельств.