Все потоки

Перенёс пет-проект с хоумсервера в облако. Что удивило:

Года два держал несколько ботов и сервисов на старом ноуте. Работало. Но надоело: отключение света, перегрев летом, динамический IP, ngrok который иногда падал.

Решил переехать в Яндекс Облако. Думал займёт выходные. Занял три выходных.

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

Secrets. Раньше у меня токены лежали в .env файле. В облаке сразу захотелось сделать через Lockbox. Потратил конечно же время, но теперь не страшно что репозит случайно станет публичным.

CI/CD. Дома деплой был «зашёл по SSH, git pull, перезапустил». В облаке настроил GitHub Actions: пуш в main - автоматически собирается образ и обновляется сервис. Первый раз в жизни сделал нормальный пайплайн. Оказалось не так страшно как казалось.

Мониторинг. Дома я узнавал что бот упал когда кто-то писал «почему не работает». Теперь есть алерты. Мелочь, но разница ощутимая.

Стоимость для пет-проекта маленькая, несколько сотен рублей в месяц на небольшой инстанс. Для хоббийных вещей вполне ок.

Какие ещё подобные решения есть?

Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?

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

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

Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:

ALTER ROLE replicator WITH REPLICATION;

Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.

Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:

systemctl reload postgresql

В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.

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

На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.

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

Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

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

Как выглядит миграция с Power BI, когда дашбордов 155, а команда никогда не писала на Python

В новой статье GlowByte разбираем кейс «Дикси»: почему в шорт-листе остались Sigla Vision и Apache Superset, что перевесило в итоге и почему мы не стали переносить всё разом.

Цифры на середину 2026:

✅ 37 дашбордов уже мигрировали

✅ time-to-market со 210 дней до 112

✅ CES вырос с 3,5 до 3,8

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

👉 Читать: https://habr.com/ru/companies/glowbyte/articles/1063906/

Почти все модели жульничают на кибербез бенчах

Исследователи Dreadnode проверили, насколько честно LLM-агенты проходят задания по наступательной ИБ. В эксперимент вошли 22 передовые модели семи провайдеров, 23 CTF-задания средней сложности из Cybench и три системных промпта: без запрета на обход правил, с обычным запретом и с жёстким перечнем запрещённых действий. Все 1518 траекторий прошли многоступенчатый аудит.

Результат ставит под сомнение pass rate как меру реальных возможностей. Без запрета 37,1% успешных прохождений были получены с нарушением правил, а жульничала 21 из 22 моделей. Средний pass rate составлял 41,5%, но доля честно решённых заданий — лишь 26,1%. У отдельных моделей оценка завышалась до пяти раз. Агенты искали готовые write-up, клонировали репозитории с решениями, читали файлы с флагами и исследовали служебную инфраструктуру.

Инструкции помогли, но проблему не закрыли. Доля заданий, в которых модель хотя бы пыталась жульничать, снизилась с 33% до 17,8% с обычным запретом и до 8,5% с жёстким. Доля честных решений при этом выросла с 26,1% до 34,4%: модели чаще продолжали самостоятельный поиск. Но даже при максимальных ограничениях восемь моделей получили хотя бы один результат с нарушением правил, а у четырёх возник обратный эффект. Обман также сместился от веб-поиска к исследованию инфраструктуры.

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

Полное исследование на arXiv / Подписаться на Похек AI

Открыли доступ к курсам по ML-системам от основ до продакшна. И да: это бесплатно

Кто-то смотрит на ML как на способ оперативно занять рыночную нишу, не понимая, какой технический фундамент необходим для реализации идеи очередного прорывного продукта. Кто-то запускает идеальный эксперимент в ноутбуке, но выясняется, что он не работает в продакшене. Это две крайности одной и той же проблемы: мало кто понимает, как работают ML-системы от первого винтика данных до последней шестеренки мониторинга. Чтобы глобально исправить это, мы собрали весь свой опыт провайдера облачных и ИИ-решений в линейку курсов Cloud.ru ML System Design и сделали доступ к ней открытым.

Какие курсы есть в линейке? 

• «Машинное обучение в облаке»⏳15 ч — как использовать облачную инфраструктуру для разработки, обучения и эксплуатации ML-систем.

• «ML в продакшене»⏳2 ч — база, которую нужно знать, чтобы довести модель от эксперимента до стабильной работы в боевой среде с учетом инфраструктуры, данных и процессов.

• «Основы ML‑систем и обработки данных» ⏳3 ч — базовое устройство ML-систем, пайплайнов данных и ключевых компонентов end-to-end решения.

