Мы давно перестали воспринимать интернет как что-то необычное. Для абсолютного большинства из нас это нечто настолько же рядовое, как электричество или водоснабжение. Но это, пока пока интернет вдруг не отключат. Совсем как горячую воду. Вот тогда-то и начинается интересное. Именно в этот момент выясняется, что вся ваша работа была возможной только потому, что возможен ОН, и, если ОН пропадет, встанет буквально весь конвейер. 

Реальные масштабы зависимости от интернета

По разным оценкам, среднестатистический сотрудник крупной компании в течение дня обращается к 30-40 облачным сервисам. Кажется, много? Но в масштабе организации их количество вообще достигает 1200-1300 штук. У кого-то больше, у кого-то меньше. Главное, что примерно 3/4 компаний находятся в состоянии критической зависимости от онлайна. То есть если падает какой-то один компонент, за ним рушится весь стек по принципу домино.

Россия в этом смысле не исключение. Отечественный рынок облачных сервисов в 2025 году оценивается в 380+ млрд рублей, а 69% компаний так или иначе используют облачную инфраструктуру. То есть они не просто хранят там какой-то периферийный софт для презентаций. На облако завязана самая что ни на есть критическая инфраструктура: корпоративная почта, базы данных, системы управления проектами, CRM, документооборот, коммуникации.

С одной стороны, удобно, а с другой – у многих просто нет плана на случай, если все это упадет. Да, есть теория про резервные каналы связи, есть SLA с компенсациями за простой, есть обещания от вендоров. Но практического плана, который бы позволил полноценно продолжать работу в случае падения провайдера – чаще всего нет.

Что отключится, если пропадет интернет

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

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

Опять же, можно созвониться просто по телефону. Но, во-первых, до этого надо еще додуматься. А, во-вторых, иметь записанные номера коллег, чего многие не делают. Вот и получается, что физически команда никуда не делась, но связаться друг с другом у них нет никакой возможности. Если только вы все не сидите в одном офисном здании.

А ведь связь – это только вершина айсберга. Проблема в том, что одновременно с мессенджерами отваливается вообще все, что жило в облаке. И список этого «всего» оказывается куда длиннее, чем кажется на первый взгляд.

CRM и продажи:

• Битрикс24, amoCRM, Мегаплан, RetailCRM, Salesforce

• 1С в облачных вариантах

Задачи и проекты:

• Jira, Яндекс Трекер, Kaiten, ПланФикс, Asana

• Notion, Confluence

Документы:

• Google Docs, МойОфис Облако, Яндекс.Документы, OnlyOffice

• Файловые хранилища: Яндекс.Диск, Облако Mail.ru, Google Drive

Разработка:

• GitHub, GitLab (облачные версии)

• CI/CD: GitLab CI, GitHub Actions

• Системы мониторинга: Grafana Cloud, Zabbix SaaS

• Логирование: ELK в облаке, Graylog

Аналитика и отчетность:

• DataLens, Power BI, Tableau, Qlik

• Дашборды, построенные на облачных данных

Документооборот и бухгалтерия:

• СКБ Контур (Диадок, Экстерн), 1С-Отчетность, СБИС

• СЭД: Directum, Docsvision

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

Что будет работать, если отключат интернет

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

Хотя, конечно, современное ПО часто любит проверять лицензии, подписки и доступы через сеть. Возьмем даже банальный VPN-клиент. Если авторизация завязана на внешний сервис, в отсутствие интернета активировать виртуальную частную сеть не получится, а значит, и часть программ просто откажутся стартовать.

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

Git в этом плане честнее, потому что будет работать локально почти без ограничений. Можно будет продолжать писать код, фиксировать изменения, разруливать конфликты в файлах даже в условиях тотального интернет-блэкаута. Ограничение одно: если единственный удаленный репозиторий живет в GitHub или облачном GitLab, синхронизироваться с командой вы уже не сможете. Каждый разработчик окажется в своем пузыре из локальных коммитов, – и привет.

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

Хотите что-то уточнить? Присоединяйтесь к нашему комьюнити Практики FinOps в Telegram и расскажите о своем опыте.

Что дает собственная инфраструктура

