Рейтинг
0.00

H3LLO CLOUD

2 читателя, 42 топика

Чисто русский переезд в другой дата-центр




У нас на неделе был эпический переезд из Ростелекома в IXcellerate. Кажется, мы обязаны про это рассказать.

Потому что случился просто весь сок того, как работает отечественный рынок:
  • Те, кто ждал подъёма своего облака всё это время — вы ждали СДЭКа, который вёз два патч-корда «день в день».
  • У нас глючили сетевые железки, и мы не знали, в чём дело. Две недели поиска бага закончились тем, что мы перевезли их в другой дата-центр, и там глюк прошёл полностью.
  • Нельзя зайти в ЦОД Ростелекома 21 человеку, потому что 1 человек оформляется охраной 5 минут с записями в бумажный журнал, а через час они просят пересоздать заявку.
  • Если у вас в команде есть белорусы и казах, то их будут проверять 3 дня, прежде чем пустить на стратегический объект, потому что таков SLA безопасников по обмену данными. Но если у вас есть сириец, его пустят сразу (вероятно, потому что обмен данными не налажен).
  • И да, после переезда мы наконец-то обновили бесплатные лимиты, теперь даже не надо пополнять счёт, чтобы их получить.


Бета облака
Мы строим последнее коммерческое облако в России. Есть масштабная бета, в бете много халявных ресурсов, но надо помнить, что, несмотря на 5 автономных зон, геораспределённое хранилище, другие плюшки, в любой момент всё может пойти по звезде. Потому что мы решили поправить какой-то баг на проде (на самом деле нет).

Нашу бету уже ломали коллеги (спасибо большое), ломали тестеры (спасибо большое), нам показывали на проблемы с UI, была куча пожеланий — в общем, постоянно идут работы.

В целом всё началось с желания запуститься как можно быстрее. Поэтому мы развернули нашу бету на самом оптимальном стеке. Демоинсталляция с халявными ресурсами живёт всё ещё не на той же архитектуре, что прод. В ней ещё торчали куски Козистека — уже кубероцентричного, красивого и новомодного, блестящего такого, но с прослойкой для своего, пока ещё сырого API и без физического разделения сетей. Ну и заодно оказалось, что это решение тоже не очень нормально работает. Мы постепенно избавлялись от него итерация за итерацией, но его наследие продолжало нас преследовать.

Параллельно у нас существовало две другие реальности. Первая — это наша основная ветка разработки, где мы строили правильную архитектуру для будущего продакшена. Вторая, и самая продвинутая, — ветка для одного крупного телеком-оператора, которому мы делаем white-label облако. Поскольку там мы разворачивали всё с нуля на их кластере, то многие архитектурные проблемы уже были решены, и эта ветка по своей проработанности ушла далеко вперёд.

Массово посыпались проблемы на бете
То на ровном месте начинали флапать внутренние BGP-сессии с хостов до ToR-коммутаторов. То внезапно отваливалась наша гиперконвергентная дисковая подсистема — поды начинали мигрировать, отваливаться, а хосты «затенялись» (становились tainted) и переставали принимать новые нагрузки. Всё упиралось в один маршрутизатор ядра. Производительность у него была неплохой, оверхед маленький, но стабильность исчезла.

Мы привезли новые железки, и они стали показывать примерно 40–50% от номинальной производительности по пропускаемому трафику. Представьте: у вас 25-гигабитный линк, а он выкачивает от силы треть.

Почему? Расследование в моменте, когда всё вокруг горит, не дало результатов, но копались мы пару недель. В итоге подъехали 100-гигабитные карточки и мы решили не тратить время и просто пересобрать всё на них.

Дальше можно было долго и упорно ловить баги, чинить разваливающуюся сеть и пытаться понять, почему железо не работает. А можно было признать очевидное — архитектура, созданная для демо, исчерпала себя.

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

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

Как переезжать? Был вариант с плавным переносом серверов, частичными переездами, попыткой обеспечить совместимость двух несовместимых кластеров. Это долго, мучительно и чревато новыми, ещё более изощрёнными проблемами.

Если вы любите приключения, рекомендую такой путь.

Но поскольку это бета, а в бете, как известно betta than nothing, мы выбрали путь Безумного Макса и Дороги ярости. Полностью всё вырубить, физически перевезти и собрать с нуля в новом стеке и новом ЦОДе. Да, это означало простой около 2 дней для пользователей беты (как нам казалось вначале). Но так было быстрее и, как оказалось, веселее.

Мы объявили, что берём тайм-аут, и дальше затеяли масштабный тимбилдинг: почти весь офис, включая фаундеров, отправился в Ростелеком паковать серверы.


Место проклятое!
Шаг 1: подаём заявку на проход 21 человека за сутки. Мы такие заявки (правда, на меньшее количество людей) подавали полтора года по одной и той же форме. Перезванивают их сотрудники и говорят:
— Надо заявку переделать!
— А почему?
— Вам надо по-другому название ЦОДа написать, не Nord, а «РТК-Медведково-1», потому что Nord — это слишком прозападно.

Ладно, поменяли. Последний раз же.

Потом за пару часов до времени заезда коллеги внезапно выясняют, что у нас в штате работают белорусы и пара человек из Казахстана. Им вход блокируют.

— Я сотрудник физической безопасности, мне надо на то, чтобы проверить человека из Беларуси, три дня. У вас их тут двое. Ещё из Казахстана двое. Короче, идите на хер, пересоздайте заявку без них.

Интересно, что у нас есть сириец, который такие проверки не триггерил ни в одной заявке.

Ладно, пересоздались без них. Последний раз же.

Наученные прошлым опытом, печатаем серийники для заявки на выезд.

Дальше мы сломали их физический IAM. То есть попыткой зайти разом вся их пропускная система подвисла так нехило, больше чем на час. Потому что каждого они пропускают минут по 5. Записи в бумажный журнальчик делают, паспортные данные какие-то переписывают, забивают, хотя они все в заявке есть. Потом ещё выдают тебе на планшете ту самую инструкцию, которую никто не читает, но вместо галочки — роспись пальцем. Потом это всё в определённый момент просто зависает, ломается. А у них же ещё двое ворот на входе в ЦОД. И, понятно, чтобы не создавать очередь, часть людей уходит на другие ворота, и их логика ломается окончательно.

В итоге оказалось, что пропустить всех надо за 1 час, потому что потом слот активации пропуска заканчивается. Пять человек не попали вообще.

— Заявка закрылась, мы не можем запускать новых людей. Пересоздайте, пожалуйста, заявку на вход!

Ладно, пересоздали. Последний раз же.

Около 14 звонит газель, которая должна была всё это вывозить. Она, как это принято, внезапно ломается. Мы срочно ищем другую. Пересоздаём заявку. Последний раз же.

Дальше выезд из Ростелекома. Это ещё хуже, чем вход новых, ни разу не посещавших людей. На каждый сервак сверяется серийник. И благо, они ушли от той идеи, что мы в заявке должны указывать ещё внутренний учётный номер. Раньше было так: при ввозе они клеили наклейку с номером и в заявку надо было вбивать и его, и серийник железки. Мы с первого же раза сказали, что этой хернёй заниматься не будем, и ни разу её не вбивали. Поэтому все наши заявки проходили прекрасно по серийникам серверов.





Патч-корды — оказывается, это проблема
Заезд в IXcellerate как небо и земля. Мы приехали чуть раньше, чем грузовик, успели выпить кофе и посидеть. Заявка делается просто по списку людей, документы проверяют на входе, без всяких журнальчиков (всё электронное). Проход занял по 20 секунд на человека.

Примерно за 3 часа всё смонтировали — быстрее, чем разбирали в РТК, потому что белорусов пустили.


Но! Для того чтобы в IXcellerate связать наш meet-me-room с новой инсталляцией (она у нас идёт как отдельный контур), понадобилась парочка отдельных патч-кордов. Трассы проложены, кроссы разварены, трансиверы есть. И вот нам, значит, нужен обычный патч-корд, FC — LC-дуплекс.

Заказываем его 30-го, в среду.

На «Всех инструментах» патч-корды были, на них было написано «доставка 1 день», но при добавлении в корзину дата доставки превращалась в 5 августа.

Нашли на Nag.ru. Они такие — «сейчас привезём!» Оплачиваем супернаценку за доставку СДЭКом. Это, кстати, в два раза дороже, чем сами патч-корды, чтобы доставить день в день.

И СДЭК их морозит на хрен.


Прикол в том, что у нас собрано уже всё. Контур заведён, уже всё крутится. Связать его с ядром сети — два, два маленьких патч-корда, и их не хватает!

То есть все, кто ждали нашего облака, имейте в виду, вы ждали два патч-корда, которые мы заказали в трёх разных местах. Мы с коллегами из ЮЛ-Ком уже шутили на предмет купить аппарат для сварки этих патч-кордов и варить их самим. Оказалось, это стандарт рынка. Это боль. Оказалось, что у многих это блокер включения нового клиента. Потому что две недели ждать патч-корды! Что происходит, почему в Москве их дефицит, я не знаю.

СДЭК привёз заказ день в день через 6 дней.


Изменения в архитектуре демоинсталляции
Была архитектура, растянутая на VLAN’ах. Пять физически изолированных сетей (для управления, хранения, публичного трафика и т.д.), которые всё равно терминировались как разные VLAN на одном маршрутизаторе. Мы жили даже в продакшене с MTU 1500 (!), что создавало проблемы для оверлейных сетей и производительности. И не спрашивайте, почему мы не пробовали его увеличить — мы пробовали, но пришлось откатиться. Это мешало построить полноценную оверлейную сеть Kube-OVN и изолировать теннаты друг от друга.

Сейчас полностью перешли на микросервисную архитектуру, выпилив все рудименты. Сеть теперь построена на EVPN VXLAN с физической топологией Dragonfly+. На уровне отдельной группы стоек — Clos (Node, Leaf, Spine), между Спайнами — full-mesh. Там тоже не без сюрпризов, про то, какие грабли поймали, напишем отдельно.

Выкатили API напрямую. Здесь мы вдохновлялись подходом AWS, которые через свой IAM прокачивают до миллиарда запросов. Наш API станет точкой входа для веб-интерфейса, CLI и внешних инструментов типа Terraform’а. То, что вы просили с беты, тоже запустим. Теперь эти доработки делаются ещё быстрее. Будут VPC для объединения машин в разных зонах доступности, Managed Kubernetes, управление DNS-зонами, очереди сообщений (Kafka, RabbitMQ, NATS).



Про бесплатный доступ
Для юрлиц сделали ролевую модель доступа (RBAC) для создания и управления пользователями с разными правами. Корпораты, добро пожаловать! При регистрации юрлица сразу даём 50 тысяч бонусов на 3 месяца.

Для пользователей-физлиц обновили наши бесплатные лимиты. Теперь, чтобы их получить, не нужно пополнять счёт. Мы просто будем холдить небольшую сумму на привязанной карте на несколько дней для верификации пользователя, потом отпускать. Сделали грейды бесплатных ресурсов: если нужен будет быстрый кластер с балансировщиком и расширенной СУБД, уже после пополнения счёта он подключится в бесплатные ресурсы.

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

h3llo.cloud/ru

Где подвох: почему даём две виртуалки бесплатно на год




Мы даём новым пользователям облачного сервиса огромный приветственный лимит. Он настолько щедрый, что щедрее на российском рынке просто нет. Мы проверяли.

Всё совершенно бесплатно на целый год:
  • Две виртуальные машины, у которых 2vCPU и 4 Гигабайта DDR5 у каждой.
  • Managed Postgres (тоже 2vCPU и 4ГБ RAM)
  • Ещё на 40 GB — сетевой диск, который можно по желанию подключать к любой машине.
  • Объектное хранилище на 100 GB.
  • + белый статический IP. V4, конечно.

Никто на российском рынке и среди крупных западных облачных хостингов такого объёма не даёт больше чем на месяц. Собственно, из тех, кого мы нашли, — вообще никто.


Скоро мы планируем прикрутить ещё одну фичу — бесплатный доступ к Kubernetes.
  • Любой желающий сможет три месяца поиграться с простеньким кластером на один мастер-воркер и понять, что за контейнерами — будущее. Ну или бесплатно сойти с ума.
  • А потом получить месяц доступа к продакшен-кластеру. Это полноценный отказоустойчивый кластер, состоящий из трёх–пяти мастер-нод. Тут можно уже развернуться по полной, начать серьёзные продажи, протестировать свои идеи в реальных условиях.

После этого, конечно, бесплатный период закончится. Мы не филантропы, двигающие идею облачного инстанса в массы, мы практичная компания со своей экономической моделью. И, кстати, дешевизной мы не заманиваем: средний чек у нас на уровне тех же Селектела, Яндекса и Сбера.

Мы пришли за вашими деньгами. Но хотим, чтобы вы смогли посмотреть инфраструктуру сами.

Где, собственно, подвох?
Такой большой лимит подходит для того, чтобы вы смогли полноценно поработать с облачным сервисом, ощутить его преимущества. Облачные сервисы мы любим и хотим, чтобы все поняли, насколько они крутые и как с ними нужно работать.

