+7 831 423-67-03 Обсудить задачи
Главная / Стандарты ИТ-инфраструктуры / Глава 14. Сервер в облаке
Глава 14 Серверы ~11 минут чтения

Сервер в облаке: магии нет, есть чужой сервер

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

Версия статьи:
С чего начать

Никакого облака на самом деле нет

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

Технически «облако» — это дата-центр, в котором стоят стойки с железом. На этом железе работают виртуальные машины — то есть программно нарезанные «виртуальные сервера», которые провайдер сдаёт в аренду клиентам. Когда вы арендуете виртуальный сервер в Yandex Cloud, Selectel или Timeweb — вы получаете один из таких ломтиков. С точки зрения ваших программ это такой же сервер, как стоял бы у вас в офисе. Только физически — не у вас, а где-то в ДЦ.

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

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

Контекст

Облако — это чужой сервер на чужой площадке

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

Технически облако — это дата-центр провайдера, в котором стоят стойки с серверами. На этих серверах через гипервизор работают виртуальные машины, которые провайдер сдаёт в аренду клиентам. Когда вы арендуете виртуальный сервер в Yandex Cloud, Selectel, Cloud.ru, VK Cloud или Timeweb — вы получаете одну такую виртуалку с заявленными CPU, RAM и диском. С точки зрения операционной системы и ваших приложений это такой же сервер, как стоял бы у вас в офисе — разница только в том, где физически крутится железо.

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

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

Что меняется

Чем облако лучше, а чем хуже своего железа

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

+ Что даёт облако
Нормальные условия размещения: серьёзное питание с резервированием, кондиционирование, резервные интернет-каналы, охрана и контроль доступа. По инфраструктуре такого уровня в обычном офисе вы не достанете.
− Чем за это платите
Физическим контролем. Подойти к серверу, переткнуть кабель, заменить диск, посмотреть индикатор — вы уже не можете. Всё это происходит через тикеты в поддержку провайдера и на его правилах. Если провайдер тормозит — вы ждёте.
Условия эксплуатации vs физический контроль
+ Что даёт облако
Никаких капитальных расходов (CAPEX). Не надо разово выкладывать 250-500 тысяч рублей за сервер, не надо думать про утилизацию через 5 лет, не надо закладывать в бюджет амортизацию железа. Виртуалку можно поднять за пять минут и погасить, если она оказалась не нужна.
− Чем за это платите
Постоянными операционными затратами (OPEX). Платите каждый месяц, годами. На коротком горизонте дешевле, на длинном — часто получается дороже, чем своё железо. Особенно если ресурсов нужно много.
Капитальные затраты vs операционные
+ Что даёт облако
Сервисы из коробки: бэкапы дисков, снэпшоты, мониторинг, балансировка, отказоустойчивость на нескольких зонах доступности. Всё то, что у себя надо строить отдельно и нанимать людей.
− Чем за это платите
Зависимостью от интернет-канала. Канал упал — облако недоступно, как будто его нет. Канал медленный — приложения тормозят. Канал нестабильный — связь рвётся в неподходящий момент. Без нормального интернета у вас в офисе облако не работает.
Готовые сервисы vs зависимость от канала
Что меняется

Что облако даёт — и чего требует взамен

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

+ Что приобретается
Нормальные условия размещения: резервированное питание, прецизионное охлаждение, несколько независимых интернет-каналов, физическая безопасность, регламентное обслуживание. Среда уровня дата-центра, который у себя в офисе вы воспроизвести не сможете без сопоставимых вложений.
− Чем расплачиваетесь
Физическим контролем. Подойти к серверу, переткнуть кабель, заменить диск, посмотреть индикатор — всё это теперь через тикеты в поддержку провайдера и на его условиях. Если поддержка тормозит — простой растёт пропорционально.
Условия эксплуатации vs физический контроль
+ Что приобретается
Никаких капитальных расходов (CAPEX). Не надо разово выкладывать 250-500 тысяч рублей за сервер, не надо закладывать в бюджет амортизацию и утилизацию железа. Виртуалку можно поднять за пять минут и погасить, если она оказалась не нужна. Оплата по факту использования.
− Чем расплачиваетесь
Постоянными операционными затратами (OPEX). Платите каждый месяц, годами. На коротком горизонте дешевле, на длинном — при стабильной нагрузке часто получается заметно дороже, чем своё железо. Особенно если ресурсов нужно много. Плюс тариф провайдера — внешний параметр, который он может пересмотреть.
Капитальные затраты vs операционные
+ Что приобретается
Сервисы из коробки: бэкапы дисков, снэпшоты, мониторинг, балансировщики, отказоустойчивость на нескольких площадках. Всё то, что у себя надо строить отдельно и тратить на это время инженеров.
− Чем расплачиваетесь
Зависимостью от интернет-канала. Канал упал — облако недоступно. Канал медленный — приложения тормозят. Канал нестабильный — связь рвётся в неподходящий момент. Без нормального интернета в офисе облако не работает, а одиночный канал становится узким местом всей конструкции.
Готовые сервисы vs зависимость от канала
Где работает

