H3LLO CLOUD

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

Но на самом деле ИБ в малом и среднем бизнесе нет. И не будет.

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

Почему так:

• Доступные зарубежные вендоры ушли. Российские аналоги очень дороги, ориентированы на крупный бизнес и госсектор, а для малого бизнеса пока ничего нет.
• Бюджетов на ИБ у малого бизнеса обычно нет. Реальных ИБ-специалистов за зарплаты малого бизнеса тоже мало. И вообще их зарплаты неподъёмны.
• ИБ часто требует круглосуточной работы целой службы, а не одного человека. Для реальной защиты нужен дорогой стек технологий (антивирусы, NGFW, IDS/IPS, SIEM, IRP и т. д.).
• Низкая культура ИБ и беспечность. Распространены практики вроде бесконтрольного использования личных устройств (BYOD), устаревшего и необновляемого ПО (пример с Bitrix), слабых и неизменяемых паролей.

В итоге сейчас малый и средний бизнес — лёгкая мишень для массовых автоматизированных атак, а не только для целевых APT.

Давайте поковыряемся чуть детальнее.

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

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

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

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

То есть иностранные вендоры ушли, а доступных отечественных решений пока нет. Может быть, позже будут. Но сейчас говорить о том, что можно взять коробками и в next-next-done настроить что-то для малого и среднего бизнеса, не получается. А вот раньше кое-как, но было можно.

Нет денег на ИБ
Давайте посмотрим, кто это такой — малый бизнес. По официальным меркам, это оборот до 800 миллионов рублей в год. Средний — до двух миллиардов. Суммы вроде бы внушительные, но если копнуть глубже — налоги, расходы, закупки (если это торговля), — то на IT-инфраструктуру остаются крохи. А на информационную безопасность как часть этой инфраструктуры денег не остаётся совсем. Даже если компания наскребёт на какое-то железо или софт — это лишь верхушка айсберга.

Чтобы построить хотя бы подобие нормальной системы ИБ, нужен целый стек технологий:

• Антивирусы на всех рабочих станциях и серверах (если это Win, на других ОС — свои нюансы).
• Next Generation Firewall (NGFW) для защиты сетевого уровня.
• IDS/IPS (системы обнаружения и предотвращения вторжений), чтобы автоматически выявлять попытки вторжения.
• SIEM (система управления событиями ИБ), куда будут стекаться все логи и события безопасности.
• В идеале — ещё и IRP (платформа реагирования на инциденты) для автоматизации ответных мер.

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

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

Тенденция в целом такая, что никому эта ИБ особо-то и не нужна.

Неподъёмные зарплаты безопасников
Специалисты — самая больная тема. Даже если бы у малого бизнеса и были деньги на дорогие ИБ-решения, то кто будет всем этим управлять? Реальных ИБ-специалистов на рынке — раз-два и обчёлся. А те, кто есть, особенно если они не фейковые, просят зарплаты, сравнимые со стоимостью крыла от Боинга.

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

Да, есть модные онлайн-курсы по ИБ. Но это капля в море. Когда мы искали специалистов себе в Security Operation Center, к нам приходили люди, чей потолок компетенций — это настроить домашний файрвол, чтобы можно было качать торренты, а к тебе в компьютер никто не залез. И так сейчас реально выглядит рынок кандидатов среднего уровня под средний бизнес. Ну и что нам с этим делать в масштабах облачного провайдера?

Или вот ещё живой пример некомпетентности, которым делились коллеги на одном бизнес-завтраке. Взломали компанию, заразили шифровальщиком. Приехали разбираться специалисты по форензике, а там директор по безопасности — молодой парень, увешанный сертификатами о свежеоконченных курсах. Когда его начали спрашивать про ханипоты, IDS/IPS, про то, что делалось для защиты контура, он сделал круглые глаза и ответил: «Ребята, вы так интересно рассказываете! Пойдёмте пообедаем, вы мне всё поподробнее расскажете». То есть он даже не понимал, о чём его спрашивают и что он должен был делать! И это, увы, — повсеместная практика.

Информационная безопасность — это не работа с 9 до 18. Это круглосуточные мониторинг и реагирование. Это требует целой службы, а не одного, пусть даже гениального, специалиста.

Раздолбайство и низкая культура ИБ
По факту в малом и среднем бизнесе процветают раздолбайство и крайне низкая культура информационной безопасности.

Типичная картина: сотрудник приходит со своим ноутбуком (BYOD, да?) и подключается к корпоративной сети. Никого не волнует, что он там дома на этом ноуте делал, чем мог заразиться и что принёс в офис. Это считается нормой. Я лично слышал, как один такой «директор по безопасности» на конференции с пеной у рта доказывал эксперту по форензике, что ничего страшного в этом нет, ведь «Мы же всех выпускаем в Интернет через NAT, к нам никто не попадёт». Без комментариев.

Повсеместно используется устаревшее программное обеспечение. Регулярное обновление ПО — это базовая цифровая гигиена, но в малом бизнесе это экзотика. Яркий пример — Bitrix24 и просто Bitrix. Там каждое обновление — это риск, что слетят все кастомные доработки. Поэтому системы годами не обновляются и кишат известными уязвимостями. Можно вспомнить и OpenStack с его известными, но годами незакрываемыми дырами, — это как пример системной проблемы с обновлением сложного ПО.

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

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

Вы лично на фиг никому не нужны. Ломают сейчас всех. Реальность — это массовые автоматизированные атаки. Современные хакеры — это разработчики, которые поставили взломы на поток. Работает это по принципу «воронки»:

• Сначала с помощью огромных ботнетов (заражённых компьютеров, телефонов, «умных» утюгов — чего угодно) идёт массовое сканирование IP-адресов всего Интернета на предмет отклика. Допустим, из 100 миллионов адресов откликнулось 10 миллионов.
• Затем эти 10 миллионов сканируются на наличие открытых портов с потенциально уязвимыми системами (уязвимости и порты, которые они используют, хорошо известны). Нашёлся, скажем, миллион таких.
• Далее идёт проверка версий ПО на этих портах. Любая программа при подключении к ней часто выдаёт свою версию, версию сервера, операционку. Злоумышленники сверяют эту информацию с базами известных уязвимостей. Так из миллиона находится, допустим, 100 тысяч потенциально уязвимых приложений.
• И, наконец, на эти 100 тысяч целей автоматически запускаются эксплойты — специальные программы, эксплуатирующие конкретные уязвимости. Если на 10 тысячах из них эксплойт сработал, то злоумышленники получают доступ.

Результатом может быть что угодно: заражение шифровальщиком (ключ от которого, кстати, почти никогда не возвращают, даже если заплатить выкуп), кража данных, использование вашего сервера для дальнейших атак. Можете сами провести эксперимент: создайте виртуальную машину, дайте ей публичный IP-адрес. Буквально через 10 минут посмотрите логи (команды lastb или tcpdump) — вы увидите шквал попыток подключения и сканирования.

Есть, конечно, и APT (Advanced Persistent Threat) — это уже точечные, сложные и хорошо подготовленные атаки на конкретные организации. Чаще их целью становятся крупные компании или госорганы, но и средний бизнес может попасть под удар, если у него есть что-то ценное, например, поставщик с доступом к крупной компании. Атака на цепочку поставок на сегодняшний день — довольно популярная техника.

APT-атаки многовекторны: используются технические средства, человеческий фактор, социальная инженерия (например, внедрение своего человека в компанию или «случайно» оставленная на собеседовании флешка). Примерами APT-атак можно назвать взломы правительственных департаментов, Google, Пентагона или вот из недавнего российского — удаление всего контента и исходников Rutube. Такие атаки часто выявляются уже постфактум, когда ущерб уже нанесён, и последствия могут быть катастрофическими.

Есть DDoS-атаки. Любой хостинг-провайдер подтвердит, что их инфраструктура и клиенты постоянно находятся под DDoS-атаками, часто — с требованием выкупа.

И вишенка на торте — недобросовестность некоторых «защитников». Миф о том, что разработчики антивирусов сами пишут вирусы, — это, к сожалению, не такой уж и миф. Мне известны случаи, когда, по слухам на рынке, один очень крупный известный российский антивирусный вендор организовывал DDoS-атаки на потенциальных клиентов, чтобы потом «героически» предложить свою помощь в защите. Кроме того, одна из причин запрета многих зарубежных ИБ-решений у нас — это подозрения в наличии программных и аппаратных «закладок», которые могут быть использованы в любой момент. Комментировать правдивость не возьмусь, но слухи ходят очень активно.

Истории:

• Был забавный случай, когда одним махом открыли все постаматы одной известной компании. Представляете картину?
• Я лично больше года имел администраторский доступ к порталу Министерства образования Албании. Нашёл уязвимость в их веб-сервисах, просто сканируя диапазоны IP-адресов. Год читал всё, мог модифицировать данные. Закрылась эта история только после того, как я сам им написал, что, мол, ребята, я тут у вас играюсь уже год, пора бы вам дыры залатать. Это было в начале нулевых, так что сейчас уже можно рассказать. Уверен, что с огромным количеством систем и сейчас происходит то же самое, просто данные этих компаний никому особо не интересны.
• Ещё один интересный кейс, упоминания о котором вдруг стали пропадать, но остались в Коммерсанте: «В апреле корпоративные клиенты 1Cloud, MTSCloud, oblako.kz (ТОО «1 Клауд», входит в ООО «ИТ-ГРАД 1 Клауд», работает на территории Казахстана) направили в Минцифры и уполномоченному по защите прав предпринимателей в России Борису Титову коллективное обращение… Из обращения следует, что в результате сбоя 17 марта стало недоступно более 1 млн виртуальных серверов, размещённых на инфраструктуре ЦОДов в Москве, Санкт-Петербурге и Казахстане.«Инфраструктура провайдеров услуг была взломана, данные клиентов, включая резервные копии, уничтожены или зашифрованы. Ситуация вокруг инцидента, причины, последствия и прогнозы тщательно скрываются», — подчёркивается в обращении.»
• Или вот ещё нашумевший случай, когда предположительно из-за уязвимости у одного крупного банка хакеры получили доступ к городским рекламным панелям и почти сутки крутили на них порноролики. Видео с этих панелей гуляли по Интернету.

Что делать?
Несмотря на всю беспросветность, какие-то шаги сделать всё-таки можно и нужно.

• Реалистично оцените риски. Предположим, что вас взломали теми самыми решениями на потоке. Что будет дальше? Бекапите ли вы клиентскую базу, документы, бухгалтерию? Как быстро всё восстановите?
• Рассмотрите облачные сервисы. Почта, 1С, документы, корпоративный чат — можно развернуться в инфраструктуре у кого-то: главное — убедиться, что этот кто-то действительно хоть как-то занимается ИБ.
• Базовая гигиена: минимальные привилегии сотрудников, регулярные обновления ПО на стабильные версии, везде двухфакторная аутентификация, обучение сотрудников не открывать странные файлы в письмах (и пару раз — практическое обучение), если заметили что-то подозрительное (например, взлом telegram-аккаунта сотрудника), то говорить сразу.
• Если вы сразу — ИТ-проект, то в самом начале можно использовать Web Application Firewall, ограничивайте частоту вызовов API-методов, особенно тех, которые приводят к расходным операциям (например, отправке SMS). Этот совет спас уже как минимум один бизнес. Если нет жёстких регуляторных ограничений, то, возможно, стоит рассмотреть «серые» схемы для получения нужного зарубежного ПО, потому что это может быть лучше, чем не иметь никакой защиты вообще.
• Если повезёт найти адекватного специалиста, который не будет просто «разводить на деньги», а действительно поможет разобраться в ваших рисках и подобрать посильные решения, то это может быть очень ценно.

Так какой выбор остаётся у малого и среднего бизнеса?

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

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

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

Если интересно посмотреть, как мы обосрёмся (или вдруг нет) с нашим облаком — вот телеграм-канал t.me/+g1JETQ88dDBlZTRi Там есть про то, зачем граната и пистолет айтишнику в России. Очень нужны.

h3llo.cloud/ru
limits.h3llo.cloud
hh.ru/employer/11153353

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

Удивительно, но спрос на нормальную жизнь, кажется, растёт. Поэтому корпорации компенсируют это деньгами.

Но при этом я не вижу сейчас в России по-настоящему внятных и перспективных стартапов. Это огромнейшая яма, образовавшаяся после известных событий.

