Из серверной в подвале — в Google Cloud: пошаговый план миграции для казахстанского бизнеса без простоев

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

Для малого и среднего бизнеса (МСБ) в Казахстане это абсолютная норма. Исторически сложилось так, что предприниматели предпочитают "свое" железо. Его можно потрогать, оно стоит в офисе, и кажется, что так безопаснее. Но по мере роста компании эта иллюзия контроля начинает обходиться слишком дорого. Серверы устаревают, диски сыплются, отключения электричества парализуют работу, а резервное копирование, как правило, делается "иногда" и на внешний USB-диск.

Сегодня мы поговорим о том, как бизнесу решиться на переезд в Google Cloud, почему облако — это не только для IT-гигантов и финтеха, и как организовать миграцию так, чтобы ни один клиент не заметил простоя.

Главные страхи казахстанского бизнеса перед облаком

Когда мы предлагаем фаундерам или финансовым директорам перенести инфраструктуру в Google Cloud, мы всегда сталкиваемся с одними и теми же возражениями. Давайте разберем их.

Страх №1: "Это дорого. Лучше мы один раз купим сервер за 3 миллиона тенге, и он будет работать 5 лет"

Это классическая ловушка капитальных затрат (CapEx) против операционных (OpEx). Да, вы покупаете сервер за 3-5 миллионов тенге. Но вы забываете посчитать стоимость лицензий на виртуализацию, стоимость Windows Server, бесперебойники (ИБП), кондиционирование, замену сгоревших дисков и зарплату инженера, который всё это обслуживает. Более того, вы покупаете сервер "с запасом" на будущий рост, то есть переплачиваете за мощности, которые будут простаивать первые два года. В облаке вы платите только за то, что реально используете прямо сейчас. Месячный счет в 30-50 тысяч тенге за облачную инфраструктуру для небольшой компании — это реальность.

Страх №2: "А если интернет отключат? У нас же Казактелеком/Транстелеком иногда падает"

Справедливое опасение. Если у вас в офисе пропадет интернет, вы не сможете подключиться к облаку. Но давайте посмотрим на это с другой стороны: если у вас пропадет интернет в офисе с локальным сервером, ваши удаленные сотрудники, менеджеры "в полях" и клиенты на B2B-портале тоже потеряют доступ к системе. Решение простое: провести в офис два независимых интернет-канала от разных провайдеров с автоматическим переключением (failover). Это стоит копейки по меркам бизнеса, но решает проблему связи навсегда.

Страх №3: "Там наши данные украдут, а сервер в офисе — под замком"

Физическая безопасность локального сервера часто ограничивается дверью из гипсокартона и уборщицей, которая может случайно задеть шваброй кабель питания. Данные на локальных серверах редко шифруются. В Google Cloud ваши данные хранятся в дата-центрах с вооруженной охраной, биометрическим доступом и многоуровневым резервированием. Все данные по умолчанию шифруются (Encryption at rest и in transit). Шанс того, что ваши данные "утекут" из-за халатности или изъятия серверов, в облаке стремится к нулю.

Кейс: Миграция дистрибьютора без паники и простоя

Чтобы не быть голословными, разберем недавний проект лаборатории ОЗАТ. К нам обратилась региональная дистрибьюторская компания. Масштабы скромные по меркам Enterprise, но критичные для владельца: около 150 сотрудников, 30 активных пользователей в 1С (Управление торговлей), небольшая CRM-система и B2B-портал для приема оптовых заказов. Размер базы данных 1С — около 80 ГБ, общий объем файлового архива — 300 ГБ.

Проблема: Старый сервер начал "умирать". 1С жутко тормозила при проведении документов. B2B-портал периодически отваливался, потому что крутился на той же машине, что и 1С. Владелец бизнеса устал от постоянных жалоб менеджеров и клиентов.

Мы предложили миграцию в Google Cloud. План был составлен так, чтобы процесс занял минимум времени и не прервал продажи.

Пошаговый план миграции (Как мы это сделали)

Шаг 1. Аудит и инвентаризация (Неделя 1)

Нельзя переносить то, о чем вы не знаете. Мы запустили скрипты сбора метрик на старом сервере. Выяснилось, что из 64 ГБ оперативной памяти 1С использует 40, а остальное "съедает" старый, давно забытый SQL-сервер, который никто не использовал уже два года. Мы составили точную карту зависимостей: кто, куда и по каким портам подключается.

Шаг 2. Развертывание Landing Zone (Неделя 2)

