H3LLO CLOUD

Мы пошли в сертификацию ФСТЭК, аттестацию 152-ФЗ и на получение лицензии для работы с гостайной. Потому что мы вместо Опенстека сделали свою платформу и на ней смогли всё настроить под требования госорганов.

Поэтому вот пост, как получить сертификацию на гостайну по ФЗ-152 — уровень УЗ1.

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

Всё ████████ ████ с ████████. В соответствии с новым ████████. Для ████████ требовалась ████████. Поэтому ████████, и в рамках очень жесткого SLA.
████████.

████████ ████.

████████ ████████ █████ █ █████.

Началось с ████████. ███ █████████ █ ███████ ████ комиссия. Их ████████. Потребовали выделить ████████ под ████████ периметр ██████. Только ████, ███████, ███████ bare-metal. Весь наш IaaS-слой пришлось ████████████.
В ███████████ с █████████ от ██.██.████, на █████████ ████████████, ██████████ █████████ о █████████████ ███████████ ████████. В ███████ ███████████████ и ████████████ по ██████████ в ███████████████████, ██████████ ███████████ ████████████, █████████████ на ███████████████.

Основные ████████████:

████████████ в ███████ █████████████████ ████████ «█████████████-████»;

██████████ для █████████████ с █████████ всех █████████████ ███████, через ███████████████ ████████████;

████████████████ по ███████████ с ███████ ██████████ и █████████████, ████████████ после ███████████.

В ██████ с ████████████████, █████████████ по █████████ ████████████ на █████████████ ██████. Все █████████████ ██████████ ██████ █████████████ и ██████████ в ██████ до ███████████ ███████. При ███████████ █████████████, ████████ ████████████ к ████████ № ███-ФЗ.

Контроль за █████████████ ██████████ █████████ ██████████ на ████████████████████████ (████████ ████ ██).

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

Ввиду ███████████████████████████ **угрозы считывания дрожания стекла **лазерным лучом, █████ ██████ ███████████ ███████████ █████████ ███████ ███████████████ к █████████████ ██████ ███████.
Критерии ████████████:

███████ █████████ ████ ███████████ ███ █ ██████████ ██████████ █████.

Соответствие ██████ █ ██████ ████ ██ ████ ██████ ███ ████ ГОСТ ██████-██.

██████ ███████ ████████ ███████████. ████ █████ █████ ███████████ и ████ ██████████████.

Сроки из-за этого поплыли, конечно.

Теперь самое сложное:

█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████

Далее — сеть
Весь трафик ████████. Сегментация на уровне ████████. Отдельный VLAN. И ████████ роутинг через ████████. Логирование ████████.

Затем ████████. Наша PaaS-платформа на ████████ была ████████. Каждый деплой через ████████. Все образы ████████ по ГОСТ. Шифрование на уровне ████████ и на уровне ████████.

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

Основными ████████████ являются:

████████████ и ███████████ в рамках █████████████████ проекта «█████████████-████»;

██████████ для ███████████████ с ███████ всех ██████████████ сторон, в том числе через █████████████████ ████████████;

████████████████ по ███████████ с учётом ██████████ и ██████████████, полученных после █████████████ ██████████.

По возможности делайте именно в таком порядке, а не обратном, не наступайте на наши грабли.

В связи с вышеизложенным, ████████████ по ███████████ ответственность ████████████ на █████████████ отдел. Все █████████████ документы должны быть █████████████ и ██████████ в архив до █████████████ ███████. При ███████████ █████████████ █████████████, следует ████████████ к ███████ ████-ФЗ.

Контроль за █████████████ настоящего ██████████ пришлось передать ████████████████████████ (██████████ ██. ██.). И это, конечно, дикий сюрприз.

Затем — финальная аттестация. ████████. Мы ████████. Потом ████████. И так по ████████.

После ████████. Мы ████████. Думали, что всё ████████.

А потом ██████ ██ ████████.

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

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

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

Удивительно, но многие узнавали нас по блогу на Хабре.

Участие стоит несколько десятков миллионов рублей за стенд (мы не взяли) — ну или 50 тысяч рублей за самый простой билет и 150 тысяч за VIP. Мы взяли за 150, но сразу скажу, подсыхающие канапе этого не стоили. Но тем не менее оказалось дичайше полезно.

