Облачные сервисы *

Несмотря на то что в России последние годы идет явный тренд на импортозамещение, многие компании продолжают пользоваться не только отечественными, но и зарубежными облаками. У кого‑то остались подразделения за границей, кто‑то завязан на legacy‑решения, которые дешевле оставить как есть, чем переезжать, а кому‑то просто лень. Причины у всех разные, но объединяет их одно: необходимость свести этот облачный зоопарк в понятную модель затрат, с которой будет удобно работать всем. 

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

Protobuf как контракт: spec‑first валидация с protoc‑gen‑validate

Первая статья из мини‑серии про валидацию на базе Protobuf. В этой части — концепция spec‑first и protoc‑gen‑validate. В следующей поговорим про protovalidate и то, почему его вообще имеет смысл рассматривать как «следующее поколение» (или же как очередная эволюция в обратную сторону?)

Также, чтобы не пропустить следующую часть, очень рекомендую подписаться на мой телеграмм канал :-)

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

Вы переводите — и человек пропадает.
Или наоборот: клиент оплатил — и тишина.

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

И — нет мгновенной обратной связи.

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

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

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

С вами вновь Александр Константинов — технический эксперт в Cloud.ru. В статье расскажу, как собрать слаженный оркестр агентов, который играет по вашим нотам и работает на усиление бизнеса, а не на его разрушение.

Когда в продуктовой компании растёт база клиентов, первая линия поддержки всё чаще решает не «где найти кнопку», а «почему сломалась интеграция с CRM» или «как правильно вызвать API, чтобы не уронить биллинг». В этот момент становится очевидно, что старый добрый «скрипт для колл-центра» из двух страниц в Word не работает: оператору нужно держать в голове архитектуру сервиса, бизнес-правила и десятки edge‑кейсов. 

Привет! Меня зовут Александр, я ведущий разработчик VK Tech в команде, которая занимается сервисом Kubernetes в нашем публичном облаке. Все чаще провайдеры отказываются от модели, где пользователь получает полный контроль над кластером и всеми управляющими компонентами, в пользу управляемых (managed) решений. В такой архитектуре вы остаетесь администратором внутри своего кластера — создаете неймспейсы, деплоите приложения, настраиваете RBAC, — но инфраструктура, control plane и системные компоненты полностью управляются провайдером и скрыты от глаз пользователя. 

В начале декабря наша команда выпустила новый сервис managed-k8s, в котором как раз реализован такой подход. Я расскажу вам про то, как выглядит наш Kubernetes с точки зрения архитектуры и каким образом Gatekeeper делает архитектуру безопасной.

В корпоративных сетях RADIUS — один из самых распространённых протоколов аутентификации доступа к VPN, Wi-Fi, сетевому оборудованию и терминальным серверам. Но интеграция с 2FA и каталогами пользователей до сих пор часто остаётся самодельной для каждого отдельного админа: костыли, скрипты, нестандартизированные схемы.

Поэтому в MULTIFACTOR мы переработали собственный Radius Adapter и недавно выпустили версию V2 — с кросс-платформенностью, поддержкой нескольких LDAP-источников и переработанной логикой второго фактора. В этом разборе рассказываем, как всё работает и что изменилось в обновлении.

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

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

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?

Привет, Хабр! У платформы VK Cloud есть продукт, который позволяет компаниям частично или полностью перенести свою инфраструктуру не в публичное, а в частное облако. То есть хранить все в своем ЦОД и под личным контролем — но пользоваться при этом интерфейсом и инструментами, разработанными VK Tech.

В этой статье расскажем, как работает платформа VK Private Cloud и чем на самом деле она отличается от публичного облака. Будет много технических примеров, деталей и конфигураций и минимум общих описаний — только для уточнения нюансов. А также подробности о новой версии 4.3.

Привет, Хабр! Меня зовут Макарий, и как Senior SRE в Yandex Cloud я не только участвовал в разработке Managed Service for Kubernetes, но и всегда любил в свободное время посмотреть, что интересного понавыпускали для «кубика». Kubernetes, как де‑факто стандарт оркестрации контейнеров, предлагает базовые механизмы для управления вычислительными ресурсами. Однако стандартный планировщик Kubernetes (kube‑scheduler) разрабатывался с учётом общих принципов балансировки нагрузки и не специализирован для уникальных особенностей рабочих GPU‑нагрузок.

Предлагаю рассмотреть весь спектр возможностей — от встроенных механизмов шедулинга K8s до специализированных планировщиков, таких как Volcano, Apache YuniKorn и KAI‑Scheduler. Проанализирую конкретные сценарии, в которых каждый из этих инструментов демонстрирует свои преимущества, и предложу рекомендации по выбору оптимального решения для ваших рабочих GPU‑нагрузок.

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

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

Статья поможет ответить на вопросы:

- Как понять, какую функцию ядра выбрать для использования с механизмом kprobe?

- С чего начать ее поиск?

- Какими инструментами пользоваться?

kprobe — это, по сути, ловушка, или брейкпоинт, который можно установить почти в любом месте кода ядра Linux. 

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

Всем привет! Меня зовут Сергей, я занимаюсь backend-разработкой уже больше 15 лет, а последние несколько лет разрабатываю объектное хранилище для ваших файлов в компании Сloud.ru. Мы пишем свое собственное распределенное хранилище данных с нуля.

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

Привет Хабр! Я Иван, QA в Хайстекс. Уже несколько лет занимаюсь тестированием и внедрением решения Акура.

Этот материал родился из практики. Внутри компании мы регулярно поднимаем решения в OpenStack для тестов, пилотов и внедрений, и часто сталкиваемся с одними и теми же вопросами. Где-то не тот порт, где-то нестандартный эндпоинт, где-то сеть устроена чуть иначе, чем ожидаешь. Мелочи, которые на старте могут съедать часы.

Под катом – полное, пошаговое руководство по подготовке OpenStack и развертыванию контроллера Акуры. Это не документация в классическом смысле, а рабочий конспект. Поэтому по ходу статьи разберем процесс подготовки OpenStack и покажу, на что стоит обращать внимание при развертывании решений в этом окружении. Попутно затронем особенности платформы, которая остается одним из самых популярных open source облаков.

Всем привет! Меня зовут Александр, я работаю менеджером по аналитике в Cloud.ru. В этой статье разберёмся, с какими подводными камнями сталкиваются компании при работе с облаком и как их можно избежать.

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

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

Привет, Хабр!

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

Когда на RDP или VPN одновременно приходит несколько тысяч запросов авторизации, 2FA перестает быть просто удобным способом безопасного входа. Это становится чисто инженерной задачей: как выдержать нагрузку, не потерять запросы на авторизацию и не превратить безопасность в точку отказа.

Мы в МУЛЬТИФАКТОР несколько лет решаем именно этот вопрос — строим систему двухфакторной аутентификации, которая работает в больших и маленьких корпоративных сетях, поддерживает все основные протоколы и при этом не зависит от зарубежных сервисов. В этой статье расскажем о том, как устроена система MULTIFACTOR: архитектура, взаимодействие компонентов и инженерные решения, которые позволяют системе быть стабильной при любой нагрузке.