Когда облако — хороший выбор

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

01
Совсем маленькая компания
Сервер уже нужен (1С, файлы), но покупать и обслуживать своё железо для пяти человек экономически не имеет смысла. Аренда виртуалки за 3-10 тыс ₽/мес закрывает задачу без капитальных затрат и без необходимости держать в офисе серверную.
02
Нет нормальных условий на объекте
Нет серверной, питание нестабильное, интернет от одного провайдера и тот периодически падает, кондиционера для сервера тоже нет. На вашей площадке сервер будет страдать — в ЦОДе провайдера ему будет лучше.
03
Нужны несколько площадок и высокая отказоустойчивость
Бизнес не может позволить себе остановиться, даже если в одном ЦОДе случится пожар. Построить две собственные площадки и настроить репликацию между ними — миллионы и серьёзная команда. У нормального облака зоны доступности уже готовы.
04
Временные или непредсказуемые нагрузки
Тестовая среда на месяц. Аналитика, в которую раз в квартал «вваливают» большой расчёт. Сезонный пик трафика. В облаке такие нагрузки покупаются по факту и гасятся, когда не нужны. На своём железе пришлось бы держать запас «на всякий случай».
05
Сервисы, которым облако подходит лучше
Даже когда у вас есть своё железо, есть классы задач, которым место именно во внешней инфраструктуре. Корпоративная почта — должна работать всегда, и логично, чтобы она была независима от вашего офиса. VPN-шлюз и виртуальный роутер — нужны как точка сборки удалённых сотрудников и филиалов, и часто проще держать их на нейтральной площадке. Сайт и публичные веб-сервисы — им нужен внешний канал, статический IP и отказоустойчивость, которые лучше выходят у провайдера.
Где работает

Когда облако — обоснованный выбор

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

01
Совсем маленькая компания
Сервер уже нужен (1С, файлы), но покупать и обслуживать своё железо для пяти человек экономически не имеет смысла. Аренда виртуалки за 3-10 тыс ₽/мес закрывает задачу без капитальных затрат и без необходимости держать в офисе серверную и ИБП.
02
Нет нормальных условий на площадке
Нет серверной, питание нестабильное, интернет от одного провайдера и тот периодически падает, климатконтроля нет. В таких условиях серверное железо деградирует ускоренно и даёт регулярные инциденты. В ЦОДе провайдера с нормальной средой эксплуатации серверу будет существенно лучше.
03
Нужны несколько площадок и высокая отказоустойчивость
Бизнес не может позволить себе остановиться — даже если в одном ЦОДе случится пожар. Построить две собственные площадки с каналами между ними и настроенной репликацией — это миллионы и серьёзная команда. У нормального облака отказоустойчивость через несколько зон доступности уже готова и подключается тарифом.
04
Временные или непредсказуемые нагрузки
Тестовая среда на месяц. Аналитика, в которую раз в квартал «вваливают» большой расчёт. Сезонный пик трафика интернет-магазина. В облаке такие нагрузки покупаются по факту и гасятся, когда не нужны. На своём железе пришлось бы держать запас «на всякий случай», который большую часть времени простаивает.
05
Сервисы, которым облако подходит лучше
Даже когда у вас есть своё железо, есть классы задач, которым логичнее жить во внешней инфраструктуре. Корпоративная почта — должна работать всегда, в том числе когда офис обесточен или интернет в нём упал. VPN-шлюз и виртуальный роутер — это точка сборки удалённых сотрудников и филиалов, и часто удобнее держать её на нейтральной площадке, не завязанной на офис. Сайт и публичные веб-сервисы — им нужен внешний канал, статический IP и отказоустойчивость, которые у провайдера получаются проще и надёжнее.
Где не работает

А вот что в облако лучше не тащить

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

Тяжёлая 1С с большой базой
Когда база 1С весит десятки или сотни гигабайт, а в ней одновременно работают десятки пользователей, — это серьёзная нагрузка на процессор, память и дисковую подсистему. В облаке для такой задачи нужна не дешёвая виртуалка, а арендованный серьёзный сервер, и стоит он уже сильно дороже своего — и на коротком, и на длинном горизонте. Плюс задержки сети, которые в толстом клиенте 1С чувствуются мгновенно. Если 1С — ядро вашего бизнеса, держите её у себя.
Единственный контроллер домена
Контроллер домена — это сервис, через который сотрудники в офисе входят на свои компьютеры, получают доступ к файлам и принтерам. Если он единственный и живёт в облаке — при падении интернет-канала весь офис перестаёт работать. Не «с ограничениями», а вообще: люди не могут залогиниться. Логичная схема — основной контроллер локально, в офисе, а в облако можно вынести резервный.
Сервисы с локальной интеграцией
Всё, что должно общаться с оборудованием прямо в офисе: ПО для производственных станков, серверы видеонаблюдения с камерами в здании, телефонная станция с аналоговыми линиями, кассы и торговое оборудование, серверы СКУД. Тащить такие сервисы в облако — значит гонять трафик «офис → интернет → облако → интернет → офис», где он по логике должен идти просто внутри сети. И терять связь, когда интернет лёг.
Особо чувствительные данные
Бывают категории информации, которые по соображениям безопасности нельзя или нежелательно отдавать на чужую сторону: коммерческая тайна, иногда — персональные данные клиентов и сотрудников в специфических конфигурациях. Здесь вопрос не в технике, а в юриспруденции и модели угроз: если вы не готовы, чтобы данные физически лежали на чужом оборудовании, — значит, облако вам по этой задаче не подходит.
Где не работает

