Piklema Predictive — российская компания, разрабатывающая решения для оптимизации горного производства через анализ данных диспетчеризации, цифровые советчики, MES-систем и планирования. За 4 года сотрудничества AvantIT выполнил три миграции их инфраструктуры между облаками (Azure → AWS → GCP → Azure), внедрил Kubernetes и настроил мониторинг, что позволило клиентам Piklema снизить затраты на производство на 15–20%.

Проблема

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

Цель проекта

Создать гибкую, отказоустойчивую инфраструктуру, которую относительно просто переносить между облаками при завершении гранта. Она должна:

  • гарантировать высокую доступность сервисов для клиентов;

  • позволять прогнозировать и предотвращать инциденты.

Чтобы достичь этого, мы разработали стратегию, объединяющую перенос инфраструктуры, управление ресурсами через Terraform и Ansible и GitOps-подход.

От анализа до плана: как мы выстроили стратегию

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

Этапы реализации:

  1. Миграция между облаками: гибкость под финансовые условия.

Учитывая зависимость Piklema от грантов, мы предусмотрели цикличные переносы инфраструктуры между Azure, AWS и Google Cloud. Это позволило клиенту оставаться в рамках бюджета, не теряя доступность сервисов.

  1. Infrastructure as Code (IaC): управление через Terraform и Ansible.

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

  1. Переход с Docker Compose на Kubernetes.

Для замены устаревшей архитектуры мы выбрали Kubernetes — это дало Piklema отказоустойчивость, гибкое масштабирование под нагрузку и унификацию деплоев.

  1. Настройка CI/CD и мониторинга.

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

Каждый этап минимизировал риски для бизнеса Piklema. Автоматизация через IaC уменьшила человеческий фактор при миграциях, а Kubernetes и CI/CD заложили основу для быстрого масштабирования под требования новых заказчиков.

Первым и самым сложным шагом стали миграции между облаками — именно о них мы расскажем дальше.

Миграция между облаками: гибкость и надежность

Для Piklema ежегодные миграции между облаками (Azure → AWS → GCP → Azure) были критичной задачей. Завершение грантов требовало оперативного переезда, чтобы избежать роста затрат. Мы спроектировали процесс, превративший хаотичные переносы в управляемый workflow с фиксированным сроком — 1-2 месяца на каждую миграцию.

Первая миграция (Azure → AWS): основа для будущих переходов

  1. Провели полную ревизию: удалили неиспользуемые серверы, упростили архитектуру.

  2. Перевели инфраструктуру на Terraform + Ansible, что стандартизировало конфигурации и сделало их понятными для переноса.

  3. Перенесли данные из старого PyPi-регистри и Nexus в новый Nexus развернутый через Ansible.

Для автоматизации переноса репозиториев из одного Nexus в другой мы написали кастомный скрипт, который ускорил процесс переноса.

При миграции инфраструктуры Piklema из Azure в AWS ключевым вызовом стал перенос Windows-виртуальных машин с Oracle на 5 дисках. Из-за того, что никто не знал как эти сервера были настроены, пришлось переносить все по дискам, а не создавать новый настроенный сервер с Oracle и переносить данные бекапом/рестором на уровне БД.

Сложный кейс: Windows-сервер с Oracle.

Сервер с базой данных Oracle на Windows вызывал особые сложности:

  • архитектура включала 5 дисков с неизвестной логикой распределения данных;

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

Восстановление доступа

Для сброса пароля администратора мы использовали LiveCD Ubuntu и утилиту chntpw:

  • загрузили Ubuntu в режиме «без установки»;

  • установили chntpw;
    add-apt-repository universe
    apt install chntpw -y

  • Смонтировали раздел с Windows;
    fdisk -l
    mkdir /mnt/ntfs1
    ntfsfix /dev/sda2 (например)
    mount -t ntfs /dev/sda2 /mnt/ntfs1
    cd /mnt/ntfs1/Windows/System32/config

  • Получаем список пользователей в системе
    chntpw -l SAM

  • Редактируем нужного пользователя
    chntpw -u "USERNAME_FROM_4" SAM

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

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

Результат: данные перенесены без потерь, сервисы клиентов не пострадали.

Если кратко, то перенос выполнялся следующим образом

  • Фиксируем публичный IP чтобы не потерять, может пригодиться в будущем

  • Выполняем снапшот виртуальной машины

  • Создаем виртуальную машину в AWS в которую будем копировать диски и S3 бакет в который будем переносить скопированные диски

  • Заходим на Windows машину, запускаем в ней

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe   Важно: После этого шага машина не загрузится — обязательно создайте снапшот дисков.

  • По завершении генерализации, отключаем виртуальную машину и в консоли Azure в подстранице Disks страницы этой виртуальной машины прокликиваем все диски и во вкладках дисков на подвкладке Disk Exports генерируем ссылки на скачивание VHD образов дисков

В Azure Portal сгенерировали временные ссылки на скачивание VHD-образов дисков через раздел Disk Exports.

  • Заходим на виртуальную машину в AWS и скачиваем с помощью wget образы по сгенерированным ссылкам

wget "" -O disk.vhd

  • Загружаем образы в S3

aws s3 cp disk.vhd s3://<bucket-name>/path/  

  • Импортируем VHD образ диска с системой в AMI образ командой

aws ec2 import-image --architecture x86_64 --license-type BYOL --platform Windows --disk-containers "Format=VHD,UserBucket={S3Bucket=S3_BUCKET_NAME,S3Key=PATH_TO_VHD_IMAGE_IN_S3}"

Не системные диски импортируем в снапшоты дисков командой