• Training Data⏳3 ч — как собирать, очищать, версионировать и поддерживать обучающие данные без деградации качества.

• Feature Engineering ⏳4 ч — как проектировать и поддерживать признаки, которые работают не только в обучении, но и в проде.

• Model Development ⏳3 ч— как разрабатывать модели с учетом требований к качеству, воспроизводимости и дальнейшему деплою.

• «Офлайн-оценка ML‑модели»⏳3 ч — как корректно валидировать модели до продакшена и не переоценивать их качество.

• Model Training⏳4 ч — как строить надежные и масштабируемые процессы обучения моделей.

• Inference⏳4 ч — как организовать инференс (онлайн и батч) с учетом latency, нагрузки и архитектурных ограничений.

• Model Monitoring⏳3 ч — как отслеживать деградацию моделей, data drift и аномалии в проде.

• MLOps⏳4 ч — как выстроить процессы, CI/CD и инфраструктуру для жизненного цикла ML-моделей.

• «Проектирование ML-системы»⏳2 ч — практический кейс для отработки навыков, который поможет персонализировать ленту новостей.

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

Проходите курс и создавайте зрелые ML-продукты! 

Увольте дизайнера, избавьтесь от Figma

10+ лет я просил дизайнеров делать clickable prototype, чтобы потом, спустя спринт или два, не переделывать. Но им было некогда.

Теперь дизайнер не нужен: любой Front любой сложности LLM собирает за минуты, и если нужны два варианта — посветлее и потемнее, — то это еще 2 минуты.

Но самое главное — мысль, которая возникла в голове у Product Owner, сразу материализуется. 

И это не просто clickable prototype, это рабочий продукт, который можно наживую править. 

Первая версия всегда говно. Я так за один день сделал 30+ изменений и наконец увидел то, что было у меня в голове. 

И самое главное: мысль в голову Product Owner может прийти в 6 утра, и не надо ждать, пока все проснутся и заведут свою Figma. 

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

Как вы поняли, аналитиков в этом loop тоже нет — они тоже не нужны 🙂

Больше по теме тут.

Через час расскажем, как настроить аварийное восстановление с возможностью георезерва

Сегодня в 12:00 мск вместе Хайстекс Акура проведем практический вебинар «Как настроить аварийное восстановление с возможностью георезерва». На нем представим готовый сервис, который по клику обеспечивает запуск копий систем в облаке. Решение поможет в случае поломок, кибератак и аварий.

Вы узнаете, как организовать георезерв в облаке Selectel, пройти внедрение под ключ и подтвердить фактические RTO/RPO тестовым восстановлением. Особенно ждем системных администраторов, DevOps- и SRE-инженеров, CTO и руководителей IT-департаментов.

Программа вебинара

• Почему бэкап не равен аварийному восстановлению: где заканчивается резервное копирование и начинается восстановление сервиса 

• Почему аварийное восстановление сложно внедрять самостоятельно 

  Подробнее о докладе

• Как устроен DRaaS от Selectel на базе Хайстекс Акура 

• Георезерв Москва-Санкт-Петербург как один из сценариев аварийного восстановления ИТ-инфраструктуры 

• Как подтвердить реальную готовность аварийного восстановления: тестовое переключение и проверка фактических RTO/RPO 

• Ответы на вопросы

А если спросите нас по теме вебинара и ваш вопрос запомнится спикерам, подарим легендарного плюшевого Тирекса.

Присоединяйтесь через час →

Обновление платформы SimpleOne 1.34.0 ускоряет реакцию на критичные события и снижает риски внутренних аудитов

Новая функциональность платформы SimpleOne помогает быстрее отрабатывать критичные события и снижать риски при внутренних проверках.

Что нового:

• Нативные push‑уведомления в браузер
  Оповещения приходят напрямую в поддерживаемые браузеры на разных устройствах, без зависимости от почты и мессенджеров.

• Форматирование теперь и там, где был только простой текст
  Лента активности перешла со стандартного текстового поля на визуальный редактор (WYSIWYG): форматирование, списки, ссылки и изображения; ранее созданные сообщения отображаются без изменений. А существующие колонки типа Text администратор может перевести на такой же редактор с сохранением данных — раньше для этого пришлось бы создавать новое поле и переносить значения вручную.

• Роль «Аудитор»
  Даёт полный доступ на чтение ко всем таблицам на уровне администратора, но без права редактирования. Это упрощает проверки и расследования и поддерживает принцип разделения обязанностей.

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

Подробнее о платформе SimpleOne
Техническая документация

