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

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

Всем привет, с вами Макс Гуляев. Я отвечаю за разработку сервиса Evolution Notebooks.

Jupyter Notebooks — проверенный временем инструмент, который на слуху у каждого DS или ML-инженера. Перечислять все его плюсы смысла нет, а вот минусы — вопрос, пожалуй, актуальный. Меня как ML-щика раздражало, что ты приходишь в ноутбук полный энтузиазма, надеешься решить все проблемы человечества с помощью своей модельки… Но выясняется, что путь к обучению усеян локальными ограничениями ресурсов, проблемами с установкой зависимостей и коллаборациями, тут надо проверить, там подкрутить. В итоге модель ты обучаешь 20% времени, а остальные 80% проводишь в обработке напильником инструмента, который должен тебе помогать. Но хорошая новость: сегодня мы прокачаем эту унылую «тетрадку».

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

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

Я Владислав Доронин — Go-разработчик в команде S3 облачной платформы Cloud.ru Evolition. Хочу рассказать про подход к управлению отказами реплик, который мы кристаллизовали опытом выхода из строя разных частей системы. Практика показала, что массовые и не очень отказы приводят к взлету задержки ответов и увеличению количества client-side повторов, которые тоже висят. Пускай на уровне записи из-за требований репликации и гарантии мы много поделать с ситуацией не можем (хотя и там не все безнадежно), то вот чтение гораздо более гибкое. У нас получилось сделать retry на чтении красивыми, об этом сегодня и поговорим.

Привет, Хабр! На связи вновь Алексей Капранов, архитектор-исследователь в команде квантовых вычислений Cloud.ru. В первой части мы узнали, что такое тензорные сети, познакомились с графическим представлением, вспомнили основные операции и подумали над алгоритмической сложностью.

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

Рекомендуется к прочтению ML/AI‑исследователям и инженерам, которым интересны продвинутые методы понижения размерности; исследователям алгоритмов и численным аналитикам, а также всем, кто интересуется математикой и знаком с линейной алгеброй.

Когда мы говорим об искусственном интеллекте, мы неизбежно говорим о наследии Марвина Минского. Этот ученый не просто стоял у истоков области — он во многом определил, какой она станет. Сооснователь лаборатории AI в MIT, создатель первой нейросети, консультант культового фильма «Космическая одиссея 2001 года» и автор революционных теорий о природе разума — Минский был одним из тех людей, которые превращают научную фантастику в реальность.

С вами снова Катя Косова, днем я бизнес-аналитик в Cloud.ru, а свободное время посвящаю исследованию когнитивных процессов, преподаванию «Психологии рекламы» в Вышке и «Когнитивной психологии и наук» в РАНХиГС. Сегодня хочу познакомить вас с тем, кого многие современные изобретения и научные теории могут назвать если уж не отцом, то как минимум дедушкой.

Привет, Хабр! Меня зовут Капранов Алексей, я архитектор-исследователь в команде квантовых вычислений в Cloud.ru. Сегодня я расскажу про подход, который позволяет не только моделировать большие квантово-механические системы, но и полезен для целого ряда задач, включая машинное обучение и нейронные сети.

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

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

Привет, Хабр! Меня зовут Роман Путилов. Последние восемь лет я занимаюсь облачной инфраструктурой. SRE-процессы, SLA «пять девяток», регулярные инциденты и постмортемы – часть моей работы, а не только новостная повестка.

За последние годы несколько крупных инцидентов в облаках показали, что одна ошибка может вырубить сразу несколько глобальных сервисов. На кейсах VK, ЕГРН, Яндекса, AWS, Google Cloud и CrowdStrike я разбираю, ведет ли консолидация инфраструктуры к цифровой катастрофе – идеальному шторму, где простая ошибка и несколько неудачных совпадений окажут такой разрушительный эффект, от которого уже нельзя будет оправиться.

Будет полезно SRE, архитекторам, IT- и ИБ-руководителям.

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

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

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

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

Эта статья не про правила проведения ревью дизайнером, а про инструмент, который вывел код-ревью, дизайн-ревью и тестирование на абсолютно новый уровень. Инструмент, который помог нашей команде сократить количество итераций на задачу с 7 до 2—3 — расскажу, как это повторить.

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

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

Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.

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

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

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

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

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

Всем привет, меня зовут Олег Юрчик, я старший разработчик в Cloud.ru. Современный интернет — это не только IT-гиганты и готовые облачные сервисы. Под капотом глобальной сети скрываются базовые принципы, которые может воспроизвести любой технический специалист. В этой статье сначала вспомним, как появился Интернет и как он работает. А затем разберем, как создать его уменьшенную, но полностью управляемую копию с собственными DNS, центром сертификации и веб-сервисами.

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

Привет, снова Костя из Cloud.ru. Мы поговорили уже про as для типобезопасного полиморфизма, asChild для композиции и FACC для вариативного дизайна. Но что, если я скажу, что есть способ комбинировать логику ещё элегантнее и не смешивать ее с отрисовкой? Сегодня разбираем полиморфные декораторы - HOC'и на стероидах.

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

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

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

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

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

Привет, Хабр! Меня зовут Иван Дюков. Последние несколько лет я занимался разработкой и оптимизацией сетевых компонентов для облачной инфраструктуры. Среди моих проектов — участие в разработке сетевого процессора для компании Google в составе российского подразделения Intel, а также оптимизация программных сетевых функций для облака Samsung в команде Samsung R&D Institute Russia. В настоящее время работаю над сетевыми сервисами для платформы Cloud.ru Evolution в R&D-команде Cloud.ru.

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

Привет! Меня зовут Андрей, я фронтенд-разработчик в Cloud.ru, веду блог о фронтенде и AI в Telegram. За время работы с ComfyUI убедился: страх перед его сложностью — миф, который мешает раскрыть настоящую силу этого инструмента.

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

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

Привет, с вами снова Костя из Cloud.ru. Мы поговорили про паттерн as для типа безопасного полиморфизма и asChild для чистой композиции. Но сегодня поговорим о подходе, который даёт такую гибкость в вариативном дизайне, что дизайнеры будут гордиться вами - FACC (Function as Child Component).

Я — Оксана Пастернак, старший юрисконсульт компании Cloud.ru. Мы предоставляем облачные сервисы и взаимодействуем с Роскомнадзором (РКН) по вопросам защиты персональных данных и соответствия требованиям законодательства. Изнутри вижу, как важно выстроить процессы так, чтобы облако оставалось безопасным и проверку можно было пройти спокойно.

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

Привет, Хабр! Меня зовут Алексей, и я разработчик в Cloud.ru. Бороздя просторы Github в поисках вдохновения для проекта выходного дня, наткнулся на репозиторий Pi.Alert. В его описании первой строкой было ёмкое «WIFI / LAN intruder detector». Мне понравилась концепция устройства, которое выполняет мониторинг подключенных к сети девайсов, и я захотел сделать что-то подобное. Но выделять под эту задачу машинку, способную исполнять Python-код, показалось избыточным. Было решено - пора сдуть пыль с давно заказанного, но так и не нашедшего применения ESP32, и наконец-то поупражняться в написании кода под эту SoC. Целью эксперимента стало создание анализатора домашней сети, отображающего подключенные устройства. В качестве дополнительной фичи добавим сигнализирование о ситуациях возможного arp-spoofing.