Поэтому построили публичное облако, масштаб которого позволяет решать реальные задачи. Поставили топовые сервера, процессоры Xeon пятого поколения, сети на 400 гигабит, всё это нарезали на виртуальные кусочки и готовы по запросу предоставить клиенту нужную мощность.

Релиз у нас сегодня, если что. До этого тестировали.

И вот эти лимиты: 2 ВЦПУ + 4 ГБ памяти для управляемых баз данных. Они минимум вдвое быстрее тех, что есть сейчас на рынке. Мы протестили.

Это как первая доза бесплатно. Втянетесь в нормальное хорошее облако — будет тяжело съезжать после того, как увидите, насколько оно экономит время в разных местах. И насколько удобно работать с нашим UX, благо мы всё сделали и делаем для того, чтобы экономить ваше время.

Почему две машины? Потому что только так можно поиграть полноценно. Многие берут или дают для теста одну машину. С одной, даже хорошей, вы не наступите на все грабли. Мы даём сразу две, чтобы можно было поднять отказоустойчивую систему.

Важный элемент этой схемы — балансировщик нагрузки. И нет, ящер с картинки наверху не врёт. Балансировщик у нас тоже входит в бесплатный пакет, что обычно встречается только в платных тарифах у других провайдеров.

Всё это для того, чтобы любой пользователь мог сразу и на целый год запустить полноценный продукт. Блог на 10 тысяч посещений, небольшой онлайн-магазин, корпоративный сайт. Это возможность запустить онлайн-проект без покупки железа, без аренды и долгой настройки виртуальных машин.

Мы предоставляем базу данных, так что можно не париться с настройкой Postgres, Mongo или целого кластера, MySQL или ещё чего угодно.

Всё запускается буквально в два клика. И никаких финансовых рисков на старте.

Никакой экономии на хранении: это полноценный прод без деградации. Все диски дублируются трёхкратно, а резервные копии создаются в другой зоне доступности. Даже если один из дата-центров вдруг выйдет из строя, информация останется доступной. Это означает, что ни один сбой не приведёт к потере проекта или базы данных.

Ещё один плюс двух машин — их гораздо легче масштабировать. Если продажи пошли, нагрузка растёт, то к двум можно добавить ещё две, пять, сто… Вся инфраструктура уже готова. И, что немаловажно, это безопасная инфраструктура.

В этом первый подвох: если ваш проект взлетит, то вы захотите масштабироваться. С одной ВМ дальше хотелок дело не пойдёт. С двумя вы сможете всё и сразу — и дадите нам денег.

Вторая история — конечно, со временем, возможно, мы снизим лимиты. Но пока мы можем позволить себе такого рекламного расхода. Машзал со старта облака будет загружен не полностью и не весь, а нагрузка на вычисления — наименьшая часть расходов cash burn. Поэтому, если мы загрузим машзалы хотя бы наполовину бесплатными клиентами с некоторой конверсией (хотя бы 5 %) в рост, это очень быстро приведёт к нашей прибыли. Быстрее, чем другие модели. Мы считали. Мы любим считать и любим теорию игр.

В процессе расчётов мы пришли к выводу, что переподписка, когда один физический ресурс распределяется между несколькими пользователями, может быть эффективной, если тщательно настроить баланс нагрузки. Мы будем использовать её только для бесплатных демохостов, чтобы оптимизировать ресурсы на старте. А для постоянных клиентов ресурсы выделяются индивидуально: так мы исключаем риск, что одновременный высокий спрос приведёт к перегрузке и испортит работу сервиса.

Про белый IP
Надо сказать пару слов про деньги и ограничения законодательства.

У нас простая регистрация: достаточно электронной почты и номера телефона, причём второе — даже не наше требование, а Минцифры. Поэтому легко предположить, что кто-то со второй симки, например, захочет получить вторую пару бесплатных серверов. Или через год зарегистрирует новый аккаунт, чтобы снова сидеть бесплатно.

Есть две системы. Первая — финансовая. Для того чтобы получить бесплатные лимиты, нужно пополнить счёт. Там немного, тысяча рублей минимум, но от спама одноразовыми аккаунтами это защищает. И, что важно, это не плата за бесплатный пакет (как звучит-то!). Эти деньги останутся на счёте, ими можно будет оплачивать дополнительные услуги. А при пополнении на пять тысяч рублей активируется полный набор лимитов, включая белый IP. Это защищает нас от массовых фейковых регистраций: случайный пользователь вряд ли будет заводить десятки аккаунтов и замораживать на них деньги, пусть и небольшие.

Вторая — нейросеть, которую мы уже обучаем (на базе Tensor Flow). Она анализирует контрольные суммы, имена образов и другие параметры, чтобы выявлять повторные регистрации и попытки обойти ограничения. И если кто-то, исчерпав бесплатный лимит, запустится с нового аккаунта, то мы это, вероятно, увидим.

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

Мы сразу же ушли от оверхеда технологий. Помните историю про неповоротливость и уязвимость OpenStack — платформы, на которой сидят почти все российские облака? Так вот: это не про нас. Мы OpenStack попробовали, оценили и сразу отказались, написав в итоге свою платформу на Go с парой ключевых обработок на Scala.

У нас очень продуманная команда, и, вероятно, мы сможем сохранить это преимущество ещё пару лет. Небольшая оптимизированная команда, где каждый на своём месте и эффективно закрывает свой сектор, — одна из причин, по которым мы можем давать такие жирные приветственные лимиты. О других расскажем чуть позже.

Единственная сфера, в которой мы отходим от принципа «один человек — одна задача», — это безопасность. Site Reability Engineering, Network Operation Center и инженеры по безопасности у нас работают в несколько смен, поэтому мониторинг ситуации и техподдержка — круглосуточные. И если заметим подозрительную активность, то не будем сразу отключать клиента, как большинство провайдеров. Попробуем разобраться, свяжемся с самим клиентом. Хотя стопроцентно этого обещать не могу: ландшафт ИБ меняется каждый день. Но постараемся.

Чтобы не ловить детские косяки типа ненастроенного файрволла, у нас есть внешние утилиты «обстукивания». Если, например, у вас открыты небезопасные настройки или база данных без пароля, то мы предупредим об этом.

У нас очень хороший старт на собственных активах (без кредитов). Про старт я подробно рассказывал вот тут, если кратко: была майнинг-ферма — непрофильный актив, который нужно было переоборудовать во что-нибудь более интересное. А майнинг-ферма — это не только доступ к дешёвому электричеству, но и большое количество производительных видеокарт. Располагалось всё это добро далековато от Москвы, в Александрове, так что мы решили заняться облаком. Особенно после того, как побегали по территории с пистолетами, потому что асиков было на миллиард.

Плюс два ЦОДа в Москве в аренде.

Закупили самое новое оборудование. Есть дата-центры мощнее нашего, глобальнее — у Яндекса, например. У нас сейчас стоят процессоры Xeon пятого поколения, как только в продаже появятся шестые — сразу купим. Это серьёзное преимущество: у других облачных сервисов — в среднем третье поколение, а оно в несколько раз слабее. И, что важно, для той же мощности нам нужно меньше физических серверов, а следовательно, и места. Больше вычислений на стойку, а расходы у ЦОДов идут именно на стойку.

Ещё один наш бонус — продуманный цикл жизни железа. Многие другие ЦОДы создавались годами, там огромное количество техники, и разом её заменить… ну, наверное, можно. Но потребуется бюджет, сопоставимый с бюджетом небольшого региона. Это как в авиации: когда выходит новый двигатель, надо менять весь парк. Весь парк менять невозможно, поэтому новые компании эффективнее уже имеющихся. А уже имеющиеся продают самолёты в Африку.

Отработав свой срок в клиентском сегменте — там, где важна производительность, сервер переедет в ванну на другие задачи. Туда, где процессор и память менее важны. За пределы Москвы в ЦОД с более дешёвой стоимостью поддержания стойки на задачи по фактическому потреблению типа инференса. И продолжит приносить пользу, плавая в диэлектрической жидкости. Иммерсионное охлаждение позволяет тратить меньше электричества, а компактная команда из 30 человек делает обслуживание бизнеса дешевле.

Про иммерсию я ещё расскажу отдельно, она прямо очень сильно меняет правила игры. Если у вас ЦОД приспособлен под неё. У нас приспособлен.

Что делать, если придёт большой клиент и надо будет освобождать машзал?

Ничего. Докупим железа. Если придёт условный Озон или Вайлдбериз — мы потянем. Не моментально, не по клику: потребуется докупить оборудования, настроить поддержку. Это не повлияет на бесплатные лимиты.

Но наша ЦА — не такие гиганты, а российский топ-1000. Давайте представим, например, Тануки. У них, кстати, отличные ИТ, если что. Вот 100 таких компаний мы прямо сейчас можем включить по клику, и даже на постоплатной системе. То есть без авансов, без всего, просто приходите, пользуйтесь — по истечении месяца заплатите.

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

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

К лету мы планируем масштабировать бизнес: приедет новое оборудование, которое разместим уже на базе iXcellerate. Когда закончим основные работы, у нас будет достаточно мощностей, чтобы без проблем завести почти любого клиента. Если у других провайдеров ресурсы ограничены — у нас с этим проблем нет. Хотите масштабировать интернет-магазин? Легко. Запускаете крупный корпоративный проект? Потянем. Мы не просто расширяем инфраструктуру, а создаём площадку, где бизнес сможет расти без ограничений.

Вот здесь можно забрать.
limits.h3llo.cloud

Вот в этом подвох. Мы хотим, чтобы вы почувствовали себя неожиданно хорошо и подсели.

Если вдруг вам по какой-то противоестественной причине интересно наблюдать за реалити-шоу «айтишники против всего мира», то вот наш телеграм-канал, в котором рассказы, как мы строим это облако и какие грабли уже нащупали.

Переезжаем в новый ЦОД, где всё будет распределено и отказоустойчиво




BGP — автоматический протокол маршрутизации.

То есть чтобы BGP начал работать, нужно отправить письмо. В 2025 году. Две тысячи. Двадцать. Пять на дворе, леди и джентльмены.

Всё, что мы анонсируем, должно распространяться по интернету, желательно моментально. Понимаете, какая тут зависимость от оператора.

Пару недель назад переключаемся с основного провайдера на резервного. Всё анонсировано корректно, но интернет не работает. Пишем в поддержку — в ответ:

А вы не уведомили нас письменно, что начали анонсировать новые подсети. Поэтому мы их игнорируем.

Сервисы для большинства пользователей работали штатно. Но историю мы запомнили.

Теперь у нас автоматическая балансировка маршрутов по восьми линкам. Переезжаем в новый ЦОД, где всё будет распределено и отказоустойчиво. Надеемся, что письма писать не придётся.

Наши эпические косяки при запуске облака




Мы запускали облако, но сделали много ошибок. Сейчас расскажу про основное.

Если коротко — у нас в какой-то момент было больше двух тысяч человек, примерно половина из которых не понимала, что происходит, и мы не понимали, что происходит, и при этом нам со всех сторон сыпались жалобы. Разные.

Мы давали бесплатные лимиты в облаке, но нам нужно было убедиться, что это не будут абузить. Поэтому мы сделали порог в 1 000 рублей на часть бесплатных ресурсов и порог в 5 000 рублей пополнения счёта — на полную модель.

Вот эти пополнения и вызвали большую часть попоболи.

Баннеры
В статье мы всё подробно расписали про условия акции.
А вот на баннере так сделать нереально. Детали были по ссылке. Написаны.
Люди кликали на классный заголовок, ожидая полностью бесплатного предложения, букв особо не читали, а потом по мере процесса регистрации их перебрасывало на шаг, где выяснялось, что нужно пополнить баланс на 5 000 рублей. Естественно, они приходили к нам в Телегу кричать: «А вы просите, блин! Вот я-то думал, что мне всё бесплатно дадут!»


А вот и нет, совсем бесплатно просто за регистрацию мы, конечно, ничего не дадим. Точнее, могли бы, если бы придумали способ избежать повторных регистраций по кругу. В нашей картине мира пять тысяч рублей — достаточный аргумент, что пользователь добросовестный. Особенно если ему нужно облако.

Конечно же, мы ошибались.

5 000 рублей
По закону нам нужно аутентифицировать любого пользователя хостинга, для этого подходят номер сотового (потому что паспорт — у оператора при выдаче симки), банковский платёж (потому что паспорт — у банка при выдаче карты с чипом, как у симки) или регистрация через Госуслуги (потому что они тоже каким-то чудом создают однозначную связь с паспортом). Прикручивать Госуслуги — квест не для слабонервных. Где купить тысячу сотовых номеров за приемлемые деньги, мы знаем, и это распространённый вид абуза в сфере хостинов в России, поэтому остаётся банк.

Так вот, мы даём год бесплатного использования двух виртуальных машин, еще одну такую же виртуалку — под базу данных, балансировщик, объектное хранилище, место на диске и ещё всякую требуху. И хотим, чтобы там был честный пользователь, который привыкнет к хорошему, в идеале научится мыслить управляемыми сервисами, посмотрит год на нашу стабильность и поймёт, что можно переезжать с коммерческим проектом.

Для такого пользователя 5 000 рублей на баланс — не проблема.

Но!