Из важного, что сейчас видно на срезе (и да, это сугубо личные наблюдения):

• Мало узких специалистов и много джунов. Особенно пострадали от LLM фронтендеры, там джунов очень сильно вытесняют, и их переизбыток. А вот DevOps, ИБ-специалисты, Scala-разработчики в дефиците.
• Удалёнка требует зрелых процессов и менеджерского контроля. Многие возвращаются к офису, потому что для офисного формата менеджер может быть и слабее.
• Всё чаще откликаются те, кто пару лет назад уехал, а теперь мониторит российский рынок и хочет вернуться. Таких действительно становится больше. Похоже, шок прошёл, люди пожили там, сравнили — и не всем понравилось.
• Формальный опыт перестал много значить, как и возраст. Про это чуть ниже будет подробнее.
• Нужны навыки «вайб-кодинга» — это не слепой копипаст, а продуманная работа с AI-агентом, интегрированным в IDE. Как минимум нужны навыки архитектуры и ревью. Ленивый вайб умрёт, потому что несёт огромные риски. Останутся только те, кто прочитывает каждую строчку сгенерированного кода, но тратит меньше времени на само написание.

Что на рынке труда в IT сейчас
Мы тут набирали команду к запуску нашего последнего коммерческого облака в России, насмотрелись всякого.

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

С другой стороны, наша HR Юлия Васильева наблюдает сильный тренд на отток из корпораций. Раньше очень много людей переходило туда за стабильностью, большими деньгами и всякими «плюшками».

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

Люди ищут что-то поживее. Им хочется драйва и проектов, где видно, что твой код реально на что-то влияет. Они хотят видеть результат своей работы, влиять на продукт, заниматься чем-то, от чего глаза горят. Это сильно отличается от поисков IТ-брони два года назад, например.

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

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

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

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

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

Вернусь к рынку. Если с джунами всё отлично, то вот с узкоспециализированными специалистами, как я уже говорил, всё сложнее. Девопсы, Scala-разработчики, сетевые инженеры — их мало, они нарасхват. По Scala Senior, например, мы весь рынок кандидатов знаем лично. Всех трёх с половиной человек.

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

Много хайпа вокруг нейронок и того, что мы называем вайб-кодингом. Был у нас недавно парень на Go-разработчика. Он был чётко против нейронок. Прям реально против. На вопрос, какая любимая нейронка, ответил — никакая. После интервью мы показали ему, как работаем сами, что у нас в IDE полноценный AI-агент, который помогает писать и рефакторить код прямо в среде разработки. У человека случился сильнейший разрыв шаблона. Он-то представлял вайб-кодинг как банальный копипаст из чатика в окно редактора. А тут всё иначе.

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

Как мы ищем людей
Ищем мы в основном через HeadHunter, также используем HuntFlow (это HRM — что-то типа CRM для кандидатов).

Сначала отсекаем по флагу удалёнка или нет.

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

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

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

Мы смотрим на реальные навыки и мотивацию.

Мы не ищем суперджунов и не всегда ищем суперсеньоров. Нам нужны крепкие мидлы. У нас нет времени на долгую раскачку, нужно сразу включаться в работу. Но и суперсеньоры нам не всегда подходят — они часто уже «не голодные». Голодные до нового: что-то создать и чтобы оно работало, вдохновляло, приносило самореализацию и самоудовлетворение. Кто-то, поработав пару лет в банке или интеграторе, гаснет. А у кого-то это не проходит никогда. Вот таких «голодных» мы и ищем.

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

У нас размыты роли, это тоже нормально для стартапа.

Нам важно, чтобы человек был готов вникать в продукт целиком. Мы все часто делаем вещи, которые в других местах считались бы «не их зоной ответственности». Никто не заставляет — но это возможность для роста. В больших компаниях такое почти не встретишь — кому-то это интересно, кого-то отпугивает.

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

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

Многое видно по мелочам: включает ли видео, как разговаривает. Очень ценно, когда человек признаётся, что чего-то не знает. Это абсолютно нормально. Мир такой, что знать всё невозможно.

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

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

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

Дальше офер.

Что дальше будет с рынком?
Нас ждут очень интересные 5 лет. Рынок разделится на два лагеря: те, кто поймёт, как работать с LLM, и те, кто будет писать код руками, как в 2005-м, и гордиться этим, собираясь в своих «олдскульных барчиках без электроники».

Я видел статью на CNews, где вайб-кодинг назвали способом ничего не делать и зарабатывать больше. Это настолько не так! Работы не убавилось, её стало больше. Просто она другая.

Кто это понимает — будет расти в продуктивности феноменально.

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

Ну и там что-то появляется про личную жизнь и смыслы этой жизни за пределами корпоративного мира.

Если интересно посмотреть, как мы обосрёмся (или вдруг нет) с нашим облаком — вот телеграм-канал t.me/+g1JETQ88dDBlZTRi Там есть про то, зачем граната и пистолет айтишнику в России. Очень нужны.

h3llo.cloud/ru
limits.h3llo.cloud/
hh.ru/employer/11153353

Главный прикол с k8s: поднять базовый кластер займёт всего 15 минут. А вот чтобы он реально заработал, ответить на все вопросы перед установкой, всё спланировать — на это нужны дни, реально дни мозгового штурма и планирования. Ну или потом придётся разбирать и делать ещё раз. Несколько раз.

Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.

И вот про эти самые вопросы мы сейчас и поговорим, потому что там целое волшебное поле грабель.

Начнём с простых вещей, например, выбора дистрибутива, выбора способа хранения данных (и динамического выделения места), а также того, куда складывать пароли к критичным ресурсам. На этих трёх выборах ломается примерно 50 % админов.

Поехали в ад!



Архитектура

Kubernetes — это кластер. То есть много серверов, которые работают вместе. Эти серверы называются нодами, или узлами. Есть ноды управляющие (Control Plane). Раньше их звали Master, но сейчас это слово немодное, так что Control Plane. А есть ноды рабочие (Worker Nodes) — вот на них-то и крутятся ваши приложения в контейнерах (точнее, в подах).

Рядом с Control Plane живёт etcd. Это распределённая база данных (ключ-значение), где Кубер хранит всю инфу о себе и о том, что в нём запущено: какие поды, какие сервисы, какие конфиги — вот это всё. Она тоже обычно распределена по нескольким управляющим нодам для надёжности. Для полной надёжности её ставят отдельно.

Работает это так: вы пишете файл с конфигом, который описывает условия и состояния, например: «Хочу такой-то деплой из стольких-то подов, чтобы он при таких условиях вёл себя так, а при таких — вот так». Эти правила хранятся в etcd, а Control Plane следит за их исполнением. Если есть разница между тем, как надо, и тем, как есть, — всё приводится в нужное состояние. То есть что-то грохается или добавляется. Автоматически.

Казалось бы, всё просто, но тут огромная кроличья нора.

Дело — в условиях и работе приложений. Чтобы прописать нормальные условия для работы кластера, придётся вытащить наружу кучу метрик изнутри ваших приложений. Потому что более-менее доступные условия «из коробки» — это, например, «Если нагрузка на процессор больше 80 % 10 секунд подряд», а не «Если я записываю в базу данных быстрее чем за 0,1 секунды, и очередь — меньше 1 000 событий».

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

Вторая особенность — вам надо обеспечить правильное поведение приложения при добавлении-убавлении контейнеров. Это касается транзакций (надо корректно закрываться после обработки транзакции, а не терять её), записи на диск и так далее.

С диском — тоже отдельный сюрприз: мышление придётся изменить. Но давайте по порядку.

Если у вас планируется реально большой, нагруженный кластер, то Control Plane и особенно etcd лучше выносить на отдельные, выделенные ноды. Не надо на них вешать рабочую нагрузку, пусть они занимаются только управлением. У себя на деве или стейдже мы можем и совмещать, чтобы экономить ресурсы, но на проде лучше делить. В наших собственных продуктах на dev-части мы совмещаем узлы, а на прод-части создаём два отдельных контура.

Почему это проблема?



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

• Начинаешь с Kubernetes — вроде всё понятно по верхам, курс прошёл, потыкал. Гугл и AI помогают. Но потом лезешь глубже: драйверы для хранилищ, autoprovisioning, сети… и это просто стена! Понять базово — это одно, а настроить под себя — совсем другое. Нужны или огромный опыт, или куча времени, чтобы просто сидеть и ковыряться. Настроить выход наружу? Тоже целая история с кучей нюансов: часто просто копируешь решения, не до конца понимая.
• Написать код — быстро. А вот развернуть его в Кубере первый раз — это дни мучений! Сертификаты, связь между сервисами, настройка Argo CD с ключами — всё совершенно неинтуитивно. Если рядом нет опытного DevOps, который проведёт за ручку, то это просто взрыв мозга и боль: не понимаешь, за что страдаешь! Но когда наконец всё настроишь, думаешь: «Боже, как же хорошо! Теперь только так и буду работать! Только, пожалуйста, пусть кто-нибудь другой развернёт сам Кубер, я этого больше не хочу!»
• Пытаешься соединить внутренние сервисы Кубера с внешним миром — и тут начинаются танцы с бубном. Куча технологий, и все — на разной стадии готовности.
• Самое сложное в начале — просто понять, как вообще работать с Kubernetes. У тебя не запускается простой сайт в Docker-контейнере, а DevOps объясняет проблему терминами Кубера, и ты даже не понимаешь, как это отладить, куда смотреть. Потом тебе дают конфиг для kubectl и говорят: «Разбирайся сам». Ощущение, будто тебя выкинули с лодки посреди озера: плыви!

Что ставить
Это классика жанра для новичка. Открываешь доку Кубера, а там бац — десяток способов установки! И хрен поймёшь, какой тебе нужен.

Дальше можно гуглить «Kubernetes Hard Way» и «Kubernetes Simple Way»: там статьи разной степени упоротости. Поскольку на дворе — XXI век, можно попросить помочь и LLM, но это будет step-by-step-воспроизведение одной из этих двух инструкций.

Третий путь — пойти к облачному провайдеру и там найти managed-service для k8s, обычно выглядящий для пользователя как волшебная кнопка «Создать кластер Kubernetes». Жмакнули, подождали минут 10–15, и вам вываливается файлик с конфигом. А дальше наступает ступор. Смотрите на этот файлик и думаете: «Ну зашибись, а дальше-то что?»

Мой личный совет: прежде чем лезть в облака или мучиться со своими серверами, поставьте себе на ноут Minikube. Это такая песочница, маленький Кубер на одной машине. Погоняйте его, потыкайте палочкой, разберитесь с базовыми понятиями: что такое Pod, Service, Deployment — вот это всё. Освойте kubectl — это главная команда для общения с кластером. Вот когда вы через это пройдёте, тогда и Managed Service в облаке станет в разы понятнее, и вы будете знать, что делать с этим загадочным admin.conf.

Итак, вариантов три с половиной:

• Managed Service в облаке (типа нашего H3LLO CLOUD) — это когда вы приходите к провайдеру, говорите: «Хочу Кубер», нажимаете пару кнопок (ну или не пару: всё зависит от упоротости провайдера), получая готовый кластер и kubeconfig. Плюсы: не надо париться с установкой и обновлением управляющих нод (Control Plane, etcd): всё это — головная боль провайдера. Масштабирование нод — часто «из коробки»: настроил правило, и если нагрузка растёт, то провайдер сам добавит виртуалок в ваш кластер. Автоматическое выделение persistent volume любого размера в любом количестве — тоже на провайдере, как и LoadBalancer для внешнего доступа. Минусы: зависимость от провайдера, его ограничений (про них ещё скажу) и его ценовой политики.
• На своих серверах (Bare Metal) или своих виртуалках. Полный контроль над железом, над софтом, над настройками. Делайте что хотите. Но на вас падает вся сложность установки, настройки, обновлений, бэкапов. Масштабировать кластер новыми серверами? Только ручками: пошёл, купил сервер, поставил в стойку, настроил, добавил в кластер. Никакой магии.
• Руками в облаке на виртуалках: можно, но зачем? Если очень хочется поковыряться в кишках, но своего железа нет. Или если Managed-сервис чем-то критично не устраивает (например, версией Кубера или доступными опциями). По сути, это то же самое, что и Bare Metal, только серверы арендованные. Вся сложность — ваша, но хотя бы серверы покупать не надо.

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