Сейчас расскажу, зачем вообще ездить на такие конференции и какой профит с них можно получить. Потому что может показаться довольно странным ехать на конференцию «Цифровая индустрия промышленной России» не в онлайн.

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

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

Почему Нижний — потому что там крупный ИТ-кластер, наука и промышленность. Почти как Екатеринбург, где тоже промышленность и большое население дали отличный старт для роста ИТ в 90-х.

Начну с того, что, конечно, дико жалко денег. Жаба прям давит.



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

Дальше надо было обойти всех, поменяться контактами и познакомиться, чтобы, если что, писать напрямую, а не через секретарей и продажников. Приезжают чиновники (особенно Минцифры и Минпромторг), госкорпорации типа Сбера и ВТБ, Росатома, Роскосмоса, Ростеха, Ростелекома, РЖД и т.п., крупный бизнес вроде Яндекса, 1С, Позитива, Касперского, потом промышленность — там я мало кого знаю лично, но в целом хотя бы по человеку от всех крупных производств, куча стартаперов (хотя, казалось бы, венчур в России кончился в 2022-м), преподаватели из университетов и дамы разного поведения, которые не могут пропустить такую концентрацию людей с деньгами.

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



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

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

Дальше прямая речь Антона (коммерческого директора):

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

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

Так что да, за нами следят и ждут, когда же рванём.

Пользуясь случаем, передаю привет уважаемым коллегам. И напоминаю, что пока вы корпорация, вы двигаетесь раз так в 7–8 медленнее, чем маленькие команды, где нет бюрократов и идиотов. Ну, знаете, как мы. Хотя про идиотов я ещё не до конца уверен, это время покажет. С гранатой за птицами мы уже бегали.

Что было в целом

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



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

Но главной, просто всепоглощающей темой стал искусственный интеллект, ГИГАЧАТ 2.0. Это они так называют LLM, как уже говорил. А вместе с LLM туда под общий хайп загребли всё: от классификаторов машинного зрения до термоса. В конце концов, он же знает, какую воду хранить — если налить горячую, через час в нём горячая, если холодную — там через час не горячая, а холодная. Для этого нужен серьёзный AI.

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

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

Организация пространства интересная. Внутри выставочного комплекса — закрытое помещение со стендами, условные площадки 5 на 3 метра. Там же был и зарубежный павильон: китайцы, белорусы, иранцы, но всё как-то невизуально, ничего, что заставило бы остановиться.

А вот на площади, в зоне, где, по идее, кормили людей, были отдельные лаундж-зоны. Там можно было поваляться на подушках, посидеть на лавочках с ноутбуком. И вот там, особенно под вечер, собиралось много народа. Погода стояла жаркая, за 30 градусов, и некоторые компании этим отлично пользовались: ITGLOBAL.COM (Айтиград) разливали пиво, Softline готовили коктейли. Я видел, как крупные интеграторы привозили заказчиков, как говорится, культурно на выгул.

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


Изнанка
У меня был статус VIP за 150 тысяч рублей. И он был вообще ни о чём. Абсолютно пустая трата денег. В теории он давал доступ к контактам, но на письма по этому списку никто не отвечал — вообще мёртвая история. В следующий раз, если поедем, то только как обычные делегаты за 50 тысяч. Мы даже рассматривали вариант со своим стендом, но цена вопроса уходит сильно за новый Майбах и квартиру в Москве. Там спонсорский пакет + проектирование стенда ещё 3–4 миллиона, а строить его можно только силами рекомендованных компаний за отдельные деньги.

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

Логистика и быт просто ужасны. Интерфейс для покупки билетов как у кривых копий Фаргуса, «озвучено профессиональными программистами». Чтобы попасть на какую-то вечеринку, нужно было регистрироваться за пределами основной системы где-то в third-party софте. Когда нам понадобилось переоформить билет с одного сотрудника на другого, это заняло неделю! А ещё нужно распечатать соглашение, вручную заполнить его, подписать, отсканировать и прислать обратно!

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

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

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

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

Ну и вишенка на торте: после регистрации мне до сих пор летит всякий спам и рассылки. Возможно, как раз от других VIP-участников.

Немного публикаций, чтобы вы понимали уровень:

• Хакеры не смогли взломать веб-ресурсы конференции ЦИПР-2025. Это, если что, «…успешно предотвратить множество автоматизированных попыток сканирования веб-ресурсов ЦИПР».
• Достигнем полного импортозамещения к 2030 — это, если что, про IVA.
• Можно было заселяться в отель по биометрии. Терминалов было то ли один, то ли два, в одном отеле, в основном, чтобы сфотографировать. Ладно, это классно, тесты.
• Роскосмос направит нейросеть на МКС — когда был тренд на роботизацию, робота они уже отправили.
• Во всех поездах РЖД введут единый мультимедийный стандарт.
• МТС вложит 22 млрд рублей в модернизацию ИТ-инфраструктуры.
• На ЦИПР-2025 представили российский сервер нового поколения — это не Байкал, если что, это на базе Xeon 6.

Интернет на борту отечественных самолётов может появиться в 2027 году. «Любой винтик, лампочка, модем, который будет установлен на борту воздушного судна, — это лишний вес, лишний объём, и это должно быть подтверждено производителем», — отметил заместитель гендиректора по информационным технологиям и информационной безопасности «Аэрофлота» Антон Мацкевич. «Именно поэтому речь пока идёт о перспективных отечественных самолётах, которые сейчас испытываются».



Итог
Несмотря на всё это, поездка была полезной. Прямых заказчиков найти было сложно — они все прям за ручку ходили со своими менеджерами, которые их не отпускали разговаривать с конкурентами, незнакомцами и вообще взрослыми дядями. Но мне больше дало личное знакомство с коллегами по цеху. Я встретил людей, которых не видел много-много лет. И вот так, слово за слово: «Привет, как дела?», и вдруг: «Слушай, а не хотите поучаствовать с нами в проекте?» Субподряд для Касперского так нащупался, а наш директор по партнёрствам Андрей пообщался со многими топ-менеджерами, например из Positive Technologies, Astra Group, РЕД СОФТ, SberTech, Nexign, NAUMEN, PostgresPro, Directum, Express, Р7, Almi Partner и Цифровыми технологиями Москвы, которые теперь нас знают и готовы вести диалог.



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

Но зато нас увидели и, возможно, поняли, что мы адекватные. Хотя это неточно.

h3llo.cloud/ru

Включили 3 из 4 линков с провайдерами (еще одну кроссировку ждем). Это наш маршрутизатор ядра сети в новом ЦОДе IXcellerate Юг.

Казалось бы, 2025 год на дворе, какие могут быть сложности с интернетом?

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

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

Из всех провайдеров, кого мы трясли, нашлось только два: Ростелеком и VIP-Телеком-Сервис.

Местный Трайтек вообще предлагал 100 000 ₽ за гигабит — то есть миллион в месяц за десятку. Не, спасибо.

С Ростелекомом мы начали мучения ещё в декабре. Долгие согласования, заминки на ровном месте. Например, один из затыков — отсутствие 10G-трансиверов. Серьёзно?! Это расходник, который стоит 1–2 тысячи рублей, у нас на столе таких коробок куча. Но у Ростелекома не было. Наши со стола они брать тоже не хотели.

Предложили подождать месяц-другой. В итоге договор подписали только в июне. А приведение всего в рабочее состояние займёт ещё 5 месяцев. Ну вы поняли. Ростелеком.

Параллельно работали с VIP-Телеком-Сервис. Они пришли по рекомендации и с ходу зарядили: «Мы вам построим точку на M9 и в Александрове за 20–25 дней». И знаете что? Построили!

Канал уже запущен и работает. Пока мы используем его для внутренних сервисов и тестирования, но это наш первый глоток 10G.

Почему же мы всё равно ждали Ростелеком, если VIP такие шустрые? Потому что облачный бизнес — это не про один канал. Нужны минимум два независимых! Сейчас один интернет есть (VIP), второй будет от Ростелекома. Плюс строим отдельное тёмное волокно.

В итоге будет:
— 10G от VIP.
— 10G от Ростелекома.
— Тёмное волокно наше, домашней выпечки.

Если с одним из провайдеров что-то происходит — всё не полетит к чертям.

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

h3llo.cloud/ru

Мы получили статус LIR, подсеть /29 IPv6 и встали в очередь на подсеть /24 IPv4!
www.ripe.net/membership/member-support/list-of-members/ru/h3llo-cloud/