Нас начали подозревать в том, что всё было ради этих пяти тысяч. Почему? Потому что изначально мы думали, что вернуть их нельзя, а можно только потратить на услуги хостинга.

И вот это по какой-то причине разозлило людей. В целом мы уже догадываемся, по какой: прописать условия возврата действительно было бы справедливо.

Путаница с условиями
Тут была целая история. Изначально у нас было два типа железа — старое и новое. Старое — такое же надёжное, как и новое, только больше, теплее и медленнее. Но за два дня до запуска приехали наши крутейшие серваки с Xeon 6530 и DDR5. Успели всё воткнуть до релиза: сами поработали грузчиками, раскатили всё, что было нужно, подняли сервисы и запустились полностью на них — мощных и свежих.

Поначалу предполагалось, что на старом мы делаем более медленные ВМ и даём их при пополнении счёта на 1 000 рублей — это достаточное подтверждение. Но если хочется иметь две топовые машинки, то надо пополниться на 5 000.

Так вот, проблема с порогами пополнения возникла из-за того, что старое мы просто выкинули из ЦОДа, а вот информация про него где-то осталась. В итоге мы пришли к тому, что вариант с 1 000 рублей убрали. Баннеры проапгрейдили, а часть публикаций — нет.

Последствия не заставили себя ждать. В статье мы всё быстро пофиксили, но к тому моменту уже успели получить две категории пользователей: первые, которые радовались офигенному офферу на 5 000, и вторые, приходившие и требовавшие халяву, которую ожидали, кликнув по баннерам или прочитав старую версию статьи.

Дефицит IP-адресов
В моменте мы буквально чуть не выстрелили себе в ногу с IPv4. У того, у кого мы их берём, как раз непосредственно перед запуском не оказалось нужного количества. Просто в мире всё меньше белых v4, и даже у поставщиков запас на складе иногда заканчивается. Еле выкрутились. Получилось дороже, но зато вовремя.

Оплата в новом окне
Потом — классическая проблема 2020-х: мы сделали переход на страницу оплаты в новом окне. А в новом окне обычно открывается всякое непотребство. И, конечно, «умные» браузеры начали блокировать открытие этих внешних ссылок.

Банк же считал открытие окна событием начала оплаты со всеми вытекающими последствиями, что добавило путаницы в сессиях.

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

Открываю статистику, вижу тысячи оплат, думаю: «Вау, красота, регистрации валят!» А вот и нет: денег меньше, это просто люди не могли понять, куда и как их кидать в экран.

Наверное, стоило видеть моё лицо в тот момент, когда я увидел сводную по данным нашего API, а не банка. Потому что банк в своей статистике все транзакции «в процессе» тоже считал за мясо.

Очень, очень дофига людей
Мы не ждали тысяч обращений за часы, поэтому на второй день внедрили лист ожидания. Пользователь заходил, мы выводили дружелюбное сообщение: «Ты в листе ожидания, как в клубе, но без фейсконтроля. Скоро мы тебя запустим». И реально скоро запускали.

Так вот, там появились ручные случаи, когда люди писали, что фейсконтроль не пускает. На деле это письмо с приглашением уходило в спам.

Письма в спаме у Яндекса
Наши письма с приглашениями и информацией у Яндекса почему-то упорно попадали в спам. Пользователи присылали скрины: «Это письмо попало в папку «Спам» по следующим причинам: в письме — невалидная dkim-подпись».

Вроде мы не совсем конченые, админим не первый год и настроили всё верно. Да и писем у нас мало.

Я, естественно, ради проверки отправляю такое же письмо на гугловскую почту — Google говорит, что все подписи корректные, везде галочки. А Яндекс нашу подпись воспринимать отказывается. Единственный.


В итоге просто принял это как факт, что Яндекс не любит наших заголовков, а может, просто «Hello, Cloud». Не думаю, что они нас вообще хоть как-то заметили как конкурента (хотя мы их считаем основным будущим конкурентом), но само явление странное.

Что сделали для исправления
Править надо было на лету.

Сначала самое горячее — оплаты и лист ожидания. Сделали двухэтапную рассылку. Сначала — подтверждение регистрации, а уже потом — письмо: «Приходи, оплачивай пять тысяч, заноси деньги на баланс и получай вот это, это и это». Со всеми условиями, подробно. Это заработало. Было приятно, когда банк дублировал на почту уведомления об оплатах и они сыпались пачками.

Подробнее объяснили, что именно в бете. Мы подключаем фичи по мере их выхода из тестов. Например, балансировщика мгновенно не обещали, но как будет релиз — сразу. Люди удивлялись, что его нет сразу, и засыпали поддержку вопросами, где его найти.

Вывели все ожидаемые ресурсы в админпанель и показали, что и когда будет в бете. Подробнее написали про это в лендинге, чтобы не ждали сразу.

Повесили дисклеймер: «Дружище, это бета-версия. Здесь всё что угодно может пойти не так. Если есть вопросы, то welcome к нам в группу в Телегу и на почту». Дали прямой контакт в почте (отвечаю я) и Телегу, где отвечает вся команда.

Потом столкнулись с частой ошибкой пользователей. Люди не читали строчку в интерфейсе для подключения по SSH и пытались залогиниться с логином root вместо user. А рутовский доступ у нас везде по дефолту закрыт из соображений безопасности. Объясняли. Сделали строчку заметнее.

По возврату денег и борьбе с абузом посидели, покубатурили и решили: желающим вернуть — вернём. Но если заводить второй аккаунт, то бесплатных лимитов уже не дадим. Процедуру для вывода средств и верификации уже внедрили и протестили.

Смысл этой суммы был в том, чтобы выстроить некий фильтр и не допустить массовой регистрации ради бесплатных ресурсов.

И сейчас делаем интеграцию с Госуслугами, но нервы не выдерживают: для нас это уже ЭРЕБОР. Но надо доделать. Кому-то важно не давать поганым капиталистам ни рубля за демо, поэтому, вероятно, со временем доведём.

Многие регистрировались компаниями, и там бесила предоплата. Сейчас готовим такую механику: в аккаунте будет возможность создать компанию, некую абстракцию, и даже пригласить туда других пользователей. Это будет такой корпоративный аккаунт. К нему можно будет привязать как оплату карточкой постфактум, так и оплату через счёт, подключив ЭДО. Вот как раз для «физиков», если подключить карточку, будут удобны Госуслуги, потому что мы дадим возможность неограниченно уходить в минус (или можно пользоваться балансовой системой на личном аккаунте, чтобы не бояться внезапного масштабирования облака). Для компании подключение юрлица через ЭДО выглядит как вполне такой нормальный фильтр. И таким аккаунтам мы будем начислять, я думаю, тысяч 50 бонусных баллов на несколько месяцев. А бонусный балл в нашей сегодняшней игре равен российскому рублю. Кроме того, хотим перейти на честную постоплатную систему. Месяц пользуешься — потом тебе выставляется счёт. Даже если этот счёт выставлен на карточку, у тебя есть пять дней: можешь, если с чем-то не согласен, даже оспорить. Через пять дней мы просто захолдим сумму на карте, а ещё через пять запроцессим её. Юрлицам же даётся 10 дней — стандартная история. Понятно, что ещё есть период, когда он не оплатил, но мы его пока не блокируем, а только напоминаем. Если совсем долго не оплатил — тогда уже скажем: «Друг, ну всё, хорош это терпеть», всё остановим, но данные сохраним. У нас есть огромное холодное хранилище на два петабайта: туда можно сложить все бэкапы и ещё какое-то время его держать, если, конечно, пользователь не дал прямой команды уничтожать всё сразу при отключении.

Вот такие пироги! Ошибок мы наделали, но двигаемся дальше, учимся и спасибо, что пинаете нас. Добавили кнопку, чтобы послать нас в жопу на корпоративном сайте, прямо на главной, кстати.

Так что, если чем обидели — приходите на наш корпоративный сайт!
h3llo.cloud/ru

Что там с последним коммерческим облаком в России (и как мы лажали этот год)



Коротко итоги за год:
  • Пустили ИИ в прод.
  • Уволили отдел продаж.
  • Чуть не положили дата‑центр.
  • Ещё раз пустили ИИ в прод.

Сейчас ещё один раунд халявы на 4000 рублей в облаке для новых пользователей.

Примерно год назад мы опубликовали статью о том, что запускаем последнее коммерческое облако в РФ. Тогда мы честно рассказывали про наши амбиции, про ненависть к медленному корпоративному подходу и так далее.

А потом на год пропали. Вышли из беты и пропали.

Нас сгубили корпоративные заказы. Они оказались намного более жирными, чем коммерческое облако. И ещё их стало ОЧЕНЬ МНОГО.

Самый простой ответ на вопрос, почему мы ничего не писали: нам было тупо некогда.

Но облако тоже развивалось. За этот год мы прошли путь от стартапа до нормального IaaS‑провайдера.

Официальный старт состоялся 26 декабря 2025, под самый Новый Год. И пока вся страна просыпалась и лечила похмелье, я сидел и отвечал на тикеты в саппорт. Я смотрел в монитор и думал: «Кто вообще эти люди, которые 1 января лезут настраивать виртуалки и писать в поддержку?»

Январь
В январе мы знали, что просто не будет, потому что люди сталкиваются с облаком, и там для них всё новое и непонятное. А справки, которая идеально всё покрывает, ещё нет. Поэтому приходилось сразу писать справку, допиливать интерфейсы, выносить функции с бека в UI‑панель и так далее.

Тикеты были самые разные: от тривиального «ой, я, кажется, криво загрузил SSH‑ключ, проверьте» и «почему у меня нет денег на балансе» до жёсткого траблшутинга на стадии загрузки ОС через консоль и расследования вторжений в машины.

Почти 100% L2-саппорта я тогда закрывал один, просто потому что доступ к боевым серверам был только у меня. Напомню, у нас команда — 10 человек. Мы с тех пор выросли до мегакорпорации в 20 человек, кстати.

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

Февраль: пошли крупные факапы
У нас было два по‑настоящему массовых инцидента, которые затронули больше одного тенанта (клиента).

Инцидент первый. Изначально наши Managed БД жили в публичной сети — у каждой был белый IP. Мы решили дать пользователям возможность прятать базы в изолированную приватную сеть. Со стороны кажется: ну поменяй ты IP, пропиши два Network Policy, делов‑то. Нам так в саппорт и писали: «Вы чё, два полиси настроить не можете?» Хотелось ответить: «Приезжай к нам в офис, подпишем NDA, покажешь на нашем проде, как ты это сделаешь».

Дело в том, что у нас под капотом не классический Kubernetes с простыми неймспейсами. За сеть отвечает суровый зверь — Kube‑OVN. Он изолирует тенантскую подсеть намертво. Трафик за её пределы не выходит вообще. Но базой данных управляет оператор, которому нужен доступ к подам БД для контроля жизненного цикла. Нам пришлось изящно и точечно выпускать наружу конкретную нагрузку, сохраняя абсолютную безопасность.

На бете мы бы, конечно, херанули бы иначе. Но тут уже не бета.

Мы сделали это архитектурно, но споткнулись на автоматизации. Скрипт миграции старых баз на новую архитектуру не учёл, что у нас исторически скопилось две версии созданных ресурсов. Версия 2 (более новая) смигрировала идеально. А вот десяток баз версии 1 сломался. Пользователи начали обрывать тикеты: «База недоступна, у меня там прод!» Пришлось всё бросать и ручками, индивидуально по каждому тенанту, править конфиги. Починили быстро, за пределы SLA в годовом измерении не вышли, но седых волос прибавилось.

Инцидент второй: AI‑кодеры и зацикленный IPAM. Мы запартнерились с одним курсом по AI‑кодингу. К нам на интенсив пришла толпа студентов, которым нужно было массово и одновременно разворачивать виртуалки. И тут наш любимый Kube‑OVN выкинул фокус: его счётчик в IPAM зациклился и перестал вовремя освобождать адреса.

Подсеть на 1000 адресов выжралась моментально. Студенты жмут кнопку создания машины, а им не хватает IP! Нам пришлось прямо в моменте, за полтора часа, склеивать четыре маленькие подсети (/24) в одну большую, анонсировать её, учить Kube‑OVN (который из коробки этого не умеет) маршрутизировать трафик в две разные публичные сети и писать скрипты‑костыли, чтобы новые юзеры падали только в новую подсеть.

Самое крутое в этой истории — тенантская изоляция. SLA не пострадал вообще, потому что ни одна из уже запущенных машин даже не моргнула.

Март: AI Ops и чем это закончилось
Пока я полгода сидел на первой линии поддержки, я методично превращал свой опыт в данные. Я скрупулёзно собирал каждый кейс в отдельный чат с Claude. У меня накопилось около 500 чатов с детальными постмортемами и десяток пошаговых ранбуков (инструкций по починке). В какой‑то момент стало ясно: пора это автоматизировать. Но пускать LLM в прод бесконтрольно — самоубийство.


Правило 32x. Недавно коллеги из энтерпрайза поделились математикой: успешно решённый ИИ‑агентом тикет стоит 10% от стоимости работы человека. А вот неуспешно решённый (когда ИИ галлюцинирует и ломает систему) обходится в 32 раза дороже, чем если бы туда изначально полез человек. Выгоднее вообще не пускать агента, чем пускать его без тормозов.

