Когда облако падает: какие процессы у вас останавливаются вместе с ним

Мы держим своё железо и свой контур с ИИ не потому, что нам нравится возиться с серверами. А потому что слишком часто видели одну и ту же картину: у компании всё работает, пока не падает чужой сервис — и вместе с ним падает половина бизнеса, которая о той чужой стороне даже не знала. Речь о реальных сбоях внешних сервисов: почта, платёжные шлюзы, облачная аналитика, ИИ-модели по API. Они падают регулярно, и предсказать конкретный день нельзя — можно только заранее понять, что именно встанет вместе с ними.

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

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

Обычный день, который остановился

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

Сюда же добавился новый персонаж: ИИ-ассистент, встроенный в бизнес-процессы. Он отвечает клиентам в чате, готовит черновики ответов, собирает сводки. Если он работает через облачную модель по API, то молча гаснет вместе с ней — и процессы, которые утром были автоматизированы, вечером выполняются вручную или не выполняются вовсе.

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

Где прячутся зависимости

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

• CRM-интеграции. Сделки тянут данные из внешних сервисов: подсказки компаний, обогащение контактов, проверка контрагентов, автоматические письма. Когда внешний API молчит, CRM формально работает — но половина кнопок в ней не делает ничего полезного.
• Телефония. Облачная АТС — это внешний сервис. Звонки не проходят или не записываются, а вместе с ними пропадает и распознавание разговоров, если оно тоже облачное.
• ИИ в бизнес-процессах. Черновики ответов, сводки, классификация обращений, ассистент в чате. Всё это держится на облачной модели, и «на минуту отключилось» для неё значит «процесс встал».
• Почта и документы. Корпоративная почта в облаке, документы в облаке, подписи в облаке. Отдельный сюрприз — сервисы, которые при недоступности почтового API ставят отправку в очередь и никто не замечает, что письма ушли с задержкой.

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

Три уровня готовности

Мы привыкли описывать готовность к сбоям как шкалу. На ней три уровня, и разница между соседними — это разница между «день без работы» и «день с неудобствами».

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

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

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

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

Что даёт локальный контур

«Локальный контур» звучит как что-то дорогое и датацентровое, но на практике это набор конкретных вещей, которые продолжают работать, когда внешняя сеть недоступна.

Инференс на своём железе. У нас это кластеры из DGX Spark — компактные рабочие станции на архитектуре GB10 с достаточным объёмом памяти, чтобы держать современные открытые модели локально. Письменные задачи, ассистентские сценарии, работа с базой знаний — всё это крутится у нас в офисе и не зависит ни от одного внешнего API. Мы подробно разбирали, как открытая модель размера «на одну рабочую станцию» закрывает повседневные задачи, в статье про локальный запуск Qwen3.8-Flash, и что такое этот класс железа — в разборе DGX Spark.

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

Статический сайт с CDN. Сайт компании — это то, что должно работать всегда, в том числе когда недоступны внешние API, из которых он обычно тянет данные. Статическая генерация решает это радикально: сайт продолжает отдаваться, даже если внешние сервисы недоступны. Мы описывали такой подход в статье про статический сайт с ИИ-контуром.

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

Сумма этих четырёх вещей даёт интересный эффект: на третий день готовности сбой внешнего сервиса — это не ЧП, а сценарий, у которого есть инструкция.

План непрерывности: четыре шага

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

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

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

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

Шаг четвёртый — регламент. Кто что делает, когда лежит. Кто узнаёт о сбое, кто объявляет переключение, кто communicates клиентам, кто проверяет восстановление. Без этого документа даже хорошая техническая замена не включается вовремя — потому что никто не уверен, имеет ли он право её включить.

Наш опыт: переключение на ходу

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

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

Мы разбирали архитектуру Hermes подробно в отдельной статье — там же про агентов, инструменты и наши грабли. Для темы этой статьи важно одно: отказоустойчивость — это не «никогда не падает», это «падает одна часть, и система заранее знает, на что переключиться». Именно эту логику стоит переносить с уровня одного агента на уровень всего бизнеса.

Что зависит от облака: короткая таблица

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

Правый столбец и есть ваша карта непрерывности. Задача плана — чтобы у критичных процессов в нём стояло «да», или хотя бы «частично, с заменителем».

Итог: пять вопросов вашему ИТ

Сбои внешних сервисов — не вопрос «если», а вопрос «когда и что именно встанет». Подготовка к ним — это не паранойя, а обычная гигиена: список зависимостей, критичные процессы, локальные заменители, регламент на случай простоя. Проверить себя можно прямо на этой неделе — задайте своему ИТ-отделу или подрядчику пять вопросов.

• Какие внешние сервисы нужны нашим критичным процессам, и где их список?
• Что из этого продолжит работать, если внешний сервис недоступен день?
• Где у нас ИИ держится на одном облачном API, и что вместо него при сбое?
• Кто объявляет переключение на запасной сценарий и по какому регламенту?
• Когда мы последний раз проверяли это не в теории, а отключением?

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