Как ставить

• Kubeadm — официальная утилита от создателей Кубера. Но это, как я говорю, «путь самурая». Все команды — ручками, все конфиги — ручками, бутстрэп каждой ноды — ручками. Если вы не мазохист и ставите Кубер первый раз — не советую категорически: намучаетесь и проклянёте всё на свете.
• Kubespray — это наш выбор для своих инсталляций на железе или виртуалках. Это, по сути, набор готовых Ansible-сценариев. Он автоматизирует 90 % рутины по развёртыванию кластера на куче нод. Есть неплохие статьи, как его подготовить и запустить. Очень рекомендую начинать именно с него, если вы решили ставить сами и уже выросли из Minikube. Очевидный плюс — в дальнейшем удачный конфиг можно многократно воспроизвести.
• Экзотика — есть и другие штуки, часто привязанные к специфичным ОС. Например, для Talos OS есть свои утилиты — Talos CTL (ручками) и talm (типа Helm, но для Талоса). Интересные вещи, но это уже для тех, кто в теме.

На какую ОС ставить ноды

• Есть обычные Linux — старая добрая Ubuntu, CentOS, Debian, и всё это прекрасно работает. Привычно, понятно, куча доков в сети.
• Специализированные ОС — есть дистрибутивы, заточенные специально под контейнеры и Кубер. Это Fedora CoreOS / Flatcar Container Linux: часто у них read-only — корневая файловая система для безопасности, атомарные обновления. Но есть нюансы: например, FCOS вместо привычного cloud-init использует свой формат конфигов — Ignition. Надо разбираться, как его готовить (там есть ещё утилита Butane). Talos — ещё более хардкорный вариант. Там вообще нет привычной ОС с shell! Всё управляется через API. Максимальная безопасность, минимализм. Но требует полного переосмысления подхода к управлению хостами.

Если нет особых требований к безопасности или специфике, то начинайте с обычной Ubuntu LTS — не ошибётесь.

Container Runtime

• Docker (точнее, dockershim) — до недавнего времени был стандартом де-факто. Сейчас его официально выпилили из Кубера, но многие дистрибутивы и инсталляторы по-прежнему его поддерживают через прослойку. Если у вас нет веских причин для другого — можно начать с него: он самый привычный.
• Containerd — а вот это стандарт де-факто сейчас, поддерживаемый Кубером напрямую через интерфейс Container Runtime Interface. Кстати, Docker сам под капотом использует containerd, так что переход на него обычно безболезненный. Большинство новых инсталляций использует именно его.
• CRI-O — ещё реализация CRI, разрабатываемая Red Hat. Тоже хороший вариант.
• Есть и совсем специфичные вещи типа Kata Containers (запускает контейнеры в легковесных виртуалках для изоляции) или Kubevirt (позволяет запускать полноценные ВМ внутри Кубера). Но это уже для особых случаев.

Рекомендация: начинайте с containerd. Это сейчас мейнстрим.

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

Сразу забудьте про использование локальных дисков на нодах для хранения важных данных в продакшене! Нода умерла — данные пропали.

То есть данные должны быть размазаны по кластеру или храниться в выделенном отдельном хранилище.

Кубер для работы с хранилищами использует стандартный интерфейс Container Storage Interface. Это позволяет подключать к нему самые разные системы хранения данных — как локальные, так и сетевые.

Базовое решение Ceph — очень популярное, мощное и надёжное распределённое хранилище. Наш опыт показывает, что это отличный выбор. Его можно развернуть отдельно, а можно прямо внутри Кубера с помощью специального оператора Rook. Rook сам поднимает все компоненты Ceph (мониторы, OSD на дисках нод) в виде подов и делает его доступным для Кубера через CSI. Мы у себя часто используем именно связку Ceph + Rook.

Всё это работает так. У вас есть приложение, работающее в контейнере внутри Kubernetes K8s. Этому приложению, например, базе данных, нужно место для хранения данных — скажем, пять гигабайт. Создаётся PVC (Persistent Volume Claim). Это как заявка на диск. Кубер понимает запрос и обращается к системе хранения данных (например, Ceph) через autoprovisioning с командой: «Создай диск на пять гигабайт». В Ceph создаётся блочный диск (RBD) и выделяется Куберу в виде его сущности PV (Persistent Volume). И уже этот PV подключается к поду.

Ceph — это распределённая система хранения, которая обычно устанавливается на те же серверы (узлы), где работают и сами контейнеры (сейчас мы — про Bare Metal). Она объединяет диски этих серверов в единое большое хранилище.

Хотя компоненты Ceph (например, процессы, управляющие отдельными дисками — OSD) могут запускаться в своих управляющих контейнерах (часто — с помощью инструмента Rook), сама система хранения тесно связана с физическими дисками и серверами. Когда контейнер падает, диск в Ceph остаётся. Когда падает целый сервер, данные сохраняются. Система не хранит всех данных на одном диске или узле: при записи копии данных «размазываются» по разным дискам на разных серверах. Мы сами выбираем, какой уровень репликации установить. Ceph автоматически обнаружит потерю OSD и начнёт перераспределять данные по оставшимся рабочим дискам, чтобы восстановить нужный уровень избыточности.

Если контейнер поднимется на другой машине после перезапуска, то новый экземпляр контейнера просто подключится к тому же самому постоянному тому (Persistent Volume), который был создан для него в Ceph. Данные на диске никуда не делись. Управление самим кластером Ceph — тоже отказоустойчиво. Есть специальные процессы-мониторы и манагер с репликами в режиме standby. Если сервер с главным манагером выходит из строя, то управление автоматически переходит к другому манагеру на другом сервере.

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

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

Ещё варианты:

• LinStor — ещё одно распределённое хранилище, и тоже с CSI-драйвером. Говорят, может быть производительнее Ceph в некоторых сценариях. Тоже достойный вариант.
• Если вы в облаке, то у провайдера есть свои CSI-драйверы для их блочных хранилищ (Amazon EBS, Google Persistent Disk, Azure Disk, etc.). Обычно это самый простой вариант в облаке. Причём их можно смешивать для разных условий и для разных типов данных.
• Более экзотичные GlusterFS, локальные диски через Local Persistent Volumes (только для специфичных задач!) и куча других вариантов.

Вы можете определить разные «классы» хранения (StorageClass), например, fast-ssd, slow-hdd, cloud-premium. А потом в манифесте для вашего приложения (в PersistentVolumeClaim) вы просто указываете имя нужного класса. Кубер через CSI-драйвер сам создаст диск нужного типа в соответствующем бэкенде (Ceph, облако, etc.). Это позволяет абстрагироваться от конкретной реализации хранилища.



Сеть
Если диски ещё более-менее понятны, то тут спотыкаются даже опытные админы. Сеть в Кубере — это, пожалуй, одна из самых сложных тем. Вам точно понадобятся хотя бы базовые знания сетей (IP-адресация, маршрутизация, файрволы).

Kubernetes создаёт свою собственную виртуальную сеть поверх вашей физической (или облачной) сети. Каждый под (контейнер) получает свой IP-адрес в этой виртуальной сети. И поды, запущенные на разных физических нодах, должны иметь возможность общаться друг с другом по этим виртуальным IP. Чтобы эта магия работала, нужно выбрать и установить CNI-плагин (Container Network Interface). Это такой софт, который и отвечает за настройку сети для подов. Наши фавориты:

• Cilium — очень мощный и быстрый плагин. Он использует новомодную eBPF прямо в ядре Linux, что даёт ему производительность и кучу фич (сетевые политики, шифрование, балансировка). У Cilium есть ещё крутой инструмент Hubble — это UI и CLI для визуализации сетевых потоков и зависимостей между сервисами. Супервещь для отладки, мы его любим.
• Calico — тоже очень популярный и зрелый плагин. Часто идёт по умолчанию во многих инсталляторах (например, в Kubespray). Умеет работать как с оверлейными сетями (VXLAN, IPIP), так и без оверлея, используя BGP-маршрутизацию, если ваша сеть это поддерживает. Тоже отличный выбор.
• Flannel (простой, для начала неплох).
• Weave Net, Antrea и куча других, в том числе специфичных для облаков (AWS VPC CNI, Azure CNI, GKE Netd).

В зависимости от выбранного CNI и вашей инфраструктуры вам может потребоваться разбираться с BGP, VXLAN, IPIP-туннелями, настройкой маршрутов и файрволов. Сеть — это то место, где можно застрять надолго. Как сказал один наш сетевик, когда разбирался с какой-то проблемой: «По идее должно быть так, но хрен его знает, иди копай». Эта фраза будет преследовать вас примерно везде по мере реализации.

«Я запустил Nginx в поде, как мне его открыть в браузере?»

В Кубере есть специальная штука — Service. Это абстракция, которая даёт постоянный IP-адрес и DNS-имя для группы подов (например, для всех реплик вашего веб-сервера) и умеет балансировать трафик между ними.

Типы сервисов:

• ClusterIP: сервис получает внутренний IP, доступный только изнутри кластера. Для внутренних бэкендов — самое то.
• NodePort: сервис открывает порт на каждой ноде кластера. Вы можете обратиться на IP_любой_ноды:NodePort и попасть на сервис. Неудобно, небезопасно, порты надо выбирать из определённого диапазона. Для продакшена — фу.
• LoadBalancer: вот это уже интереснее. Если вы в облаке, то при создании сервиса такого типа облачный провайдер автоматически создаёт вам внешний облачный балансировщик (ELB, Google LB, etc.), назначает ему публичный IP и направляет трафик на ваш сервис (точнее, на его NodePort на нодах). Очень удобно! А что делать, если у вас свой кластер на железе (Bare Metal)? Облачного балансировщика нет. Тут на помощь приходит MetalLB. Это такой специальный контроллер, который эмулирует облачный LoadBalancer. Вы выделяете ему пул IP-адресов из вашей локальной или публичной сети (если вы крутой и имеете свою публичную сеть), и когда создаёте сервис типа LoadBalancer, MetalLB берёт свободный IP из пула и «анонсирует» его в вашей сети (обычно через ARP или BGP), чтобы трафик на этот IP приходил на ноды вашего кластера. Обязательная штука для Bare Metal!
• Есть еще ExternalName, который использует DNS с кастомными параметрами, но даже в официальной доке предупреждают, что для некоторых протоколов типа http(s) могут быть проблемы. Мы его не используем.

Ingress — стандарт для публикации веб-приложений (HTTP/HTTPS) в продакшене. Ingress — это не тип сервиса, это отдельный ресурс в Кубере. Он работает как умный реверс-прокси или «входные ворота» для внешнего трафика. Он позволяет рулить трафиком на разные сервисы внутри кластера на основе хоста (например, api.mysite.com -> сервис API, blog.mysite.com -> сервис блога) или пути (mysite.com/app1 -> сервис App1, mysite.com/app2 -> сервис App2). Ingress также обычно отвечает за TLS-терминацию (SSL-сертификаты).

Чтобы Ingress заработал, вам нужно установить Ingress-контроллер. Это, по сути, и есть тот самый реверс-прокси, который читает Ingress-ресурсы и настраивает себя соответствующим образом. Самый популярный — Nginx Ingress Controller: знакомый многим Nginx, но специально заточенный под Кубер. Мощный, гибкий. Но! Будьте осторожны: недавно в нём находили неприятные уязвимости, позволяющие читать секреты из кластера. Это к важности своевременных апдейтов. Из других хороши HAProxy Ingress, Traefik (очень популярен, умеет сам получать Let's Encrypt-сертификаты), Contour и другие.

Настроить Ingress, сертификаты, DNS — это тоже задача не на пять минут. А если обратиться к официальной документации, то она рекомендует идти не в Ingress, а в Gateway API. Тут может показаться, что надо начать с него, и даже есть классные GUI для Gateway API, и хорошо бы ими воспользоваться! Но погодите )

Gateway API — это относительно новая спецификация в Кубере, которая со временем должна заменить или дополнить Ingress. Она более гибкая, позволяет разделять ответственность по маршрутам для разработчиков. Выглядит перспективно. Но я бы пока советовал не лезть в экзотику типа Kong Gateway. Да, у него есть красивый UI, что подкупает в мире консольного Кубера. Но он ломает саму идеологию Кубера с его декларативными манифестами в etcd и использует другую логику представлений. Лучше освоить стандартный Ingress с Nginx или Traefik, а к Gateway API присматриваться постепенно по мере накопления опыта. Есть реализации на базе того же Nginx, Envoy (Istio, Contour), HAProxy. Если разбираться с Gateway API, то лучше начать с них.