Поэтому мы создали строгий фильтр и собственный MCP‑сервер. Он дал агенту строгий набор инструментов и обогащённый контекст (RAG). Наш инструмент всеяден: через OpenRouter мы можем подключать и дорогую Claude Opus, и открытую Code Llama. При правильном контексте и жёстких ранбуках даже дешёвая модель решает задачи на уровне толкового мидла.

Как это работает сейчас:
Автопилот: пользователь пишет, что его виртуалка недоступна. Раньше я тратил 30 минут: пинговал, лез в кластер, проверял сеть, логи, ключи. Сейчас агент делает это сам за 1,5 минуты и выдаёт мне саммари: «Снаружи доступно, внутри сеть жива, SSH отвечает, в консоли виден login prompt, проблема на стыке провайдера юзера и ТСПУ».

Привилегированные действия: если для решения проблемы нужно перезапустить под с новыми параметрами, агент проводит диагностику, находит нужный ранбук и выводит мне всплывающее окно: «Разрешаешь выполнить этот экшен?» Я жму «Да».



Сейчас агент съедает почти 55 миллионов токенов в месяц (в пересчёте по API это было бы около $1100, но в рамках подписки обходится в копейки). Этот «безустальный мидл» закрывает 80–90% рутины.

То есть как бы я есть, но мне надо только покивать на то, что выдумал агент в 90% случаев. Ещё в 2% случаев это нечто новое, и он там накосорезил, и это надо исправить, а стоит это х32, то есть получается 64% работы + 10% — 74%. То есть польза от внедрения агента — 26% экономии рабочего времени.



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

Кстати, интересный инсайд: к нам пришёл человек из корпорации с 600 разработчиками. Так вот, они массово AI‑кодят, но тщательно скрывают это от руководства. Потому что в корп‑культуре за использование нейросетей могут наказать. Мы же, команда до 20 человек, благодаря легализованному AI‑кодингу обгоняем эту корпорацию по роадмапу на полтора года.

Продажи, корпораты и перебежчики
В прошлом году мы решили поиграть во взрослый B2B‑бизнес. Наняли крутого Head of Sales и коммерческого директора (на минуточку — бывшего коммерческого директора MTS Cloud). Ребята пришли со своей огромной записной книжкой, пошли по старым связям и вширь открыли шикарную воронку продаж в крупном энтерпрайзе.

А на выходе — ноль.

Я сейчас не про те ситуации, когда заказчик пришёл к нам за машзалом в аренду, поставил что‑то своё и крутит (такого, как я уже говорил, много). А именно про попытки поставить корпоратов в коммерческое облако.

Ни одной закрытой сделки.

Почему? Сработал жёсткий коктейль из стартапных реалий и корпоративной бюрократии. Корпоративные безопасники просто резали нас по формальному скорингу. Уставный капитал мы не раздували, а во всех базах светились с чистым убытком. Почему? Да потому что мы реинвестировали вообще всё и вливали бешеные деньги в закупку железа последнего поколения! Но для СБшника в пиджаке это выглядит как: «Э‑э, ребята, с этими не связываемся».

К концу года мы честно признали поражение на этом поле. Мы попрощались со всем отделом продаж и полностью сменили фокус. Наш B2B‑путь — это не прямые продажи, а партнерская модель через доверенных проводников (DevOps‑студии и системных интеграторов). Если DevOps‑студия, которая ведёт инфраструктуру клиента, скажет: «Съезжаем из Яндекса к этим ребятам», — клиент переедет.

А почему? Потому что мы бьём в главную боль гигантов — наплевательское отношение к клиентам. Один из клиентов, который сейчас рассматривает нас в качестве альтернативы, отгружает БигТех‑Облаку 6,5 миллионов рублей ежемесячно. И в поддержке он для них — никто. Его тикеты просто падают в бэклог. Хочется, чтобы на них реагировали? Ещё 1,5 миллиона в месяц, пожалуйста.

Проблема в том, что у того же Яндекса жесточайший вендор‑лок. Просто откройте их документацию в разделе «Как перенести данные своей виртуальной машины». Там бесконечная простыня текста и целая последовательность шагов с бубном: вот тут постучи, тут попляши, тут за ухом почеши — и так для каждой виртуалки.

Поэтому прямо сейчас мы дописываем автоматизацию этого процесса миграции. В том числе автоматизацию бубна. Мы хотим сделать так, чтобы вытащить инфраструктуру клиента из клетки вендор‑лока корпораций можно было без боли. С VMware, кстати, тоже помогаем соскочить.

Воронка открылась шикарная. На выходе — уже не ноль закрытых сделок )

Ещё халява
Наша старая механика «закинь 5000 рублей и получи год ресурсов» отлично отсекала ботов. Основная проблема была именно с триал‑хантерами, когда пробовали чуть ли не майнить.

Но там надо было доставать и показывать 5000 рублей на баланс (и их можно было потом вернуть в любой момент). Это как капча: показать 5000 рублей робот не может.

На vc.ru уже есть пост от одного обиженного юзера, который возмущался, что мы попросили паспортные данные, чтобы оформить ему возврат аж 6 рублей с баланса. Он там путает тёплое с мягким, мы попросили паспорт, чтобы перевести ему сумму с баланса обратно (все 5к), а не для отмены списания на 6 рублей (которые, конечно, отменили без вопросов). В общем, всё строго по правилам и вбелую.

Сейчас у нас другая механика — проще.

Теперь при регистрации мы даём бонусный демо‑баланс 4000 рублей на один месяц.

Аккаунт надо подтвердить: российский телефон, российская карта. Без этого, увы, по закону нельзя.

Что выкатываем прямо сейчас
Наш базовый IaaS (виртуальные машины, VPC, быстрые диски, S3, балансировщики, Managed PostgreSQL) работает как часы. Managed Kubernetes тоже работает в полный рост — автоскейлинг вверх и вниз, автоапдейт, autoprovisioning PV и load balancer с белым IP. Плюс мы сейчас дотягиваем его до уровня оператора Capability Level 5 (полный автопилот).

Впереди жирные релизы:
  • Serverless‑платформа (preview в конце сентября). Это Serverless Functions, Containers, очереди, Key‑Value БД и API Gateway. Главная фича: масштабирование до нуля. Пока нет запросов — контейнер схлопывается в 0 реплик, и вы не платите за простой. Логи, трейсы и метрики интегрированы из коробки.
  • AI‑платформа (в октябре). Managed inference, GPU‑виртуалки, среда для обучения открытых моделей. Мы делаем свой AI Gateway, который по API на 100% совместим с OpenAI и Anthropic. Чтобы переехать к нам, вам достаточно поменять одну строчку с URL в вашем коде.
  • AI Ops для Managed Kubernetes (октябрь). Тот самый MCP‑сервер, который мы отладили на своей поддержке, мы отдаём пользователям. Ваши SRE‑инженеры получат AI‑агента, который помогает чинить инциденты по вашим ранбукам.
  • SDLC‑платформа (релиз к концу года). Знаете проблему, когда ИИ‑кодер нагенерил кода, уволился, и весь контекст архитектуры (C4, Gherkin) потерялся? Наша платформа хранит весь агентский контекст унифицированно. А ещё она решает новую болезнь индустрии: когда разрабов премируют за использование ИИ, они качают с Гитхаба скрипты, которые гоняют LLM по кругу, просто чтобы сжечь токены для KPI. Наша SDLC считает реальные DORA‑метрики и показывает экономику фичи, включая стоимость потраченных на неё токенов.

Почему мы не боимся спойлерить роадмап?
Резонный вопрос: вдруг Яндекс или Сбер прочитают и скопируют? Не боимся. Показательный пример: в 2022 году от MWS (MTS Cloud) ушёл вендор Canonical, оставив их OpenStack без поддержки. Ребята выбили 7,5 миллиардов рублей инвестиций, наняли 400 человек и пошли пилить облако. В итоге в сентябре прошлого года они выкатили то, что у нас работало ещё в мае. Чтобы нас догнать, конкурентам с их масштабом и текущими обязательствами нужно сначала набить наши шишки и влить миллиарды в инфраструктуру. Можно пробовать )

Почему мы так уверены в своих силах? Во‑первых, по чистой производительности мы обходим гигантов. У того же Яндекса база — это Xeon 2-го и 3-го поколения и память DDR4. У нас — 5-е поколение Xeon и DDR5. В бенчмарках мы быстрее в 2 раза в базе, в 5–7 раз на базах данных и до 10 раз в инференсе.

Про инференс и GPU в целом есть нюансы. Мы ждём поставку GPU‑установок топового уровня — целимся построить кластер в два раза больше Сберовского суперкомпьютера. Но сроки уехали до 20 недель, а поставщики в открытую говорят: «В Китае я продам каждую установку на $200 000 дороже, чем повезу вам в РФ». Цена улетела за миллион долларов за штуку. Притом что себестоимость её ниже 500 тысяч. Это новые реалии, которые рождаются спросом.

А ещё мы активно переселяемся в собственные ЦОДы: с нами по соседству живёт инфраструктура Cloud.ru, X5 и OZON, что делает объект очень лакомой мишенью. Глядя на то, что происходит вокруг, очень не хочется, чтобы нам прилетело «за компанию».

Так что мы вернулись, и мы поехали дальше.

h3llo.cloud

Бизнес в России — это гомерически смешно






Первая тестовая стойка дома, до заезда в ЦОД. Уже после сборки я понял, что держать 35 миллионов рублей в квартире — так себе идея

Когда вы внутри, это, конечно, тяжко, печально и всё такое, но снаружи это всегда смешно.

Мы строим крупное российское облако, наверное, одними из последних в этой стране в ближайшие несколько лет. Потому что начали без заёмных средств до ставки 21% и ещё когда можно было более-менее внятно пройти бюрократию на лицензию.

Про ад с бюрократией я писал вот здесь.

В этом посте, кстати, было про Ростелеком, речь про Даталайн, который им стал в процессе нашего заезда:
Дальше выбор ЦОДа. Один из партнёрских ЦОДов, где мы размещаемся в Москве, — это Ростелеком. Первую стойку нам выделили в моменте: мы направили запрос, нам сказали: «В этом ЦОДе нет, но встаньте вот сюда» и прислали коммерческое предложение на следующий день. Это заняло буквально два письма туда-обратно и пару звонков. А вот предложение на последнюю стойку менеджер отправлял нам уже месяц. Возможно, согласовывал внутри.

Так вот. Через пару часов после публикации мне написал менеджер из Ростелекома и попросил отредактировать материал, чтобы не порочить деловую репутацию компании. Ну и мы согласились, потому что ничего принципиального для нас в этой истории не было и мы в целом больше за дружбу.

Знаете, в эти игры можно играть вдвоём.

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

И да, они собрали внутри себя совещание и сутки думали, что же именно нужно поменять. Мы до сих пор бы обменивались официальными письмами и шли бы им навстречу, если бы не решили оттуда уехать.

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

Наш интернет
Самое первое, что приходит в голову, — это история про провайдера, сапожника без сапог.

Это про наше подключение офиса к интернету.

Мы заехали в бизнес-центр, который принадлежит нашим друзьям. Приехали, посмотрели, всё понравилось. История классическая, как обычно, один провайдер. Просто никто не заморачивался подключать больше в сам БЦ. Собственники были не против завести кого-то ещё, но у них в принципе такой потребности и не было.

У нас потребность была. Начали смотреть предложения, считать, думать.

В это же время мы очень активно строили между двумя ЦОДами свои оптические линии. И внезапно поняли, что дойти и до офиса тоже — вообще не проблема. Закинули вопрос, сколько нам будет стоить по тёмному волокну включиться где-то здесь? Есть оно вообще где-то ближайшее?

Получили очень адекватное такое предложение — прямое включение, скорость любая, всё зависит от той пары трансиверов, которые поставишь на концах. Два волокна TX/RX, то есть одно на приём, одно на передачу.

По ценнику получилось дешевле, чем гигабитный инет в месяц.

Решили, что сейчас поставим 40 и врубим, потом 100 Гбит/с. Удобно же для офиса. Тем более команда быстро растёт.

Начали делать. Всё хорошо, но был один нюанс. Последние 150 метров достроить — надо согласовывать с собственником здания, через которое проходит как раз от ближайшего колодца трасса. У нас что с одного ввода люка, что с другого стоят жилые дома. В подвале этих жилых домов лежит трасса МГТС, в которой лежит оптика ШПД. Но когда вы ведёте там свою жилу, это становится не вопросом ШПД для дома, а отдельным проектом.

Прокинуть оптику — дело 2–3 дней. А вот этап согласования с собственником занял почти четыре месяца, из которых три он всячески пытался набить цену.

Собственник должен просто сказать: «Разрешаю, согласовываю». Подписать на плане, что согласовано, и, пожалуйста. Председатель ТСЖ, через которого предполагалось, что всё это идёт, хотел за это денег. От председателя надо получить документ, что трасса прокладки через подвал согласована. Она там уже по факту лежит и оказывает услуги дому. Казалось бы, надо как-то через неё класться. Но всё равно нужна его подпись. В этот момент мужик понял, что настал его звёздный час, и решил не упускать свой лучший шанс в жизни стрясти денег с коммерсов. Правда, он не знал, сколько именно трясти. А через помощника сигналил, что коммерческое предложение пришлите: сколько это, как это. Всё боялся продешевить. Непонятно же, сколько это стоит — 50 метров кабеля положить тебе в существующий лоток. Сколько за это взять? Разово? Ежемесячно?