А вот что в облако лучше не тащить

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

Тяжёлая 1С с большой базой
Когда база 1С весит десятки или сотни гигабайт, а в ней одновременно работают десятки пользователей, — это серьёзная нагрузка на процессор, память и дисковую подсистему. В облаке для такой задачи нужна не обычная виртуалка, а арендованный мощный сервер с выделенными CPU и быстрым диском — а это уже сильно дороже своего, особенно на дистанции 3-5 лет. Плюс задержки сети через интернет, которые в толстом клиенте 1С чувствуются мгновенно. Если 1С — ядро вашего бизнеса, держите её у себя.
Единственный контроллер домена
Контроллер домена — это сервис, через который сотрудники в офисе входят на рабочие станции, получают групповые политики, доступ к файловым ресурсам и принтерам. Если он единственный и живёт в облаке — при падении интернет-канала весь офис перестаёт работать. Не «с ограничениями», а вообще: люди не могут залогиниться. Правильная схема — основной контроллер локально, в офисе, а в облако можно вынести резервный.
Сервисы с локальной интеграцией
Всё, что должно общаться с оборудованием прямо в офисе: ПО для производственных станков, серверы видеонаблюдения с камерами в здании, телефонная станция с аналоговыми линиями, кассы и торговое оборудование, серверы СКУД. Тащить такие сервисы в облако — это гонять трафик «офис → интернет → облако → интернет → офис» там, где он должен идти просто внутри сети. И терять связь с оборудованием каждый раз, когда падает интернет.
Особо чувствительные данные
Бывают категории информации, которые по соображениям безопасности нельзя или нежелательно отдавать на чужую сторону: коммерческая тайна с высокой ценой утечки, иногда — персональные данные в специфических конфигурациях, требующих физического контроля. Здесь вопрос не в технике, а в юриспруденции и модели угроз: если вы не готовы, чтобы данные физически лежали на чужом оборудовании, — значит, облако вам по этой задаче не подходит.
Типичные ошибки

Четыре способа облажаться с облаком

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

Ошибка 01
Возьму самый дешёвый VPS, какая разница
Очень большая. Дешёвый VPS за 300-500 ₽/мес — это, как правило, медленный процессор, мало памяти и тормозной диск. Плюс на том же физическом сервере живут ещё несколько десятков таких же дешёвых виртуалок — и они конкурируют за общие ресурсы. Для простых задач вроде VPN-шлюза, маленькой почты или статического сайта — этого вполне достаточно. Для серьёзной нагрузки вроде 1С с десятком пользователей — на дешёвом VPS будет жуткий тормоз, и никакая «оптимизация конфигурации» это не вылечит, потому что упирается оно в физику процессора, который один на всех соседей.
Ошибка 02
У провайдера SLA 99,9% — значит, всё надёжно
99,9% доступности в год — это почти рабочий день простоя, который провайдер вам обещает по контракту. То есть до 9 часов в году ваш облачный сервер может официально не работать. А если он всё-таки упадёт сверх этого — провайдер возместит не ваши убытки, а 5-10% от месячной арендной платы. Если в ваш «простой» вы теряете больше, чем стоит виртуалка в месяц — готовьтесь к тому, что компенсация будет символической.
Ошибка 03
В облаке же бэкапы автоматические
Нет. Провайдер гарантирует только, что ваша виртуалка не исчезнет из-за поломки физического сервера — этим он и занимается. Но что происходит внутри вашей виртуалки — это уже ваша забота. Если вы случайно удалили базу, поймали шифровальщик или сломали что-то в настройках — провайдер не поможет. Бэкапы вы настраиваете и проверяете сами, ровно как на своём железе.
Ошибка 04
152-ФЗ нас не касается, мы же не банк
Касается. По 152-ФЗ персональные данные сотрудников и клиентов нужно обрабатывать по определённым правилам — и неважно, банк вы или магазин стройматериалов. Главное правило: персональные данные граждан России должны храниться на серверах в России. Поэтому иностранное облако — нельзя. Российское — можно, но провайдер должен это уметь (есть специальные сертификации) и вы с ним должны это явно прописать в договоре. Серьёзные российские облака всё это умеют, нужно просто не забыть про это при подключении.
Типичные ошибки

Четыре способа облажаться с облаком

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