Если что, RIPE NCC — даёт айпишники и автономные системы в Европе, Азии и России. LIR-статус — это возможность творить в своём блоке IP-адресов что угодно. Например, использовать. Раньше мы получали IP-адреса от другого LIR, то есть цепочка была чуть длиннее.

У нас уже давно (со старта) своя автономная система, и мы анонсируемся по BGP. Получить свою AS и поднять BGP-пиринг — квест недетский, но мы на старте его прошли. Теперь вот уполномочены сами выдавать AS своим клиентам.

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

/29 в IPv6 — это первые 29 бит адреса фиксированы для нашей сети. 128 — 29 — остаётся 99 бит для адресации. Если долго возводить в степень, то получится 512000 сетей /48. А сеть /48 — это 65536 сетей /64. В сети /64 целых 2^64 хостов (примерно 1.8 x 10^19). Короче, это очень дохрена. Адресов должно хватить каждому. Это нужно на достаточно большие сети для новых крупных клиентов. А они уже заезжают.

h3llo.cloud/ru

Мы любили Яндекс Метрику. Правда, любили. Издалека.

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

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

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

И это была ошибка.

Как всё начиналось

Когда мы делали наш первый продукт — L1veStack, нам хотелось сэкономить время и не писать всё с нуля. Поэтому мы взяли несколько хороших опенсорсных систем, которые могли бы закрыть приличную часть функционала. Одна из них — система аналитики PostHog. Она поставляется в двух версиях: облачная и self-hosted. Второе — как раз то, что мы искали, чтобы поставить у себя и не передавать данные на сторону. Мы решили затащить её к себе.

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

Мы включили эту опцию — и… ничего не заработало. Начали разбираться. Долго и больно.

Ковырялись с CORS (Cross-Origin Resource Sharing) и CSRF (Cross-Site Request Forgery) — это те штуки, которые отвечают за безопасность запросов между разными доменами. У нас PostHog был на одном домене, сайт — на другом. Вроде всё правильно делали, но ничего не помогало. Решили попробовать обновиться, потому что с момента установки вышла новая версия. Поставили. О чудо — сессии заработали! Но развалилось всё остальное.

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

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

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

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



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

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

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

Представьте, что вы строите инновационный финтех-сервис, а все данные о поведении ваших клиентов уходят в Яндекс Деньги (которые теперь ЮMoney). Или разрабатываете маркетплейс, а информацию о предпочтениях пользователей получает Яндекс Маркет.

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

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

Нам нужен был инструмент, который:

• Хранит все данные на наших серверах.
• Стабильно работает даже при агрессивной блокировке трекеров.
• Легко настраивается и не требует команды DevOps для поддержки.
• Предоставляет всю необходимую функциональность для глубокого анализа.

А раз нужен, то его надо сделать. Ну мы и сделали.



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

• Базовый сбор метаданных: IP, тип устройства, браузер, ОС, разрешение экрана и другие параметры — всё, что помогает понять пользователя.
• Запись сессий пользователей — аналог Вебвизора: можно воспроизвести действия пользователя на сайте и отследить моменты фрустрации или проблем.
• Продвинутый профайлинг: события до и после авторизации объединяются в один профиль. Если пользователь несколько раз заходил как гость, а затем авторизовался — вся его история объединяется в единую сессию (если не чистил куки).
• Feature flags (фича-флаги): гибкое управление функциональностью. Можно включать/отключать фичи для конкретных сегментов пользователей — например, для мобильной аудитории, зарегистрированных в декабре или просто раскатить новую фичу на 5% случайных посетителей.
• A/B-тестирование: настройка продуктовых гипотез на базе фича-флагов. Можно тестировать разные интерфейсные решения или функционал на разделённых группах пользователей и собирать аналитику.
• Customer Journey Map (CJM): визуализация пути пользователя — от первого визита до ключевого действия. Видно, где он свернул, где ушёл и как можно улучшить путь.

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

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

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

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

Архитектура с прицелом на будущее
С самого начала мы собирали систему с прицелом на простоту, скорость и масштабируемость. Поэтому — микросервисная архитектура, язык Go и только проверенные Open Source компоненты (и то — по минимуму). Всё летает, не ломается и легко разворачивается.