Кусок информационной безопасности
Пароли от баз данных, ключи к внешним API, всякие токены — ни в коем случае нельзя хардкодить в коде приложения (если кто-то ещё так делает и не был распят) или пихать прямо в YAML-манифесты! Этим вы создаёте огромную дыру в безопасности.

Для этого в Кубере есть специальные объекты:

• Secrets — для хранения чувствительных данных (пароли, токены, TLS-сертификаты). Они хранятся в etcd в base64 (что не шифрование!), но Кубер предоставляет механизмы для их шифрования «at rest» и контроля доступа к ним через RBAC.
• ConfigMaps — для хранения нечувствительной информации конфигурации (URL’ы, параметры, конфиг-файлы целиком).
• Продвинутый уровень: можно интегрировать Кубер с внешними системами управления секретами, например, HashiCorp Vault, с помощью специальных инструментов (Vault Agent Injector, External Secrets Operator). Это даёт централизованное управление, ротацию секретов и т.д.

Вы можете «подсунуть» данные из Secrets и ConfigMaps вашему приложению как переменные окружения для контейнера или как файлы, смонтированные в определённую директорию внутри контейнера.

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

Но идеальный сценарий — это когда, например, кластер Cassandra создаётся автоматически через оператор типа k8ssandra, и приложение берёт креды для доступа из секрета, созданного оператором при запуске кластера. Ни в БД, ни в приложение ручками их никто не прокидывает.

Аутентификация и авторизация
В вашем кластере наверняка будут работать разные люди: DevOps/SRE, разработчики команды А, разработчики команды Б, может быть, QA-инженеры… Кто может деплоить приложения, кто может смотреть секреты, кто может удалять ноды?

• Аутентификация. Сертификаты X.509, токены (статичные, JWT, через OIDC-провайдера типа Keycloak или Dex), интеграция с LDAP/AD.
• Авторизация (RBAC — Role-Based Access Control). Вот это — самое главное. RBAC позволяет очень гибко настроить, что (какие действия: get, list, create, update, delete) с какими ресурсами (pods, services, secrets, nodes, etc.) в каких неймспейсах (или во всём кластере) и кто может делать (какой пользователь, группа или сервисный аккаунт). Вы создаёте Роли (Roles) или Кластерные Роли (ClusterRoles), где описываете набор разрешений. Затем вы создаёте Привязки Ролей (RoleBindings) или Кластерные Привязки (ClusterRoleBindings), чтобы связать роль с конкретным пользователем, группой или сервисным аккаунтом.
• Namespaces: используйте неймспейсы для логической изоляции ресурсов разных команд, проектов или окружений (dev, stage, prod). Это помогает упорядочить кластер и упрощает настройку RBAC (роли можно создавать внутри неймспейса). Хотя для окружений более правильно и эффективно использовать разные кластеры (опять же привет, облака).
• Золотое правило — минимальные привилегии. Давайте пользователям и сервисным аккаунтам только те права, которые им реально необходимы для выполнения их задач. Не надо всем раздавать cluster-admin: это прямой путь к катастрофе.

Observability
Вот мы и приехали к той самой волшебной части. Работать с кластером Kubernetes без настроенной системы мониторинга и логирования — это посадить админом слепого котёнка.

Метрики:

• Нужен Metrics Server — это базовый компонент (обычно ставится аддоном), который собирает основные метрики использования ресурсов (CPU, RAM) с нод и подов. Он нужен как минимум для работы kubectl top и базового HPA.
• Стек Prometheus + Grafana — это де-факто стандарт для сбора, хранения и визуализации метрик в мире Кубера. Prometheus — это база данных временных рядов, которая сама опрашивает метрики с разных источников (ноды, поды, сервисы). Grafana — инструмент для построения красивых дашбордов на основе данных из Prometheus (и не только).
• Приложения должны сами отдавать метрики в формате, понятном Prometheus (обычно это текстовый формат по HTTP-эндпоинту /metrics). Не только CPU/RAM, но и специфичные для приложения: количество запросов в секунду, время ответа, размер очереди, количество ошибок, бизнес-метрики. Без этого ваш мониторинг будет неполным.

А я предупреждал )

Логи:

• Контейнеры в Кубере обычно пишут логи просто в stdout и stderr. Эти логи собираются движком контейнеров (containerd/docker) и доступны через kubectl logs. Но смотреть логи каждого пода по отдельности — это ад.
• Нужен централизованный сбор логов. Необходимо настроить агентов (например, Fluentd, Fluent Bit, Promtail), которые будут бегать на каждой ноде, собирать логи из файлов или напрямую от движка контейнеров и отправлять их в центральное хранилище.
• Популярные варианты хранилищ логов — Elasticsearch (в составе стека ELK/EFK: Elasticsearch + Logstash/Fluentd + Kibana) или Loki (от создателей Grafana, хорошо интегрируется с Prometheus, обычно используется в стеке LGTM: Loki + Grafana + Promtail).

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

Трассировка. Если у вас микросервисная архитектура, то один запрос пользователя может проходить через десяток разных сервисов. Чтобы понять, где именно возникла задержка или ошибка, нужна распределённая трассировка. Инструменты: Jaeger, Zipkin, Tempo.

Конечно, приложения должны уметь принимать и передавать дальше специальные заголовки (trace ID, span ID) и отправлять информацию о своих операциях (спанах) в коллектор трейсов. Это тоже требует доработки кода.

Масштабирование
Ну что, база есть, доступ настроен, всё видно. Теперь можно и фишками обмазаться.

Устали поднимать руками и настраивать PostgreSQL, Kafka, Redis, Elasticsearch в Кубере? Следить за их состоянием, бэкапами, обновлениями? Для этого придумали операторов. Оператор — это, по сути, ваш кастомный контроллер внутри Кубера, который знает, как управлять определённым типом сложного приложения. Он расширяет API Кубера с помощью Custom Resource Definitions.

Работает это так:

• Вы устанавливаете CRD для, скажем, PostgreSQL. Теперь Кубер знает о новом типе ресурса, например, PostgresCluster.
• Вы устанавливаете сам Оператор PostgreSQL (это обычное приложение, работающее в поде).
• Вы создаёте простой YAML-файл, где пишете — kind: PostgresCluster, name: my-db, spec: { replicas: 3, version: «15», storage: «fast-ssd» }.
• Применяете этот YAML (kubectl apply-f).
• Оператор видит, что вы создали новый ресурс PostgresCluster, и начинает действовать: создаёт нужные StatefulSets/Deployments, заказывает диски (PersistentVolumeClaims) нужного StorageClass, настраивает сервисы для доступа, конфигурирует репликацию, может настроить бэкапы и мониторинг — в общем, делает за вас всю грязную работу по развёртыванию и поддержке сложного stateful-приложения.

Существует огромное количество готовых операторов от сообщества и вендоров для баз данных, очередей, мониторинга, CI/CD — да чего угодно! Это очень мощный механизм расширения Кубера. Для совсем уж специфичных внутренних систем можно даже написать свой оператор (но это уже высший пилотаж).

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

• Горизонтальное автомасштабирование подов (HPA — Horizontal Pod Autoscaler) — самый частый и полезный вид. Вы создаёте HPA-ресурс и говорите: «Хочу, чтобы количество реплик моего приложения my-app было от двух до десяти, и чтобы оно масштабировалось, если средняя загрузка CPU по подам превысит 70 % (или RAM, или кастомная метрика из Prometheus, например, длина очереди)». Кубернейтс сам будет следить за метриками и автоматически добавлять или удалять поды my-app в указанных пределах.
• Вертикальное автомасштабирование подов (VPA — Vertical Pod Autoscaler). Менее популярный, но тоже бывает полезен. VPA анализирует реальное потребление ресурсов подами и может автоматически изменять requests и limits по CPU/RAM в манифесте пода. Чаще используется в режиме «рекомендаций», чтобы понять, сколько ресурсов реально нужно приложению. Использовать VPA вместе с HPA нужно осторожно: они могут конфликтовать.
• Масштабирование кластера (Cluster Autoscaler). Это уже про добавление и удаление целых серверов (нод) в кластер. Работает так: если в кластере появляются поды, которые не могут никуда запланироваться (состояние Pending) из-за нехватки ресурсов (CPU, RAM) на существующих нодах, то Cluster Autoscaler замечает это и автоматически заказывает у облачного провайдера новую ноду (или несколько), ждёт, пока она не поднимется, и добавляет её в кластер. Поды тут же планируются на неё. И наоборот: если Cluster Autoscaler видит, что какие-то ноды долгое время недозагружены и все их поды можно переместить на другие ноды, то он может автоматически удалить эти лишние ноды, чтобы сэкономить деньги. Это главная фишка облачных Managed Kubernetes. Там это обычно работает «из коробки». Если у вас свой кластер — на железе или виртуалках, то заставить Cluster Autoscaler работать можно, но сложнее. Нужно использовать Cluster API. Это такой проект, который позволяет управлять жизненным циклом кластеров Kubernetes (в том числе создавать и удалять ноды) с помощью самого Kubernetes. Cluster API имеет провайдеров для разных инфраструктур (vSphere, OpenStack, AWS, Azure, Bare Metal через Tinkerbell/MAAS). Но это отдельная большая тема.

Кстати, тут надо передать пламенный привет некоторым российским облакам. У них часто есть довольно смешные лимиты на максимальное количество нод в одном Managed-кластере: где-то — 100 (привет, ТаймВеб), где-то — вообще 32 (Яндекс). А Кубер, на минуточку, сам по себе спокойно тянет 5 000 нод в кластере и 150 тысяч подов и даже не поперхнётся (по официальным тестам). У ВК вроде лимит побольше — 500 нод, у Сбера — 249 (хотя в доке пишут, что 500). Всё равно не 5 000. У нас в H3LLO CLOUD мы постарались эту проблему решить и даём возможность строить реально большие кластеры, близкие к максимальным возможностям Кубера.


Думаете, это конец?
Нет, это начало.

Развернули кластер, настроили сеть, сторадж, мониторинг? Поздравляю! Вы прошли… ну, скажем, разминку.

• Короткий анонс. Приложения должны быть готовыми жить в динамичной эфемерной среде Кубера. Почитайте про 12-factor app — это мастхэв. Приложение должно:
• Читать конфиги и секреты из окружения или файлов (никаких локальных config.xml!).
• Писать логи в stdout/stderr (а не в файлы!).
• Быть максимально stateless (состояние хранить во внешних базах, кэшах, хранилищах).
• Быстро стартовать.
• Корректно обрабатывать сигналы SIGTERM для graceful shutdown.
• Уметь отдавать метрики для мониторинга (health checks, readiness/liveness probes).
• Быть упаковано в легковесный Docker-образ.

Вам нужны конвейеры, которые будут автоматически:

• Собирать Docker-образы вашего приложения при коммите в Git.
• Пушить образы в Docker Registry (типа Harbor, GitLab Registry, Docker Hub).
• Обновлять YAML-манифесты (Deployments, StatefulSets, Services, Ingresses) с новой версией образа.
• Деплоить эти манифесты в Kubernetes (например, с помощью kubectl apply, Helm, Argo CD, Flux).
• Проводить тесты после деплоя.
• Обеспечивать лёгкий откат на предыдущую версию.

Инструментов для этого — море: Jenkins, GitLab CI, GitHub Actions, Tekton, Argo CD, Flux…

В идеальном розовом мире единорогов ваши разработчики вообще не должны знать слова «Kubernetes». Они просто пишут код, коммитят в Git, а дальше некая «платформа» сама всё собирает, тестирует и выкатывает куда надо. Нажал кнопку — получил фичу в проде. Достичь такого уровня абстракции — это Грааль платформенного инжиниринга. Это требует не только зрелого Кубера со всеми обвесами, но и глубокого понимания ваших приложений, процессов разработки и кучи инструментов поверх Кубера (часто это называют Internal Developer Platform). Это долгий и сложный путь.