Ошибка 01
Возьму самый дешёвый VPS, какая разница
Очень большая. Дешёвый VPS за 300-500 ₽/мес — это медленный процессор без выделенных ядер, мало памяти и тормозной диск без гарантий по скорости. Плюс на том же физическом сервере живут ещё несколько десятков таких же дешёвых виртуалок, и они конкурируют за общие ресурсы. Для лёгких задач вроде VPN-шлюза, маленькой почты или статического сайта — этого достаточно. Для серьёзной нагрузки вроде 1С с десятком пользователей — на дешёвом VPS будет жуткий тормоз, и настройками внутри системы это не вылечится, потому что упирается в физику процессора, разделённого между всеми соседями.
Ошибка 02
У провайдера SLA 99,9% — значит, всё надёжно
99,9% доступности в год — это почти рабочий день простоя, который провайдер вам гарантирует по контракту. До 9 часов в году ваш облачный сервер может официально не работать. А если упадёт сверх этого — провайдер возместит не убытки бизнеса, а 5-10% от месячного платежа за виртуалку. SLA — это контрактный показатель, а не гарантия фактической доступности. Если ваш бизнес теряет за день простоя больше, чем стоит виртуалка в месяц — план аварийного восстановления должен исходить именно из этого.
Ошибка 03
В облаке же бэкапы автоматические
Нет. Провайдер гарантирует только, что ваша виртуалка не исчезнет из-за поломки физического сервера — этим он и занимается. А что происходит внутри вашей виртуалки — это ваша зона ответственности: случайно удалили базу, поймали шифровальщик, ошибка в настройках, упал диск самой виртуалки — провайдер не поможет. Бэкапы по правилу 3-2-1 с регулярной проверкой восстановления нужны точно так же, как и на своём железе.
Ошибка 04
152-ФЗ нас не касается, мы же не банк
Касается. По 152-ФЗ персональные данные сотрудников и клиентов нужно обрабатывать по определённым правилам — и неважно, банк вы или магазин стройматериалов. Главное правило: персональные данные граждан России должны храниться на серверах в России. Поэтому иностранное облако — нельзя. Российское — можно, но провайдер должен иметь соответствующую аттестацию (УЗ-1...УЗ-4 в зависимости от категории данных), а с вами должен быть заключён договор поручения обработки. Серьёзные российские провайдеры это всё умеют, нужно просто не забыть подключить на этапе настройки — потом переделывать дороже.
Деньги

Облако дешевле или дороже? Зависит от сценария

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

Сценарий
Своё, 5 лет
Облако, 5 лет
Где выгоднее
Лёгкая 1С на 5 человек
База до 10 ГБ, тонкие/веб клиенты, типовая нагрузка маленького офиса.
~250 тыс ₽
Сервер на базе обычного ПК + электричество за 5 лет при средней мощности 150 Вт.
~300 тыс ₽
Аренда 1С Fresh, около 1000 ₽ за пользователя в месяц.
Спорно. Облако чуть дороже на дистанции, но не требует начальных вложений.
Тяжёлая 1С на 50 человек
База около 300 ГБ, тонкие/веб клиенты, активная работа в учётной системе.
~700 тыс ₽
Б/у enterprise-сервер + электричество за 5 лет при средней мощности 250 Вт.
~1,8 млн ₽
Аренда мощного VPS / VDS: CPU 5 ГГц, 64 ГБ RAM, около 30 000 ₽ в месяц.
Своё. И дешевле, и производительнее на высоких нагрузках.
Почта на 5 человек
Общий объём ящиков около 30 ГБ, типичный профиль маленькой команды.
~150 тыс ₽
Сервер на базе недорогого ПК + электричество за 5 лет при средней мощности 100 Вт.
~96 тыс ₽
Подписка VK WorkSpace / Яндекс 360 для бизнеса: около 300 ₽ за пользователя в месяц.
Облако. И дешевле, и удобнее, и без начальных вложений.
Почта на 50 человек
Общий объём ящиков около 600 ГБ. То же железо, что и для пятерых, — просто больше места.
~150 тыс ₽
Сервер на базе недорогого ПК + электричество за 5 лет при средней мощности 100 Вт. Те же условия, что и для 5 человек.
~360 тыс / ~960 тыс ₽
VPS с диском от 600 ГБ около 6000 ₽ в месяц — или подписка VK / Яндекс по 300 ₽ за пользователя.
Своё, и с огромным запасом. Облако удобнее, но в разы дороже.

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

Деньги

Облако дешевле или дороже? Зависит от сценария

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