aws ec2 import-snapshot --disk-container "Format=VHD,UserBucket={S3Bucket=S3_BUCKET_NAME,S3Key=PATH_TO_VHD_IMAGE_IN_S3}"

Получить прогресс можно командами:

aws ec2 describe-import-image-tasks --import-task-ids и aws ec2 describe-import-snapshot-tasks --import-task-ids соответственно

  • По завершении импорта создаем виртуальную машину из импортированных образов и снапшотов

Нюансы

  1. Если диск с данными занимает больше 500 GiB то импорт может никогда не закончиться, в этом случае нужно переконвертировать VHD образ в RAW образ, сделать это можно утилитой qemu-img

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

Источник: Migrating a Windows Azure Virtual Machine (VM) to AWS

Способ оказался не без изъянов, после такого переноса сбрасывается пароль на учетной, пришлось сбрасывать пароль.

От Docker Compose к Kubernetes: как мы обеспечили высокую доступность для клиентов Piklema

Переход с Docker Compose на Kubernetes стал ключевым шагом в выполнении требований клиентов Piklema. Если раньше инфраструктура не гарантировала отказоустойчивость, то внедрение Kubernetes позволило добиться высокой доступности (HA) — критичного параметра для горнодобывающих предприятий, которые полагаются на аналитику Piklema в режиме 24/7.

Почему Kubernetes, а не Docker Compose?

Клиенты Piklema требовали бесперебойной работы сервисов. Кроме того, управление 10 Python-приложениями (включая ядро прогнозной аналитики) в разрозненной среде Docker Compose стало непосильной задачей. Kubernetes дал возможность централизованно управлять всеми сервисами через единый интерфейс.

Как проходил переход:

1. Перенос приложений.

Мигрировали все сервисы в Kubernetes-кластер. Настроили StatefulSet для баз данных и Deployment для stateless-сервисов.

2. Адаптация CI/CD.

Существующие пайплайны (ранее заточенные под Docker Compose) перестроили под Kubernetes-деплой. Добавили динамические окружения для тестирования: каждое изменение в коде автоматически разворачивалось в изолированном dev-окружении.

3. Результат.

Клиенты Piklema перестали сталкиваться с простоями из-за сбоев в инфраструктуре, а разработчики получили инструменты для быстрого внедрения новых фич.

Следующим шагом стало внедрение систем мониторинг�� и безопасности, которые закрепили достигнутую стабильность.

Стабильность и контроль: как мы исключили простои и защитили данные

Проблема

До внедрения решений команда Pikleма узнавала о проблемах (например, нехватке CPU или места на диске) только после жалоб клиентов.

Наши решения

Мониторинг и алерты:

Внедрили Prometheus для сбора метрик и Grafana для визуализации данных. Настроили алерты через встроенную систему Grafana, чтобы команда Piklema получала уведомления о критических событиях: нехватке дискового пространства, высокой загрузке CPU или памяти.

Скрипт тестирования CPU
Скрипт тестирования CPU

Централизованный мониторинг для заказчиков

Клиенты Piklema получили доступ к дашбордам Grafana, где видят статус своих сервисов в режиме реального времени. Это повысило прозрачность и сократило количество запросов в поддержку.

Удобство управления секретами через Hashicorp Vault

Внедрили Vault для централизованного хранения секретов. Теперь:

  • изменения вносятся через UI — не нужно пересобирать приложения или лезть на сервер (реализовано посредством CRD ресурса VaultStaticSecret который умеет перезапускать деплойменты при изменении секрета);

  • интеграция с Kubernetes позволяет приложениям автоматически запрашивать секреты при запуске.

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

Единая система для всех: как мы адаптировали инфраструктуру под требования заказчиков

Piklema работает с клиентами, чьи IT-контуры требуют строгого соблюдения политик безопасности. Например, доступ к их Kubernetes-кластерам извне часто запрещен. Чтобы обеспечить доставку обновлений с учетом этих особенностей, мы реализовали гибридный подход на базе GitOps и ArgoCD.

Этапы внедрения

1. Установка Kubernetes на VM в контурах двух заказчиков.

Развернули изолированные кластеры Kubernetes непосредственно в инфраструктуре клиентов. Для этого использовали упрощенные Ansible-плейбуки, которые упростили процесс по сравнению с традиционными решениями вроде Kubespray (поделимся ими в будущих статьях).

Настроили сетевую интеграцию и подключили сбор метрик в облачную инфраструктуру через Prometheus Remote Write, чтобы Piklema могла управлять приложениями через GitLab, не требуя прямого доступа к кластерам.

2. Развертывание 20+ приложений через ArgoCD

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

Пример утилиты для автоматизации объединения kube-конфигов
Пример утилиты для автоматизации объединения kube-конфигов

3. Деплой 15 приложений в Openshift у другого заказчика

Адаптировали конфигурации под требования Openshift, включая настройку Security Context Constraints. Сохранили единый подход управления через ArgoCD, чтобы команда Piklema ��е переучивалась под новую платформу.

Клиенты Piklema получили автоматические обновления без риска нарушения политик безопасности. Время на деплой сократилось, а частота ошибок из-за «человеческого фактора» снизилась.

Отзыв клиента и выводы

Цитата от Константина Гопа (TeamLead ML Piklema) – ключевые достижения.

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

Заключение

Сотрудничество с Piklema Predictive показало, что даже сложные задачи — частые миграции между облаками, переход на Kubernetes и интеграция с изолированными контурами заказчиков — можно решать системно. Главное преимущество нашего подхода — гибкость. Мы не просто автоматизируем процессы, а создаем инфраструктуру, которая адаптируется под изменения бизнеса: смену грантов, новые требования клиентов или рост нагрузки.

Бонусы