26 февраля
Как перейти в облако: пошаговый план миграции IT-инфраструктуры в Казахстане
26 февраля 2026 г.
Введение
По данным IDC, среднегодовой темп роста (CAGR) рынка облачных сервисов в Казахстане составляет 22,5%. В 2026 году его объём достигнет $455 млн. Банки, промышленные предприятия и ритейл активно переносят инфраструктуру в облако. При этом на конец 2024 года в стране насчитывалось около 3 800 серверных стоек — и они были заполнены почти на 100%.
Компании переходят в облако, чтобы сократить капитальные затраты, ускорить запуск продуктов и повысить отказоустойчивость сервисов. Дополнительный стимул — требование о локализации персональных данных на территории РК, вступившее в силу в январе 2025 года. Это заставляет бизнес пересматривать инфраструктуру и выбирать провайдеров с дата-центрами в Казахстане.
Однако миграция в облако — не просто «скопировать файлы на удалённый сервер». Это комплексный проект, который затрагивает инфраструктуру, процессы разработки, безопасность и даже оргструктуру IT-команды. Без чёткого плана переезд может затянуться на месяцы, а бюджет — вырасти в 2–3 раза.
В этой статье — пошаговый план миграции IT-инфраструктуры в облако с учётом специфики Казахстана: регуляторные требования, выбор провайдера, контроль бюджета и чек-лист готовности. Материал будет полезен CTO, IT-директорам, DevOps-инженерам и техническим руководителям, которые планируют или уже начали перенос данных в облако.
Что такое облачная миграция и когда она нужна
IT-миграция в облако — это процесс переноса приложений, данных, баз данных и других компонентов IT-инфраструктуры из локального дата-центра (on-premise) или одного облака в другое облачное окружение. Миграция может быть полной (все сервисы переезжают в облако) или частичной (гибридная модель, когда часть нагрузок остаётся на собственных серверах).
5 причин перейти в облако
1. Серверы загружены до предела, а закупка нового оборудования занимает месяцы. Если бизнес растёт быстрее, чем IT-команда успевает масштабировать инфраструктуру — облако решает проблему за часы. С учётом дефицита серверных стоек в РК это особенно актуально.
2. Затраты на поддержку инфраструктуры растут, а бюджет — нет. Обслуживание физических серверов, аренда стоек, оплата труда специалистов — всё это фиксированные расходы. Облако переводит CAPEX в OPEX и позволяет платить только за используемые ресурсы.
3. Команде разработки приходится ждать окружения несколько дней. В облаке новый тестовый стенд разворачивается за минуты через Infrastructure as Code. Это ускоряет CI/CD и time-to-market.
4. Нет плана аварийного восстановления (DR). Облачные провайдеры предлагают встроенные инструменты Disaster Recovery с RPO/RTO в минутах, а не в часах.
5. Нужно выполнить требования по локализации данных. С января 2025 года персональные данные граждан РК должны храниться на территории Казахстана. Локальные облачные провайдеры — самый быстрый способ привести инфраструктуру в соответствие.
Если хотя бы два пункта совпадают — стоит рассмотреть миграцию в облако.
Основные стратегии миграции в облако
Прежде чем переносить сервисы, нужно определить стратегию миграции. Классическая модель — 6R, основанная на методологии Gartner (5R, 2011) и расширенная AWS в 2016 году. Каждая из шести стратегий подходит для определённых типов нагрузок.
Rehost (Lift & Shift) — перенос «как есть»
Приложение переносится в облако без изменений архитектуры. Виртуальная машина on-premise превращается в виртуальную машину в облаке. Это самый быстрый способ: миграция одного сервера занимает от нескольких часов до пары дней.
Когда подходит: legacy-приложения, которые работают стабильно и не требуют модернизации прямо сейчас. Типичный пример — перенос 1С-серверов или корпоративной почты.
Replatform (Lift & Reshape) — перенос с оптимизацией
Приложение переносится с минимальными изменениями, чтобы использовать облачные managed-сервисы. Например, вместо самостоятельно настроенного PostgreSQL на виртуальной машине — managed PostgreSQL от провайдера.
Когда подходит: приложения, которые выиграют от managed-сервисов, но не готовы к полному рефакторингу.
Refactor (Re-architect) — перестройка архитектуры
Приложение переписывается для cloud-native архитектуры: микросервисы, контейнеры, serverless-компоненты. Самый дорогой и долгий путь, но он даёт максимальную выгоду от использования облака.
Когда подходит: критически важные приложения, которые нуждаются в высокой масштабируемости и отказоустойчивости.
Repurchase — замена на SaaS
Вместо переноса собственного решения компания переходит на готовый SaaS-продукт. Например, вместо собственного почтового сервера используют облачную почту.
Retain — оставить на месте
Некоторые системы не имеет смысла переносить: аппаратные HSM-модули, специфическое оборудование, системы с жёсткими требованиями к latency.
Retire — вывести из эксплуатации
Аудит перед миграцией часто выявляет системы, которые больше не нужны.
Как выбрать стратегию
На практике компании комбинируют несколько подходов. Оптимальная тактика: начать с Rehost для быстрого переезда, а затем постепенно переходить к Replatform и Refactor для критических сервисов.
Этапы миграции в облако: пошаговый план
Этапы миграции в облако можно разделить на шесть последовательных фаз.
Этап 1: Аудит текущей инфраструктуры
Прежде чем переносить что-либо, нужно понять, что именно предстоит перенести. Аудит отвечает на вопросы:
- Сколько серверов, виртуальных машин и контейнеров в эксплуатации?
- Какие приложения на них работают и как они связаны между собой?
- Какие объёмы данных хранятся и как быстро они растут?
- Какие требования к производительности, latency, доступности?
- Есть ли регуляторные ограничения (Закон РК о персональных данных, требования МЦРИАП, отраслевые стандарты)?
- Какие данные подпадают под требование локализации на территории РК?
Инструменты аудита: CMDB-системы, сетевые сканеры, средства APM. Некоторые облачные провайдеры предоставляют бесплатные утилиты для инвентаризации.
Результат этапа: карта зависимостей приложений (dependency map), реестр нагрузок с метриками потребления ресурсов, список ограничений.
Этап 2: Выбор облачного провайдера
Критерии выбора провайдера для казахстанских компаний:
- Соответствие Закону РК «О персональных данных и их защите» (№ 94-V). С января 2025 года персональные данные должны храниться на территории Казахстана. Дата-центры провайдера обязаны находиться в РК.
- Сертификаты безопасности. ISO 27001, PCI DSS (для платёжных данных), сертификация дата-центра по Uptime Institute (Tier III и выше). Соответствие единым требованиям в области ИКТ и ИБ (Постановление № 832).
- Набор managed-сервисов. Чем больше сервисов провайдер берёт на себя, тем меньше ресурсов тратит IT-команда на поддержку. Более 66% локальных провайдеров в РК предоставляют только IaaS — учитывайте это при выборе.
- SLA и отказоустойчивость. SLA 99,95% — стандарт рынка. Для mission-critical нагрузок нужно смотреть на мультизональную архитектуру.
- Прозрачность ценообразования. Почасовая тарификация, отсутствие скрытых платежей, калькулятор стоимости. Обратите внимание на стоимость исходящего трафика — это частый сюрприз в счёте.
- Техническая поддержка. Поддержка на русском и казахском языках 24/7 с гарантированным временем реакции.
Ключевые игроки на рынке РК (2025–2026): QazCloud, PS Cloud Services, Транстелеком, Yandex Cloud (дата-центр в Алматы с 2024), VK Cloud (партнёрство с QazCloud), ИТ-ГРАД.
Этап 3: Проектирование целевой архитектуры
На этом этапе определяется, как будет выглядеть инфраструктура после переезда:
- Сетевая архитектура: VPC, подсети, VPN-туннели для гибридной связности, балансировщики нагрузки.
- Вычислительные ресурсы: типы виртуальных машин, конфигурации Kubernetes-кластеров, serverless-функции.
- Хранение данных: объектное хранилище для статики, блочное — для баз данных, файловое — для общих ресурсов.
- Безопасность: межсетевые экраны, WAF, IAM-политики. Для данных ограниченного доступа — криптозащита не ниже 3-го уровня по СТ РК 1073-2007.
- Мониторинг и логирование: централизованный сбор метрик, алертинг, трейсинг.
Результат этапа: архитектурная схема, IaC-шаблоны (Terraform, Pulumi), план сетевой связности.
Этап 4: Пилотный перенос и тестирование
Пилотный перенос — это «генеральная репетиция» миграции на одном-двух некритичных сервисах. Цели пилота:
- Проверить скорость передачи данных между on-premise и облаком
- Убедиться, что приложение работает корректно в новом окружении
- Замерить производительность и сравнить с on-premise
- Отладить процедуры отката
Критерии успеха пилота: приложение работает в облаке не менее 2 недель без деградации SLA. Все метрики (CPU, RAM, IOPS, latency) в пределах допустимых значений. Для latency внутри РК целевое значение — менее 50 мс.
Рекомендация: выбирайте для пилота сервис с умеренной сложностью — не самый простой (тест будет нерепрезентативным) и не самый критичный (риски слишком высоки).
Этап 5: Основная миграция данных и сервисов
После успешного пилота начинается перенос данных в облако по согласованному графику. Ключевые принципы:
- Миграция волнами. Разбейте все нагрузки на 3–5 волн по приоритету. Первая волна — сервисы, проверенные в пилоте. Последняя — наиболее критичные системы.
- Окна обслуживания. Для stateful-приложений (базы данных, файловые серверы) потребуется плановый downtime. Минимизируйте его за счёт предварительной синхронизации данных.
- Параллельная работа. На время миграции держите старую и новую инфраструктуру одновременно. Переключение трафика — через DNS или балансировщик.
- Валидация после каждой волны. Прежде чем переходить к следующей волне, убедитесь, что перенесённые сервисы работают стабильно.
Этап 6: Оптимизация и мониторинг
Миграция не заканчивается переносом последнего сервера. После переезда начинается фаза оптимизации:
- Right-sizing. Подберите оптимальные конфигурации виртуальных машин на основе реальных метрик потребления. По опыту, до 30% ресурсов можно сократить без потери производительности.
- Резервирование ресурсов. Если нагрузка предсказуема, зарезервируйте ресурсы на 1–3 года — экономия до 40% по сравнению с on-demand.
- Автоскейлинг. Настройте горизонтальное масштабирование для сервисов с переменной нагрузкой.
- FinOps-практики. Внедрите теги для учёта затрат по проектам, регулярный аудит неиспользуемых ресурсов, алерты при превышении бюджета.
Какие данные и сервисы переносить в первую очередь
Не все нагрузки одинаково просто перенести. Перенос инфраструктуры в облако стоит начинать с сервисов, которые:
- Не имеют жёстких зависимостей от физического оборудования
- Легко масштабируются горизонтально
- Не обрабатывают данные, подпадающие под строгие регуляторные требования (либо провайдер выполняет эти требования)
- Имеют хорошее покрытие тестами и мониторингом
Хорошие кандидаты для первой волны
| Тип нагрузки | Почему легко перенести |
| Веб-приложения (фронтенд) | Stateless, легко масштабируются |
| CI/CD-пайплайны | Не привязаны к конкретному железу |
| Dev/test-окружения | Низкий риск, высокая выгода |
| Бэкапы и архивы | Объектное хранилище дешевле локального |
| Аналитические нагрузки | Выигрывают от эластичного масштабирования |
Что лучше оставить on-premise (пока)
- Системы с аппаратными ключами защиты (HASP, HSM)
- Промышленное ПО, привязанное к специфическому оборудованию (актуально для нефтегазовой отрасли РК)
- Нагрузки с требованием latency менее 1 мс (HFT, real-time processing)
- Системы, миграция которых запрещена регулятором
Гибридная модель — не компромисс, а зрелый подход. По данным Flexera State of the Cloud 2024, 89% компаний в мире используют мультиоблачную стратегию, а 73% — гибридную.
Регуляторные требования Казахстана: что нужно знать
Для компаний в РК миграция в облако связана с рядом регуляторных особенностей. Незнание этих требований может привести к штрафам и блокировке сервисов.
Ключевые законы и нормативные акты
| Документ | Что регулирует |
| Закон РК «О персональных данных и их защите» (№ 94-V, 2013) | Сбор, обработка, хранение и защита ПДн |
| Закон РК «Об информатизации» (№ 418-V, 2015) | ИКТ-инфраструктура, критически важные объекты, электронное правительство |
| Концепция «Киберщит Казахстана» (Постановление № 407) | Стратегия защиты ИКТ-инфраструктуры |
| Единые требования в области ИКТ и ИБ (Постановление № 832) | Обязательные стандарты для госорганов и критических объектов |
Что это значит для миграции
Локализация данных. С 8 января 2025 года персональные данные обязаны храниться в электронных базах данных, физически расположенных на территории Казахстана. Это значит, что серверы провайдера должны находиться в РК — даже если доступ организован удалённо.
Трансграничная передача. Передача ПДн за рубеж допускается только в страны с адекватным уровнем защиты и с согласия субъекта данных.
Уведомление об инцидентах. С 1 июля 2024 года компании обязаны уведомлять МЦРИАП о нарушении безопасности ПДн в течение 1 рабочего дня.
Криптозащита. Хранение и передача персональных данных ограниченного доступа требуют защиты не ниже 3-го уровня по СТ РК 1073-2007.
Особенность МФЦА. На территории Astana International Financial Centre действует отдельный режим, приближённый к GDPR. Для финтех-компаний и международного бизнеса это может быть преимуществом.
Риски миграции и как их избежать
Миграция в облако — проект с десятками переменных. Вот пять основных рисков и способы их минимизации.
1. Недооценка сложности зависимостей
Приложение, которое «просто работает» на физическом сервере, может зависеть от десятков неочевидных компонентов: локальных файлов конфигурации, сетевых настроек, привязки к IP-адресам, системных cron-задач.
Как избежать: провести детальный аудит зависимостей до начала миграции. Использовать инструменты автоматического обнаружения (Application Discovery).
2. Проблемы с производительностью после переноса
Сетевая архитектура в облаке отличается от on-premise. Latency между сервисами может вырасти, если не продумать размещение компонентов.
Как избежать: размещать взаимозависимые сервисы в одной зоне доступности. Учитывать, что основные дата-центры в РК расположены в Алматы и Астане — выбирайте регион ближе к пользователям. Проводить нагрузочное тестирование до переключения production-трафика.
3. Неконтролируемый рост затрат
Облако работает по модели pay-as-you-go. Без контроля расходы могут оказаться выше, чем on-premise. Типичные ловушки: забытые тестовые окружения, избыточные снапшоты, over-provisioned виртуальные машины.
Как избежать: внедрить FinOps-практики с первого дня. Настроить бюджетные алерты. Проводить ежемесячный аудит ресурсов. Использовать reserved instances для предсказуемых нагрузок.
4. Безопасность и compliance
Безопасность облака — зона совместной ответственности провайдера и клиента. Провайдер отвечает за безопасность инфраструктуры, клиент — за безопасность данных и настроек.
Как избежать: разработать модель угроз для облачного окружения. Настроить IAM-политики по принципу наименьших привилегий. Включить шифрование для всех хранилищ. Убедиться, что провайдер соответствует требованиям Закона о ПДн РК и Концепции «Киберщит Казахстана».
5. Дефицит мощностей в дата-центрах РК
На конец 2024 года около 3 800 серверных стоек в Казахстане были заполнены почти на 100%. Это может стать ограничением при масштабировании.
Как избежать: заранее резервировать ресурсы у провайдера. Следить за вводом новых мощностей — дата-центр Akashi (Tier IV, 4 000 стоек) в Астане запустит первый блок в 2026 году, что удвоит ёмкость страны.
Сколько стоит миграция в облако в Казахстане
Стоимость миграции складывается из нескольких компонентов. Понимание структуры затрат помогает избежать сюрпризов.
Прямые затраты
| Статья расходов | Диапазон |
| Облачные ресурсы (compute, storage, network) | Зависит от объёма нагрузок |
| Лицензии на ПО (если меняется модель лицензирования) | 0–30% от стоимости ресурсов |
| Инструменты миграции | Часто бесплатны у провайдера |
| Внешние консультанты / интегратор | От 2 до 25+ млн тенге |
Скрытые расходы
- Канал связи. Для переноса 10 ТБ данных через канал 1 Гбит/с потребуется ~24 часа. Если канал уже нагружен production-трафиком — возможно, нужен выделенный линк.
- Обучение команды. Инженерам нужно освоить облачные инструменты, IaC, новые подходы к мониторингу.
- Двойная оплата. В период миграции компания платит и за старую, и за новую инфраструктуру. Закладывайте 1–3 месяца параллельной работы.
- Рефакторинг. Если приложение требует изменений для работы в облаке — это время разработчиков.
Как оценить TCO
Для корректной оценки совокупной стоимости владения (Total Cost of Ownership) сравнивайте не «цену сервера» с «ценой виртуальной машины», а полные затраты:
On-premise: оборудование + амортизация + электроэнергия + охлаждение + аренда стоек + зарплаты администраторов + лицензии + DR-площадка.
Облако: compute + storage + network + managed-сервисы + поддержка. По опыту, для компаний с 50–500 серверами миграция в облако снижает TCO на 20–40% в горизонте 3–5 лет. Основная экономия — на сокращении операционных расходов и ускорении вывода продуктов на рынок.
Чек-лист: готовность к миграции
Перед стартом проекта проверьте каждый пункт:
- Инвентаризация завершена. Есть полный реестр серверов, приложений и зависимостей.
- Стратегия выбрана. Для каждой нагрузки определён подход: Rehost, Replatform, Refactor или Retain.
- Провайдер определён. Проверены SLA, сертификаты безопасности, наличие ЦОД в Казахстане.
- Целевая архитектура спроектирована. Есть схема сети, IaC-шаблоны, план размещения.
- Бюджет согласован. Учтены прямые и скрытые расходы, заложен резерв 15–20%.
- Команда готова. Инженеры прошли обучение, роли и ответственности распределены.
- Compliance проверен. Требования Закона о ПДн РК, локализация данных, уведомление об инцидентах — всё учтено.
- План отката разработан. Для каждого сервиса есть процедура возврата на on-premise.
- Пилотный перенос проведён. Один-два сервиса успешно работают в облаке 2+ недели.
- Безопасность настроена. IAM, шифрование, сетевые политики, мониторинг инцидентов.
Если хотя бы два пункта из десяти не выполнены — не начинайте основную миграцию. Вернитесь к подготовительным этапам.
Заключение
Миграция в облако — стратегический проект, который при правильном подходе кратно повышает гибкость IT-инфраструктуры и снижает операционные затраты. Для казахстанских компаний дополнительные стимулы — требования по локализации данных, рост цифровизации госсектора и дефицит собственных серверных мощностей.
Ключ к успеху — системный подход: аудит, выбор стратегии, пилотный перенос, поэтапная миграция и непрерывная оптимизация. Не пытайтесь перенести всё за один weekend. Разбейте проект на управляемые этапы, начните с некритичных нагрузок и наращивайте экспертизу команды.
Рынок облаков в Казахстане развивается стремительно: новые дата-центры (включая первый в Центральной Азии Tier IV), приход международных провайдеров и государственная программа цифровой трансформации создают благоприятную среду для переезда. Если вы планируете перейти в облако — начните с аудита текущей инфраструктуры и пилотного переноса одного-двух сервисов. Это даст реальные данные для принятия решений.
FAQ: частые вопросы о миграции в облако в Казахстане
Сколько времени занимает миграция в облако?
Зависит от масштаба: пилотный перенос 1–2 сервисов — 2–4 недели, полная миграция инфраструктуры из 50–200 серверов — от 3 до 9 месяцев. Ключевые факторы: объём данных, сложность зависимостей между приложениями и готовность команды.
Обязательно ли хранить данные на территории Казахстана?
Да, с 8 января 2025 года персональные данные граждан РК обязаны храниться в электронных базах данных на территории Казахстана (Закон № 94-V «О персональных данных и их защите»). Трансграничная передача допускается только в страны с адекватным уровнем защиты и с согласия субъекта данных.
Можно ли использовать зарубежных облачных провайдеров?
Можно — для данных, которые не подпадают под требование локализации. Но для персональных данных граждан РК серверы должны быть на территории Казахстана. Ряд международных провайдеров (например, VK Cloud) уже открыли дата-центры в РК и подходят для этих задач.
Какие отрасли в Казахстане активнее всего переходят в облако?
Лидеры — банковский сектор (наиболее зрелый, онлайн-банкингом пользуются почти 100% населения), промышленность (цифровые двойники, IIoT) и ритейл (доля e-commerce выросла с 1,4% в 2018 до 13,1% в 2023 году). Госсектор стабильно занимает 53% спроса на облачную инфраструктуру.
Что делать, если дата-центры в Казахстане заполнены?
На конец 2024 года ёмкость дата-центров в РК (~3 800 стоек) была практически исчерпана. Рекомендуем: заранее бронировать ресурсы у провайдера, рассматривать reserved instances и следить за вводом новых мощностей. В 2026–2027 ёмкость удвоится за счёт Akashi (4 000 стоек, Tier IV) и других строящихся ЦОД.
Сколько стоит миграция в облако?
Стоимость зависит от объёма инфраструктуры. Прямые затраты: облачные ресурсы + лицензии + работа интегратора (от 2 млн тенге). Скрытые расходы: двойная оплата инфраструктуры на 1–3 месяца, обучение команды, возможный рефакторинг приложений. По опыту, TCO снижается на 20–40% в горизонте 3–5 лет за счёт сокращения операционных расходов.
Какой облачный провайдер лучше выбрать в Казахстане?
Универсального ответа нет — зависит от задач. Для регулируемых нагрузок и госзаказа подходят QazCloud и PS Cloud Services. Для компаний, которым нужен широкий набор managed-сервисов — Yandex Cloud и VK Cloud (оба с дата-центрами в РК). Главное — проверить наличие сертификатов (ISO 27001, PCI DSS), SLA и провести пилотное тестирование.
Нужно ли уведомлять регулятора о миграции?
О самой миграции уведомлять не нужно. Но с 1 июля 2024 года компании обязаны сообщать МЦРИАП о любых инцидентах безопасности, связанных с персональными данными, в течение 1 рабочего дня. Убедитесь, что процесс уведомления настроен до начала миграции.
Оставьте заявку, чтобы получить консультацию
Оставьте заявку или напишите на почту digital.tech@corp.mail.ru, чтобы узнать больше о сервисах VK и получить коммерческое предложение.
Почитать по теме
29 января
Почему сайты падают под нагрузкой и как облако решает эту проблему
28 января