Сценарий
Своё, 5 лет
Облако, 5 лет
Где выгоднее
Лёгкая 1С на 5 человек
База до 10 ГБ, тонкие/веб-клиенты, типовая нагрузка маленького офиса.
~250 тыс ₽
Сервер на базе обычного ПК + электричество за 5 лет при средней мощности 150 Вт.
~300 тыс ₽
Аренда 1С Fresh, около 1000 ₽ за пользователя в месяц.
Спорно. Облако чуть дороже на дистанции, но не требует начальных вложений и освобождает от возни с железом.
Тяжёлая 1С на 50 человек
База около 300 ГБ, тонкие/веб-клиенты, активная многопользовательская работа.
~700 тыс ₽
Б/у enterprise-сервер + электричество за 5 лет при средней мощности 250 Вт.
~1,8 млн ₽
Аренда мощного VPS / VDS: выделенный CPU 5 ГГц, 64 ГБ RAM, NVMe — около 30 000 ₽ в месяц.
Своё. И дешевле, и производительнее на высоких нагрузках.
Почта на 5 человек
Общий объём ящиков около 30 ГБ, типичный профиль маленькой команды.
~150 тыс ₽
Сервер на базе недорогого ПК + электричество за 5 лет при средней мощности 100 Вт.
~96 тыс ₽
Подписка VK WorkSpace / Яндекс 360 для бизнеса: около 300 ₽ за пользователя в месяц.
Облако. И дешевле, и удобнее, и без начальных вложений.
Почта на 50 человек
Общий объём ящиков около 600 ГБ. То же железо, что и для пятерых, — просто больше места под ящики.
~150 тыс ₽
Сервер на базе недорогого ПК + электричество за 5 лет при средней мощности 100 Вт. Те же условия, что и для 5 человек.
~360 тыс / ~960 тыс ₽
VPS с диском от 600 ГБ около 6000 ₽ в месяц — или подписка VK / Яндекс по 300 ₽ за пользователя.
Своё, и с огромным запасом. Облако удобнее, но в разы дороже.

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

Зрелый подход

Лучший ответ часто — не «или / или», а «и то, и другое»

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

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

У себя в офисе
Что плохо без локальной сети или критично для работы офиса прямо здесь и сейчас
  • Контроллер домена — чтобы офис работал даже при падении интернета
  • Тяжёлая 1С с большой базой — ради скорости и нечувствительности к каналу
  • Файловое хранилище — быстрый доступ к тяжёлым файлам внутри офиса
  • Видеонаблюдение и его архив — камеры физически здесь
  • Локальная телефония — если связана с аналоговыми линиями
  • Кассы, СКУД, производственное ПО — всё, что общается с железом на месте
В облаке
Что выигрывает от нейтральной площадки, лучшего канала, готовой отказоустойчивости
  • Корпоративная почта — должна работать всегда, в любой ситуации в офисе
  • Сайт и публичные сервисы — статический IP, отказоустойчивый канал
  • VPN-шлюз / виртуальный роутер — точка сбора для удалёнки и филиалов
  • Внешние бэкапы — вторая копия на другой площадке (правило 3-2-1)
  • Тестовые / временные среды — чтобы не держать на своём сервере «на будущее»
Реальный пример из нашей практики

Производственная компания на 70+ человек. Раньше держали всё в облаке — «потому что современно». Через полтора года устали: 1С тормозила в часы пик, при падении интернета производство останавливалось, счета от провайдера росли. Перевели обратно к себе 1С, контроллер домена, файловое хранилище — остановки прекратились, экономия около 60 тыс ₽ в месяц. А в облаке оставили почту, корпоративный VPN на 40+ удалёнок и внешний бэкап. Получилось ровно то, что должно: каждая роль там, где ей живётся лучше.

Зрелый подход

Лучший ответ часто — не «или / или», а «и то, и другое»

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

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

У себя в офисе
Чувствительность к сетевым задержкам, локальные зависимости, требования к автономности офиса от интернета
  • Основной контроллер домена — чтобы офис продолжал работать при падении интернета
  • Тяжёлая 1С с большой базой — ради скорости и нечувствительности к каналу
  • Файловое хранилище — быстрый доступ к большим файлам внутри сети
  • Видеонаблюдение и его архив — камеры физически здесь, поток внутри LAN
  • Телефонная станция — особенно при наличии аналоговых линий
  • Кассы, СКУД, производственное ПО — всё, что общается с оборудованием на месте
В облаке
Внешняя доступность, готовая отказоустойчивость, нейтральная точка сборки удалённых сотрудников
  • Корпоративная почта — должна работать всегда, в любой ситуации в офисе
  • Сайт и публичные сервисы — статический IP, отказоустойчивый канал, SSL
  • VPN-шлюз / виртуальный роутер — точка сборки для удалёнки и филиалов
  • Внешние бэкапы — вторая копия на другой площадке (правило 3-2-1)
  • Тестовые / временные среды — чтобы не держать на своём сервере «на будущее»
Кейс: возврат критичных нагрузок on-prem с сохранением периферии в облаке

Производственная компания, 70+ пользователей. Было: всё в облаке «по идеологии». Через 18 месяцев — 1С тормозит в пик, при обрыве интернет-канала встаёт производство, аренда облака растёт. Решение: 1С, контроллер домена и файловый сервер перенесли в свою серверную, а почту, VPN для удалёнщиков и бэкап на отдельной площадке — оставили в облаке. Результат: простои ушли, экономия около 60 тыс ₽/мес. Каждая роль размещена там, где ей реально лучше, а не по общему лозунгу.

Как это устроено

Наши принципы — применительно к облаку

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