Каждый компонент упакован в контейнер: всё разворачивается через Docker Compose или Helm Chart. Установить на собственные серверы можно за 3–4 клика. А при размещении у нас — вообще в один.

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

В архитектуре:

• REST API принимает данные с фронта;
• Микросервис записывает сессии пользователей;
• Работает система профилирования и объединения данных до и после авторизации;
• Админка построена на GraphQL;
• Для интеграции на фронте — SDK для React (Next.js).

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

Для админки — отдельный GraphQL-микросервис. Он общается только с внутренними компонентами и не торчит наружу. Всё, что касается настройки фича-флагов, A/B-тестов, CJM и просмотра сессий, — делается через него. Это повышает безопасность: административная логика отделена и не доступна извне.

Всю систему мы собрали на проверенных Open Source компонентах: Postgres — для хранения структурированных данных, Redis — для кеширования, Kafka — для обмена сообщениями, ClickHouse — для аналитики. Никаких закрытых зависимостей или скрытых ограничений.

Сразу внедрили инструменты наблюдаемости — LGTM-стек (Loki, Grafana, Tempo, Mimir). Это позволяет отслеживать состояние системы, трассировать запросы и анализировать логи — всё прозрачно и под контролем.

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



Вайб-кодинг: нейросети в разы ускорили нам разработку
Разработка такой системы вручную — это долго и дорого. Если собрать команду из 2–3 бэкендеров, 2 фронтендеров, DevOps и тимлида, то даже на минимальный MVP уйдёт полтора-два месяца плотной работы. Именно так это делалось бы год-полтора назад — без нейросетей, с написанием всего кода вручную. И затраты на разработку вряд ли оправдали бы себя — проще было бы просто оформить подписку на готовый платный сервис.

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

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

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

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

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

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

• Базовый сбор метаданных — то же самое, что собирает Яндекс Метрика: IP-адрес, данные о браузере, тип устройства, разрешение экрана.
• Запись сессий — полноценный аналог Вебвизора, позволяющий воссоздать каждое действие пользователя на сайте.
• Продвинутый профайлинг — объединение данных о пользователе до и после авторизации, что решает извечную проблему «потери» посетителя при логине.
• Фича-флаги — включение или отключение функций для разных групп пользователей без необходимости деплоить новую версию.
• A/B-тестирование — инструменты для проверки продуктовых гипотез с детальной аналитикой результатов.
• Customer Journey Map (CJM) — визуализация пути клиента с выявлением точек отказа и затруднений на каждом этапе воронки.

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

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

В чём мы круче конкурентов
Про Яндекс Метрику я уже много сказал. Добавлю ещё про PostHog: он требует отдельного домена, 4 vCPU, 16 Гб ОЗУ и 30 Гб диска. Установка долгая, несмотря на контейнеры и собственный инсталлятор. При трафике выше 50 тысяч пользователей в сутки начинаются проблемы с производительностью.

Собственно, для наглядности сведу всё в таблицу:


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

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

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

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



Чему всё это нас научило
Вот ключевые уроки, которые мы извлекли:

• Технологические ограничения внешних сервисов неизбежны. Когда вы используете чужой продукт, вы всегда зависите от решений, принятых его разработчиками. Собственная система даёт полный контроль.
• Выбор правильного технологического стека критически важен. Go и микросервисная архитектура позволили создать легковесное, но мощное решение, которое легко масштабируется.
• Нейросети способны радикально ускорить разработку при правильном подходе. Секрет в строгих технических рамках и постоянном тестировании промежуточных результатов.
• Меньше кода — лучше код. По мере развития проекта мы постоянно оптимизировали архитектуру, уменьшая объём кода и делая его более поддерживаемым.

Для разработчиков, которые задумываются о создании подобных систем, наши рекомендации просты:

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

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

Контроль над данными — это не роскошь, это необходимость. Не отдавайте своё золото конкурентам. Стройте будущее на основе собственных знаний о своих клиентах.

h3llo.cloud/ru

Вот эта штука примерно в 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

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

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

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

Почему так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Истории:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дальше офер.

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

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

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

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

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

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

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

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

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

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

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

Поехали в ад!



Архитектура

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Как ставить

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

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

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

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

Container Runtime

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метрики:

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

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

Логи:

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

beta.h3llo.cloud
h3llo.cloud