Некоторым везет, и они переходят на свою собственную инфраструктуру. Если таковая имеется, локальный файловый сервер, внутренняя wiki, таск‑трекер продолжат работать даже в офлайне. Тут главное – чтобы была жива внутренняя сеть и было электричество. А внешний интернет вообще может умереть. Внутри периметра люди все так же смогут открывать документы, видеть задачи и формировать заявки.

Также будут доступны все внутренние сервисы: самописные админки, простые отчетные формы, внутренние порталы. Да даже свой Git-сервер. Пока внешний GitHub или облачный GitLab остаются недоступными, разработчики все равно смогут:

• пушить

• мерджить

• комментить

• ревьюить.

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

Спасет ли своя инфраструктура от отключений интернета

Хотя, конечно, везде есть свои зависимости.

Если срок действия какого-то сертификата истек, а его продление завязано на внешний CA/ACME, то все. Без доступа к центру сертификации его будет не продлить. То есть и часть внутренних сервисов, заточенная под автоматическое обновление сертификатов, банально не включится. Технически-то все останется доступно локально. Но фактически сервис не поднимается без похода наружу.

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

А SSO? Да, единая учетка, которая открывает доступ сразу ко всему, – это удобно. Но обычно вся эта красота, как и VPN, завязана на внешний сервис авторизации. Если точка входа в SSO недоступна, локальная инфраструктура формально остается, но попасть в нее будет уже нельзя.

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

Как подготовиться на случай отключения интернета

На этом месте обычно всплывает естественный вопрос: что с этим всем делать? Радикально отказаться от облака уже нельзя, но и жить в подвешенном состоянии и надеяться, что все будет в порядке как-то само, – решение так себе. 

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

CRM в облаке? Если она упадет, встанет весь отдел продаж. А всего-то и нужно, что заранее создать простую таблицу на внутреннем файловом сервере с именем клиента, контактами, сутью запроса, статусом и ответственными. Затем прописываете адрес этой таблицы в инструкции и открываете доступ всем сотрудникам отдела продаж. В этом случае, если CRM вдруг перестанет отвечать, МОПы смогут переключиться туда. Да, после восстановления записи придется переносить обратно вручную или скриптом, но главное – что в критический момент работа не встала.

Документы? Если база знаний расположена в облачном Confluence, при обрыве связи доступа к ней не будет. Решается – перемещением критичных регламентов на внутренний файловый сервер: как закрыть смену, оформить возврат, провести экстренный платеж. Тащить в локаль все подряд не надо. Только то, без чего нельзя прожить ближайшие часы.

Таск-трекер в облаке? Туда же. Просто поднимаете на внутреннем сервере легкий Redmine, Taiga или Kanboard. Опять же, переносить туда всю историю нет никакого смысла. Достаточно сделать пару базовых колонок: новые задачи, в работе – и хватит. При падении основного команда работает здесь, а после восстановления задачи мигрируют обратно или закрываются с пометкой "выполнено офлайн".

SSO на внешнем IdP тоже портит всю малину. Поэтому для критичных систем заводим локальные учетки с отдельными паролями. Или выдаем ключевым людям токены, которые работают в обход основного механизма и живут не 10 минут, а подольше.

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

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

Пробное выключение интернета: проверяем реакцию

Теперь надо проверить, чего на самом деле стоит вся эта готовность к отказам. Делается очень просто: отключаем и смотрим, что будет.

Для этого берем заранее согласованное окно (на час-полтора), один офис или одна команда, и режем им выход в интернет. Еще раз: не симулируем сбой в PowerPoint, а наглухо отключаем. И даем людям прожить этот час как обычно.

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

Тут, кстати, и всплывают самые забавные вещи:

• Вдруг неожиданно выяснится, что у половины людей нет рабочих паролей от внутреннего VPN, потому что они им ни разу не пользовались.

• Никто не помнит адрес внутреннего трекера без единой учетки.

• Все инструкции про падение интернета лежат в Confluence, который тоже лег.

• Телефоны коллег есть только в мессенджере, который тоже не работает.

История смешная, ситуация страшная. Согласен. Главное, когда все это вскроется, не посмеяться и разойтись, а сделать выводы и исправить проявившиеся недочеты.

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

Просто возьмите за правило:

• Никаких SSO, завязанного на внешний IdP;

• Никаких VPN через облачный сервис;

• Никаких централизованных почт без локального запасного пути.

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

Работа без интернета: борьба с реальностью

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

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

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