Надёжность
У нормального облака — выше, чем у большинства самодельных серверных: настоящее резервирование питания, охлаждение, резервные каналы, дисциплина эксплуатации. Но появляется новая точка отказа — ваш интернет-канал. Если он единственный и слабый, надёжность всей конструкции определяется им, а не ЦОДом.
Управляемость
Резко выше, чем у своего железа. Панель управления, API, мониторинг, снэпшоты, шаблоны — всё в комплекте. Машину можно поднять за минуту, изменить ресурсы на ходу, откатиться к снэпшоту. Это, пожалуй, главное операционное преимущество облака.
Масштабируемость
Флагман облачной модели. Удвоить ресурсы — минуты, не недели. Раскатать ещё пять виртуалок под нагрузку — минуты. Снести лишнее — минуты. У своего железа потолок жёстче и виден сразу, в облаке он дальше — но только пока вы готовы платить.
Безопасность
Двусторонняя картина. Физическая защита у провайдера лучше, чем в офисном шкафу. Но появляется юридическое измерение (152-ФЗ, оператор персональных данных, договор поручения) и операционное: доступ через интернет — это новая поверхность атаки, нужны 2FA, VPN, грамотные права. Облако само по себе ничего не защищает — оно даёт другой набор инструментов и других рисков.
И экономичность тоже никуда не делась
Облако даёт низкий порог входа: можно стартовать за минимальные деньги и вырасти. Но на дистанции в 3-5 лет, при стабильной нагрузке 24/7, помесячная аренда часто выходит в разы дороже, чем покупка своего железа. Платить за облако имеет смысл, когда оно решает реальную задачу — гибкость, отказоустойчивость, отсутствие своих специалистов или площадки. Если этих задач у вас нет — вы переплачиваете за удобство, и это уже выбор по комфорту, а не по технике.
А доступность теперь считается по всей цепочке
Сам ЦОД проектируется под высокую доступность лучше, чем в большинстве офисных серверных. Но реальная доступность сервиса считается по самому слабому звену цепи: если ваш интернет-канал даёт 98%, никакие 99,99% провайдера эту цифру выше не поднимут. SLA провайдера — про их ЦОД, а ваша задача — про весь путь от ЦОДа до пользователя.
Как это устроено

Четыре принципа — применительно к облаку

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

Надёжность
У нормального облака — существенно выше, чем у большинства самодельных серверных: настоящее резервирование питания, профессиональное охлаждение, резервные интернет-каналы, регламентное обслуживание. Контрвес — надёжность вашего интернет-канала: реальная доступность сервиса = минимум из доступности ЦОДа и доступности канала. Тонкий ненадёжный канал сводит на нет все плюсы провайдера.
Управляемость
Резко выше, чем у своего железа. Панель управления, API, мониторинг, снэпшоты, готовые шаблоны — всё в комплекте. Виртуалку можно поднять за минуту, изменить ей ресурсы на ходу, откатиться к снэпшоту. Это, пожалуй, главное операционное преимущество облака.
Масштабируемость
Флагман облачной модели. Удвоить ресурсы — минуты, не недели. Поднять ещё пять виртуалок под пиковую нагрузку — минуты. Снести лишнее — минуты. У своего железа потолок жёстче и виден сразу, в облаке он дальше — но только пока вы готовы за это платить.
Безопасность
Двусторонняя картина. Физическая защита у провайдера лучше, чем в офисном шкафу: зоны разделения ответственности проговорены, у провайдера — железо, гипервизор, сеть, у вас — система, ПО, доступы, данные. Появляется юридическое измерение (152-ФЗ, оператор персональных данных, договор поручения) и операционное: доступ через интернет — это новая поверхность атаки, нужны двухфакторка, ограничения по IP, грамотные права доступа. Облако само по себе ничего не защищает — оно даёт другой набор инструментов и других рисков.
И экономичность тоже никуда не делась
Облако даёт низкий порог входа: можно стартовать за минимальные деньги и расти постепенно, без капитальных затрат на железо. Но на дистанции 3-5 лет, при стабильной нагрузке 24/7, помесячная оплата облака часто проигрывает разовой покупке своего сервера в разы. Платить за облако имеет смысл, когда оно решает реальную задачу — гибкость, отказоустойчивость, отсутствие компетенций или площадки. Если эти задачи у вас не стоят — переплата идёт за удобство, и это уже выбор по комфорту, а не по инженерии.
А доступность теперь считается по всей цепочке
Сам ЦОД проектируется под высокую доступность лучше, чем в большинстве офисных серверных. Но реальная доступность сервиса для пользователя считается по самому слабому звену цепи: если ваш интернет-канал даёт 98%, никакие 99,99% провайдера эту цифру выше не поднимут. SLA провайдера — это про их ЦОД, а ваша задача — про весь путь от ЦОДа до конечного пользователя. После переезда в облако канал в офис превращается из «просто интернета» в часть продакшен-инфраструктуры — а значит, нужны два независимых провайдера и план на падение каждого из них.
Частые вопросы

«А что насчёт …?»

Практические вопросы, которые нам задают про переезд в облако.

Какое российское облако выбрать?