Первые два месяца, пока это делали, мы сидели, как самый крутой провайдер, на мобильных интернетах. Потом получили L2 VPN с последней милей от другого провайдера, офис ожил.

А потом после примерно десятой итерации переговоров выяснилось, что председатель ТСЖ вообще не при делах. И его звёздный час прошёл. Подвал, через который всё идёт, давно выкупил другой человек — и он нам всё это очень быстро подписал. Безвозмездно.

Теперь по цене обычного офисного интернета у нас 40 Гбит/с напрямую к ЦОДу с минимальными задержками и без посторонних на пути. Но второй раз в такую игру я играть не хочу. Либо же сразу буду приходить с ультимативным коммерческим предложением.

При любой прокладке кабеля такая потенциальная проблема всегда присутствует. Поэтому когда мы брали собственный ЦОД, заодно купили ещё участок земли по дороге от электростанции — как раз на такой случай. В общих затратах на инфраструктуру он почти бесплатный.

Теперь представьте тех людей, которые строят трассу длиной не 150 метров, а 120 километров. И через сколько собственников она проходит. Сразу вспоминаются все эти жилые дома посреди скоростной трассы и прочие радости жизни.

Виртуализация туалета
Для офиса мы сняли почти весь этаж. Почти — потому что у нас только один сосед на этаже. Давно сидят в бизнес-центре, проверенные спокойные люди. У них там работает несколько человек, по нашей оценке, 4, плюс-минус 2.

И вот они с чего-то решили поделить территорию общего пользования, а конкретно туалеты.

Просто взяли и закрыли себе одну из двух кабинок туалетов.

Врезали в дверь замок и сделали выделенный персональный туалет.

К этому моменту у нас было уже под два десятка человек. А два десятка человек во вторую кабинку помещается не всегда.

Грубо говоря, их туалет dedicated, а у нас адская переподписка. Зашли на чай к собственникам бизнес-центра, они сильно удивились, и через 20 минут работы АХО, замок исчез. Всё, казалось бы, хорошо, я думал на этом и закончилось. Так нет, их учредитель пришёл к нам за эти туалеты качать права. Казалось бы, уже 25-й год на дворе, а кто-то додумывается поделить кабинки туалета. К счастью, быстро объяснили про общие права доступа.

Собеседования
Самое главное требование у нас — работа только из офиса, удалёнка невозможна. При этом у нас нет строгого расписания — кто-то приходит позже, кому как удобно. Отбор у нас идёт через два фильтра. Сначала с кандидатом обсуждают базовые условия, знакомятся. Потом проверяют технические навыки. И только после этого человек попадает ко мне на финальное интервью.

Как-то к нам пришёл парень, который назвался middle+ фронтендером. Когда он начал рассказывать о своём опыте, выяснилось, что на сайте одной крупной букмекерской конторы он просто вручную обновляет информацию о матчах.

— Я беру шаблон, копирую, вставляю весь контент в реактовские компоненты руками и загружаю на сайт.

Я осторожно выдохнул и спросил опытного middle+ про концепцию DRY (Don't repeat yourself) и как он применяет её в работе.

— DR что?

Я объяснил. На что кандидат просто сказал: «Нет, сдаюсь» и вышел с собеседования.

Сразу скажу, что место немного холиварное, потому что DRY не всегда однозначно хорошо — где-то вступает в противоречие с KISS. Но это, по крайней мере, можно обсудить. Да и реактовские компоненты сами по себе подразумевают DRY — ты определяешь компонент один раз, а потом просто вызываешь его с разными параметрами.

А где он руками копипастил — это крупная контора, реально на слуху у всех. В каждый видеоролик свою рекламу пихает и такой подход к разработке сайта. Я офигел, конечно, что там до сих пор не слышали про CMS.

Вторая история с собеседования была ещё веселее. И вот она уже заставила надолго задуматься.

Два Scala-разработчика. Забегая вперёд, скажу, что в итоге-то мы столкнулись с очень большими проблемами с набором Scala-команды и после выхода Sonnet 3.6 переключили часть компонентов на Go, но про это чуть позже. А Sonnet 3.7 вообще поставил точку в вопросе.

Но вот собеседование. Откликов совсем немного. Scala-разработчики — это нечто очень экзотическое, днём с огнём не найдёшь.

Пришёл, значит, к нам первый кандидат нормальный такой. Пообщались, всё понравилось, пригласили в офис. Дали небольшое тестовое задание — спецификацию OpenAPI с описанием эндпоинтов REST API для веб-сервера. Говорю: «Подними. Стек любой. Инструментарий любой. Как тебе удобно, так и делай. Главное — без нейронок». Мы же скил оцениваем. Так-то мы за LLM. Дали всё, что он попросил. Отошёл заварить кофе. Возвращаюсь. Он:

— Вот. Готово.

Я не понял.

Смотрю — действительно готово.

У него был свой фреймворк написанный, который берёт спеку OpenAPI и поднимает веб-сервер. Он просто несколько строчек кода имплементировал во внутреннюю логику к каждому методу, а всё остальное за него делал фреймворк. Потому что задача встречается не первый раз. Классная вещь. Я прям воодушевился: 10 минут и выполнен рабочий веб-сервер. Но денег этот кандидат хотел прям очень много. Мы ещё поговорили и решили, что надо подумать, потому что один такой человек с правильными инструментами заменяет целый отдел. А с нейросетками, возможно, два.

В этот момент пришёл другой кандидат. Такой дядечка уже в возрасте. Отметился в крупном банке. Всё хорошо рассказывает, дали то же самое задание. Он открыл Vim вместо IDE и начал быстро набирать пятую сонату код.

Спустя полтора часа на Play! Framework эта штука еле-еле завелась и выдавала один работающий метод. Не микросервис, а именно один метод. Без логики.

Контраст, конечно, был очевиден.

Денег он запросил столько же много. А за сакральное знание, как выйти из Vim, мы столько платить не готовы.

В итоге после всех обдумываний перешли на Go. Scala закрывает исключительно тот кусочек, который прям вообще не вариант ни на чём другом сделать, и в команде есть люди, которые с ней работают, в том числе я.

Ещё одна интересная особенность в том, что современные LLM обучены очень хорошо кодить на Go, но очень плохо на Scala, и использовать их возможности просто не выйдет. Возможно, выборка была не очень большая. Мы надеялись на o1 и R1, но тоже нет. В общем, Go. Там и проблем с разработчиками нет.

Третья история с собеседований — аналитики ИБ. Руководитель по ИБ в компании должен завестись сам, потому что публиковать вакансию всё равно не выйдет со всеми деталями. Да и на рынке специалистов по ИБ нет от слова «совсем». Как и самого ИБ в малом и среднем бизнесе.

Мы всё же взялись строить SOC и более-менее открыто прописали, что делать и как. И начался поток людей, которые умеют поднимать файрвол на роутере. И это потолок их навыков. До строки квалификационных требований про спокойствие так и не дошли. А спокойным надо быть.

Специфика бизнеса — в том числе не допустить открытия канала к ОРМ. Мы, как хостер, должны определённый формат СОРМ поддерживать. К счастью, мы не должны закупать никакое дорогостоящее железо как телеком-операторы. Но мы должны наружу выставить для них защищённые концы с доступом к определённой информации. Её перечень, структуры и так далее, они все открыты в нормативке. Там 70-страничный документ с описанием GraphQL схемы. Собственно, мы должны её поддерживать и не давать посторонним лицам. Это персональные данные и, в принципе, репутация. Ну и помимо СОРМ есть базовая гигиена ИБ, за которой необходимо следить.

Поиски, кстати, всё ещё продолжаются.

35 миллионов в квартире — плохая идея
Первая наша стойка для MVP, как вы видели выше, была не стойка, а груда серваков, стоящих друг на друге у меня дома. Выглядело зачётно. Светилось как новогодняя ёлка — и был это как раз конец зимы.

У меня несколько розеток отдельных под домашний кинотеатр, акустику и так далее. По идее каждый сервак — блоки питания 800–1400. После включения всё это начинает жужжать адски, как рой дронов. Я думал, что соседи испугаются, что сейчас атака будет.

Потом ёлочка начинает гореть, то есть греться. Естественно, включаешь кондей либо открываешь окно, когда холодно. Дальше можно с этим сидеть, жить, настраивать.

А вот дальше по факту я очень удивился, что вся стойка потребляет как микроволновка. Десяток серваков жрёт меньше, чем чайник. Я до этого привык, что если заявлено три с половиной киловатта на асике или видюхах в риге, значит, оно и будет жрать три с половиной киловатта. Так и есть, в принципе, плюс-минус пять процентов. А здесь, оказывается, ни фига.

Но самое смешное случилось, когда мы это через неделю настроили и повезли уже в ЦОД. Вызвали «Грузовичкоф». Приехала к нам Лада Ларгус и такой типичный водитель Ларгуса, который откуда-то с региона, видимо, приехал на заработки.

Посмотрел он на сервак. Мы ему объяснили, что стоит он дохрена и надо с ним очень аккуратно. Всё шикарно. Он потихонечку их перенёс. Мы помогли, загрузили. Всё это на грузовом лифте по нескольку штук за раз, на подземную парковку, всё уложили. Обмотали, естественно, плёнкой пупырчатой. Коммутаторы упаковали сверху. Всё хорошо.

Выезжаем из паркинга, и он говорит:

— Ребята, а незамерзаечки у вас не будет? У меня что-то закончилась.

Мы ему отдали канистру незамерзайки. Он, значит, что-то залил, а что осталось — положил в багажник.

Уже приехав в ЦОД, мы поняли, мало того, что он её хреново закрыл, он в багажник её кинул прям поверх серверов.

И вся незамерзайка по ним течёт!

Пока я матерился страшными словами, он всё поспешно выгрузил и уехал.

В незамерзайке спирт (этиловый или изопропиловый), что для серверов условно-безопасно. И вода. Вода уже не так безопасна. К счастью, дальше крышки это не протекло. В паре мест капнуло на платы, я протёр, просушил, и всё завелось.

Это были наши первые серваки для Proof-of-Concept. Сейчас эти серваки будут доживать в наших инстансах под CDN, а мы закупаем уже HPE Gen12. Надеюсь, скоро покажу. Их точно сразу в ЦОД и не на Ларгусе.

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

Получилось как с той рисоваркой, для запуска которой нужен админ, Senior-разработчик, тимлид и уборщица.

Садится команда людей, среди которых DevOps опытный, который сам Linux-драйверы низкоуровневые пишет для железа. Тимлид, который поднял десятки проектов руками, до этого много в студии Лебедева отработал и в блокчейн-проекте. Собственно, L1veStack (наш контейнерный хостинг) под его руководством вышел. Другой тимлид (тоже с хорошим опытом за плечами), разработчики и я.

И вот мы логинимся в VK и начинаем делать себе VDI. Прям по кнопке «создать VDI». Перед нами мастер на 7 шагов. Проходим первый экран, и там такая хитрая кнопочка «протестировать, всё ли правильно». Нажимаем. Просто начинает крутиться кругляш, и ничего не происходит.

В ресурсах смотрим — херак, создалась виртуалка. Что-то там крутится, крутится, крутится и не меняется. Минут через пять вместо кругляша появляется галочка, что у нас всё окей.

Но виртуалку он не удаляет. Тарификация на неё капает.

Едем дальше. Дальше сетевые настройки, надо зайти в настройки сети, создать новую сеть. Причём диапазон 24-й ей маловат, ей подавай сразу минимум 22-й — и иди ещё с этим всем разберись и пойми из их описания. Ладно, курим маны и кое-как этот этап проходим.

Начинается третий шаг. Называется «введите данные для домена». И просит разные параметры LDAP. Прикол в том, что выскакивают всякие подсказки с ошибками, что введённая строка не соответствует формату. Проверка прикручена. Но вот авторизации по этим данным нет, и можно вставить чужой домен.

На следующем шаге запуск виртуалки под уже выбранную конфигурацию.

1 рабочий стол, 1 контроллер, минимальные ресурсы.

Запустить виртуалку невозможно, потому что квоты не хватает.

Дальше курим ман, и оказывается, что ни один новый аккаунт это всё запустить не сможет никогда.

Деньги есть, а вот лимиты стоят запрещающие. И иначе как через поддержку, это не решается.

Мы всё это посмотрели и поняли, что вряд ли кто-то эти сценарии проходит легко и хорошо.

Пошли тестить других. На третий день случайно вспомнили про ту виртуалку, которая включилась во время теста, пошли тушить. Тоже непросто, удаление заняло минут 20, потому что её нельзя просто удалить (кнопка тупо заблокирована). Сначала надо удалить все связанные с ней ресурсы — сеть, VDI-группу и так далее. А до этого надо ещё додуматься. Прикинули, сколько таких у других крупных клиентов )