А оно вообще того стоит? Если у вас реально сложная, большая, динамичная система, которая должна быть отказоустойчивой, масштабироваться под нагрузкой, часто обновляться без простоя, то однозначно — ДА, стоит. Головной боли на старте будет много, но потом вы получите такие гибкость, скорость и надёжность, которых другими путями добиться очень сложно, если вообще возможно. Вы реально сможете выкатывать фичи быстрее и спать спокойнее (но это неточно).

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

• L1VESTACK или другой контейнерный хостинг — тут мы пошли по пути максимального упрощения: полностью спрятали оркестратор под капот. Вы просто даёте нам свой docker-compose.yaml (да-да, прямо его!) или используете наш простой CLI — и ваше приложение магическим образом разворачивается и работает на нашей инфраструктуре. Вообще не надо думать ни про ноды, ни про сети, ни про стораджи, ни про Ингрессы, ни про RBAC. Просто код и деплой. Идеально для тех, кто хочет «просто чтобы работало». Естественно, нет фишек инфраструктуры для продвинутых, потому что вы запустили контейнер, который работает.
• H3LLO.CLOUD — на нашей платформе есть Managed Kubernetes. Здесь мы не прячем Кубер полностью, но берём на себя самую нудную и сложную часть: бутстреппинг, Control Plane, etcd, обновления базовой системы, обеспечение работы сети и хранилища, предоставляем автомасштабирование нод «из коробки». Вам всё ещё нужно понимать основные концепции Кубера (поды, сервисы, деплойменты) и уметь пользоваться kubectl, но основную инфраструктурную рутину и сложность мы снимаем. Это хороший баланс между контролем и удобством.

Что почитать или посмотреть

• Для старта — Minikube.
• Запуск Кубера без заморочек — kubespray.
• Концепции Кубера из первоисточника — курим доку. Начать лучше с туториала, а потом читать Concepts и Tasks.
• Хорошая книга — Production Kubernetes. Есть на русском.
• Глубже по сетям — Networking and Kubernetes.
• Тоже есть на русском.
• GUI для Кубера — Lens
• The Twelve-Factor App

Жирнющие бесплтаные лимиты на облачные сервисы на целый год, включая Managed Kubernetes — H3LLO.CLOUD.

Не менее щедрые лимиты на платформу для запуска приложений в контейнере — L1veStack.

beta.h3llo.cloud
h3llo.cloud

В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.

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


Пример проекта с прикручиванием аналитики к инфраструктуре:

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

И всё.

А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами.
Качество LLM-кодинга сильно зависит от языка программирования
Главная проблема — объём блока (точнее, зависимостей) и нормальная обучающая выборка.

Scala
Попытки написать на Scala работающий микросервис по OpenAPI-спецификации провалились.

Модель генерирует код, он не компилируется. Скармливаешь ошибки компиляции — следующая итерация кода содержит ещё больше ошибок.

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

Попытки транслировать код с другого языка (например, с Go) в Scala тоже могут быть проблематичны, особенно если требуется сохранить функциональный стиль Scala — на понятиях PHP, например, такое просто не опишешь.

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

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

• Go — очень квадратно-гнездовой язык. Задачу чаще всего можно решить одним, максимум двумя способами. Нет такого разброса стилей и подходов, как в Scala или даже JS. Это упрощает обучение для LLM: меньше вариативность «правильных» ответов на один и тот же запрос. Эта прямолинейность отличается от C, который хотя и прост на первый взгляд, как автомат Калашникова, но позволяет легко «провалиться» на низкий уровень, иногда незаметно. Go тоже позволяет уйти в сторону ассемблера, но при решении стандартных задач он очень явно описывает путь.
• Строгая стандартизация. Встроенный форматер (gofmt), линтеры (golint), общепринятые конвенции — всё это делает кодовую базу на Go очень однородной. Это лучше, чем в Python, где тоже есть линтеры, но вариативности в написании больше. В Go сама идея языка была в том, чтобы код легко читался всей командой.
• Качественная и большая обучающая выборка. Огромное количество успешного Open Source написано на Go (Kubernetes и вся его экосистема, Docker, Prometheus, Terraform и т.д.). Вероятно, этот код использовался для обучения моделей с высоким весом, возможно, даже с усилением (как если бы Википедию добавили в базу 10 раз).
• Меньше «говнокода». Возможно, Go — язык более молодой, его чаще выбирают уже более опытные разработчики для серьёзных проектов (это сейчас слабое допущение). В отличие от Python или JS, куда порог входа ниже и больше новичков, генерирующих код не самого высокого качества, который тоже попадает в обучающие выборки. Плюс сам язык Go меньше прощает ошибок и не провоцирует написание «кривого» кода так, как это делает, например, JS. Сам язык как бы «не предусматривает» говнокода в той же мере.
• Почему мы сами выбрали Go — бинарники маленькие, памяти ест мало, работает быстро. Хотя и PHP последних версий тоже компилируется, но это отдельный спор. До сих пор, кстати, не утих другой холивар — можно ли считать PHP языком программирования или нет. Я придерживаюсь мнения, что можно. Но пишем мы преимущественно на Go.

Rust
Тоже хайповый современный язык. LLM генерят код, который проходит проверку синтаксиса в IDE. Но при попытке сборки (которая в Rust сложнее, чем в Go) вылезает куча ошибок. И вот с исправлением этих ошибок сборки LLM справляются хуже, чем с написанием изначального кода или исправлением ошибок в Go. Вероятно, дело опять же в сложности языка и, возможно, пока ещё менее репрезентативной выборке кода с решёнными проблемами сборки.
Экспериментировали мы не очень много.

Java
Самая интересная ситуация, показывающая принципы LLM-кодинга.
Проблема — в структуре типичного Java-проекта: там везде глубокая вложенность пакетов, сложные цепочки наследования. Чтобы понять, что происходит в одной функции, LLM нужно проанализировать много связанного кода.
Это требует огромного окна контекста: меньше 64к токенов — почти бесполезно для серьёзного Java-кодинга. К счастью, модели с большими окнами появились.
Ещё нужны агенты для исследования кодовой базы. Инструменты вроде Cursor, Cline позволяют LLM «ходить» по проекту. Но и тут проблема: системный промпт агента (который сам по себе может быть большим, на тысячи токенов), прочитанные файлы классов и интерфейсов, дерево проекта — всё это быстро забивает даже большое окно контекста, особенно учитывая, что в Java много мелких лексем (точки, скобки), каждая из которых — токен.
То есть сама структура проектов на Java такая, что нужно не только смотреть тот блок, где сейчас идёт редактирование, но и держать «в голове» вообще всё то, что происходит в зависимостях. Это, кстати, причина тех самых мемов про состояние потока программиста. Вот у LLM то же самое.

Идеальное решение (которого пока нет в массовом использовании) — агенты, способные хранить состояние проекта в долговременной памяти, а не только в текущем окне контекста. Тогда LLM сможет «помнить» всю структуру и историю изменений. Сейчас же каждый новый агент начинает почти с нуля.
Сравните с Go: там часто достаточно контекста одного файла + импортов, чтобы понять, что происходит. Добавьте нашему вымышленному программисту не только отвлекающие звонки, но и болезнь Альцгеймера, чтобы он забывал задачу каждые 15 минут, — и вы получите примерное представление о LLM-кодинге на Java.

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

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

Про Python рекомендую вот эту публикацию.
github.blog/news-insights/octoverse/octoverse-2024/



Что получается
Для Go-проектов и ряда других LLM уже применимы на уровне мидлов, которые хорошо кодят, но которым надо давать точное техническое задание.

От разработчика нужны глубокие архитектурные знания и умение делать качественное ревью, иначе никак.

Если это есть и он готов выступать тимлидом LLM-агентов, то эффективность растёт в разы.

Разработчик общается с LLM так же, как раньше с джунами — ставит задачу, проверяет, корректирует.

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

Код-ревью становится важнее: генерируемый код нужно внимательно читать.

Понимание архитектуры и умение читать чужой код становятся критически важными.

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

Результат: проект, который силами небольшой команды делался бы минимум месяц до начального рабочего состояния, у нас был собран за три дня. Ещё примерно столько же ушло на ревью (в том числе по ИБ), ручное тестирование крайних случаев и подготовку к продакшену. Затраты на токены — около 150 $.

Уверенность в коде? После моего ревью — высокая. Если сравнивать сгенерированный код до ревью с кодом джуна до ревью — уверенности в LLM-коде у меня больше. Он сразу пишет с учётом observability, тестов, лучших практик (если правильно попросить), даже с интеграцией токенов для защиты вызовов. Джуна этому ещё учить и учить.

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

Правильное техническое задание становится самой дорогой и важной частью.

Пайплайн «задача -> реализация» у нас уже радикально упростился. При обсуждении фич мы меньше зависим от опыта конкретного разработчика в конкретной технологии. Нужно интегрировать Cassandra? Не проблема, даже если у человека нет 5 лет опыта с ней. LLM выдаст «курс молодого бойца», поможет спланировать интеграцию, сгенерирует код. Разработчик контролирует процесс, вносит правки с учётом специфики нашего Go-кода. Стек стал гибче. Мы можем выбирать лучшие технологии под задачу, не ограничиваясь текущими знаниями команды. LLM помогает быстро вкатиться и интегрировать. Разработчик при этом получает реальный опыт с новыми инструментами.

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

За один спринт (две недели) команда делает то, что раньше заняло бы месяц, и это при работе над новым проектом с нуля. Создать новый микросервис по образу и подобию существующих? Даёшь LLM пример, и он генерирует всю обвязку. Остаётся наполнить бизнес-логикой.

Время разработчиков перераспределилось: меньше совещаний (экономия оценивается примерно в 8 часов за две недели на человека), так как синхронизироваться по архитектуре нужно меньше.

И давайте ещё раз: меньше совещаний. Это важно. Синки только по необходимости.

Освободившееся время уходит на ревью, продумывание сложной логики и тот самый «вайб-кодинг» — параллельную работу, где на одном экране код генерит LLM, на другом — правишь или пишешь сам, потом меняешься ролями для ревью. Работа становится более «дирижёрской». Даже DevOps-задачи частично можно переложить на LLM (генерация Dockerfile, K8s-манифестов).

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

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

Как мы теперь нанимаем
Мы требуем уметь хорошо кодить руками на входе.

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

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

Этап джуна придётся проскакивать на тренировках, а не на реальных проектах.

Сам промпт-инжиниринг из области заученных лайфхаков превратился в умение сформулировать задачу. Модели достаточно развились, чтобы понимать свободные формулировки. Осталось только внести в них смысл — ради смысла и нужен профессионал. Нужно декомпозировать задачу, учесть все нюансы: версии библиотек и фреймворков (сказать: «Next.js», не уточнив App Router vs Pages Router — получить не то), протоколы взаимодействия (не указать gRPC — получить HTTP по умолчанию), конкретные требования к архитектуре, базам данных, безопасности.

Промптинг становится итерационным. Мы часто сначала генерируем верхнеуровневую архитектуру (например, в Markdown), правим её руками. Потом генерируем схемы взаимодействия между микросервисами (Protobuf, GraphQL, OpenAPI, SQL DDL) — это становится критически важным шагом, и только потом используем эту схему как часть промпта для генерации кода самих сервисов. Потом — документацию. Потом генерируем тесты (интеграционные тут особенно важны). Потом — структуру файлов и сигнатуры функций с комментариями. И только потом — сам код.

У новых людей меняется отношение к коду. Он становится расходным материалом, а не домашним питомцем — если что-то пошло не так, часто проще откатиться, доработать промпт и сгенерировать заново (иногда и 10 раз), чем пытаться исправить сложный баг в машинном коде.

Ценность навыка написания кода снижается в пользу навыка чтения чужого кода. Однако и тут есть нюанс: после оперативного запуска нового кода ценность смещается в сторону знания кодовой базы. И именно этот фактор делает разработчиков незаменимыми (вспоминаем про bus factor, которого боятся все инвесторы).

Тим О'Райли недавно написал отличную статью о том, как меняется кодинг. Его мысль перекликается с нашими наблюдениями: LLM — это следующий уровень абстракции после фреймворков. Если раньше многие разработчики использовали фреймворк, не до конца понимая, как он работает «под капотом», то скоро появится целый класс специалистов, которые будут «просить LLM сделать», не зная деталей реализации. Программирование как навык и как бизнес ждут серьёзные трансформации в ближайшие 5–10 лет. Да, похожие вещи говорили с появлением BASIC и других высокоуровневых языков, и это нормально — каждая такая революция меняла ландшафт.

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

