H3LLO CLOUD

Вот эта штука примерно в 10 раз снижает затраты электричества на охлаждение


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

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

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

Поэтому мы сели и подумали, какие затраты вообще можно оптимизировать, а какие сильно не поменяются никогда:

• Например, в копеечной экономии на комфорте сотрудников нет никакого смысла.
• Фонд зарплат явно должен использоваться на маленькую команду профессионалов, а не на большую толпу середнячков.
• Аренда стоек: каждая сотая доля процента цены скажется на нашей марже, тут надо очень чётко всё продумывать.
• Железо: жёстко торговаться много раз.
• Электричество — ключ к марже. Оно определяет место ЦОДа.
• Поставщики: строго взаимовыгодные открытые отношения, иначе — никак.
• Сразу нужен хороший юрист для договоров (там потенциально самые большие потери).
• Минимум совещаний внутри команды, там самые большие потери — то есть усиление архитекторов и сеньоров LLM-инструментами сразу.

Теперь давайте попробуем угадать, что получится, а что — нет )

Офис: не экономим
Мы не стали арендовать помещение в бизнес-центре класса B где-то за МКАДом, а нашли вместо этого офис рядом с метро Цветной бульвар. Долго искали, выбирали и в итоге нашли вариант с более-менее приемлемой арендой, который перекрывает кучу удобств: расположение, метро рядом, много интересных мест поблизости. Сели в приличном бизнес-центре, и по факту это не стоит нам огромных денег, а в общей массе издержек это вообще какие-то маленькие проценты.

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

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

У обычного облака наших размеров — около 300 человек в штате. У нас — 30. Перебаланс — на разработчиков вместо инженерной службы, чтобы максимум вещей решать автоматизацией.

Эффективность у двух условных middle или senior при одинаковой зарплате может отличаться в 10, а то и более раз. Мы всячески стремимся, чтобы каждый, кто к нам приходит, был настоящим монстром в своей области, знал про соседние и при необходимости умел закрывать разные компетенции. Чтобы не было историй типа «Ой, а это за соседним шажочком, это меня не касается».

Благодаря тому, что команда у нас очень маленькая, мы не тратим времени на всякую фигню типа долгих внутренних согласований и излишнего проектирования. Нам проще быстро сделать proof of concept, посмотреть, как это работает, и если ОК — двинуться дальше, а если нет — выкинуть и сделать новый подход. Мы можем быстро договориться между собой, что будем делать, и бюрократия у нас отсутствует как класс.

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

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

Интернет в офисе: бросили свою оптику
Мы сами — облачный провайдер и пользуемся услугами провайдеров, подключённых в ЦОДе. Подключать с такими вводными отдельную точку доступа в офисе и платить 30–50 тысяч за гигабит не очень интересно.

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

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

В арендованных ЦОДах важна автоматизация выключения неиспользуемого железа.

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

Так вот, по нашим прикидкам, машзал на иммерсивке потребляет примерно в 10 раз (!!!) меньше электричества при полной загрузке (PUE = 1,03 вместо 1,30). Но это мы проверим на практике чуть позже.

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

Мы нашли способ уводить железо умирать примерно как это делает Hetzner, но через контейнеры и serverless. Там, где нужны массовые stateless-расчёты (или statefull-расчёты, где надёжная хранилка и ненадёжные расчётные модули) — ну, условно, например, это инференс нейросетей или обработка звука, видео и т. п., когда один любой расчётный модуль может в любой момент вылететь и никто ничего даже не заметит, — они идеальны для старого железа. Остаётся вопрос аренды стойки и электричества, а мы их решили жидкостным охлаждением и дешёвым ЦОДом в Подмосковье, напоминаю. Расширенная поддержка нам тоже не нужна: если процессор умрёт — ну умер и умер, мы его отключим от матрицы и погрузим в жидкость новый. Точнее, старый. По нашим расчётам, это позволит железу служить семь лет. Из которых последние три — в задачах матрицы, где нужны роевые вычисления, а не ответственные транзакции, как в задачах IaaS облака.

Своё железо
Железо у нас полностью своё, мы принципиально не берём сервера в аренду. Поэтому все технические потребности закрываем буквально по клику: надо — взяли и использовали. У нас нет историй с долгой арендой, хотя на старте б/у серверов у нас было много (они достались нам по наследству вместе с ЦОДом), и мы могли позволить себе разные эксперименты.

Покупаем сервера последнего поколения
HP заявили, что один сервер 12-го поколения (на котором стоит шестой Xeon) по производительности заменяет семь серверов 10-го поколения (на которых стоял второй-третий Xeon). Если смотреть по процессорам: в 10-е поколение ставили второй-третий Xeon, в 11-е — четвёртый-пятый плюс переход на DDR5-память, а в 12-е — шестой, и тоже DDR5, но ещё более быстрый. Его энергоэффективность как минимум вдвое выше, чем у 11-го поколения, и всё это легко переводится в понятные деньги и финансовые модели окупаемости.