Кстати, вероятно, если вы несколько раз запустите тест, виртуалок тоже будет несколько. Пробовать не стали.

В итоге после трёх дней такого тыкания во все VDI на рынке, мы для себя записали, как должен выглядеть проект. Думали, что клиенты этого не замечают, потому что всё падает на девопсов, — но дошли до знакомых архитекторов с 1200 столами, они посмотрели, увидели фотографии графического кластера в ванной и сказали, что мы первые адекватные, кто заглянул. Хорошо пообщались. Стало многое понятно.

Как покинуть офис
Лучшая история с офисом была, когда мы устроили вечеринку в пятницу с пиццей. Бизнес-центр у нас относительно небольшой, арендаторов не сотни, все уходят около 20–21. Охранник по стандартной привычке закрывает выход из здания и уходит на обход.

У нас корпоратив до 22. Мне понадобилось срочно уехать. Спускаюсь, охранника нет, выход закрыт. Соответственно, наши, кто любит просыпаться в 16 и работать вечером, делятся со мной лайфхаком — надо выйти в окно.

Показали окно. Я и вышел.

Охранник это увидел снаружи, и нам чуть не накрыли корпоратив группой быстрого реагирования. Дальше уже объяснили, что мы, айтишники, дикие люди, и можем не только приехать после завтрака в 17, но и уходить ночью. Больше таких инцидентов не было.

Привет Таймвебу
Ну и чисто хабровская история. Про комментарии к статьям. Буквально недавно столкнулся с тем, как эсэмэмщики работают в лучших традициях.

Вот наш пост про перформанс-тесты. Там есть про этих прекрасных облачных провайдеров, и не очень лестное. Хотя, несмотря на адскую переподписку, по деньгам там всё же довольно интересные условия. Но про переподписку тезисы, видимо, не понравились.

Сначала от них пришёл засланец просто, у которого стояла отметочка в профиле, что он работает в Таймвебе. Он накатал длинную-длинную телегу про то, какое мы говно. Его начали минусовать, спустили до -5. И внезапно попёрли плюсы, причём очень кучно! И это совпало с моментом, когда он отредактировал профиль и убрал, что он работает в Таймвебе. Прям отличная переобувка в воздухе — чудо, человек уволился, чтобы нас прокомментировать.

«Я вам оборудование закину погонять»
Напомню, когда мы только взяли площадку под ЦОД, там были развёрнуты ванны под асики. И ещё контейнеры стояли. И вот один из наших знакомых спрашивает, раз уж мы купили площадку, можно ли поставить своё оборудование.

Соглашаемся, но не проговариваем все детали. А важной деталью была цена этого оборудования, а не только условия аренды нашей площади.

Асиков там было почти на миллиард. Комплект майнера включал в тот момент травматический пистолет, и не один.


Набор майнера

Мы тогда с сооснователем вместе дополнительно дежурили в будущем ЦОДе в нагрузку к росгвардейцам, которые нас охраняли. Потому что места дикие, и если что — росгвардейцы убегут первыми. Потому что вопрос на миллиард и 15 минут погрузочных работ.

Объект мы за первую ночь утыкали камерами с детекцией движения, но детекцию нормально настроить не успели. И камеры реагировали не только на росгвардейцев, но и на птиц. Птицы летали не только снаружи, но и внутри ангара, и сильно чаще, чем я думал. А я на измене, представляю, что кто-то полезет это оборудование вытаскивать.

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

Всё же облаком в России заниматься гораздо спокойнее и предсказуемее.

h3llo.cloud
auth.h3llo.cloud/register

Отреверсили проприетарный gRPC и выложили в опенсорс 100% совместимый аналог их сервера, потом CLI





А вы тоже организуете общение между микросервисами по HTTP/1.1 + JSON? Так вот, адекватные люди на хайлоаде давно так не делают.

Как это выглядит в классическом REST: какой-нибудь сервис заказов стучится в сервис оплаты и отдаёт JSON-файлик: {«user_id»: 123, «amount»: 1000}. Принимающий сервис этот текст читает, парсит, валидирует, переводит в машинный код…

JSON сделан для людей. Человеку удобно читать JSON, потому что это текст. Но серверу для обработки текста приходится тратить драгоценные такты процессора на поиск и разбиение. Ещё классический HTTP тащит за собой гигантские заголовки с метаданными. Часто они весят больше, чем сама полезная нагрузка. Ещё если вы передаете число 123456789, в JSON оно займёт 9 байт (по байту на символ), а в бинарном виде — всего 4 байта.

Гугл ещё в 90-х это посчитал. Они со своими масштабами столкнулись с проблемами за 10 лет до того, как с ними столкнулся весь остальной мир. Для DNS-а в Гугле сделали внутреннюю систему Borg-NS. Они пытались сделать предка gRPC, чтобы решить две фундаментальные проблемы. Во-первых, зоопарк технологий. Когда у тебя тысячи микросервисов — одни на Java, другие на C++, третьи на Python, четвёртые на Go (ладно, этих тогда точно не было) — им нужен единый язык общения. Нужно было запилить стандарт: описали спецификацию интерфейса в одном независимом стиле — и система сама сгенерировала готовый сетевой код для всех нужных языков.

А во-вторых — это как раз производительность обмена.

Поэтому сейчас используется gRPC. И вот когда началась какая-то там по счёту волна санкций, внезапно выяснилось, что в России нет поддержки серверов gRPC.

Не было, пока не появился наш клиент EasyP. Передаю слово Эдгару Сипки — Founder EasyP & Sipki Tech. Он расскажет, зачем и как это сделали.

Зачем это обычным людям?
99% наших пользователей — это бэкендеры, которые строят микросервисы. Бэкенд общается с бэкендом. Да, связывать бэкенд с фронтом, например, с мобилой, тоже можно, это не проблема, но это просто не стандарт рынка. В России, да и вообще во всём мире, я знаю буквально только одну компанию — Uber, кто реально сидел с gRPC на мобилках.

Первый запрос — стандартизация. Объёмы, как у Гугла, есть не у всех, а вот зоопарк — точно у всех. Можно использовать OpenAPI, а можно gRPC. Big Tech (американские Google, Amazon, Microsoft или наши Ozon, WB и Сбер) ещё и экономят на железе. В рамках их гигантских архитектур работают тысячи микросервисов, и в секунду происходят сотни тысяч таких внутренних вызовов.

Чтобы стал понятен масштаб: представьте, что вы открываете приложение, чтобы заказать такси или купить кроссовки. Вы нажимаете всего одну кнопку «Заказать», но под капотом этот единственный клик порождает каскад из 50−100 микросервисных вызовов. Сервис авторизации проверяет токен, сервис геопозиции ищет водителя, биллинг проверяет карту, сервис рекомендаций обновляет вашу ленту, антифрод анализирует паттерн поведения, а пуш-сервис готовит уведомление. И все они общаются между собой. Если на каждом таком шаге сервер будет тратить миллисекунды на открытие новых соединений и парсинг текстовых JSON-ов со скобочками, то на 10 тысяч пользовательских запросов в секунду вы немного охренеете. Гонять тяжёлые текстовые данные со всеми массивными HTTP-заголовками и постоянно их парсить обходится для серверов дорого.

gRPC работает поверх HTTP/2 и использует бинарную сериализацию: данные передаются не как текст, а как архив. HTTP/2 умеет мультиплексировать запросы, он не открывает новое соединение для каждого чиха, а гоняет сотни параллельных запросов по одной уже открытой «трубе». Во-вторых, данные пакуются в бинарный формат. Сервер-отправитель не пишет ключи типа «user_id», он отправляет только числовые теги и сами значения. Сервер-получатель не занимается парсингом текста, он просто считывает смещения в памяти процессора. Это работает куда быстрее.

В итоге это раза в 2−3 дешевле по пропускной способности сети и нагрузке на процессоры. То есть gRPC реально очень сильно экономит деньги на железе (мы говорим про миллионы долларов на закупку и обслуживание серверов), но этот эффект в полной мере ощущается только при огромных объёмах.

Ну и де-факто этот протокол сильно защищённее, там есть ещё ряд бонусов.

Но есть нюанс: с этим протоколом исторически было очень неудобно работать
Когда вы пишете обычный REST-сервер, вам надо как-то объяснить команде одного микросервиса, как работать с микросервисом другой команды. Нужна документация. Если вы когда-нибудь работали с OpenAPI (или Swagger) для REST, то Protobuf (язык описания интерфейсов для gRPC) — это альтернатива OpenAPI, которая просто родилась фактически за 10−15 лет до него.

Protobuf — это строгий контракт. В нём чётко написано: поле номер один — это ID юзера, тип — целое число (int32 user_id = 1;), поле номер два — сумма платежа.

Но в самом ванильном Protobuf нет встроенного линтера! Каждый разработчик мог описать сервисы так, как он захотел. В итоге рождалась классическая катастрофа распределённых систем: разработчики одного микросервиса поменяли контракт и никому об этом не сказали.

Представьте вполне реальную ситуацию на проде: команда сервиса оплаты решает изменить тип поля или удалить поле user_id и молча выкатывает обновление. Или, например, джун в сервисе корзины решает, что сумму заказа лучше передавать не в виде строки «100.50», а в виде целого числа (в копейках — 10050), и меняет это в своём коде. А сервис заказов всё ещё шлёт старый формат. Сервис оплаты получает неожиданный тип данных, не может его прочитать, выкидывает ошибку, и всё падает в рантайме. Платежи не проходят, бизнес теряет миллионы рублей в минуту, а дежурные инженеры в панике ищут, где именно сломалась цепочка из десятков микросервисов.

Чтобы как-то впихнуть эту стихийную разработку в рамки и защититься от таких ошибок, в мире появилось четыре конкурирующих инструмента: один от Uber, один от индусов, один от канадцев и один ещё от кого-то. В итоге в какой-то момент канадский стартап сказал всем остальным троим: «А давайте мы вас всех купим? Давайте вы все станете мной?»

И все стали ими, переложили наработки в единый продукт Buf Build, получили 93 миллиона долларов инвестиций и заняли нишу.

А потом наступает 2023 год
Архитектура российского ИТ-рынка начинает сильно меняться.

У меня это выглядело так: мне надо через пару дней выступать в Сколково на конференции HighLoad с темой работы с gRPC. Доклад о том, насколько этот протокол важен и ценен для бизнеса. Все мои примеры архитектуры и пайплайнов в докладе были построены на Buf Build. Доклад приняли. А потом Buf Build выпускает заявление:

— До свидания. Мы в России блокируем доступ к своим сервисам!

Куратор моего доклада был сотрудником Yadro — это наш гигант, производящий серверное оборудование и железо для ЦОДов. Он был там кластер-лидом, и у него как раз стояла острая рабочая задача в рамках компании: решить проблему того, что инфраструктура Buf перестала собираться в России. Он говорит мне: «Эдгар, а ты сможешь сделать так, чтобы Buf Build заработал в России?»

Ну, потому что невозможно же делать доклад о продукте, который не работает, кому это надо? Я говорю: «Ну, окей, я подумаю».

Я сел и ровно за один месяц просто зареверс-инжинирил их серверную инфраструктуру. Она у них проприетарная, не open source. Я буквально стучался по их API и по крупицам формировал понимание (это было ещё даже до появления мощных нейросетей), как именно это говно у них устроено и почему оно так работает.

Разобравшись в логике, я с нуля создал эмулятор их сервера. В итоге их собственная CLI и кусок клиентской части продукта завелись с моим сервером так, как будто он для них родной.

Всё заработало.

Мы повозились, отладили процессы, показали это решение прямо на конференции, все кайфанули. А потом мы сели и такие: «А зачем нам делать поддержку инструмента, который нас забанил?» Мы по факту сделали костыль. Зачем нам поддерживать чужую экосистему? Давайте сделаем прям свою полноценную замену?

Первыми, кто взял мой сервер, были как раз Yadro и Positive Technologies. В каком-то общем чате инфраструктурщиков ребята написали: «Так и так, кто-то же должен был столкнуться с блокировкой Buf, как решаете?» Им кинули запись моего доклада. Они взяли оттуда продукт, стали активно юзать у себя на больших объёмах, и в итоге столкнулись там с очень специфическими багами.

Чувак, который отвечал за развёртку этой инфраструктуры в Позитиве, искал создателя, то есть меня. Через кого-то ему передали контакт, он мне написал, я ему ответил. А потом я случайно смотрю в Телеграме в общую группу нашего ЖК в Петербурге, и мы такие: «А ты что тут делаешь?» Оказалось, живём буквально в соседних парадных! В тот же вечер мы собрались с кальяном, поштормили и начали делать с ним прям аналог — нашу собственную CLI-ку.

Полноценный dev-tool для разрабов, чтобы им было просто и безопасно работать с Protobuf'ом. Наш продукт — EasyP.

Мы сделали то, зачем крупные энтерпрайзы изначально шли к Buf'у — железобетонную стандартизацию. Используя наш продукт, микросервисная команда получает проверяемый манифест API с понятной документацией, быстрый протокол gRPC под капотом и строгий линтер поверх всего этого.

Как это работает на практике?
Во-первых, наш инструмент — это строгий контролёр. Он заставляет тебя писать контракты по единым правилам компании, чтобы код никуда не вылез за рамки стайлгайдов.