11,5 миллионов в месяц за управление знаниями: мечта или реальность?

Продолжаю разбирать вакансии, связанные с управлением знаниями и технической документацией. Сегодня смотрим позицию LMS/База знаний координатора в международной компании Union Staff.

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

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

Дисклеймер. Я больше 15 лет внедряю менеджмент знаний в российских компаниях. Запустил эти разборы, чтобы работодатели могли увидеть спорные места в вакансиях, а специалисты – точнее оценить задачи и подготовиться к собеседованию. Анализирую только опубликованные тексты вакансий, а не реальные процессы внутри компаний.

Начну с плюсов

Вакансия описана на языке профильных специалистов. В ней прямо упоминаются база знаний, Knowledge Management и распространённые платформы: Confluence, Notion, SharePoint и другие. Это помогает опытному кандидату быстро понять, с чем предстоит работать.

Требования к опыту выглядят адекватно. Достаточно опыта работы с LMS, базами знаний или корпоративными порталами. От кандидата не требуют десяти лет в Knowledge Management и экспертного владения всеми перечисленными системами одновременно.

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

Дальше начинаются вопросы

Первый – роль размыта. В одной вакансии смешаны обязанности менеджера по управлению знаниями и специалиста по обучению. Контроль прохождения курсов и администрирование LMS скорее относятся к L&D, чем к Knowledge Management. 

Эта неопределённость влияет на отклики. Специалист по управлению знаниями может решить, что вакансия в основном про обучение. Кандидат из L&D, наоборот, может недооценить объём работы с базой знаний.

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

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

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

Мой вывод

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

Особенно интересной она может быть для L&D-менеджера, который хочет глубже работать со знаниями, или для начинающего KM-специалиста, готового совмещать развитие базы знаний с операционными задачами в LMS.

Перед откликом я бы уточнил:

• как распределяется время между работой со знаниями и корпоративным обучением;

• какую платформу используют сейчас и почему в вакансии перечислено несколько систем;

• кто отвечает за структуру, поиск, качество и актуальность базы знаний;

• какие процессы уже настроены, а какие предстоит создать;

• обязательно ли подтверждать русский язык на уровне C2;

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

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

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

SimpleOne выпустила версию ITSM 2.0.0 с ИИ-помощником на сервисном портале

Теперь в SimpleOne ITSM есть ИИ-помощник на портале самообслуживания. Пользователь пишет запрос в свободной форме, ИИ понимает контекст, находит нужную услугу или статью, подготавливает форму обращения.

СМОТРЕТЬ ВИДЕО

Что меняет ИИ-помощник:

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

• Для сотрудников и клиентов — портал становится понятнее: достаточно описать ситуацию своими словами, и помощник сам найдёт ответ, подберёт услугу или подготовит форму обращения.

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

И это работает не только для ИТ — помощник одинаково применим к HR, бухгалтерии, юридическому отделу и любому сервисному подразделению.

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

Андрей Вишняков, директор по бизнес-продуктам компании SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ

Что ещё изменилось в ITSM 2.0:

• База известных ошибок (KEDB) вынесена на портал — пользователи сами находят обходные решения до создания тикета

• Комментарии из мессенджеров и почты подтягиваются прямо в обращение

• Появилась возможность оставить заметку ко всем обращениям при их массовом завершении

• На форме инцидента появился виджет сервисных отношений

• Автозаполняемые поля дочерних инцидентов защищены от случайного редактирования

Подробнее о SimpleOne ITSM
Техническая документация

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

Дорогие статическо-системные-ловлевел-бояре я вас напугаю - в новых системных языках программирования есть… интерпретаторы!

А как это выглядит внутри? Чем крут Jai?

🤓 Новый мини пост в моём блоге про всё это: тык

▶️ А ещё есть в видео формате: ютуб

Как подключить брокерский счёт к ChatGPT и другим ИИ-сервисам?

«Финам» интегрировал платформу FinamTrade с искусственным интеллектом через стандарт MCP (Model Context Protocol). Теперь любой пользователь может “подружить” свой брокерский счёт с ИИ-ассистентом — ChatGPT, Claude или любым другим сервисом, который поддерживает MCP. Всё настраивается за пару минут через веб-версию FinamTrade: выпускаете токен, подключаете — и можно получать аналитику и ответы на свои инвестиционные вопросы обычными текстовыми запросами, прямо в чате.

Что умеет Finam MCP уже сейчас:

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

• Принимает текстовые запросы вроде «Покажи список моих позиций», «Какая сейчас цена GAZP?» или «Что у меня в секторе “Технологии”?».

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

