On-prem, облако или гибрид: матрица выбора для приложений

С чего начинается выбор: боль, а не технология

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

Спор «on-prem, облако или гибрид» часто начинается с привычек или моды. На практике все упирается в три вещи: где живут данные, как они ходят между системами и сколько времени можно ждать ответ.

Данные задают правила. Если много персональных, медицинских или финансовых данных, сразу появляются требования к хранению, доступам, журналам и проверкам. Это не про «где дешевле», а про «где допустимо».

Интеграции добавляют скрытую сложность. Приложение почти никогда не живет одно: бухгалтерия, склад, CRM, BI, ЭДО, порталы, кассы, терминалы, гос-сервисы. Если перенести только «ядро», а обмен оставить «как получится», быстро появятся очереди, дубли и ручные выгрузки.

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

Признаки, что модель выбрана неправильно:

• жалобы на «тормоза» в часы пик или из филиалов;
• простои из-за каналов связи или перегрузки сервера;
• «сведение данных» вручную в Excel;
• интеграции ломаются при каждом обновлении;
• растут затраты на сопровождение, а пользы для бизнеса не прибавляется.

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

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

Три модели размещения простыми словами

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

On-prem (на своей площадке)

On-prem значит, что серверы и системы физически находятся у вас: в серверной, корпоративном дата-центре или у подрядчика, но на выделенном для вас оборудовании. Вы управляете почти всем: доступом, обновлениями, резервным копированием, мониторингом.

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

Облако (у провайдера)

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

• IaaS: вы арендуете виртуальные серверы и диски, а ОС и приложения поддерживаете сами.
• PaaS: вам дают платформу (например, управляемую базу данных), вы больше думаете о коде и данных.
• SaaS: вы пользуетесь готовым приложением, а провайдер отвечает почти за все, кроме ваших настроек, пользователей и данных.

Ограничения часто упираются не в технологию, а в условия: где хранятся данные, как делается экспорт, сколько времени дается на восстановление, что считается простоем.

Гибрид (смешанный подход)

Гибрид - это связка двух миров: часть компонентов остается on-prem, часть уходит в облако. Так делают, когда нельзя выносить чувствительные данные, но хочется облачной масштабируемости для фронта, аналитики или резервирования.

Где гибрид чаще всего «ломается»:

• интернет-канал (пропускная способность и задержка между площадками);
• интеграции и постоянный обмен «туда-сюда»;
• управление доступом (разные учетные записи и роли в двух средах);
• поддержка (неясно, кто отвечает за инцидент на стыке);
• стоимость (неожиданные расходы на трафик и дублирование).

Простой пример: если интерфейс приложения в облаке, а база on-prem, каждый клик упирается в задержку канала. Тогда либо «сближают» данные и приложение, либо оставляют критичный контур целиком на одной стороне.

Данные и требования: что нельзя упустить

Выбор on-prem, облако или гибрид почти всегда начинается с данных. Важно понять, какие данные вы храните, кто к ним должен иметь доступ и что будет, если система остановится.

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

Где появляются требования «хранить в стране» и ограничения доступа

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

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

Практичная проверка:

• какие данные критичны и можно ли их выносить за пределы страны;
• кто по регламенту имеет право администрировать систему и просматривать логи;
• нужны ли неизменяемые журналы (кто, что и когда делал) и сколько их хранить;
• какой простой допустим и какой объем данных можно потерять;
• есть ли требования к сертификациям, аудитам и отчетности.

Шифрование, ключи и журналы: кто управляет

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

On-prem обычно дает полный контроль над ключами и логами, но накладывает обязанность все настроить и поддерживать. В гибриде важно избегать «серой зоны», когда часть логов в облаке, часть локально, и никто не видит картину целиком.

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

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

Интеграции: главный источник скрытой сложности

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

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

С чем и как интегрируются приложения

Вариантов обычно несколько:

• API (REST/GraphQL) для онлайн-обмена;
• очереди и шины сообщений для событий и фоновой обработки;
• файлы (выгрузки по расписанию) для отчетов и пакетных задач;
• терминалы и кассы, где важны стабильность сети и офлайн-режим;
• оборудование (сканеры, датчики, принтеры), часто привязанное к локальной сети.

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

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