Эксплуатационная служба
По классике для облака нам нужны круглосуточно работающие NOC, SOC и SRE. То есть всё это выглядело так, будто нам нужны целые три круглосуточные службы. Вдобавок к этому на каждом ЦОДе неплохо иметь инженеров, которые быстро реагируют на все изменения. Мы решили пойти не по классике и строим сейчас одну службу мониторинга, которая будет реагировать на все инциденты и стараться решить их по стандартным автоматизированным сценариям. А в случае неудачи передавать информацию либо сетевым инженерам, либо безопасникам, либо SRE’шникам, у которых вводятся дополнительные дежурства по инцидентам. Они не будут сидеть на месте круглосуточно, их задача — при необходимости реагировать на нестандартные ситуации.
Возможно, мы на этом наколемся, и через некоторое время я расскажу, как мы завели все три службы, но пока наш опыт показывает, что до 15 площадок так будет можно. А у нас пока их планируется восемь в этом году.

Работники на удалёнке
Серваки за последние годы стали более-менее надёжными. Заботу о них и необходимость инженеров непосредственно в ЦОДе мы прекрасно закрываем работниками на удалёнке. Аутсорсить такое дёшево. Но надо иметь в штате как минимум несколько админов, способных устроить «секс по телефону», если удалёнщик не понимает, что делать.

Аутсорсим неключевые задачи
Мы не строим in-house-службы. Нам проще разово обратиться в крутое агентство, решить задачу и успокоиться, чем нанимать специалистов, которые будут нужны очень редко. Например, когда нам понадобился брендинг, мы решили, что обратиться в профессиональное агентство будет эффективнее, и заказали его у агентства Signal (это часть ONY), они нам всю эту историю и проработали.

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

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

Во-вторых, если не разобраться в комплектациях, лицензиях, совместимости оборудования и прочих нюансах, то есть большая вероятность купить дрянь по завышенным ценам. Когда я договаривался о нашей текущей закупке с российским поставщиком, то дал ему спецификацию и подробно рассказал, что мне нужно. Единственное, чего не написал, — конкретные партномера сетевого оборудования. Мне прислали коммерческое предложение на 690 тысяч долларов. Вроде всё норм. Но потом я попросил прописать точные названия каждой позиции с лицензиями. И понеслось! Во-первых, поставщик со своим проектным отделом вписал туда несколько лицензий, несовместимых с оборудованием, а во-вторых, закупка в момент внезапно подорожала до 740 тысяч долларов, «потому что Трамп ввёл новые пошлины». Увеличенные пошлины, правда, касаются поставок в Штаты, но поставщиков это в тот момент не волновало.

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

Потому что с китайцами всё вообще очень интересно. Однажды нашим коллегам нужно было купить много асиков, и мы помогали им закупиться. Через хороших знакомых вышли на человека, который, скажем так, возглавлял китайский Главстрой и был отнюдь не последним человеком в партии. Если бы всё получилось, то мы купили бы через него весь годовой объём нескольких заводов, консолидированный в один заказ. То есть асиков было нужно очень много. Всё было здорово, пока нам не выставили цены выше, чем у российских перекупщиков с их наценкой. Мы тихонько поинтересовались, в чём тут бизнес. В ответ нам родили небольшую скидку, но модель не менялась. Я запросил те же железки напрямую на заводе — ценник получился ощутимо ниже, но все равно не проходной. То есть это в принципе общая странная тенденция — китайцы заряжают цены «на дурачка». Нужно проверять буквально каждый заказ, который формируется в Китае. В любой момент цена может оказаться завышенной вдвое просто потому, что им так захотелось. Даже у проверенных поставщиков.

Буквально на днях мне понадобилась новая линейная карта в наш холодильник (Juniper MX960). Я пошёл туда, где в прошлом году покупал такую за 1,8 миллиона, и ровно за то же самое у меня попросили уже три миллиона, ссылаясь на китайцев. Я начал искать альтернативу и нашёл в наличии за 1,4 миллиона. И так — каждый раз. С ними нужно долго торговаться, бодаться, но как только договорился по одной поставке, следующая может стать снова невыгодной, потому что однажды вы расслабитесь. Это как на рынке: даже если вы покупаете в Китае овощи у одного продавца, то он каждый раз будет говорить вам, что цена выросла. Прямо каждый день у него будет обстоятельство, почему сегодня дороже, и каждый день нужно будет торговаться обратно до старой цены.

Анализируем каждое технико-коммерческое решение со всех сторон
При закупке оборудования я всегда моделирую в Apple Numbers (не Excel: у меня Numbers на Mac) технико-коммерческое решение. Собираю и техническую, и коммерческую стороны, вывожу итоговую цифру. Бьюсь при этом буквально за каждую десятую долю процента в периоде окупаемости. Высчитываю стоимость владения и все операции, связанные с обслуживанием железа и сетей, расход электроэнергии для каждой конфигурации, объём ресурса, который можно продать из построенной инфраструктуры, стоимость закупки и содержания. У одного и того же вендора разные конфигурации из одной и той же линейки могут за счёт производительности отличаться по времени окупаемости в два раза. Всю экономику может поменять какой-нибудь очень мелкий фактор, поэтому проверять всё нужно гипервнимательно. Например, если говорить об оверхеде, то любая виртуализация — это оверхед. У нашего любимого OpenStack он настолько высокий, что на одном и том же железе наша платформа и OpenStack при прочих равных будут отличаться по времени окупаемости примерно в два раза. Для конечного клиента это выражается как минимум в ценообразовании.

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

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

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