beta.h3llo.cloud
h3llo.cloud

Вам станут доступны бесплатно на год:

• 2 виртуальных машины с 2 vCPU и 4 ГБ RAM
• 40 ГБ сетевого диска
• объектное хранилище на 50 GB
• белый статический IPv4

Запускаем последнее в России коммерческое облако. Успейте войти в число бета-тестеров и на целый год мы предоставим не только большой объем бесплатных ресурсов, но и скидку до 90% на все сервисы.



beta.h3llo.cloud

Мы тут запускаем последнее в России коммерческое облако, и один из побочных эффектов этого процесса — настраиваем тесты всех конкурентов, чтобы понимать объективную картину. Прошлый тест был про переподписку ядер процессора, и он вызывал нехилое такое пригорание пятой точки у суперпереподписанного Таймвеба (хотя по цене за производительность они оказались вполне в порядке).

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

Облака в тесте:

• Selectel.
• Cloud.ru.
• Timeweb.
• VK.
• Yandex.
• Rostelecom.
• H3LLO.CLOUD.

Коротко о результатах


Radar chart по трём показателям: производительность, стоимость к производительности и задержка инвертированная. Больше площадь — лучше

• Timeweb показал одну из самых низких производительностей, но при этом снова хорошую цену за единицу вычислений.
• VK Cloud и Яндекс оказались аутсайдерами: и производительность не впечатляет, и стоит дорого. У Яндекса есть ограничитель на максимальную производительность.
• Потом вы просили добавить нас в тесты, чтобы потом можно было предъявить, если что, и мы добавили. Нам надо было установить цену для своих тарифов, мы взяли её как медианное значение между Cloud.ru и Selectel.

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

Потому что вы нас немного заклевали за подход «херак-херак и в продакшен» на первом тесте. Хотя он вполне решал свою задачу — оценить производительность связки vCPU-RAM на машинах с одинаковыми характеристиками у разных провайдеров. Или, проще говоря, выяснить, кто же больше охренел )

В общем, методология. Сразу решили не изобретать велосипед и взяли встроенный в PostgreSQL тест pgbench. Он создаёт три таблицы разного размера, которые отличаются друг от друга в 10 и в 100 000 раз по числу записей. Выбрали фактор масштабирования 200, и это дало нам таблицы размером 200, 2000 и 20 миллиона записей. Достаточно, по нашему мнению, чтобы проверить, как облака справляются с нагрузкой.

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

• База данных Postgres 16.
• 4vCPU + 16 Гб RAM + 40 Гб SSD (где был выбор между дефолтным флейвором БД и настраиваемым сайзингом, мы выбирали дефолтный флейвор).
• Где был выбор между Ice Lake vs Cascade Lake мы выбирали Ice Lake.
• Без пулинга, репликации и бекапов.
• Без тонкой настройки дополнительных параметров конфигурации Postgres.
• Для бенчмаркинга выбрали стандартный pgbench, который входит в состав Postgres.
• Для минимизации времени отклика pgbench запускался из виртуальных машин находящихся в той же приватной подсети, что и Managed Postgres, без SSL.
• Проводили 4 итерации: 1 разогревочная + 3 фактических.
• Бенчмаркинг проводился в рабочее время.

4 стандартизированных нагрузки pgbench:

• default, «Стандартная нагрузка TPC-B»
• simple_update, скрипт обновляет баланс в таблице `pgbench_accounts`
• select_only, скрипт выполняет выборку данных из таблиц `pgbench_accounts`, `pgbench_branches` и `pgbench_tellers`
• complex_write, скрипт обновляет балансы в таблицах `pgbench_accounts`, `pgbench_tellers` и `pgbench_branches`, моделируя сложную транзакцию

Отказались от использования 2 нагрузок, поскольку по результатам предварительных тестов бенчмаркинга они не добавляли информативности к результатам от уже существующих стандартных тестов, а только удлиняли бенчмаркинг:

• join_heavy: скрипт выполняет соединение таблицы `pgbench_accounts` самой с собой несколько раз, что позволяет оценить производительность при выполнении joins
• insert_with_indexes: скрипт вставляет новую запись в таблицу `pgbench_history` и обновляет баланс в таблице `pgbench_accounts`, что позволяет оценить производительность при выполнении операций вставки и обновления с использованием индексов

Измеряли 2 метрики:

• Количество транзакций в секунду (TPS): Сколько операций база данных может выполнить за одну секунду.
• Время отклика запросов: Сколько времени требуется базе данных для выполнения запроса.

Коэффициент стоимости считался в руб/час/TPS.

Параметры бенчмаркинга:

• scale factor = 200 (это значит что в базе будут 3 таблицы, по 20 млн записей, 2 тыс. записей и 200 записей соответственно).
• Одновременные клиенты базы данных client_counts = [16, 32, 64].
• Рабочие потоки thread_counts = [32, 64, 128].
• run_time одной итерации = 30 секунд.

Всего для каждого провайдера было проведено 108 тестов: 3 различных client_counts * 3 различных thread_counts * 4 типа нагрузки * 3 итерации.

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

В Timeweb такой возможности вообще не было. Так что мы до сих пор не знаем, тестировали мы их с пулингом или без.

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

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

На новых всё запускалось предельно плохо, непонятно, с какими-то невнятными ошибками уровня «обратитесь в поддержку, мы не можем что-то создать». Решение такое: старые аккаунты мы не удалили, но убрали из них старые организации и перевоссоздали новые организации в рамках старого аккаунта. И там всё было совершенно иначе. Вообще другой UX.

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

Мы не делали ничего необычного — просто запускали стандартный pgbench, который создаёт нагрузку не больше, чем обычное приложение. Примерно так интернет-магазин обращается к своей базе данных. На следующий день Timeweb нас разблокировал, и мы попытались запустить тесты уже с виртуальной машины внутри их сети. И тут произошло что-то странное: они сделали что-то со своим кластером managed db, что он вдруг резко стал показывать производительность гораздо выше, чем всё, что у нас было в тестировании — даже выше, чем наш собственный локально размещённый сервер GEN11 на Xeon 6430.

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

Ростелеком — наш гомерический смех продолжается! Их мы вообще исключили из теста. Потому что снова бюрократия. Мы не смогли запустить облако. Потому что база данных до сих пор на согласовании у их менеджера.

Казалось бы, 21-й век. Но нет, Ростелеком продолжает жить в эпохе «ждите звонка менеджера». Я готов предположить, что они так сделали для того, чтобы избежать потока людей с непонятной репутацией.

Результаты
Зависимость скорости транзакции к задержке


Количество транзакций в зависимости от соединений


Количество транзакций в секунду по типам нагрузки


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


Отношение стоимости к производительности


Распределение количества транзакций в секунду


Среднее количество транзакций по провайдерам


Средние задержки по провайдерам


По результатам тестов явно выделились два лидера: Клаудру и Селектел с практически идентичными показателями. Разница между ними была в пределах статистической погрешности.

ВК Cloud оказался примерно на 30–40% ниже лидеров. Это, кстати, полностью коррелирует с нашими предыдущими тестами виртуальных машин на Geekbench — похоже, у ВК просто железо послабее.

С Яндексом получилась совершенно абсурдная ситуация. Как только мы пытались подключить 64 клиента — тесты валились с ошибками. Мы просто не могли провести полноценное тестирование, отрезав весь верхний диапазон производительности. Как это интерпретировать? Да никак. Как будто вы пришли тестировать машину на автодроме, а вам говорят: «Извините, больше 60 км/ч ехать нельзя, у нас такие правила».

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

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

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


Дисклеймер

Важный момент: все тесты мы проводили только в рабочие дни и только в дневное время.

Никаких ночных или выходных измерений.

Ограниченное количество конфигураций тестов: 3 варианта thread counts и 3 варианта client counts, только 1 вариант scale factor. Фиксированная конфигурация — тестировалась только одна конфигурация CPU/RAM/SSD (4vCPU + 16 Гб RAM + 40 Гб SSD).

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

Длительность исследования (несколько дней) и продолжительность итерации (30 секунд) могут быть недостаточны для выявления снижения производительности в долгосрочной перспективе. Мы включили 3 итерации для статистической значимости плюс 1 предварительная прогревочная итерация.

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

Итого: тест — не измерительный инструмент, а ориентир! Результаты стоит рассматривать как примерный подход. Если вы выбираете хостинг для своего проекта, лучше провести собственное тестирование с учётом специфики вашей нагрузки.

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

h3llo.cloud
auth.h3llo.cloud/register

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

Это значит, что можно запустить приложение с одним набором зависимостей, а рядом — второе с другим. Это значит, что можно сохранить все связки приложения, упаковать его в контейнер и деплоить где угодно — и знать, что оно точно запустится. Есть нюансы с переходом между ARM-архитектурой и x86, но в целом контейнеры универсальны.

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

К контейнерам монтируются свои ресурсы — диски, сети, конфиги и секреты.

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

Рои контейнеров могут масштабировать крупные корпоративные проекты, про это ниже.

И, наконец, никакой современный CI/CD почти не делается без контейнеров. Системным администраторам, DevOps-инженерам, разработчикам и СТО критически важно разобраться в контейнеризации.

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

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

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

И здесь на сцену выходят контейнеры — технология, которая объединяет эти миры. Но чтобы в 2025 году оставаться в игре, нужно не просто знать, что такое Docker. Нужно понимать всю экосистему — от простейших контейнеров до оркестрации в Kubernetes и интеграции с нейрокодингом.

Сначала у нас были физические серверы — железки, которые занимали целые стойки. Хочешь новое приложение? Покупай новый сервер. Нужно больше мощности? Апгрейдь железо.

Потом пришла виртуализация и изменила правила игры. Теперь на одном физическом сервере можно запустить несколько виртуальных машин с разными операционками. Это был прорыв: меньше железа, больше гибкости, лучше утилизация ресурсов.

Но виртуализация принесла и свои проблемы. Каждая виртуалка — это полноценная операционная система со всеми потрохами. Это гигабайты дискового пространства, сотни мегабайт оперативки только на старте и заметное время запуска.

Виртуалки — штука классная, но у них есть несколько серьёзных ограничений:

• Проблемы масштабирования. Допустим, у вас «чёрная пятница» и нагрузка выросла в три раза. С виртуалками у вас два пути: либо увеличить ресурсы существующей машины (ресайз), либо клонировать её. Оба варианта требуют времени и дополнительной настройки.
• Сложности с зависимостями. Представьте: у вас на одном сервере два приложения. Одному нужна Java 8, другому — Java 11. С виртуалками решение одно: две отдельные виртуалки. Это лишние ресурсы и головная боль с администрированием.
• Неэффективное использование ресурсов. Каждая виртуалка жрёт ресурсы даже в простое, потому что крутит полноценную ОС. Это как держать заведённую машину на парковке.

Разница между виртуализацией и контейнеризацией

Здесь важно понять ключевую разницу в подходах.

Виртуальные машины — это «домашние питомцы». Вы их поднимаете, называете по имени, заботитесь об их здоровье, бьётесь над их аптаймом. Вы знаете их всех в лицо, все ваши восемь виртуалок. Стараетесь, чтобы они прожили как можно дольше.

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

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

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

Существует даже кейс с очень коротким жизненным циклом контейнера: за 1–2 секунды поднимается контейнер, отрабатывает запрос, умирает. Это крайне удобно. Так делают на платформах приложений и в CI/CD-pipeline.

Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС. Для изоляции контейнеры используют не возможности железа (как виртуалки), а возможности ОС — так называемое пространство имён. Например, Docker использует cgroups в ядре Linux.

Виртуалка весит гигабайты, контейнер — мегабайты. Postgres в контейнере (без нагрузки) — всего 9 мегабайт оперативки. Девять! Это просто смешно по сравнению с полноценной виртуалкой.

Виртуалки запускаются минуты, контейнеры секунды.

Но самое главное — портативность между различными средами. «У меня локально работает, а на проде — нет». С контейнерами такое почти исключено. Запаковали приложение в контейнер, и оно будет работать одинаково, что у вас на ноуте, что на тестовом сервере, что в продакшне.

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

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

Вот почему они такие крутые.

Первые шаги: знакомство с Docker’ом