Практический ориентир: для каждой интеграции зафиксируйте частоту, объем, допустимую задержку и ответ на вопрос «что будет при обрыве на 30 минут». По этой таблице быстро видно, что нельзя далеко разносить.

Задержки и производительность: как перевести в цифры

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

Важно отделять «неприятно» от «нельзя». Для кассы лишняя секунда часто превращается в очередь. Для колл-центра 2-3 секунды при каждом клике быстро съедают время разговора. Для MES задержка может означать простой линии.

Ориентиры, чтобы говорить с бизнесом на одном языке:

• 50-100 мс: почти не ощущается, подходит для частых кликов и интерактивных экранов;
• 100-300 мс: нормально для большинства офисных действий;
• 300-800 мс: заметно, но терпимо для редких операций;
• 1-3 секунды: приемлемо для отчетов и тяжелых форм;
• десятки секунд и минуты: только для фоновых задач.

Чтобы понять текущую картину, не нужны сложные инструменты. Выберите 5-7 ключевых действий (по ролям: касса, оператор, мастер смены, бухгалтер) и замерьте «от клика до результата» в обычный рабочий день. Затем отметьте два признака: тормозит только в пик или всегда, и сколько пользователей делают одинаковые операции одновременно. Если проблема появляется только в пике, чаще виноваты сервер/база и их производительность, а не расстояние.

Если часть функций должна быть рядом с пользователем, не обязательно выбирать одну модель «целиком». Частый компромисс: быстрый локальный контур (кэш, локальная очередь, небольшой сервис печати), а остальное централизованно. Например, касса пишет операции в локальный буфер и подтверждает продажу сразу, а синхронизация с центральной системой уходит фоном.

Перед фиксацией модели проверьте:

• какой максимум задержки бизнес терпит для 3-5 главных операций;
• что будет при обрыве канала на 10-30 минут;
• где нужны «местные» данные (кэш, справочники, остатки);
• как будет выглядеть рост нагрузки через год.

Пошаговый алгоритм выбора модели для приложения

Выбор проще делать не «по ощущениям», а по шагам. Тогда спор «on-prem, облако или гибрид» превращается в сравнение, где видно, чем вы платите: риском простоя, сложностью интеграций, задержками или требованиями к данным.

5 шагов, которые дают ясность

1. Опишите критичные процессы и допустимый простой. Что именно остановится, если приложение недоступно: продажи, склад, запись пациентов, расчеты? Зафиксируйте окно простоя: «не более 30 минут», «можно ночью до 4 часов», «остановка недопустима».

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

3. Нарисуйте схему интеграций и потоков данных. Достаточно листа: какие системы обмениваются данными, что является «источником истины», где очередь, где файлы, где API.

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

5. Выберите 2-3 варианта и сравните по одной таблице. Например: on-prem, облако, гибрид. Для каждого оцените требования по данным, интеграциям, задержкам, стоимости владения и скорости изменений.

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

Матрица решения: критерии и как ее заполнять

Матрица убирает эмоции из спора «on-prem, облако или гибрид» и сводит выбор к проверяемым фактам. Заполняйте ее для каждого приложения отдельно: у CRM, бухгалтерии, VDI и видеонаблюдения разные данные, интеграции и требования к отклику.

Критерии и шкала

Выберите 5-6 критериев, которые реально влияют на ваши приложения. Обычно хватает таких:

• данные (чувствительность, место хранения, требования регулятора);
• интеграции (число систем, протоколы, частота обмена);
• задержка и производительность (допустимый отклик, пики нагрузки);
• доступность и восстановление (SLA, RTO/RPO);
• команда и бюджет (компетенции, CAPEX/OPEX, сроки).

Дальше задайте шкалу 1-5 через признаки, а не «как кажется». Например: для задержки 5 = нужен отклик до 50-100 мс для большинства операций, 3 = до 200-300 мс, 1 = секунды не критичны. Для данных 5 = персональные/медицинские данные и жесткие ограничения, 1 = публичные или легко обезличиваемые.

Чтобы снизить субъективность, фиксируйте источники: замеры мониторинга, требования ИБ, статистику интеграций, реальные инциденты и простои за год.

Как заполнять и получать итог

