Как мы помогли Piklema Predictive создать надежную и масштабируемую IT-инфраструктуру

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. Это позволило клиенту оставаться в рамках бюджета, не теряя доступность сервисов.

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

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

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

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

4. Настройка 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

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

Клиенты 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-конфигов

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

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

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

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

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

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

Заключение

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

Бонусы

• Скрипт для теста производительности CPU → https://github.com/the-avant-it/Common.Scripts/tree/master/cpu-speed-test

• Скрипт для теста производительности диска → https://github.com/the-avant-it/Common.Scripts/blob/master/disk-speed-test/fio

• Скрипт для бекапа и рестора Hashicorp Vault (можно использовать для переноса данных) → https://github.com/the-avant-it/Common.Scripts/tree/master/vault-backup

• Утилита для мержинга кубконфига → https://github.com/the-avant-it/Common.Scripts/tree/master/add-kubeconfig