Во-вторых — это пакетный менеджер. Раньше, чтобы сервис уведомлений на Python узнал о новых ручках сервиса заказов на Go, разрабам приходилось руками копировать .proto-файлы или городить костыли с Git-сабмодулями. Мы же сделали элегантный механизм: ты просто указываешь нужную версию контракта, EasyP сам скачивает зависимости из реджистри и фиксирует их в easyp.lock. Дальше ты пишешь easyp generate, и мы внутри изолированных Docker-контейнеров (или через Wasm) сами компилируем нужный код. Больше никакой боли с фразами «а у меня локально всё собиралось» — у всех разработчиков всё генерируется абсолютно идентично.

Но самое главное: на уровне CI/CD (при автоматической сборке кода) наш инструмент проверяет обратную совместимость. Он прямо на этапе пулл-реквеста проанализирует изменения и защитит от фатальных ошибок. Если разраб сервиса заказов случайно удалит поле, а сервис уведомлений всё ещё завязан на него, линтер просто заблокирует деплой и скажет: «Стоп, ты ломаешь обратную совместимость. Все клиенты твоего микросервиса упадут, если ты сейчас замержишь эту ветку».

Ну и наконец — интеграция с IDE. Специально для OpenIDE с поддержкой Go прямо из коробки мы разработали плагин EasyP, который уже сейчас доступен в маркетплейсе для установки. Пишешь в .proto строку import «orders/v1/order.proto» — и IDE сразу знает, откуда эта зависимость тянется по твоему easyp-конфигу. Никаких красных «unresolved import»: работает переход к определению и автокомплит по чужим контрактам, будто они лежат локально. Заодно плагин подтягивает в редактор правила и стандарты EasyP — те самые, по которым потом бьёт линтер на CI.

В 2025 мы выяснили, что стали монополистами в России
Да, продукт нишевый, инфраструктурный, но монопольный. Сервера полностью наши, CLI-ка написана нами. Мы Git-native, то есть никакие корпоративные контракты не улетают на чужие облачные сервера, всё крутится внутри контура компаний. Плюс мы полностью open source под лицензией Apache 2.0.

Долгое время мы специально сохраняли обратную совместимость с CLI-кой от канадского Buf'а, чтобы российским компаниям было легко переезжать. Но этим летом мы выкатим мощную энтерпрайзную версию, зарелизим версию 1.0 (потому что мы всё ещё числимся в бете уже 3 года) и планируем отсечь старое легаси, отказавшись от прямой совместимости с их синтаксисом. Но чтобы никого не бросать, мы сделаем изящную механику: девопсу достаточно будет вызвать одну команду нашей CLI-ки, и она автоматически прочитает старый конфиг Buf'а, переведёт его в наши концепции и бесшовно сгенерирует родной конфиг EasyP.

Что мы делаем в H3LLO
У нас были высокие требования к инфраструктуре. Собственно, пошли смотреть облака по рынку, их там ровно три, подходящих два. В H3LLO написал в поддержку, типа, у меня нет проблем, есть идея. И они связались!

Короче, мы получили мощность на развитие проекта, поддержку от облака с крупными корпоратами и сейчас делаем совместные проекты.

Зачем нам облако, если всё можно On-Prem? Ну, надо было разместить реестр схем. Это облачный репозиторий, где хранятся, версионируются и документируются все Protobuf-файлы компании. Туда можно в любой момент загружать новые версии API-контрактов и скачивать актуальные схемы. Обычно это сервер в корпоративной сети, но у нас ещё работает малый бизнес, поэтому это для него.

P.S. А, и кстати, вот ссылка на комьюнити t.me/easyptech

Что не так с попытками бизнеса заменить джунов на ИИ



Компании сейчас массово режут косты и сокращают джунов. Решение кажется бизнесу идеальным: выдаём мидлам токены, ускоряем время выкатки фич, а бонусом экономим на выращивании спецов.

Тем более на рынке уже есть кейсы, как команды до 30 человек с ИИ собирают и запускают целые облачные платформы. Например, мы в H3LLO Cloud. Эта модель называется tiny teams.

Разница в том, что мы умеем думать, знаем, зачем применять и для чего НЕ применять LLM. И у нас нет KPI на использование токенов. При этом в корпорациях они обычно есть, и часто там мидлы гоняют бессмысленные запросы, просто чтобы дойти до лимита по KPI.

Я в этой истории по обе стороны баррикад: сам каждый день работаю с нейронками и сам же нанимаю людей. И я могу очень чётко рассказать, где у этой красивой схемы дыры.

Их минимум 5, и каждая со временем обойдётся дороже, чем весь сэкономленный фонд оплаты труда джунов. Ну, например, то, что найм сломан, а система резюме не работает.

Цифры и истории дальше — в основном от моего знакомого, предпринимателя и преподавателя Даниила Пилипенко, который с 2014 года занимается подбором и оценкой айтишников в своей компании SymbioWay. Он и его команда принципиально не делают выводов на резюме.

И они же больше десяти лет ведут статистику: сколько на рынке вакансий, сколько резюме и что из этого получается на практике. Мы будем рассказывать о наблюдениях вместе.

Начнём с того, как кончилась сказка про то, что в ИТ всё хорошо и всех ждут золотые горы.

Сказка кончилась прошлым летом
Десятилетиями рынок IT жил в режиме хронического дефицита: вакансий было стабильно больше, чем резюме, примерно на 40%. Кривые шли параллельно, дружно проседали к Новому году (все хотят отдыхать, а не нанимать) и снова расходились.


Весной 2020-го пандемийный локдаун уронил обе кривые: кандидаты сидели по домам, а компании перестали нанимать. Потом всем срочно понадобились доставки и онлайн-сервисы, и спрос меньше чем за два года вырос почти в три раза. Это был пузырь, но изнутри он ощущался как новая нормальность: айтишников носили на руках и давали офферы и контрофферы, зарплаты и «плюшки» кратно росли.

В марте 2021-го знакомый провёл эксперимент. Java-разработчик выложил резюме утром во вторник. К вечеру вторника у него уже было 60 писем на почте и 30 звонков на телефоне. К вечеру среды — оффер: кто-то особо настойчивый прорвался и уговорил выйти на работу в четверг утром. Вот так выглядел рынок. Утром публикуешь резюме, днём сидишь и выбираешь, вечером проходишь короткое собеседование, а буквально завтра уже выходишь на работу.

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

Уже в марте 2023-го российский рынок вернулся, и до октября 2024-го всё было как раньше: дефицит 40%, жизнь хороша.

А с октября-ноября 2024-го вакансии снова полетели вниз. И прошлым летом кривые впервые за десятилетия пересеклись. Резюме стало больше, чем вакансий.

Локальной российской аномалией это не назовёшь. В США в пике было около полумиллиона технических вакансий, в июне 2022-го рынок просел втрое — до 150 тысяч. Сейчас отрос до 260 тысяч и ползёт вверх со скоростью улитки. По еврозоне график выглядит аналогично.



Сейчас у Python-разработчиков конкурс — 20 человек на место, во фронтенде ситуация немногим лучше. А вот, например, в 1С или разработке на Go всё не так плохо, там конкурс гораздо меньше, но в среднем температура по рынку пугающая. Джуну, чтобы попасть на одно собеседование, нужно откликнуться несколько сотен раз, а такого количества вакансий по его специальности может и не быть. Не 30, после которых обычно опускаются руки, а несколько сотен!

Дальше происходит вот что. HeadHunter — это примерно 40% рынка. Кандидатам лениво откликаться руками, и они включают ботов-автооткликаторов. Рекрутер утром открывает вакансию и видит тысячу откликов. Он читает первые двадцать, зовёт самого «симпатичного» кандидата, на неделе читает ещё 40−50 откликов, кого-то в итоге нанимает и закрывает вакансию. Хвост из девятисот откликов не прочитает никто и никогда.

Вот в такую среду бизнес и принёс свежую идею: джунов больше не нанимаем, у нас теперь ИИ.

Соблазн понятен и подкреплён фактами
Свежий пример от заказчика. Он устал платить за amoCRM и Bitrix24: дорого, интерфейс перегруженный, половина функций не нужна, есть опасения за безопасность данных о клиентах. Хочет свою CRM. Знакомый спросил нескольких фулстек-разработчиков, которые ещё пишут по старинке (тех, кто ещё не заразился подходом и не стал AI-native специалистами), во сколько они оценивают такой проект в одно лицо. Объём известен: 15 таблиц в базе данных, страниц тридцать интерфейса. Все ответили примерно одинаково — два-три месяца, если нормально отладить и протестировать.

В итоге подключили того, что владеет ИИ-инструментами, и у него на создание полноценной системы ушло 12 часов плотной работы. Заказчик пользуется своей системой уже 4-й месяц. За этот срок он всего пару раз попросил доработать функционал под свои задачи, на что ушло где-то 3 часа.

Секрет при этом обидно скучный. Никакого промпт-инжиниринга со специальной структурой запросов, которой учат на курсах. Работает инженерная последовательность: сначала проектируем базу, потом интерфейс, потом API по REST. Сверяем всё это между собой. Потом пишем бэкенд отдельно — по API и базе. Потом фронтенд отдельно — по API и описанию интерфейса. Потом стыкуем, пишем автотесты на интерфейс и API и автоматически исправляем все ошибки. На выходе — чистый код в единой архитектуре, всё документировано, в README инструкция: залил на хостинг, прошёл шаги, и готовый ресурс с удобным интерфейсом заработал.

День против двух-трёх месяцев. Плюс такой исполнитель стабилен: не болеет, не увольняется и не приходит в среду вечером поговорить про пересмотр зарплаты.

Знакомый техлид из крупного e-commerce — Дмитрий Буров, senior разработчик Go в Lamoda — хорошо сформулировал, что с нами всеми произошло: «Мы перестали думать о том, как красиво написать код, и начали двигать квадратики. Уровень абстракции повысился, и мы поголовно стали архитекторами. В англоязычных компаниях таких специалистов уже начали неформально называть „builders“ — строителями».

В пределе картинка такая: инженер заводит себе AI-агента-фронтендера и AI-агента-бэкендера, ставит им задачи и валидирует результат. Также тут не помешает агент-тестировщик. Рядом — живой системный аналитик, который общается со стейкхолдерами и приносит бизнесовые задачи. Двое вместо команды из десяти человек.

Выглядит как смертный приговор джунам.

Токены без тимлида не работают
Те двое с AI-агентами в среднем по рынку эффективнее команды из десяти примерно в два раза. В два. Не в 50. Не на порядок.

Потому что нейронка — джун. Очень быстрый, очень начитанный, не болеющий, но джун. Ей нужны рамки и границы ровно так же, как живому стажёру. Сформулируешь джуну задачу в общих чертах — получишь в общих чертах продукт. С нейронкой то же самое, слово в слово. А садиться вайб-кодить, не понимая, какой результат хочешь получить, — на выходе будет каша и огромный расход токенов.

Очень частая ситуация — получить что-то похожее на результат почти сразу, а потом 3−5 дней доформулировать требования и переделывать мелочи. И это ещё повезёт, если выйдет — на больших проектах надо сразу думать иначе.

Отдельная иллюстрация — самопроверка. Спросите ИИ, какие проблемы он видит в собственном только что написанном коде. Первая итерация — что-то найдёт. Вторая — ещё что-то. На третьей-четвёртой зациклится и объявит, что проблем больше нет. Живой опытный разработчик на этом вопросе может копать бесконечно и технически грамотно: конкурентность, безопасность, узкие места архитектуры, что будет со второй итерацией продукта. Нейронка комплексно на это не смотрит. Такие требования в промпт впишет только человек, который сам набил эти шишки, — он же заметит проблемы в готовом коде глазами.

И вот первая нестыковка бизнес-плана. «Выдадим мидлам токены» на практике означает «назначим каждого мидла техлидом AI-команды». А техлидство — это отдельные конкретные навыки: проектирование архитектуры, декомпозиция, постановка задач, выстраивание границ, валидация чужой работы. Откуда эти навыки берутся? Из опыта руководства живыми джунами. Которых мы только что сократили. А ведь мы выступаем в роли техлидов для ИИ ровно в той же мере, как если бы перед нами сидел живой джуниор.

Мидлы не самозарождаются
Любой мидл — это джун, которого кто-то когда-то терпел.

В 2011 году знакомый нанимал себе разработчика, дал задачку на листочке бумаги, в духе «компилируй в голове, пиши на бумаге». Кандидат решил всё, кроме рекурсивной функции. Просто не смог написать рекурсию. Формально это отказ: заместитель знакомого такого кандидата завернул бы не раздумывая. Вместо этого они заключили сделку: про рекурсию никому не рассказываем, а к понедельнику, к выходу на работу, ты знаешь её идеально. В понедельник человек вышел со знанием рекурсии, проработал в компании много лет и сейчас занимает серьёзную должность. А заместитель, который завернул бы кандидата за незнание рекурсии, лишил бы компанию отличного кадра.

Это один из вариантов «вырастить специалиста» — поверить в него и установить жёсткий план развития. Дёшево, быстро, эффективно.