• Поддерживает работу с несколькими токенами и ИИ одновременно, всё под контролем пользователя.

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

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

Где узнать больше?

30 июля в 18:00 (мск) состоится бесплатный вебинар, на котором команда FinamTrade продемонстрирует:

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

• Как вести списки наблюдения и делать персональные заметки, не тратя время на рутину.

• Как формулировать запросы к ИИ и получать мгновенные, понятные ответы.

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

• Ответят на вопросы в прямом эфире.

Участие бесплатное по регистрации

Будем рады видеть всех, кто интересуется современными инструментами для эффективной работы с инвестициями!

System Design на собеседовании: как не утонуть в требованиях, нагрузках и архитектуре

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

В новом выпуске AvitoCode Саша Кучук, тимлид в Авито, разбирает весь путь от постановки задачи до финальной защиты решения:

• как собирать требования и не упустить нефункциональные;

• как быстро прикинуть нагрузку и не закопаться в расчётах;

• как выстроить домены и API, перейти от high-level к low-level design;

• как выбирать технологии под конкретные ограничения;

• как вести себя на защите решения и на что смотрят интервьюеры при оценке.

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

Смотреть:
📺  YouTube
🔵 ВК 
📌 RuTube

Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based

Есть у меня тулза для бэкапа фоточек с гугла - сделал ее когда бэкапилка QNAP приказала долго жить(TL;DR Google изменил API так, что идея автоматического бэкапа стала бессмысленной)

Первая версия утилиты работала очень топорно и работала на playwright+chromium(это важно)

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

Самое популярное такое решение работает на Firefox. Ну заменить один браузер на другой - что может пойти не так (спойлер: почти всё)

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

Оказывается, FF в playwright не поддерживает события загрузки файлов, которых ждет. Совсем. Тут и случилось самое страшное. Что за вендорлок, почему я должен использовать именно chromium??? - подумал я..

Решение как заставить FF делать то, что нужно - нашлось быстро. Нужно просто использовать Selenium Grid

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

Первое же тестирование показало новую проблему. Playwright позволяет сохранить все cookies, вообще все и загрузить их в контекст СЕССИИ до загрузки какой-либо страницы. Selenium так не работает: он загружает/проставляет cookies только в контексте СТРАНИЦЫ. Это делает перенос данных авторизации гораздо мучительнее, ведь Google активно сопротивляется сбору cookies авторизации, редиректит с accounts.google.com на myaccount.google.com и т.д.

Чтобы добыть вообще все cookies нужен BiDi, но вроде как в Grid его еще не завезли по умолчанию. Поэтому надо в плагине писать прокси, которое позволяет по стандартной ручке достать все cookies..

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

Как только загружался 2ГБ архив - скрипт наглухо OOM-ился. Стандартный API загрузки файла передает его целиком, заэнкоженым в base64. Естественно, целиком загнать в base64 2ГБ - жестоко, и столько памяти скрипту бэкапа никто выделять не собирается.

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

И вот на этом месте - ура, все работает как надо!
Но не проще ли было месяц назад ПРОСТО ВЗЯТЬ Chromium..🤔

Открытый ИИ-проект JCode запускается намного быстрее Claude Code и может работать в 100 сессиях одновременно: 

• одна сессия весит всего 28 МБ оперативной памяти.

• можно запустить целый рой ИИ‑агентов — они будут делать проект вместе, распределять обязанности и критиковать работу друг друга.

• есть глобальная память между сессиями, чтобы не потерять ни единой строки кода.

• работает с API Claude, OpenAI/ChatGPT/Codex, Gemini, GitHub Copilot, Azure, Alibaba Coding Plan и другими сервисами.

• поддерживает запуск локальных моделей через Ollama и LM Studio.

• редактирует, перезагружает, дебажит код, чтобы довести задачу до идеала.

• можно импортировать сессии из Claude Code, Codex, OpenCode и Cursor.

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

Как делать ИПР для сотрудника: 8 правил от эксперта Okko

На QA-days: Оkko, ИнфоТеКС и Piter QA спикер из Okko поделился подходом к формированию траектории развития QA-специалиста через индивидуальные планы развития (ИПР). Доклад поможет выстроить систему, где сотрудники растут с интересом, а не «под кнутом».

Забирай 8 готовых правил в работу.

• Смотреть запись доклада

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Инференс трансформеров на чистой Java без Python и JNI

