Серверы для CI/CD-пайплайна в команде разработки

Продуктовая IT-компания в Санкт-Петербурге разрабатывала SaaS-платформу для управления корпоративными финансами. Команда выросла с 18 до 40 инженеров за полтора года, объём кодовой базы удвоился, а число микросервисов достигло 34. Сборочный пайплайн работал на облачных GitLab-runner'ах: каждая ветка при пуше запускала полный пайплайн из 8 стадий — сборка, линт, юнит-тесты, интеграционные тесты, Docker-образ, security-scan, деплой в staging и smoke-тесты. Параллельных пайплайнов в пиковые часы набиралось 28–32.

Ежемесячный счёт за вычисления в облаке достиг 380 000 руб. Финансовый директор поставил задачу: обосновать или снизить эту статью расходов. CTO провёл анализ и пришёл к выводу, что собственные серверы окупятся менее чем за год при сохранении или улучшении текущих показателей скорости сборки.

Перенести CI/CD-инфраструктуру на собственные bare-metal серверы, сохранить или улучшить текущее среднее время пайплайна — 12 минут — и окупить инвестиции не позже чем через год. Бюджет — 2,5 млн руб. с НДС. Серверы должны разместиться в небольшом серверном шкафу в офисе: настенная стойка 12U в серверной комнате бизнес-центра. Всё оборудование — по счёту с НДС как юрлицо на ОСНО.

Офис в бизнес-центре класса B: выделенная электрическая мощность — 6 кВт на серверный шкаф. Три сервера вместе должны были укладываться в этот лимит. Настенная стойка — единственный доступный вариант размещения: стойка должна была занять не более 12U. Дополнительное требование CTO: дисковая подсистема должна быть NVMe, а не SATA, — слишком много времени сборочный процесс тратил на I/O операции с контейнерными слоями.

Три однорядных двухпроцессорных сервера с 512 ГБ RAM каждый — достаточно для 40+ параллельных контейнеров при пиковой нагрузке. Ключевое решение для производительности — NVMe SSD PCIe Gen4: скорость последовательного чтения 7 ГБ/с против 550 МБ/с у SATA SSD снижала время pull и push Docker-слоёв в 10 раз. RAID-контроллеры в режиме HBA (pass-through) передавали полный контроль над NVMe дисками ОС — без накладных расходов прошивки RAID. 10GbE-коммутатор связывал серверы между собой и с продакшн-сетью через VLAN-изоляцию: трафик сборки физически отделён от пользовательского трафика платформы. Два ИБП 1500 ВА питали серверы независимыми парами — при отказе одного ИБП половина мощностей сохранялась.

• Вычисление: 3× сервер 1U, 2× Intel Xeon Gold, 512 ГБ RAM ECC DDR5
• Хранение: 6× NVMe SSD 3,84 ТБ PCIe Gen4 (по 2 на сервер), 3× HBA pass-through
• Сеть: 1× 10GbE SFP+ коммутатор 24 порта с VLAN
• Питание: 2× ИБП 1500 ВА Smart-UPS
• Размещение: настенная стойка 12U, 4× органайзер 1U, кабель-каналы

День 1: онлайн-заявка, согласование конфигурации — CTO уточнил требования по CUDA и VLAN. День 2: выставление счёта. День 3: оплата. День 4–8: комплектация, POST-тест каждого сервера под нагрузкой 24 часа, измерение потребления (результат — 1,4 кВт на сервер, итого 4,2 кВт — в рамках лимита). День 9: доставка курьером в Санкт-Петербург с подъёмом на этаж.

После миграции GitLab-runner'ов на собственные серверы среднее время пайплайна сократилось с 12 до 7 минут — ускорение за счёт NVMe дало 41% экономии времени только на дисковых операциях. Ежемесячный счёт за облако упал с 380 000 до 42 000 руб.: остались только edge-агенты и несколько специфичных задач с GPU, которые экономически невыгодно переносить на собственное железо. Инвестиции в 2 350 000 руб. окупились за 7 месяцев. За 11 месяцев наблюдения серверы работали без единого аппаратного сбоя.

CTO нашёл ВИСТЛАН по запросу «серверное оборудование оптом по счёту» и оценил скорость реакции: коммерческое предложение с тремя вариантами конфигурации пришло через 40 минут после заявки. Конкуренты отвечали на следующий день. Тест под нагрузкой на стенде с измерением потребления снял все вопросы о вписывании в электрический лимит офиса.

После установки сборочных runner'ов GitLab на новые серверы инженерная команда провела дополнительную оптимизацию. Docker daemon был перенастроен для использования NVMe как основного хранилища слоёв образов (overlay2 на NVMe вместо tmpfs). Кеш сборочных зависимостей Maven и npm вынесен на отдельный NVMe-раздел и шарится между runner'ами через NFS внутри серверной стойки по 10GbE — latency менее 0,5 мс, что практически не отличается от локального доступа.

Реализована multi-node конфигурация: три сервера объединены в пул runner'ов с метками. Тяжёлые интеграционные тесты запускаются только на серверах с тегом «high-mem» — это позволяет распределять нагрузку по типу задачи. Лёгкие линт-задачи разбегаются по всем трём серверам равномерно.

Через два месяца работы CTO провёл повторный анализ стоимости. Фактические расходы на эксплуатацию (электричество, место в стойке) составили около 12 000 руб./мес. Итоговая совокупная стоимость владения за год: 2 350 000 + 12 × 12 000 = 2 494 000 руб. против 380 000 × 12 = 4 560 000 руб. в облаке. Разница — более 2 млн руб. в год. Решение оказалось ещё более выгодным, чем планировалось изначально.

При росте команды до 60 инженеров и увеличении параллельных пайплайнов до 50+ достаточно добавить четвёртый аналогичный сервер: тот же тип, тот же формат, тот же NVMe. 10GbE-коммутатор имеет 18 свободных портов. Инвестиция в четвёртый сервер — около 650 000 руб., тогда как масштабирование в облаке обошлось бы в 95 000 руб./мес. дополнительно. Окупаемость четвёртого сервера — 7 месяцев.

За 11 месяцев эксплуатации произошёл один инцидент: на второй месяц работы один из NVMe-дисков показал ошибки SMART (нарастающий счётчик reallocated sectors). IT-инженер немедленно заменил диск из запаса, приобретённого одновременно с основным заказом. Вся операция заняла 15 минут без какого-либо прерывания работы runner'ов — данные были зеркалированы RAID 1. ВИСТЛАН прислал замену по гарантии в течение 3 рабочих дней. Мониторинг SMART-параметров настроен через Prometheus smartctl exporter: при появлении любого нового предупреждения инженер получает Telegram-уведомление. Это превентивное обнаружение позволило заменить диск до его физического отказа, избежав деградации RAID и снижения производительности.

Оговорка: кейс носит иллюстративный характер. Реальные показатели зависят от конфигурации пайплайна и нагрузки.