Сначала вы не понимаете, зачем нужен Docker и все эти статьи на Хабре про него. Скачиваете его из любопытства, долго пытаетесь разобраться, как создать свой первый контейнер. Потом замечаете, что запустить Postgres в Docker — это мизинцем левой ноги, когда в обычной установке это адская головная боль.

Docker и GUI к нему (Docker Desktop) можно поставить и на Linux, и на Mac, и на Windows. Для начала работы достаточно знать несколько команд: docker run, docker build, docker ps, docker stop. Не пугайтесь — это проще, чем кажется. Чуть-чуть покурить обучение на Ютубе или официальный get started — и вот у вас появляется первый контейнер.

Порог входа обманчиво простой.

Дальше идёт работа с образами и репозиториями — Docker Hub и прочие Container Registry. Docker Hub — это как GitHub, только для контейнеров. Там уже есть готовые образы для большинства популярных программ.

Первый Dockerfile можно написать за 10 минут. Это просто текстовый файл с инструкциями: откуда взять базовый образ, какие команды выполнить при сборке, что запустить. LLM сейчас отлично умеют генерировать Dockerfile — это ваш первый помощник.

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

• Бизнес начинает расширяться.
• Проект превращается во что-то более крупное.
• Вы обновляете приложение несколько раз в день.
• В команде появляется больше 3–5 разработчиков.

Дальше идёт описание многокомпонентных систем в Docker Compose. Docker Compose позволяет описать в одном YAML-файле целую инфраструктуру: несколько связанных контейнеров, их сети, тома для хранения данных. Одна команда — и всё поднимается автоматически в нужном порядке.

Но до этого вас ждёт ещё пара ответвлений в дереве развития навыков.

Podman как альтернатива Docker. Со временем вы узнаёте, что Docker — не единственный вариант. Podman, например, не висит постоянно в памяти. Можно даже сделать алиас, alias docker=podman, и забыть, что у вас на самом деле не Docker.

Podman хорош для простого докерного опыта, но если нужен Docker Compose — это фича исключительно докеровская (хотя последние Podman уже поддерживает Docker Compose через плагины).

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

Продвинутый этап: мультихостовые решения и CI/CD
Когда контейнеры на одной машине уже не справляются, вы смотрите в сторону кластеров и автоматизации.

Самое главное — контейнеры упрощают CI/CD. До контейнеров CI/CD был про скрипты, которые что-то собирают, тестируют и куда-то выкладывают. Контейнеры всё упростили: среда сборки такая же, как среда запуска. Куча головных болей с зависимостями просто исчезла.

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

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

Docker Swarm обычно выступает как первая попытка оркестрации. Docker Swarm кажется логичным продолжением Docker — всё-таки от тех же разработчиков.

Вы в нём пытаетесь что-то сделать, плюётесь и думаете: «Хорошо, видимо, судьба ведёт в Кубер».

И в этот момент контейнеры ломают вас об колено.
Установить «настоящий» Кубер (тот, что в репозитории github.com/kubernetes/kubernetes) ужасно сложно. Тут возникает развилка: либо пользоваться облачными Managed Kubernetes, либо использовать упрощённые дистрибутивы вроде k3s, k0s, Minikube или Kind.

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

В Kubernetes базовая единица — не контейнер, а pod. Это такая абстракция, в которой может жить несколько контейнеров. Обычно требуется больше одного дня, чтобы врубиться, что же это такое. Вместе с этим меняется представление о контейнерах, ведь теперь у них появляются роли (init container, side-car container).

Kubernetes автоматически делает то, о чём ты раньше мог только мечтать: если приложение падает, оно автоматически перезапускается; если нагрузка растёт, оно автоматически масштабируется; если нода выходит из строя, рабочие нагрузки перераспределяются. Ну, то есть после настройки кучи всего, конечно. Например, для автомасштабирования понадобится Horizontal Pod Autoscaler и включённые метрики.

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

И ещё бывает автоматическое обновление без простоев. Kubernetes умеет обновлять приложения по принципу rolling update: постепенно заменяет старые поды новыми, поддерживая доступность сервиса. Пользователи даже не заметят, что произошло обновление.

Дальше надо понять базовые принципы сетевого взаимодействия контейнеров:

• TCP/IP и Linux bridge. Контейнеры общаются через обычную сеть. В пределах одной машины это виртуализированная сеть через Linux bridge. Создаётся виртуальный адаптер, крепится к контейнеру, появляется интерфейс с IP-адресом. К этой же виртуальной сети подключаются другие контейнеры.
• Виртуальные сети между контейнерами. С Docker Compose можно создать несколько разных сетей и ограничить общение контейнеров друг с другом. Это как виртуальные VLAN в мире контейнеров. Ручками тоже можно, но с Docker Compose — проще.
• Ingress и маршрутизация трафика. Ingress в Kubernetes — это способ маршрутизировать внешний трафик к сервисам внутри кластера. Если ставить Кубер на голом железе (или в виртуалках на голом железе), то на этом месте можно сломать голову и любой новичок гарантированно забуксует. Без возможности выставить сервис наружу Кубер превращается в чемодан без ручки дом без окон и дверей — все системы прекрасно работают внутри него, общаются между собой, но достучаться к ним снаружи кластера невозможно. Сейчас рекомендуется переходить с Ingress на Gateway API. Совет — не делайте этого, не освоив Ingress. И ни в коем случае не ставьте сразу Kong (он хорош, но о-о-о-чень сложен для начала).
• Балансировка нагрузки. Kubernetes умеет распределять запросы между несколькими репликами приложения. Managed Kubernetes обычно использует LoadBalancer от провайдера. Если ставить Кубер на своём железе — можно попробовать MetalLB — проект специально сделан, чтобы дать функционал LoadBalancer там, где он не предусмотрен по дизайну. Без балансировки между инстансами ничего не получится, иначе вы опять будете реплицировать монолит. Монолит, кстати, тоже можно разворачивать через контейнеры, но обычно смысл в другом.
• Инструменты визуализации (Hubble для Cilium). Kubernetes умеет дружить со множеством различных реализаций контейнеров, сетей и хранилищ. Делается это за счёт интерфейсов. Так вот для сетей есть Cilium, а для Cilium есть Hubble — визуальный интерфейс. Можно буквально увидеть, как взаимодействуют компоненты, куда идёт трафик. Это одна из самых частых проблем — нужно держать в голове карту взаимодействия, и это решение помогает быстрее освоиться.

Грабли, которые вы соберёте
В этом месте, если вы научитеcь оркестрировать, возникнет следующий уровень сложности — ИБ. Она, как и везде, ошибок не прощает.

Настройка портов и их экспозиция. Даже Senior-разработчики, бывает, путаются в настройке портов: что такое publish, expose, когда использовать ClusteIP, а когда NodePort. Это нормально — все через это проходят. Каждый раз, когда вы открываете порт наружу, вы создаёте потенциальную дыру в безопасности.

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

Контейнеру не нужны все права в мире. Дайте ему только то, что ему действительно необходимо для работы. Используйте seccomp, AppArmor или SELinux для дополнительных ограничений. Если Junior-разработчик предлагает запустить контейнер с флагом --privileged, это повод для серьёзного разговора (или увольнения, в зависимости от обстоятельств).

Уделите время освоению модели RBAC и практикам её использования в Kubernetes.

Никогда не хардкодьте пароли и ключи в образ контейнера. В Docker есть Docker Secrets, в Kubernetes — Secrets API. Используйте их вместо переменных окружения с чувствительными данными. Это важно, когда вы начнёте раскатывать что-то за пределы одного проекта.

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

Заражённые контейнеры тоже бывают. Образы контейнеров, как и любой код, могут содержать уязвимости. Да и атаки на цепочки поставки никто не отменял. Используйте инструменты вроде Trivy или Clair для проверки образов перед деплоем.

Ну и не наступайте на грабли с лицензиями. В мире контейнеров доминирует открытое ПО. Postgres вместо Oracle, Nginx вместо IIS. Это не только дешевле, но и удобнее упаковывается. Если у софта всё же есть коммерческая версия, то чаще всего она подразумевает поддержку от разработчика и дополнительный функционал. Обычно в мире open-source софт лицензируется по фичам, а не по ресурсам. Вы покупаете энтерпрайз-версию, а как её масштабировать — ваше дело.

Зачем всё это?
Современные LLM генерируют не просто куски кода, а целые приложения. И идеальный способ их запустить — контейнеры. Sonnet 3.7 уже настолько круто кодит, что многие компании смогли увеличить производительность в разы.

Вы описываете словами, что хотите получить, и нейронка генерирует готовый код. Дальше дело за малым — упаковать его в контейнер и запустить. Этот процесс становится таким же простым, как отправка письма. Кстати, уже есть люди, которые не умеют в электронную почту )

Ну и сейчас у каждого уважающего себя облачного провайдера есть управляемый Kubernetes. Вам не нужно возиться с установкой и настройкой — просто выбираете количество нод и через несколько минут кластер готов к работе. Но есть нюансы.

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

Яндекс, например, предлагает сервис, где контейнер запускается только на время вызова. Происходит HTTP-запрос, запускается контейнер, отрабатывает и умирает.

У нас в L1veStack подход, скорее — замена виртуалок. Serverless containers. Это логическое развитие контейнеризации: вы не думаете о серверах вообще. Есть контейнер, он запускается и работает пока вы его не остановите, и тарификация только за потреблённые ресурсы во время его работы. Наши контейнеры рассчитаны на долгую жизнь, но никто не мешает вам убить полстада и запустить заново. И повторить через 5 секунд.

Как учиться
Отличный первый проект для освоения контейнеризации — простой чат-бот. Он включает и фронтенд, и бэкенд, и базу данных — всё, что нужно для понимания взаимодействия контейнеров. Вот у нас пример. Там ещё и простой CI/CD на базе GitHub Actions, который собирает образ при каждом новом коммите.

Начните с запуска отдельных контейнеров, потом объедините их с Docker Compose, затем перенесите в Kubernetes. Это естественный путь освоения технологии.

Сейчас есть множество готовых Docker Compose файлов для популярных стеков. Хотите WordPress? Есть готовый рецепт. Хотите LowCode-платформу? Есть готовый рецепт. Нужна CRM-система? Есть готовый рецепт. Не изобретайте велосипед, используйте готовые решения.

Проиграйте failsafe-сценарии. Запустите несколько реплик, сымитируйте падение одной из них, посмотрите, как система восстанавливается. Это бесценный опыт, потому что он учит думать именно в философии контейнеров.

Грейды примерно такие:

• Junior: базовые знания Docker, умение запускать и останавливать контейнеры.
• Middle: сборка своих образов, Docker Compose, CI/CD с контейнерами, основы Kubernetes.
• Senior: глубокое понимание Kubernetes, настройка производительности, мониторинг.

Если говорить про администрирование, то джуны ломаются на Ingress и выставлении портов наружу. Мидлы поломаются на Gateweay API и настройке Auto Provisioning для persistent volumes — как настроить систему, чтобы она автоматически выделяла дисковое пространство, например в Ceph. Даже некоторые сеньоры спотыкаются на сетевых тонкостях Kubernetes.

Контейнеризация нужна везде: от стартапов до корпораций. Но особенно востребованы специалисты в компаниях, которым нужно быстро и часто деплоить обновления. В 2025 году умение работать с контейнерами — это уже не преимущество, а базовый навык. Не важно, кто вы — разработчик, администратор или CTO, вам нужно понимать, как работают контейнеры и зачем они нужны.

Нейронки сделали возможным выкатывать Proof-of-Concept целых систем за дни, а MVP — за недели. Скорость Time-to-Market решает в этой гонке, и её не повысить без инструментов автоматизации сборки и деплоя. И Kubernetes тут как нельзя в тему.

Если вы освоили всю стопку технологий и умеете их применять на практике (и не просто применять, а устанавливать и правильно настраивать), вы — мега-DevOps с зарплатой от 500к и выше. И спрос на таких специалистов только растёт.

Начать можно с официальной документации Docker и Kubernetes. Для углубления знаний рекомендую «Kubernetes в действии» и Docker: Up & Running. Есть даже отдельная книга «Kubernetes и сети» — для тех, кто хочет разобраться в сетевом взаимодействии.

Лучший способ учиться — делать. Пройдите интерактивные курсы на Katacoda или Play with Docker. Устройте себе хакатон выходного дня — запакуйте своё приложение в контейнер и запустите его в Kubernetes.