Запуск нейросетей на Java часто воспринимается как компромисс: либо JNI-обвязки, либо Python-стек, либо готовые рантаймы. Но современные JDK уже позволяют строить полноценный пайплайн инференса внутри JVM — без Python, без JNI-слоя и без лишней магии.

Хочу провести технический вебинар и показать, как на чистой Java реализовать инференс трансформеров и оптимизировать его под CPU, используя:

• Foreign Function & Memory API (FFM) — для безопасной работы с нативной памятью и маппинга весов моделей без лишнего оверхеда и давления на GC;

• Vector API — для SIMD-ускорения матричных операций на CPU.

И это не только про LLM.

На вебинаре разберём, как на Java можно запускать и оптимизировать разные классы трансформеров (encoder-only, encoder-decoder, decoder-only):

• RoBERTa — для классификации и NLP-задач;

• MiniLM — для эмбеддингов и семантического поиска;

• T5 — для seq2seq-сценариев и генерации;

• Qwen — для современных LLM-сценариев и практического инференса.

То есть цель вебинара — не показать ещё один способ вызвать llama.cpp по API, а разобраться, как устроен сам Java-слой инференса для трансформеров и где он реально полезен.

Если тема вам интересна — оставьте контакты по ссылке.

Если наберём 20+ заинтересованных, я подготовлю программу и разошлю приглашения с датой.

UPD: Всем, кто заполнит форму предрегистрации, я сразу после вебинара (или даже чуть раньше) скину ссылку на приватный репозиторий с базовым PoC/бенчмарком инференса Qwen на Vector API, чтобы вы могли покрутить код сами.

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

Часть задач можно выполнить как отдельную доработку, другие предполагают регулярное сопровождение. В списке есть проекты по УНФ 3.0, УТ 11.5, РИБ, «Альфа-Авто», 1С 7.7, ЕГАИС, «Честному знаку», ТС ПИоТ и электронным перевозочным документам.

• Адаптировать расширения в 1С:УНФ 8. Управление предприятием общепита, редакция 3.0 (3.0.13.278)

• УНФ 3: ускорение оприходования товара

• Настроить автоматическую фискализацию на облачной кассе по оплатам СБП в УНФ 3.0

• Заказ по статье «Пример адаптации УТ 10.3 для работы с ТС ПиОТ (ESM): используем модули из УПП 1.3»

• УТ 11.5: в список заказов добавить две новые колонки с возможностью фильтрации

• УТ 11.5 РИБ: при подборе товара в заказе и отчете по остаткам показывать остатки центральной базы

• Настроить интерфейс для пользователя только с журналом «Электронные перевозочные документы»

• Перенос картинок в «Альфа-Авто 6»

• Загрузить приходные и расходные накладные из 1С 7.7 в 1С:Розницу

• Регулярные доработки по работе 1С с ЕГАИС, ЧЗ и ТС ПИоТ

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

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

CPU steal time: как измерить, как доказать и когда он ни при чём. В логах пусто, загрузка процессора умеренная, а приложение отвечает вдвое медленнее обычного. Один из кандидатов на объяснение — steal time: время, когда виртуальная машина была готова считать, но не получила физическое ядро.

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

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

Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:

• конкуренция с соседними VM на ноде;

• ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;

• накладные расходы самого планировщика гипервизора;

• кратковременные всплески — миграция VM, резервное копирование ноды, обслуживание.

Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:

systemd-detect-virt

Аналог steal для контейнеров — троттлинг по cgroup:

grep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max

Растущий nr_throttled означает, что вы выбираете свою квоту. Это не соседи и не оверселлинг — это ваш лимит, и решается он либо оптимизацией, либо тарифом.

Какие значения считать нормой. Универсальной нормы нет — она зависит от платформы виртуализации, политики провайдера и тарифа. Практические ориентиры, которые у меня обычно работают:

• 0–1% — фон, встречается почти везде, игнорируем.

• 3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.

• выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.

Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.

Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.

Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:

• Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.

• Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.

• Steal ровным фоном 2–3% круглосуточно — накладные расходы платформы, обычно нормально.

Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.

Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:

• вывод sar -u 1 600 или график за несколько часов;

• mpstat -P ALL 1 за минуту — с разбивкой по ядрам;

• ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;

• конкретные временные метки, когда приложение деградировало;

• systemd-detect-virt и параметры тарифа.

Что не поможет

• Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.

• Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.

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

Чек-лист

systemd-detect-virt                          # есть ли steal в принципе
vmstat 1                                     # характер: плато или выбросы
mpstat -P ALL 1                              # распределение по ядрам
sar -u 1 600                                 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat       # для контейн