В частности, мы договорились с MasterTel и ЮЛ-Ком о том, что каждый аплинк Интернета в каждой нашей локации будет по 100 гигабит. От каждого провайдера таких два, идут независимыми маршрутами через разное оборудование (это важно!). Суммарно выходит 800 гигабит! Вроде перебор: у того же СберКлауда весь внешний трафик на облако в среднем — 40 гигабит, и кажется, что больше и не надо. Но наш аплинк — это задел на будущее, в том числе — на эффективную защиту от дидоса. И это становится возможным только благодаря взаимовыгодным партнёрским отношениям.

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

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

Внимательно читаем договоры
Договор может состоять из 70 страниц, но, если не прочитать их очень внимательно, можно влететь в неприятную историю. У нас этим занимаются два юриста: первый проверяет все пункты на предмет странных приколов, а второй проводит очень тщательную due diligence поставщика: как он ведёт бизнес, какие у него обороты, как долго он находится на рынке, сколько у него судебных исков и каких. Мы получаем рекомендации даже из налоговой, работать с этими людьми или нет. Ну, потому, что, например, делать закупку на 150 миллионов рублей у поставщика с годовым оборотом в 10 миллионов — как минимум странно. То есть посмотреть мельком руководителей через rusprofile или focus.kontur явно недостаточно. И СБ у нас работает не столько по формальным признакам, сколько готова решить любую непонятную ситуацию. Была история с собственником подвала, который не хотел подписывать бумагу на прокладку трассы: он ждал «денежных предложений». После одного звонка с упоминанием «общих знакомых», через 15 минут пришла SMS, что курьер с документами отправлен.

И такой подход выручает.

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

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

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

Софт
Для экономии времени на старте мы брали некоторые хорошие open source’ные штучки, в том числе — для аутентификации. Например, аналитикой пытались затащить PostHog, но с ним ничего не получилось. Сейчас мы потихоньку пришли к своим компонентам там, где это целесообразно.

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

У нас нет каких-то строго стандартных рабочих систем. Кто-то работает на Apple, кто-то — на Linux, каждый использует те инструменты, которые ему удобны. Но в плане IDE у нас все используют либо JetBrains, либо VS Code (который, кстати, интегрирует нейронку прямо в IDE). Некоторые ребята используют Cursor, и это тоже помогает ускориться. Уже на старте у нас была поднята вся своя CI/CD-система, в которую входили Git-репозитории и Docker registry. Дальше мы её подружили с Argo CD и начали по десять раз на дню деплоить всё это в Kubernetes. Процесс разработки отстроен очень хорошо.

Если говорить про архитектурные устройства, то практически вся платформа сделана на Go, кроме одного микросервиса на Scala (критичного к нагрузке, распределённости, но требующего строгой консистентности данных, там самый хайлоад). Прямые вызовы — это gRPC, асинхронные — Kafka, и больше ничего лишнего. Если нужно хранение данных, то в большинстве случаев это Postgres. При этом каждый микросервис для своей же простоты может использовать те вспомогательные инструменты, которые нужны конкретно ему (например, «Баланс» работает с Cassandra и т. д). Деплоится всё это отдельно и независимо, все компоненты очень хорошо изолированы. Между бэком и фронтом есть слой middleware с GraphQL. Когда мы поменяли весь бэкенд с OpenStack на свою платформу, то с точки зрения фронтенда у нас не изменилось ничего.

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

Промежуточные результаты
OPEX стабильно держался в районе 5 млн руб./месяц, а сейчас при запуске целых восьми локаций, расширении команды вдвое и подключении восьми 100-гигабитных аплинков не выходит за пределы 10 млн. И мы научились очень хорошо экономить на CAPEX. Благодаря такому подходу мы очень быстро окупаемся. И, значит, можем давать на наш ресурс хорошую цену.

h3llo.cloud/ru

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

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

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

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

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


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

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

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

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

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

Но!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему так:

• Доступные зарубежные вендоры ушли. Российские аналоги очень дороги, ориентированы на крупный бизнес и госсектор, а для малого бизнеса пока ничего нет.
• Бюджетов на ИБ у малого бизнеса обычно нет. Реальных ИБ-специалистов за зарплаты малого бизнеса тоже мало. И вообще их зарплаты неподъёмны.
• ИБ часто требует круглосуточной работы целой службы, а не одного человека. Для реальной защиты нужен дорогой стек технологий (антивирусы, 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

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

Всё совершенно бесплатно на целый год:

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

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


Скоро мы планируем прикрутить ещё одну фичу — бесплатный доступ к Kubernetes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главный прикол с 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