← weblog / 2026-06-06-career-path-devops
2026-06-06·careerdevopskubernetesinfrastructurepersonal·7 min read

Восемь лет в инфраструктуре: где я работал, что делал и что из этого вышло

Опубликовано: 2026-06-06

Восемь лет в инфраструктуре. Коротко: начинал с эникея в 2018-м, вырос до мультикластерных Kubernetes-платформ. За это время поработал в российской GDS уровня Amadeus, стартапе по продаже билетов, финтех-крипто-дивизионе и одновременно в двух продуктах travel-tech холдинга. Этот пост — развёрнутая версия: как на самом деле выглядело каждое место, что я там построил и что бы сделал иначе.

Сирена-Тревел — с чего всё началось (2022–2025)

Сирена-Тревел — российская GDS: система, которая обрабатывает инвентарь авиационных мест и транзакции бронирования на всём российском рынке авиаперелётов. Примерно как Amadeus или Sabre, но построенный и эксплуатируемый внутри страны. Когда я пришёл в августе 2022-го, инфраструктурная команда обслуживала 500+ CentOS-ВМ с полиглот-стеком — Java, Python, PHP, .NET, C++. Всё mission-critical, 24/7, миллионы бронирований.

Главный проект — миграция с ВМ на контейнеры. Прошли три поколения: XEN/libvirt → Docker Swarm → Kubernetes. Заняло почти два года — в итоге утилизация ресурсов выросла на 40%, те же нагрузки стали работать на меньшем железе.

CI/CD — второй большой кусок работы. Когда я пришёл, задеплоить что угодно занимало часы: ручной SSH, у каждой команды свои деплой-скрипты, никакой стандартизации. Я поднял пайплайны с нуля для всех кодовых баз в GitLab CI — unit и интеграционные тесты, SonarQube, Trivy, Docker build, Helm deploy. Время деплоя сократилось с часов до менее 10 минут. Добавили promotion gates (dev → staging → prod) и auto-rollback при проваленных health checks. Инциденты из-за плохих деплоев снизились на 65%.

Мониторинг: Prometheus на 500+ нодах, 30+ дашбордов в Grafana, мост на Zabbix для легаси-систем, которые жили до нашего стека. On-call с runbook'ами и обязательными post-mortem'ами. MTTR упал со 120 до 20 минут за два года.

Главная вещь про enterprise-инфраструктуру такого масштаба: быстро двигаться нельзя, и это в основном нормально. Один плохой деплой имеет серьёзные последствия для всей цепочки. Дисциплину вокруг promotion gates, runbook'ов и post-mortem'ов я вынес из Сирены на каждую следующую работу.

Flowerave — строить с нуля (2024–2025)

Параллельно с Сиреной я взял контракт в Flowerave — стартап по продаже билетов. Я был единственным DevOps-инженером. Не было ничего: ни CI, ни Kubernetes, ни мониторинга, ни IaC.

Поднял полный стек в Yandex Cloud через Terraform: VPC, managed PostgreSQL, Redis, S3, DNS. Production Kubernetes-кластер с Nginx Ingress, HPA, сетевыми политиками для изоляции микросервисов — каталог, заказы, платежи, уведомления. Self-hosted GitLab CE. Prometheus + Grafana + ELK + Sentry.

Одно из первых решений — нормальные бэкапы PostgreSQL. Ежедневный полный бэкап в S3 плюс непрерывная архивация WAL — RPO менее часа, RTO менее 30 минут. Никакой магии, просто сделано. За 15 месяцев был один инцидент, где потребовалось восстановление из бэкапа. Всё сработало.

Цифра, которой горжусь: провижнинг инфраструктуры сократился с 3 дней (всё руками) до 30 минут (Terraform). Ноль потерь продакшн-данных за 15 месяцев.

Что понимаешь, будучи единственным DevOps в стартапе: управление скопом. Каждый разработчик хочет observability, zero-downtime деплои, feature flags, канареечные релизы. Всё это можно построить, но тогда ты занимаешься строительством инфраструктуры вместо того, чтобы её поддерживать. Я на многое говорил нет и фокусировался на фундаментальных вещах: бэкапы, мониторинг, возможность откатиться.

MixVel — нормальная платформа (2025–н.в.)

MixVel — частный дивизион внутри холдинга Сирены. Агентский поиск авиабилетов с собственным кодом ГРС. Масштаб другой: высоконагруженный real-time поиск, несколько команд, 6 Kubernetes-кластеров (dev, test, sre, loadgds, demo плюс облачные окружения).

Главное, что я здесь построил, — FluxCD v2 hub-and-spoke GitOps-платформа. Один hub-кластер управляет всеми spoke через зашифрованные kubeconfig в SealedSecrets. Никакого прямого kubectl apply ни в одном окружении — всё идёт через reconciliation FluxCD. Kustomize-структура трёхслойная: base (общее для всего), custom (кастомизация на продукт), per-env patches (минимальные переопределения на окружение). Больше 90% конфигурации общие; патчи на окружение — маленькие дельты.

Data-платформа полностью через FluxCD HelmReleases: Kafka, RabbitMQ, Cassandra, ClickHouse, MongoDB, Redis, MinIO. Провижнинг кластеров автоматизирован через Ansible — k3s, bootstrap Flux, Cilium, тюнинг нод. Новый кластер готов меньше чем за 30 минут.