Удобный подход - оценивать не модели напрямую, а «насколько критерий тянет к локальному размещению»: 1 = почти не тянет, 5 = сильно тянет. Затем добавьте веса (1-3), если критерий важнее остальных.

После подсчета используйте простые правила:

• высокие баллы по данным + задержке + строгий RTO чаще ведут к on-prem (особенно при предсказуемой нагрузке и локальных интеграциях);
• низкие ограничения по данным, много переменной нагрузки и быстрый запуск чаще ведут в облако;
• если данные и интеграции локальные, а внешние сервисы нужны точечно (аналитика, резерв, фронт), обычно выигрывает гибрид.

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

Частые ошибки и ловушки

Самая частая проблема - не технология, а размытые правила. Решают «on-prem, облако или гибрид», но не фиксируют, где живут данные, кто за что отвечает и что считается «нормальной работой» системы.

Гибрид без границ

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

Помогает один документ, где записано:

• где «источник правды» для каждой сущности (клиенты, заказы, справочники);
• кто владелец каждого интеграционного канала;
• что критично: время простоя, потеря данных, задержка операций.

«VPN все исправит»

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

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

Выбор только по цене

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

Бэкапы «когда-нибудь»

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

Интеграции переносят как есть

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

Реалистичный пример: компания с филиалами и общей базой

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

Для такого сценария часто подходит гибрид, но не «по картинке», а по правилам: какие данные и сервисы должны быть рядом с пользователем, а что можно вынести.

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

Низкая задержка критична там, где работа идет «в темпе»: на складе со сканерами и терминалами, у касс, при печати накладных и этикеток, при массовом подборе и инвентаризации. Если каждое сканирование ждет ответ 1-2 секунды из-за канала, люди начинают обходить систему.

Практическая схема может быть такой:

• ERP и база данных - в головном офисе на своих серверах.
• В филиалах - локальные сервисы для печати, кэш справочников, очередь обмена на случай обрыва связи.
• Складские операции - через локальный узел, который подтверждает действия быстро и синхронизируется с центральной базой.
• Облако - для резервного копирования, аналитики и среды разработки/тестирования.

Через 2-4 недели успех проверяют метриками: время отклика ключевых операций, доля ошибок обмена, сколько раз работа останавливалась из-за связи, скорость закрытия дня/смены, нагрузка на поддержку. Если склад и филиалы перестали «ждать систему», а отчеты собираются без ручных выгрузок, значит разделение выбрано правильно.

Быстрые проверки и следующие шаги

Если времени мало, можно быстро отсеять неподходящие варианты и не спорить «on-prem, облако или гибрид» на уровне вкуса.

Прогоните короткий чеклист по фактам:

• где живут «главные» данные и кто ими владеет;
• сколько интеграций и с кем (бухгалтерия, ЭДО, CRM, производство, гос-сервисы);
• какая задержка терпима для ключевых операций;
• что будет при просадке канала связи (офлайн-режим, очереди, кэш);
• какие требования по соответствию (хранение в РК, аудит, журналы, сегментация доступа).

Дальше проверьте, готовы ли вы не только «переехать», но и безопасно вернуться назад, если что-то пойдет не так:

• что именно тестируем (нагрузка, время отклика, восстановление после сбоя, права доступа);
• план отката и сколько он займет;
• окна работ и зависимые системы;
• владельцы задач (бизнес, ИБ, сеть, приложения, подрядчики);
• резервное копирование и точки восстановления: кто отвечает и где хранятся копии.

Для пилота соберите минимальный набор, чтобы сравнение было честным: 3-5 типовых сценариев (самые частые операции), пользователи из разных ролей и метрики, которые вы меряете каждый день (время отклика, число ошибок, скорость обмена, простои).

Следующие шаги обычно такие: короткий аудит текущей инфраструктуры (сеть, хранилище, серверы, резервное копирование), затем черновая архитектура под выбранную модель и расчет стоимости владения на 2-3 года. Если видите много интеграций и строгие требования по данным или задержкам, стоит подключать системного интегратора.

Если для on-prem или гибридной схемы важны локальная сборка, сервисная сеть и требования госзакупок, в Казахстане часто рассматривают GSE.kz: компания производит компьютеры и серверы в стране и также занимается системной интеграцией и поддержкой, что помогает уменьшить «разрыв ответственности» между железом и внедрением.