Теперь смотрим, что стало со входом в профессию. Сам по себе язык программирования учится с нуля за полгода, по вечерам — месяцев за семь-восемь. Но выучить один язык давно перестало быть достижением: знания стали доступными, толстые книжки с распечатками кода на шесть страниц, которые перепечатывали руками, уехали в музей. Чтобы джун начал приносить пользу, ему нужен комплекс: бэкенд, желательно с парой языков, фронтенд с фреймворком, вёрстка, архитектура, понимание микросервисов. Это уже года два учёбы. Плюс стажировки, фриланс и дешёвые проекты ради практики — период разгона от нуля до способности приносить пользу вырос в разы.

То есть конвейер производства мидлов стал длиннее и дороже ровно в тот момент, когда бизнес решил его выключить. Запас прочности у такого решения — года три-четыре: пока нынешние мидлы не станут синьорами, не выгорят и не подорожают. Потом выяснится, что новых брать неоткуда. Джунов не растили, а ИИ за это время так и остался джуном. Да, модели умнеют с каждым релизом, но растут они у вендора. А вендор продаёт вам токены, а не выращенного внутри вашей команды специалиста.

Ладно, скажет бизнес, не будем растить сами — купим готовых мидлов на рынке!
Их же теперь много, вон какой конкурс!

Здесь начинается самое весёлое. Знаем ситуацию, когда за годы отбора накопилась стабильная, повторяющаяся из года в год конверсия: из всех людей, называющих себя программистами, реально работать программистом может каждый 20-й.

Перегретый рынок так устроен в любой профессии. В 2015-м компания Даниила подбирала клиенту бухгалтера. Решено было тестировать бухгалтеров так же, как программистов, — задачами в электронной системе, где нужно было не выбирать варианты ответов, а писать текст. На вакансию откликнулись около 600 человек. До онлайн-задач дошли 400. Задачи несложные: две компании, одна посредник, одна работает с НДС, другая без, посчитайте НДС в этой схеме. Эту задачу из четырёхсот бухгалтеров правильно решили человек двадцать пять. Все десять задач — только семеро. Троих с нормальными софт-скилами показали клиенту, одного в итоге наняли.

Отдельный штрих: ещё 7 из той воронки физически приехали в офис клиента выяснять, как им пройти собеседование, которое вообще-то целиком проходило удалённо. И это при том, что они даже простейший НДС не смогли посчитать!

Теперь добавим в эту картину ИИ — и она станет хуже. Резюме теперь пишут нейронкой, по тексту вообще ничего не понять. На онлайн-собеседованиях кандидаты включают прозрачные окна поверх экрана, которые не видны при демонстрации, и зачитывают оттуда ответы. Зачитывающих пока выдают глаза: они бегают по строчкам. Дошло до вопросов-ловушек: например, внезапно спросить кандидата, как пожарить свиные крылышки. Человек, погружённый в техническую беседу, на секунду зависнет и рассмеётся. Зачитывающий начнёт уверенно излагать рецепт — нейронка-то ответ честно сгенерировала.

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

Есть и ещё организованное движение — «волки». Философия простая, они сами называют её осознанной меркантильностью: рынок нам должен, заходим на грейд выше, чем умеем, зарабатываем максимум. Справедливости ради, часть из них потом действительно дорастает до заявленного грейда: берут на себя ответственность и пашут, действительно выдавая нужные результаты. Но для работодателя это уже лотерея.

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

Если компания уволила джунов, на своих выращенных опереться больше не может и идёт на рынок за «готовыми мидлами» — на рынок, где конкурс 10 к одному толкает людей к обману, нейронки делают обман дешёвым и массовым, а настоящим специалистом по-прежнему оказывается каждый двадцатый.

Резюме умерло, а нанимать по-новому дорого
Хорошо, а как отличать настоящих?

Старый интерфейс найма — резюме — сломался окончательно.

Он, честно говоря, никогда толком и не работал. В подкасте Даниил рассказал про товарища, который сейчас работает одним из технических руководителей в Google. И вот он как-то показал Даниилу своё резюме, в котором была всего одна строчка навыков — PHP, MySQL, HTML, CSS, JavaScript — и невзрачное место работы. За этой строчкой скрывался человек, который написал собственную версию PHP: лазил в исходники интерпретатора и переделывал синтаксис под себя, в частности, менял точку на плюсик для конкатенации строк.

Другой пример. К Даниилу на консультацию пришёл PHP-разработчик с резюме, которое выглядит так, будто у него опыта лет пятнадцать. Начинаешь расспрашивать: с микросервисами работал — слова «микросервис» в резюме нет. Гитом владеет — слова «Git» нет. Редис, очереди, хранилища — ничего нет. Объяснение прекрасное: мозг не заточен под самопрезентацию, и вообще он это всё не любит, резюме и так далось с трудом. Сильные специалисты сплошь и рядом игнорируют самопродвижение: им годами не нужно было выходить на открытый рынок, их передавали из рук в руки по рекомендациям.

А в 2015 году у Даниила был случай: искали клиенту фронтенд-разработчика на Angular. В воронку попали двое лучших кандидатов после тестирования, при этом эксперт выбирал их, не видя резюме — только по тому, как они решали задачи. У первого оказалось идеальное резюме фронтендера. У второго — всё про 1С, и лишь где-то внизу сиротливое слово «Angular», потому что он «по вечерам сайтики делал для себя» и не верил, что это коммерческий опыт. Клиент провёл собеседование, перезвонил и в восторге сказал: «Они оба такие классные, я пойду выбивать бюджет на двоих». И взял обоих, и оба проработали в этой компании по 6 лет, пока она не закрылась. И это доказывает, что честность с резюме кандидату никак не помогла, а помог наработанный вечерами опыт.

Бывают и зеркальные случаи. Знакомого позвали оценить команду из десяти верстальщиков и фронтендеров: руководитель компании засомневался в их лиде. У лида десять лет стажа, по идее, давно пора в синьоры. По навыкам оказался джун с плюсом. Все десять лет команда клепала однотипные плоские лендинги — стаж шёл, скилы не развивались.

Что работает вместо резюме? Компания Даниила уже год практикует формат, который считает самым эффективным в настоящее время. Звонок кандидату начинается с вопроса, владеет ли он Cursor. Владеет — отлично: открывай, включай демонстрацию экрана, вот описание продукта, у тебя час. Хотел списать на собеседовании — пожалуйста, списывай официально, нейронка перед тобой, сделай нам продукт и размести на тестовом сервере. Фокус в том, что для результата нужны оба набора скилов сразу: программировать и работать с ИИ. Без «включения» мозга нейронка такое не вытянет: надо поставить задачу, разложить систему на части, заметить, где она привирает, запускать агентов параллельно. Без владения инструментом не уложишься в час.

Это заодно ответ на вопрос, кого теперь считать джуном. Джун с Cursor и джун без Cursor — две разные профессии.

Дальше — устный экзамен, как в университете: эксперт, кандидат и разговор. Даниил считает этот формат золотым стандартом, и там есть свои детекторы. Например, вопрос про методы HTTP. Кандидат называет GET, POST, PUT, PATCH, DELETE — нормальный мидл. Вспомнил HEAD и OPTIONS — условно мидл с плюсом. А вот если назвал TRACE и CONNECT и бойко рассказывает, что это, — иногда отказ. Нормальные люди их не помнят, на практике они почти не встречаются (если только вы не синьор, который случайно столкнулся с этим в специфической задаче). Либо списал, либо подглядел.

Ещё есть проверка профессиональной интуиции: спросить то, чего кандидат знать не обязан. Вы Ruby не знаете? А как, по-вашему, там может быть устроено ООП? Честный человек начинает рассуждать, тянуть связи от того, что знает, и ошибаться правдоподобно — по этому видно, что чутьё есть, с остальным разберётся. «Волк» же отвечает подозрительно точно. Слишком точно для человека, который Ruby не знает.

У компании Даниила, к слову, есть и автоматизация: система онлайн-оценки следит за 67 признаками списывания — вплоть до того, как кандидат набирает текст. С ChatGPT в соседнем окне или в телефоне на столе текст набирают заметно иначе, чем из головы. Но он сам говорит, что достоверности пока не хватает, и финальное слово должно оставаться за экспертом и живым собеседованием.

Про роль ИИ в найме у него тоже есть чёткая позиция. Загрузить запись собеседования и попросить выписать плюсы и минусы кандидата — полезно: взгляд со стороны, нейронка заметит то, что вы пропустили. А вот решение отдавать ей нельзя. Решение о найме — это взвешивание рисков: вот этого кандидат не знает, ну и ладно, за выходные выучит, зато глаза горят. Машина так не взвешивает.

Богатые компании делают ещё круче: устраивают тестовые дни, когда кандидат день-два сидит за реальной работой, знакомится с компанией, а компания смотрит на него в деле. Лучший способ отбора из существующих. И самый дорогой.

Живой эксперт, час демонстрации экрана, устный экзамен, тестовые дни. Найм стал заметно дороже ровно в тот момент, когда бизнес решил на нём сэкономить.

Ставка на чужую инфраструктуру
Последняя дыра стратегическая, про неё почти не говорят на конференциях.

ИИ хорошо пишет на том, на чём его обучили, и это уже искажает рынок технологий. Проектов на TypeScript становится больше в том числе потому, что нейронки на нём сильны. Go за последние год-полтора рванул с привычных десяти процентов рынка к двадцати и вот-вот обойдёт Python по популярности в бэкенде — старая иерархия, где сверху Java, за ней Python, дальше PHP, поплыла на глазах. А вот на 1С, который держит заметную долю российского рынка, нейронки пишут плохо: данных мало, модели учились на англоязычном коде, и ждать паритета ещё года два. Embedded — вообще отдельная планета: какие баги и капризы у конкретной железки, не знает ни одна модель, поэтому люди с C, C++ и Assembler могут не паниковать в принципе.

И здесь важно понимать, что разные ИИ-модели хороши в разном: для написания кода сейчас отлично работают Gemini или продукты Anthropic, а вот отечественная Алиса, хоть и не блещет в программировании, зато делает весьма неплохие юридические подборки. То есть лозунг «заменим джунов на ИИ» в реальности звучит как «заменим джунов на ИИ в тех стеках, где ИИ повезло с обучающей выборкой». В заголовках такое уже смотрится хуже.

И второе. Взрывной рост моделей упирается в железо и энергетику, а того и другого в мире не прибавляется. Уже ходят осторожные прогнозы, что в ближайшее время рост притормозится просто потому, что вычислять будет не на чем. Знакомый позавчера сел дописать свою утилиту с Cursor — тот тормозил так, что проще было написать руками, а в какой-то момент написал, что его сервера перегружены и надо подождать. Один тормозящий вечер — мелочь. Но стратегия «джунов сократим, токенов докупим» молча предполагает, что токены всегда будут дешёвыми, быстрыми и доступными. Это ставка на чужую инфраструктуру, чужую экономику и чужую энергосеть. Откат назад возможен гораздо легче, чем кажется из 2026 года.

Под конец две истории, обе на самом деле про одно
2006 год, четвёртый курс университета. Человек в совершенстве пишет на Java и приходит на вакансию PHP-разработчика. PHP не знает вообще, ни строчки кода не написал. Всё собеседование уместилось в один вопрос: знает ли он PHP. Ответил, что знает. Приняли. Дальше он за месяц перечитал весь PHP.net, через несколько лет дорос до ведущего разработчика, и вся эта авантюра давно превратилась в длинную успешную карьеру. Работа ему тогда была не особо нужна, четвёртый курс всё-таки. Это был вызов самому себе: соврал — теперь соответствуй.

Формально перед нами волк. По сути — лучший найм тех лет.

История посвежее. Парень на собеседовании в команду поиска мимоходом упомянул, что знает, как растёт слайс в Go: в одной версии языка алгоритм был один, потом поменяли буквально строчку, и распределение памяти стало лучше. Его спросили, зачем ему это знать. Ответ обезоруживал: незачем, просто прикольно лазить по исходникам. В ту команду он не прошёл, так как не очень хорошо знал Elasticsearch, который там требовался, но запись собеседования увидел тимлид из соседней — и забрал его к себе за один этот ответ.

Вот это и есть джуны. Это люди, которые от чистого любопытства лезут в исходники, на спор выучивают язык за месяц и через несколько лет становятся теми самыми мидлами, которым бизнес сегодня торжественно выдаёт токены. Даниил Пилипенко, который сейчас собирает материал для своей будущей книги о профессионализме, говорит: именно этот искренний, глубинный интерес к тому, как всё устроено под капотом, является основной движущей силой профессионализма.

Интерес заставляет наращивать новые нейронные связи и решать всё более сложные задачи, а не только получать зарплату.

Так что просто в мире появилось новое ремесло — работать с LLM. Как когда-то появилось ремесло работать со счётами, а потом с Excel.

Подключаем международные каналы связи



Прокладываем международные ВОЛС — в 23:00 моргнём на пять минут
Новость из машзала: подключаем собственные международные каналы связи. Прям настоящие трансграничные ВОЛС.

Техническая часть
Прямо сейчас переходим на наши каналы. Сегодня (10.07.26) в 23:00 по Москве возможны перерывы связи длительностью до 5 минут. Работы плановые, дольше не затянем.