Из крупных и серьёзных — Yandex Cloud, Selectel, Cloud.ru, VK Cloud, Timeweb Cloud. У них всех есть аттестация под обработку персональных данных, нормальное SLA, развитая панель и поддержка. Принципиальной разницы в качестве для типичных SMB-нагрузок нет — смотрите по цене на конкретную конфигурацию, удобству интерфейса и набору сервисов, которые вам нужны.

Чего стоит избегать — это совсем дешёвых VPS-провайдеров без понятной репутации, которые продают «облако» за 300-500 ₽ в месяц. Это другая категория услуг, и поведение там тоже другое.

А если провайдер закроется или у него отзовут лицензию?

Реальный риск, который многие игнорируют. У крупных российских провайдеров вероятность невелика, но она не ноль. План на этот случай простой: держите внешние бэкапы у другого провайдера или у себя. По правилу 3-2-1 это в любом случае надо делать, и это же закрывает риск пропадания облака целиком.

Также имеет смысл сразу подумать, чтобы потом было проще переехать. У каждого провайдера есть две категории услуг: с одной стороны — обычные арендованные виртуальные сервера, на которые вы ставите свою систему и своё ПО. Это стандарт, такое же есть у любого другого провайдера и на вашем железе тоже. С другой стороны — «фирменные» услуги провайдера: готовая база данных с их настройками, балансировщик нагрузки с их интерфейсом, объектное хранилище с уникальной системой адресации, готовая почтовая или CRM-платформа. Они часто удобнее «обычных», и провайдеры на них активно подсаживают.

Проблема в том, что чем глубже вы используете такие фирменные услуги — тем сложнее потом уехать к другому провайдеру или к себе. У другого провайдера этих сервисов либо нет, либо они устроены по-другому: придётся переписывать настройки, перенастраивать связи, иногда переделывать целые куски системы. Это и называется «привязка к провайдеру» (vendor lock-in), и она проявляется именно тогда, когда уже хочется уйти — провайдер поднял цены, ухудшилось качество, начались отказы в обслуживании. Поэтому простое правило: чем больше у вас обычных виртуалок и чем меньше специфических услуг конкретного провайдера — тем проще будет переехать, если что.

Можно я просто арендую готовый «1С в облаке» и не буду думать?

Зависит от того, какая у вас 1С. Готовые сервисы — «1С Fresh», хостинг 1С у партнёров — берут на себя установку, обновление платформы и часто регламентные операции вроде ночных бэкапов и тестирования базы. Платите помесячно, обычно за каждого пользователя.

Когда такая аренда — хороший выбор. Маленькая компания (до 10-15 человек), стандартная типовая конфигурация (Бухгалтерия, ЗУП, Розница) без серьёзных доработок, база небольшая (до нескольких десятков ГБ). Веб-клиент или тонкий клиент. В этом случае готовый сервис закрывает задачу полностью и освобождает вас от возни с инфраструктурой.

Когда такая аренда уже не подходит. Большая база (сотни ГБ), много одновременных пользователей с интенсивной работой, серьёзные доработки конфигурации, нестандартные обработки, интеграции с другими системами в офисе (кассами, складским оборудованием, ЭДО), специфические требования по скорости работы. В этой ситуации готовый сервис либо не даст нужных возможностей, либо будет тормозить, либо при росте окажется кратно дороже собственного сервера. Тут практичнее держать 1С на своём железе — или хотя бы на арендованном выделенном сервере у нормального провайдера, под вашу полную ответственность.

А персональные данные в облаке — это вообще законно?

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

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

Боимся, что придут с проверкой и заберут сервер с данными. Может, вынести его за границу?

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

Риски, связанные с иностранным облаком. Санкции — провайдер в любой момент может перестать обслуживать клиентов из России: AWS, Google Cloud, Microsoft Azure это уже сделали, и никто не гарантирует, что не сделают остальные. Оплата — перевести деньги в нероссийский сервис из России становится квестом. 152-ФЗ — если на этом сервере оказались персональные данные граждан России, вы уже нарушили закон. Удалённое управление — если что-то пошло не так, вы туда не приедете. Провайдер может выдать данные местным властям по их запросу — у вас на это никаких рычагов влияния нет.

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

FAQ

Практические вопросы по облаку

Часто задаваемые вопросы по развёртыванию и эксплуатации облачной инфраструктуры в малом и среднем бизнесе.

Какого российского провайдера выбирать?

Из крупных и серьёзных — Yandex Cloud, Selectel, Cloud.ru, VK Cloud, Timeweb Cloud. У всех есть аттестация под обработку персональных данных, нормальное SLA, развитая панель и поддержка. Принципиальной разницы в качестве для типичных SMB-нагрузок нет — смотрите по цене на конкретную конфигурацию, удобству консоли и набору сервисов, которые вам нужны.

Чего стоит избегать — это совсем дешёвых VPS-провайдеров без понятной репутации, продающих «облако» за 300-500 ₽ в месяц. Это другая категория услуг: перегруженные физические сервера, нет гарантий по ресурсам и скорости, поддержка отвечает раз в неделю. Для критичных задач не применимы.

