Что произошло с коммерческим облаком в России: год роста, ошибок и болезненных выводов
Год назад мы рассказывали о запуске коммерческого облака, которое хотели сделать быстрым, понятным и лишённым привычной корпоративной инерции. Тогда у нас были амбиции, компактная команда и уверенность, что главное - просто собрать хороший продукт и открыть к нему доступ.
Затем мы почти исчезли из публичного поля. Не потому, что проект остановился, а ровно наоборот: работы оказалось слишком много. Корпоративные заказы неожиданно стали значительно крупнее и выгоднее розничного облака, а поток задач вырос настолько, что на статьи, презентации и регулярные отчёты попросту не оставалось времени.
За этот период мы прошли путь от стартапа, находящегося в бета-тестировании, до полноценного IaaS-провайдера. Успели выпустить искусственный интеллект в рабочую среду, закрыть отдел продаж, едва не создать серьёзные проблемы для дата-центра, снова доверить ИИ боевые задачи и запустить новый раунд бонусов для пользователей.
Официальный запуск состоялся 26 декабря 2025 года. Пока большинство людей отдыхало после праздников, мы разбирали обращения в техническую поддержку. Особенно запомнился вопрос: кто вообще разворачивает виртуальные машины и пишет тикеты первого января?
После беты началась настоящая эксплуатация
В тестовом режиме пользователи готовы мириться с отдельными сбоями и недоработками. В промышленной эксплуатации требования меняются: любая ошибка влияет на реальные сервисы, а каждое изменение приходится проверять значительно тщательнее.
В январе стало понятно, что одного интерфейса и базовой документации недостаточно. Пользователи впервые сталкивались с облачной инфраструктурой и задавали вопросы самого разного уровня: от неправильно загруженного SSH-ключа и нулевого баланса до проблем с загрузкой операционной системы через консоль и расследования возможного взлома виртуальной машины.
Почти весь L2-саппорт в тот период закрывал один человек - просто потому, что доступ к боевым серверам был сосредоточен у него. Изначально команда состояла из десяти сотрудников. Позже она увеличилась до двадцати, но даже этого было недостаточно, чтобы полностью избавиться от режима постоянного реагирования на инциденты.
Параллельно приходилось расширять справочный центр, переносить функции из бэкенда в пользовательскую панель, исправлять сценарии создания ресурсов и объяснять пользователям то, что в идеальном продукте должно быть очевидно без помощи инженера.
Инцидент с приватными базами данных
Первый крупный сбой возник при переводе Managed Database из публичной сети в изолированную приватную среду. На словах задача выглядела несложно: изменить сетевую конфигурацию и добавить несколько правил доступа.
Однако внутри платформы используется не классический Kubernetes с простыми пространствами имён, а Kube-OVN - сложная система сетевой изоляции. Она жёстко отделяет тенантские подсети и не позволяет трафику самопроизвольно выходить за их пределы. При этом оператор баз данных должен иметь доступ к подам, чтобы управлять жизненным циклом экземпляров.
Поэтому требовалось открыть только строго определённый тип трафика, не разрушив изоляцию и не создав лишних каналов доступа. Архитектурное решение мы нашли, но проблема возникла в автоматизации миграции.
Исторически в системе существовали две версии ресурсов. Новые объекты успешно переехали на обновлённую схему, а около десяти старых баз, созданных по первой версии, оказались недоступны. Пользователи начали сообщать, что их рабочие базы перестали отвечать.
Инженерам пришлось вручную исправлять конфигурацию каждого затронутого тенанта. Работы завершили быстро, а суммарно за год за пределы SLA не вышли, но этот случай показал: миграционные сценарии нельзя проверять только на актуальной структуре данных. Старые версии ресурсов должны быть полноценной частью тестового стенда.
Массовое развёртывание виртуальных машин и исчерпание IP-адресов
Второй серьёзный инцидент произошёл во время партнёрства с образовательным проектом по AI-разработке. На интенсив одновременно пришло много студентов, которым нужно было массово создавать виртуальные машины.
В этот момент Kube-OVN некорректно обработал освобождение адресов. Счётчик IPAM зациклился, и адреса перестали вовремя возвращаться в пул. Подсеть примерно на тысячу адресов быстро оказалась полностью занятой, хотя фактически работающих машин было меньше.
Пользователи нажимали кнопку создания виртуальной машины и получали отказ из-за отсутствия свободного IP. На исправление оставалось около полутора часов. За это время команда объединила четыре небольшие подсети в одну, анонсировала новый диапазон, настроила маршрутизацию через две публичные сети и написала временные скрипты, чтобы новые пользователи автоматически попадали в обновлённую подсеть.
Самым важным результатом стало то, что тенантская изоляция сохранилась. Несмотря на авральные изменения, чужие сети не пересеклись, а SLA не пострадал.
ИИ в продакшене: полезный инструмент, но не замена контролю
За год мы несколько раз пытались встроить ИИ в производственные процессы. Он помогал писать код, разбирать логи, готовить конфигурации и ускорять рутинные операции. Но практика быстро показала: автоматическая генерация решений особенно опасна там, где ошибка может повлиять на сеть, хранилище или доступность виртуальных машин.
Главная проблема не в том, что модель "плохо пишет код". Она может предложить технически правдоподобное решение, которое не учитывает внутренние ограничения конкретной инфраструктуры. Поэтому все изменения, связанные с боевой средой, должны проходить проверку человеком, тестирование на копии окружения и контролируемое внедрение.
В результате мы оставили ИИ там, где он действительно экономит время: в подготовке черновиков, анализе типовых инцидентов, поиске аномалий и генерации вспомогательных скриптов. А финальное решение и допуск к продакшену остались за инженерами.
Почему мы отказались от классической модели продаж
Со временем стало понятно, что корпоративные клиенты приходят не только за виртуальными машинами. Им нужны миграция, консультации, индивидуальные сетевые схемы, гарантии, помощь с безопасностью и сопровождение.
Для небольшого провайдера это одновременно возможность и риск. Крупный контракт способен заметно ускорить рост, но также может перетянуть внимание команды с развития массового продукта на индивидуальные требования одного заказчика.
Поэтому мы пересмотрели подход к продажам. Вместо масштабирования большого отдела сделали ставку на продукт, техническую поддержку и понятные условия подключения. Такой путь сложнее в краткосрочной перспективе, зато снижает зависимость от обещаний менеджеров и помогает строить сервис вокруг реально востребованных функций.
Что меняется в облаке сейчас
В ближайшее время мы продолжаем улучшать панель управления, расширять набор Managed-сервисов и сокращать количество операций, для которых пользователю требуется обращаться в поддержку. Отдельное внимание уделяем сетям, резервному копированию, мониторингу и диагностике инцидентов.
Также меняется процесс релизов. Новые возможности сначала попадают в изолированные окружения, затем проходят нагрузочные проверки и только после этого включаются для ограниченной группы пользователей. Для инфраструктурного продукта такая осторожность важнее скорости публикации красивого анонса.
Мы не считаем прошедший год безошибочным. Наоборот, он показал, сколько скрытых сложностей появляется после выхода из беты: старые конфигурации, редкие сетевые сценарии, неожиданные пики нагрузки, человеческий фактор и несовершенство автоматизации.
Но именно эти ситуации помогли превратить набор технологий в работающий облачный сервис. Сейчас у нас больше опыта, шире команда, понятнее процессы и гораздо меньше иллюзий. А для пользователей это означает главное: облако стало устойчивее, прозрачнее и лучше подготовлено к реальной нагрузке.
