1С в облаке без боли: как перенести учёт, сократить расходы и спать спокойно

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

Первый и один из самых важных шагов — экспресс-аудит.

До начала миграции нужно провести тщательную диагностику вашей текущей инфраструктуры. Какую информацию собирают специалисты на этом этапе:

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

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

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

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

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

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

В облаке начинается подготовка среды:

• создание учётных записей для доступа;
• настройка всех необходимых сетей и VPN-соединений;
• развёртывание средств информационной безопасности — межсетевых экранов, систем защиты и других компонентов для соответствия внутренним стандартам и требованиям инфраструктуры.

При необходимости дорабатываем код в соответствии с конфигурациями 1С, если в ходе аудита нашли какие-то особенности или ограничения.

Если ваша миграция включает не только перенос инфраструктуры, но и смену ОС — например, переход с Windows на Linux или наоборот, то мы не рекомендуем проводить оба процесса в один шаг. В проекте лучше запланировать отдельные этапы: один для физической миграции системы, другой — для смены ОС. Этот переход можно выполнить как до, так и после миграции 1С в облако, в зависимости от особенностей проекта.

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

На этом шаге проверяем:

• соответствует ли производительность системы требованиям бизнеса при работе в облаке;
• корректно ли взаимодействуют между собой все компоненты системы;
• как система интегрируется с другими сервисами и смежными решениями;
• удобен ли пользовательский опыт при работе с 1С в новой среде.

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

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

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

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

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

Что нужно всегда учитывать при переносе систем 1С в облачную инфраструктуру:

1. Настройка окружения, то есть операционной системы, СУБД и кластера 1С. Эти действия критичны для стабильной работы системы после миграции.
2. Мониторинг. Настройка инструментов мониторинга помогает выявлять узкие места в работе системы, контролировать производительность и своевременно реагировать в случае её деградации.
3. Соблюдение стандартов 1С, чтобы избежать проблем совместимости и упростить поддержку решений.
4. Тюнинг виртуализации. У некоторых облачных сервисов есть специальные опции для тонкой настройки виртуализации под работу 1С, которые нужны для повышения производительности и стабильности системы.

Public-сегмент 

В этом сегменте мы используем серверы, оснащённые современными процессорами Intel Xeon Gold 6244 (3,6-4,4 ГГц), 6254 (3,1-4 ГГц), Gold6548Y+ (2,5- 4,1 Hhrz). Эти процессоры обеспечивают широкий диапазон тактовой частоты — от 2,5 ГГц до 4,3 ГГц. Такой уровень производительности особенно востребован при работе с высоконагруженными базами 1С, где ключевой параметр — именно производительность на одно ядро, а не только общее количество ядер. Для максимальной эффективности мы проводим тонкую настройку как на уровне операционной системы, так и на уровне СУБД, обеспечивая стабильность и высокую скорость работы ваших систем.

Dedicated Nodes, или выделенные узлы 

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

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

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

Работа в 1С через облако мало чем отличается для конечного пользователя от привычного сценария использования программы на локальных серверах или рабочих станциях. Но в техническом плане облачное размещение даёт бизнесу преимущества:

1. Высокая доступность. Пользователь может подключаться к системе из любой точки мира, например, если работает в компании с распределёнными командами или филиальной сетью.
2. Быстрое масштабирование ресурсов под рост числа пользователей или объём данных. Если нагрузка возрастает, можно добавить вычислительные мощности без капитальных затрат и долгих закупочных процедур.
3. Гибкое управление ресурсами позволит сэкономить в случае низкой бизнес-активности, ведь их количество можно уменьшить.
4. Техническая поддержка 1С. Это позволяет сосредоточить усилия специалистов на развитии бизнеса, а не на технической поддержке инфраструктуры.

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

Способы доступа к облачной 1С

1. Подключение через тонкий клиент 1С. Самый распространённый вариант. Пользователь устанавливает приложение 1С на рабочий компьютер или ноутбук и через интернет подключается к облачным серверам, где развёрнуты базы данных и сервер приложений. Тонкий клиент обеспечивает быструю работу и поддержку всех привычных функций 1С.
2. Веб-доступ через браузер. Если компания хочет минимизировать затраты на обслуживание рабочих мест, можно использовать веб-клиент 1С через браузер. Такой вариант подходит для сотрудников, которые работают удалённо или с разных устройств.
3. Подключение через терминальный сервер (RDP)— например, Windows Server с Remote Desktop Services. В этом случае пользователи подключаются к удалённому рабочему столу, на котором уже установлен клиент 1С. При таком сценарии всё взаимодействие между клиентом 1С и сервером происходит внутри облака, а пользователям передаётся картинка рабочего стола, что сильно снижает требования к скорости интернета.
4. VPN-подключение к корпоративной сети. Пользователь сначала подключается к защищённой корпоративной сети, а уже затем — к серверам 1С в облаке. Это решение подходит компаниям с повышенными требованиями к безопасности или когда нужна интеграция с внутренними сервисами.

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