А если провайдер закроется или у него отзовут лицензию?

Реальный риск, который требует явной обработки. У крупных российских провайдеров вероятность невелика, но она не ноль. План на этот случай простой: держите внешние бэкапы у другого провайдера или у себя. По правилу 3-2-1 это в любом случае надо делать, и это же закрывает риск пропадания облака целиком.

Также имеет смысл сразу подумать, чтобы потом было проще переехать. У каждого провайдера есть две категории услуг: с одной стороны — обычные арендованные виртуальные сервера, на которые вы ставите свою систему и своё ПО. Такая виртуалка переедет к любому другому провайдеру или к вам без переделок. С другой стороны — «фирменные» сервисы провайдера: готовая база данных с их настройками, балансировщик с их интерфейсом, объектное хранилище с собственным API, готовая почтовая или CRM-платформа. Они удобнее «обычных» виртуалок, и провайдеры на них активно подсаживают.

Проблема в том, что чем глубже вы используете такие фирменные услуги — тем сложнее потом уехать. У другого провайдера этих сервисов либо нет, либо они устроены по-другому: придётся переписывать настройки, перенастраивать связи, иногда переделывать целые куски системы. Это и называется «привязка к провайдеру» (vendor lock-in), и она проявляется именно тогда, когда уже хочется уйти — провайдер поднял цены, ухудшилось качество, начались отказы в обслуживании. Простое правило: чем больше у вас обычных виртуалок и чем меньше специфических услуг конкретного провайдера — тем проще будет переехать, если что.

Аренда готового «1С в облаке» vs самостоятельное развёртывание?

Зависит от того, какая у вас 1С. Готовые сервисы — «1С Fresh», хостинг 1С у партнёров — берут на себя установку, обновление платформы и часть регламентных операций (ночные бэкапы, тестирование базы). Платите помесячно, обычно за каждого пользователя.

Когда такая аренда — хороший выбор. Маленькая компания (до 10-15 человек), стандартная типовая конфигурация (Бухгалтерия, ЗУП, Розница) без серьёзных доработок, база небольшая (до нескольких десятков ГБ), веб-клиент или тонкий клиент. В этом случае готовый сервис закрывает задачу полностью и освобождает от возни с инфраструктурой.

Когда такая аренда уже не подходит. Большая база (сотни ГБ), много одновременных пользователей с интенсивной работой, серьёзные доработки конфигурации, нестандартные обработки, интеграции с другими системами в офисе (кассами, складским оборудованием, ЭДО), специфические требования по скорости. В этих случаях готовый сервис либо не даст нужных возможностей, либо будет тормозить, либо при росте окажется кратно дороже своего сервера. Тут практичнее держать 1С на своём железе — или хотя бы на арендованном выделенном сервере у нормального провайдера, под вашу полную ответственность.

Регуляторика по персональным данным в облаке?

В российском облаке — легитимно при выполнении 152-ФЗ. Главные условия: данные хранятся и обрабатываются на территории РФ, провайдер имеет соответствующую аттестацию (УЗ-1...УЗ-4 в зависимости от категории данных), между оператором и провайдером заключён договор поручения обработки. Крупные российские провайдеры всё это предоставляют — у них есть отдельные тарифы и документация по запросу.

В иностранном облаке — по умолчанию неприменимо для персональных данных граждан РФ. Существующие обходные схемы (анонимизация на стороне РФ, обработка обезличенных данных) сложны юридически и для типового SMB-сценария не подходят.

Боимся, что придут с проверкой и заберут сервер с данными. Может, вынести его за границу?

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

Что вы принимаете на себя. Санкционный риск — провайдер в любой момент может перестать обслуживать клиентов из России (прецеденты AWS, Google Cloud, Microsoft Azure). Платёжный риск — оплата зарубежного сервиса из России становится квестом. Нарушение 152-ФЗ, если на этом сервере оказались персональные данные граждан России. Невозможность физического доступа при инцидентах — если что-то пошло не так, вы туда не приедете. Выдача данных местным властям по их запросу — у вас на это никаких рычагов влияния нет.

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

Что дальше
Интерлюдия · Данные и сервисы
Хорошее железо само по себе не делает инфраструктуру хорошей — переход от железа к системе
Поменять версию статьи:
Нужна помощь

Разберёмся, что у вас в облаке должно быть, а что лучше у себя

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

Обсудить нашу задачу Все стандарты
Телефон+7 831 423-67-03
Почтаsales@itmak.ru
Telegram@itmak_ru
Аудит инфраструктуры

Аудит размещения: что в облаке, что на своём железе

Разбираем по каждой роли, где ей лучше — в облаке или на своём железе: характер нагрузки, требования к скорости отклика и доступности, где по закону должны храниться данные, сравнение затрат на дистанции (TCO). Подбираем оптимальную смешанную схему «своё + облако» и план переезда — с учётом привязки к провайдеру и плана на случай сбоев.

Запросить аудит Все стандарты
Телефон+7 831 423-67-03
Почтаsales@itmak.ru
Telegram@itmak_ru