Инструменты, которые я написал в этой роли:

env-view — FastAPI-дашборд в каждом кластере. Показывает live-состояние ingress, сервисов и подов с HTTP/TCP health checks. Раньше дежурные SSH-шились в кластеры руками. Теперь есть URL. Helm chart.

abot — кастомный Alertmanager webhook receiver с per-team роутингом. Встроенный роутинг Alertmanager мощный, но неудобно расширять под разную логику эскалации на команду. abot — ~300 строк Python, задеплоен как Helm chart везде.

trivy-to-sonarqube — Python CLI, конвертирует вывод Trivy в формат external issues для SonarQube. Позволил показывать security-находки там, где разработчики уже смотрели на качество кода.

Платформенная работа научила тому, что на меньших масштабах не прочувствуешь: цена несогласованности накапливается. Когда 6 кластеров начинают расходиться, отладка кросс-окружённых проблем становится по-настоящему неприятной. Трёхслойный Kustomize и GitOps-enforcement — не лишние накладные расходы. Именно они позволяют вести 6 кластеров без шестикратного роста рутины.

МТС — контракт в финтехе (начало 2026)

С января по апрель 2026-го взял part-time контракт в МТС. Крипто/финтех-дивизион строил блокчейн-платформу для расчётов (VED) и два B2C-продукта для обмена крипты. Ни на что из предыдущего опыта не похоже.

Инфра — MWS (MTS Web Services) с кастомным Terraform-провайдером. Поднял kubeadm-кластеры под каждое окружение: dev / stage / test / prod для VED и B2C, 8 окружений суммарно. Node taints для изоляции блокчейн-нагрузок от B2C-стека.

GitOps — ArgoCD, не FluxCD. Паттерн: argocd app sync + argocd app wait из GitLab CI с таймаутом 15 минут. Библиотека пайплайнов через include: — Kaniko builds, ArgoCD Helm deploy, Trivy с кастомной OPA-политикой на non-root USER, SonarQube, Semgrep. Определения пайплайнов для мульти-окружений генерировались через Jsonnet.

Интересная часть — Ansible: роли для полного жизненного цикла кластера, LVM-тома, iptables, ротация логов, kubeadm, WireGuard VPN для доступа к нодам, провижнинг пользователей на окружение.

Короткий, но насыщенный контракт. Part-time — значит чётко расставлять приоритеты. Всё, что блокировало дев-команды, шло первым.

Red Rose Traveltech — текущее место (2026–н.в.)

Red Rose — дочка MixVel для европейского рынка, B2B корпоративные командировки. Веду инфраструктуру Red Rose и MixVel одновременно — два отдельных продуктовых стека в одной роли.

Стек Red Rose было проще поднять — после MixVel я уже знал, как это делается. Полный IaC в Yandex Cloud через Terraform, CI/CD в GitLab с циклом деплоя меньше 5 минут, Prometheus + Grafana с явными SLO (99.9%+ на core booking APIs).

Что здесь по-другому — операционная автоматизация на n8n. В обоих продуктах строю event-driven ops пайплайны: Grafana alert → Jira-тикет, дайджесты статуса reconciliation FluxCD, Slack-уведомления о деплоях, уведомления об онбординге партнёров, алерты о дрейфе Terraform. Паттерн заменяет ad-hoc скрипты, которые копятся в репозиториях и тихо ломаются при изменении API. n8n-воркфлоу видны, перезапускаемы и тестируемы.

Что бы я сделал иначе

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

GitOps с первого дня. Дисциплина «никакого прямого kubectl apply» кажется лишним усложнением, пока не отлаживаешь кластер, чьё реальное состояние разошлось с репо три недели назад. В MixVel — с первого дня. Дежурства становятся заметно менее мучительными.

Документация как полноценный результат работы. Я начал серьёзно вести runbook'и в Сирене после нескольких post-mortem'ов, где восстановление затягивалось, потому что нужные знания жили в голове у одного человека. Инструмент confluence-publisher, который я написал в MixVel — результат того, что я стал относиться к документации серьёзно: Markdown в git, автосинхронизация в Confluence, те же практики, что и в коде.

Итого

  • 2018–2022: эникей → Linux-сисадмин, с этого всё началось
  • Сирена-Тревел: 3 года, enterprise-масштаб, миграция ВМ→K8s, CI/CD с нуля, on-call, 500+ нод
  • Flowerave: 1.5 года, solo DevOps, стартап с нуля, фундаментальная надёжность
  • MixVel: по сей день, FluxCD hub-and-spoke, 6 кластеров, собственный инструментарий, data-платформа
  • МТС: 4-месячный контракт, kubeadm + ArgoCD + Jsonnet, блокчейн/финтех
  • Red Rose: по сей день параллельно с MixVel, Yandex Cloud, n8n-автоматизация

Восемь лет в сжатом виде: инструменты меняются, проблемы — нет. Плохие деплои, отсутствующие бэкапы, runbook'и, которые никто не ведёт, инфраструктура, которую понимает только один человек. Работа — сделать решение этих проблем скучным.