С какими исходными данными обычно подходят к этапу сайзинга:

• Текущее состояние системы. Это может быть уже существующая система или проектируемая новая инсталляция. Мы анализируем её конфигурацию, количество пользователей, размер базы данных и другие важные параметры.
• Исторические данные. Если система уже эксплуатируется, часто доступны данные о динамике роста объёмов данных или числа пользователей за предыдущие периоды. Они помогают оценить тенденции и строить прогнозы.
• Бизнес-планы компании. Рост бизнеса напрямую влияет на будущие требования к системе 1С: увеличение числа пользователей, транзакций, интеграций, объёмов данных. Эти планы мы также учитываем при расчёте сайзинга.
• Расчёты на будущее. Даже если точных данных нет, можно использовать прогнозы, основанные на похожих проектах или усреднённых значениях для отрасли.

Часто при подборе инфраструктуры заказчики ставят задачу рассчитать ёмкость не только на текущий момент, но и с учётом перспективы на 3-5 лет вперёд. Это означает, что ресурсы должны покрывать пиковые нагрузки в будущем, что зачастую приводит к закладыванию избыточных мощностей «про запас».

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

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

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

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

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

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

Одно из направлений, где облачные провайдеры могут значительно упростить жизнь бизнесу, — это построение DR-решений, или Disaster Recovery решений для обеспечения отказоустойчивости и восстановления после сбоев.

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

Организация такой инфраструктуры «с нуля» в собственном контуре требует серьёзных ресурсов и времени. Нужно:

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

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

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

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

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

Мы сравнили размещение on premise и в облаке по трём основным критериям, которые чаще всего волнуют наших клиентов: масштабирование, экономика и производительность.

Масштабирование

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

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

Экономика

При размещении on premise компании оплачивают полную стоимость закупленного оборудования сразу, но на начальном этапе мощности, как правило, не используются на 100%. Нагрузка растёт постепенно, а капитальные затраты уже произошли.

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

Сравним основные статьи затрат и разберём, из чего складывается стоимость владения инфраструктурой. 

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

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

Операционные затраты начинаются с сетевого и серверного оборудования. В эту статью расходов входят закупка запасных частей и комплектующих (ЗИП), которая обычно составляет не менее 10% от стоимости самого оборудования, а также расходы на продление гарантийного обслуживания.

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

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

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

Последняя статья затрат — это фонд оплаты труда (ФОТ) для инженеров службы эксплуатации для обеспечения качественного уровня обслуживания по модели 24/7/365. При размещении в облаке эти затраты уже заложены в стоимость предоставляемых ресурсов. Пользователь получает в пакетной услуге выделенную проектную команду, техническую поддержку с регламентированным SLA и чётко определённым временем реакции на инциденты или обращения. Благодаря этому часть расходов на эксплуатацию снимается с компании и переносится на плечи провайдера.

Производительность

Существенный минус on-premise — риск vendor lock-in, или привязки к одному вендору. Она ограничивает проект техническими характеристиками уже приобретённого оборудования и сроками его амортизации.

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

Разберём, откуда берётся миф о том, что физические серверы заведомо быстрее и лучше для работы 1С, чем виртуальная инфраструктура в облаке.

Например, администратор запускает в облаке тестовую виртуальную машину, проводит несколько базовых синтетических тестов, например, на скорость дисков или процессора, и получает результаты. Если сравнить показатели виртуальной машины и физического сервера с одинаковыми техническими характеристиками (процессор, память, диски), то физический сервер, как правило, выигрывает в таких простых тестах. Причина в том, что на физическом сервере нет слоя виртуализации. 

Реальная эксплуатация систем 1С — это совсем не одноразовый синтетический тест.

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

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

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

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

Разберём пример из нашей практики. Клиент выбирал площадку для размещения своих систем 1С и рассматривал несколько вариантов: разные облачные провайдеры и аренду серверов в дата-центре.

Клиент самостоятельно развернул окружение в облаке. К сожалению, произошли ошибки в настройках:

• неправильно подобраны параметры виртуальных машин;
• неверно настроены СУБД и операционные системы;
• не учтены рекомендации для высоконагруженных баз 1С;
• отсутствовал тюнинг кластера и оптимизация инфраструктуры.

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

На консультации мы подробно разобрали окружение клиента и исправили узкие места:

• правильно подобрали параметры виртуальных машин и ядра процессора;
• сделали тюнинг операционной системы и СУБД;
• настроили виртуализацию в соответствии с лучшими практиками для работы 1С.

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

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

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

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

Если вы задумываетесь о переносе своей 1С в облако, выбирайте надёжного технологического партнёра.