Почитайте Open Container Initiative.

Покурите service mesh решения (Istio, Envoy), которые важны при работе с микросервисами.

Разберитесь со StatefulSets (хранение состояния в контейнерах) — если не сломаете голову до этого.

На сладкое оставьте CRD и операторы (возможно, даже свои).

Подписывайтесь на телеграм-каналы DevOps-сообществ, следите за кейсами компаний, которые внедрили контейнеризацию. Вступайте в сообщества на Reddit, Stack Overflow, GitHub Discussions. Задавайте вопросы, делитесь своими находками. Контейнеризация — это живая экосистема, и лучший способ оставаться в курсе — быть её частью

h3llo.cloud
auth.h3llo.cloud/register

LiveStack — это бессерверная PaaS (Platform-as-a-Service) платформа, созданная для удобного развёртывания, управления и масштабирования приложений и сервисов, работающих на основе Docker-контейнеров. Она предлагает мощные инструменты для автоматизации процессов, облегчая работу разработчиков и DevOps-инженеров с современными облачными решениями и микросервисной архитектурой.






l1vestack.ru
auth.l1vestack.ru/register
console.l1vestack.ru

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

Аренда чужого ЦОДа в 5-летней перспективе даёт 10% от стоимости оборудования — это соотношение примерно одинаковое что для стойки, что для целого машзала по мере его заполнения.

Собственный дата-центр подарит вам незабываемый геморрой, опыт строительства, опыт неправильного строительства, кучу новых рисков (включая сложные отношения с местными чиновниками) и даст в итоге 5% от стоимости оборудования. Если вам не хватает геморроя в жизни, то можно заняться рефакторингом вашего софта — потенциальный выхлоп будет примерно таким же.

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



Это асики, утопленные в диэлектрической жидкости. С каждой ячейки отводится до 5 киловатт тепла — как со среднестатистической серверной стойки

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

Естественно, при ставке рефинансирования 21% мы бы в жизни не пошли в строительство своего ангара, подстанции, воздушного сегмента и завоз новых ванн с бурлящей охлаждайкой, не заморачивались бы на прокладку оптической трассы в соседний регион и так далее. Но начинали-то мы тогда, когда такой ставки не было, и теперь у нас есть ЦОД. Немного, скажем так, необычный.

В двух ДЦ Tier-3 в Москве мы ставим высокопроизводительное железо, а в своём занимаемся разгоном серверов в ваннах. В средней полосе.

Как выбирали ЦОДы в Москве
Сначала мы заехали в Даталайн (когда он ещё не был Ростелекомом) и в 3Data. Оба они на тот момент были отличными.

С 3Data мы завязались по той причине, что нашим ключевым провайдером и партнёром по всему направлению волоконных сетей стала Мастертел, и 3Data тоже в их конгломерат входящая структура. Поэтому по их же рекомендации мы посетили, посмотрели, нам понравилось. Встали, в том числе и у них. Как раз у них мы летом планируем брать машзал. 3Data — это сеть ЦОДов небольшого размера. Условный отдельный машзал — это как кейдж у большого хостинга, поэтому просто выгоднее прийти и взять машзал у них, чем строить большой кейдж где-то ещё. Вот на что мы нацелились, о чём мы предварительно уже договорились.

Потом в Даталайне завёлся (или правильнее сказать — окончательно установил свои порядки) Ростелеком, и мы смекнули, что мы не аудитория этого ЦОДа, всё-таки там госы или окологосударственные компании. Сейчас переезжаем в два крутых IXcellerate. Это второй по крупности оператор ЦОДов, то есть после Ростелекома у них самое большое количество стойкомест. У них два кампуса по несколько ЦОДов. И темпы их роста соответствуют нашим потребностям. Мы берём по несколько рядов в каждом машзале. Ряды там проектируют так, чтобы они были с энергонезависимыми вводами каждый. Ещё у них каждая стойка под отдельным СКУДом с биометрией.

Другие также рассматривали, но основные варианты вот такие. Почему так — потому что важны локация и связность. Между кампусами IXcellerate трассы выходят по 30 километров, это значит, что наши 400-гигабитные трансиверы между ЦОДами прекрасно добьют.

Всё, что расположено за МКАДом и так далее — это не очень интересная история.

Второй момент — это условия по количеству электричества на стойку и как оно тарифицируется. Основная история у ЦОДов — это 5–6 киловатт, а IXcellerate нам даёт 14.

И ещё есть свой ЦОД.

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

Потом эфир перешёл на другую систему счисления, на Proof-of-stake вместо Proof-of-work.

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

Тот же ЦОД в Медведкове — частично ЦОД, частично — склад СДЭК. И это вполне нормальная история.

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

Параллельно мы строили своё облако в арендованных секциях и машзалах. И тут на нас упал этот самый недоЦОД с кучей иммерсионных вичислительных нод.

Мы поискали способы эффективно применить актив, и после ряда экспериментов оказалось, что это ещё очень хорошее дополнение к облаку. Как минимум потому, что дешёвое электричество и собственное здание дают возможность увеличить срок эксплуатации оборудования. Обычно оно заменяется на новое ещё и потому, что занимает меньше места и делает больше вычислений на потреблённую калорию. Но если у вас есть дешёвый ввод, можно использовать железо лишние 2–3 года, соединяя в кластеры, где для конечного клиента расчёт идёт по фактическим операциям, а не по аренде ядра.

Модель начала складываться. Собственный ЦОД внезапно получил экономическое обоснование (напомню, до повышения ставки рефинансирования).

Как считаем 5%
Берём затраты на строительство и раскладываем на срок амортизации. То есть, очень грубо говоря, считаем аренду исходя из затрат, как бы сдавая его самим себе. К счастью, тут мы не пошли в кредитные деньги, а делали за собственные, поэтому финансовые ужасы следующих лет нас не коснулись, а актив ещё и подорожал в приятном для нас, как владельцев, направлении.

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

Итак, зачем всё же свой
Подводя итог, условно, он нам достался почти что в наследство.

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

Плюс в своём мы также делаем иммерсию.


Это отдельная история, так как она у нас изначально как компетенция была. В иммерсию мы умеем очень хорошо.

Это значит, что в своём ЦОДе мы с GPU сможем снимать очень-очень много вычислительной мощности за раз. Каждая ячейка установки (а в одной ванне их 24 штуки) может снимать по 5 киловатт. Чуть меньше того, сколько снимает целая стойка в среднестатистическом ЦОДе. Соответственно, в каждую такую ячейку можно погрузить мощный процессор и ещё их подразогнать, если они это поддерживают. Можно погрузить много GPU, и в рамках одной ячейки всё это будет прекрасно жить.

Умножаем это на самый дешёвый тариф электроэнергии и получаем вполне подходящие условия для таких решений, как VDI, 3D-рендеринг и инференс.

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

Облако IaaS — в ЦОДах партнёров, инференс и Архикад по VDI — в своём ЦОДе.

Почему так — потому что в самой Москве сейчас меняются условия игры, и HP уже 12-го поколения занимают, условно, в 7 раз меньше места, чем 10-го. По факту получается, что серваков нужно намного меньше, чтобы обеспечить хороший объём производительности и количество виртуальных машин для клиентов.

Поэтому решили, что самое эффективное для локации в Москве — это встать у партнёров.

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

Но во второй собственный ЦОД я не пойду, это прямо точно лишнее.

В каком виде ЦОД был
Он нам достался в виде ангара, который был когда-то котельной, из которого просто всё котельное оборудование вынесено. Окна там заставлены просто поликарбонатом. Заливки пола не было. Энергохозяйство тоже по разрешённой мощности такое среднестатистическое.

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

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

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

Проект ЦОДа на новой площадке


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

Самое смешное, что при таких технологиях даже наш ангар будет с коэффициентом энергоэффективности 1,05. По расчёту. Это даже не мифические 1,4 для недостижимых воздушных ЦОДов, это классика иммерсивки.

Как мы собираемся сертифицировать по Tier котельную
Никак.
Мы строим под Tier-3, но не будем ничего сертифицировать.

Сертификация — это долгая, дорогая и ненужная история, если ЦОД не продаётся как услуга. Если у вас сервис, то важно SLA, фактический аптайм и т.п. Тот же Amazon, в принципе, долгое время вообще не заявлял никакую сертификацию у своих ЦОДов. Если долго искать, то можно найти, где они говорят что-то вроде «Tier3+». И вроде бы это на словах. Но в целом, когда у вас облачный сервис, которому плюс-минус пофигу, что целый ряд отрубился во время распределённой задачи, то сертификация не очень актуальна. Лишнее удорожание просто и лишний входной барьер.

h3llo.cloud
auth.h3llo.cloud/register

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

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

Ну и вот теперь показываю вам.

Задача: понять, насколько одинаковый тариф с одинаковым количеством vCPU и RAM выражается в реальную производительность у разных провайдеров.

Забегая вперёд — у меня нет вопросов к Селектелу, Клауд.ру (Сберу) и Яндексу (почти). У них переподписки, вроде, нет. А вот дальше начинается дичь.

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

Какие тесты гонял
Обычный Geekbench 6. То есть это проверка CPU + RAM, но не дисковой подсистемы. Это синтетический тест, он не показывает производительность в реальных задачах вроде задёрганной 1С или реальной работы веб-сервера под нагрузкой, но считается, что его результаты достаточно показательны, чтобы админы могли ориентироваться на них. Со временем, возможно, я добавлю тесты дисковых подсистем и сети, но пока только вычисления.

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

Везде я брал виртуальную машину с одинаковой конфигурацией — 2 vCPU и 4 Гб оперативной памяти. Оговорка: у Рег.ру такой конфигурации нет, пришлось взять 2vCPU и 2Гб RAM.

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

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

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

Результаты Singe Core теста

Тут всё чётко:


Здесь зависит от машины, с одной не повезло:


Аналогично:


Тут график пожевало:


Вопросов нет:


Вопросов больше, чем ответов:


Сводная:


Сводный средний балл:


Из расчёта на затраченный рубль (больше — лучше):


Коротко — лучше всего идти в Селектел, Сбер или Яндекс, а вот на ВК, Рег.ру и Таймвебе есть устойчивое ощущение переподписки. В случае Рег.ру — ПЕРЕПОДПИСКИ, которую пытаются компенсировать низкой ценой.

Результаты Multicore
Странный результат показывает Яндекс — показатели тестов почти как на SingleCore:


Облако ВК — есть просадки:


Клауд.ру — очень хорошие результаты, но была непонятная просадка:


Таймвеб — график попердолило:


Селектел — вопросов нет:


Рег.ру удивляет:


Сводная:


Сводный средний балл:


И вот из расчёта на затраченный рубль (больше — лучше):


Ссылки на сырые данные
pastebin.com/JK4i6wcC
static.h3llo.cloud/bench_final.xlsx

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

Облако ВК в среднем ниже на 15‐20%, а отдельные инстансы — на 30%, и может показать внезапную просадку на такой же конфигурации с таким же процессором, и это, похоже, рандом.

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

Производительность MultiCore тестов Яндекса сильно удивила — там, где другие провайдеры честно показали x2, результаты Яндекса почти идентичны Single Core-тестам.

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

Также мы не включили 1cloud.ru, потому что у них нет ни последних образов ОС, ни адекватного механизма тестирования, честной почасовой оплаты тоже не нашли — при создании ВМ консоль просит пополнить баланс на месяц. Этим, кстати, и Таймвеб грешит. Cloud4Y перезвонили и на пожелание разместиться в хостинге с прозрачной почасовой оплатой предложили «идти туда, где такое есть».

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

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

Ещё ограничение теста
Мы не проверяли две следующие гипотезы:

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

Зачем я это делаю
Мы строим публичное облако в России. Хочется строить его сразу прозрачно, честно и чтобы было понятно, за что пользователи платят.

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

Пока же мне было просто интересно, кто насколько реально отдаёт 1 vCPU, и я получил числа. Что с ними делать и делать ли — решать уже вам.

Относительно нас самих — не думаю, что мы покажем плохие результаты в категории «производительность за вложенный рубль». Я точно не планирую так сильно переподписывать ресурсы. Кроме того, у меня стоят Xeon 4 на DDR5, которые в 2–3 раза производительнее того, что стоит у других.

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

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

h3llo.cloud
auth.h3llo.cloud/register