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

Бизнес давно приучили к мысли, что облака — это удобно, современно и почти всегда выгодно. Пара кликов, и у компании появляется почта на домене, CRM, файловое хранилище, онлайн‑документооборот. Никаких серверов в офисе, никаких «железок», никаких сложных настроек.

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

Здесь на первый план выходит другая модель — собственная, in‑house инфраструктура. Это не обязательно сервер в подвале, как его рисуют нам стереотипы. Скорее это принцип, где критичные для бизнеса системы работают на ресурсах, которыми управляет сама компания, а не анонимный провайдер. В этой статье разберу, где проходят границы разумного использования облака, какие риски несет полная зависимость от провайдера и когда бизнесу стоит задуматься о переходе на собственную ИТ‑инфраструктуру.

«Облако» — что это такое на самом деле?
Если разобрать понятия, становится заметно, насколько много вокруг облаков маркетингового шума и подмены терминов. Для обычного пользователя облако — это и «Яндекс.Диск», и Google Drive, и почта у публичного провайдера, и «Битрикс24», и вообще все, к чему он попадает через браузер и логин‑пароль. Но по сути облако — это не «волшебная папка», а услуга, оказываемая на чужом оборудовании и чужом программном обеспечении, к которому имеют доступ сразу много клиентов. Важно не только то, что сервис работает «где‑то там», но и то, что к самой инфраструктуре всегда имеет доступ третья сторона — провайдер и его сотрудники.

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

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

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

Во внутренней инфраструктуре ответственность всегда адресная. Если вы обслуживаете системы своими силами — отвечает ИТ‑служба. Если с помощью подрядчика — есть договор, SLA, конкретное юридическое лицо, с которого можно спросить.

Второй миф — о дешевизне. На старте действительно кажется, что облако выигрывает. Не нужно покупать сервер, лицензии, нанимать системного администратора. На десять человек 5–10 платных ящиков по несколько сотен рублей в месяц воспринимаются как мелочь. Но ИТ‑расходы делятся на капитальные и операционные. Капитальные — это когда вы купили сервер или лицензии и превратили их в актив компании. Операционные — когда вы ежемесячно оплачиваете аренду сервиса, и деньги просто сгорают.

Пока сумма в счете выглядит как «10 тысяч в месяц», мало кто задумывается, что за год это уже 120 тысяч, которые не усилили активы бизнеса, а ушли на аренду чужой инфраструктуры. Если посмотреть на горизонт трех–пяти лет, то собственная инфраструктура с грамотным сопровождением часто оказывается ощутимо выгоднее. Вы один раз вложились в железо и лицензии, а дальше тратите меньше на ежемесячные платежи и при этом сохраняете актив у себя.

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

Допустим, компания много лет сидела на Google Workspace, упростила себе жизнь, особенно на этапе старта, а потом столкнулась с санкциями и трудностями с оплатой. Решили переезжать на «Яндекс». Формально есть инструкции, утилиты миграции, подробные статьи в справке. На практике все разбивается о человеческий фактор, когда главный административный аккаунт, с которого когда‑то давно заводили домен, привязан к старому телефону и почте, о которых уже никто не помнит. У людей есть админские учетки, но не того уровня, который нужен для автоматизированного переноса. И вся «магия» переезда превращается в проект, где инженерам приходится вручную перетаскивать данные, писать скрипты, подключать «роботов», а не просто нажать пару кнопок.

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

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

In‑house‑система такой зависимости не имеет. Вы уже купили сервер или арендуете железо в ЦОДе, вы можете физически перевезти его в офис, в другую серверную, в крайних случаях — хоть в другой город. Пока оборудование включено в розетку и за ним хоть минимально следят, сервис живет независимо от вашего текущего баланса на счете у провайдера.

Доступы, люди и утечкиЕсть еще одна тихая проблема, которая особенно остро проявляется в компаниях, быстро растущих на облаках. Сначала регистрируют «Яндекс.Почту», потом подключают Google Drive, потом появляется «Битрикс24», Trello, несколько SaaS‑систем учета, сторонние сервисы рассылок. Каждый новый сотрудник получает доступ к части этой системы. Когда человек увольняется, формально нужно пройтись по всем сервисам и везде закрыть ему доступ. В реальной жизни это почти никогда не делается до конца. Кто‑то годами сохраняет доступ к ящику с перепиской клиентов, кто‑то — к файловому хранилищу, кто‑то — к CRM. Централизованного управления правами в такой конструкции нет, и утечки становятся лишь вопросом времени.

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

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

Особенно жестко это проявляется в системах, которые подпадают под закон о КИИ (критическая информационная инфраструктура). В этом случае неважно, частная у вас компания, государственная, муниципальная, большая или средняя. Важна сфера деятельности: топливно‑энергетический комплекс, транспорт и так далее. Как только вы попали в перечень, то вопрос облака практически снимается. Основные контуры должны строиться как свои информационные системы.

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

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

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

Старые, но незаменимые системы
Отдельная история — старые, но критически важные системы. Самописные CRM, сделанные директором‑программистом 15 лет назад. Глубоко кастомизированная 1С 7.7, которая до сих пор идеально ложится на бизнес‑процессы компании. Отдельные отраслевые решения под старые версии ОС. Такие системы часто не умеют масштабироваться, не переносятся между платформами и точно не рассчитаны на жизнь в современном облаке. Замена стоит дорого, так как приходится заново вкладываться в разработку, в перестройку процессов, в обучение людей. Плюс человеческий фактор. Пользователи привыкают к интерфейсу, к логике работы, и любое внедрение новой системы вызывает сопротивление и временный провал эффективности.

Логичный выход — оставить эти системы в собственной инфраструктуре, максимально их изолировать, и защитить современными средствами защиты (СЗИ). Да, это компромисс, но он допустим в том случае, когда недостаточно средств, компетенций и времени на разработку новой системы.

Киберугрозы — вопрос доступа, а не модности технологии
Когда речь заходит о киберугрозах, принцип на самом деле один: неважно, новое у вас ПО или старое, облако это или in‑house — всегда нужно смотреть, кто и как имеет доступ. В собственной инфраструктуре это проще контролировать, так как можно закрыть прямой доступ к системе, пустить пользователей через промежуточный шлюз, который будет аутентифицировать, шифровать, логировать все, что происходит. Старые системы необходимо взять на строгий контроль, особенно в части доступа к ним. Важно ограничить доступы пользователей как из внешних и так и из внутренних сетевых сегментов. Облако же всегда подразумевает, что часть контуров находится под контролем провайдера, и вы можете влиять на них только через настройки, которые он вам предлагает.


Заключение
Важный вывод из всей этой картины не в том, чтобы объявить облака «злом», а свои серверы — «добром». На определенном этапе развития облака действительно помогают, потому что стартапу проще развернуть почту и файловое хранилище в «Яндексе», чем выстраивать свой ЦОД. Группа людей, совместно работающих над задачей, спокойно живет на бесплатных тарифах и не задумывается о долгосрочных рисках.

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

Собственные in‑house‑системы не дают волшебных гарантий. Они требуют квалификации, внимания и дисциплины. Но взамен дают то, чего у облака по определению нет: контроль над данными, над доступом к ним, над архитектурой, над юридической стороной вопроса. И на дистанции нескольких лет — экономический выигрыш.

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