Мы не стали сразу копировать данные. Сначала нужно было подготовить "посадочную площадку" в Google Cloud.

• Настроили виртуальную сеть (VPC) и правила фаервола. В облако нельзя было попасть снаружи, только через защищенный туннель.
• Подняли Cloud VPN. Это позволило объединить локальную сеть офиса и сеть в Google Cloud. Для офисных компьютеров облачный сервер стал выглядеть так, будто он стоит в соседней комнате (локальные IP-адреса).
• Создали две виртуальные машины (Compute Engine): одну для базы данных PostgreSQL (специально оптимизированную для 1С), вторую — как терминальный сервер для пользователей.

Шаг 3. Решение проблемы с 1С (Неделя 3)

1С — это больная тема для облаков. Клиент 1С очень чувствителен к сетевым задержкам (пингу). Если база данных в облаке (например, во Франкфурте), а клиент запускается на компьютере бухгалтера в Алматы, пинг составит около 90-100 миллисекунд. Для 1С это смертельно: интерфейс будет висеть, документы будут проводиться минутами.

Решение: Мы использовали паттерн Remote Desktop Services (RDS). Мы разместили терминальный сервер (Windows Server) в том же дата-центре Google Cloud, прямо рядом с сервером базы данных (пинг между ними < 1 мс). Пользователи из Казахстана подключаются к терминальному серверу по RDP (через безопасный VPN). RDP-протоколу плевать на пинг в 100 мс, он просто передает картинку. В итоге 1С "летает", потому что вычисления происходят прямо в облаке, а пользователи видят мгновенный отклик.

Шаг 4. Модернизация B2B-портала

B2B-портал компании был написан на PHP и крутился на старом Apache. Мы не стали тащить его на виртуальную машину. Вместо этого мы "упаковали" портал в Docker-контейнер и развернули в Google Cloud Run.

Почему это важно? Cloud Run — это бессерверная (serverless) среда. Ночью, когда оптовики спят и заказов нет, Cloud Run спит вместе с ними, и клиент ничего не платит. Днем он автоматически масштабируется. Базу данных портала мы перенесли в управляемый сервис Cloud SQL для MySQL. Теперь бэкапы делаются автоматически, а стабильность портала больше не зависит от того, насколько сильно загружена 1С.

Шаг 5. Тестирование без влияния на бизнес (Неделя 4)

Мы сделали "срез" базы данных и развернули полную копию инфраструктуры в облаке. Мы попросили нескольких ключевых сотрудников (главбуха и старшего менеджера продаж) поработать в тестовой облачной версии 1С пару дней параллельно с основной работой.

Вердикт главбуха: "Оно работает быстрее, чем наш старый сервер, когда он был новым". Багов не обнаружено.

Шаг 6. Час "Икс" — Миграция (Пятница, 20:00)

Миграция всегда проводится в пятницу вечером. Если что-то пойдет не так, у вас есть суббота и воскресенье на откат (rollback).

1. В 20:00 всех пользователей принудительно отключили от старого сервера в офисе.
2. Базы данных 1С и B2B-портала были переведены в режим "только чтение" (Read-Only).
3. Сделали финальный дамп (резервную копию) всех данных и перенесли их в Google Cloud через защищенный канал. Для 100 ГБ базы данных это заняло около пары часов.
4. Восстановили базы в облаке, переключили DNS-записи B2B-портала на новые IP-адреса Cloud Run.
5. В 01:00 ночи система была полностью работоспособна.

В понедельник в 09:00 менеджеры пришли на работу, кликнули на ту же самую иконку 1С на рабочем столе (мы заранее через групповые политики обновили ярлыки) и продолжили работать. Разницу они заметили только в скорости — документы стали проводиться за 2 секунды вместо 15.

Финансовый итог (FinOps для маленьких)

Что мы получили в итоге?

• Никаких капитальных затрат на новый сервер (а он обошелся бы минимум в 4 млн тенге).
• Ежемесячный счет за Google Cloud (две виртуальные машины, Cloud SQL, Cloud Run, VPN, Storage для бэкапов) составил около $180-$220 в месяц в зависимости от нагрузки.
• Мы настроили автоматическое выключение (Schedules) терминального сервера на ночь и выходные. Поскольку компания работает строго с 9 до 18, сервер работает только 220 часов в месяц вместо 730. Это сэкономило клиенту почти 60% стоимости виртуальных машин.

Резюме: Облако — это свобода

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

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

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