Анализируй и проектируй
Цифры за закрытый месяц внезапно меняются, а поиск причины превращается в разбор всего пайплайна — от загрузки событий до логики витрин.
В статье разбираем пять типовых сценариев, из‑за которых прошлое в отчётах продолжает «двигаться», и показываем, как сделать пересчёт данных предсказуемым.
Отдавая контрактному производству полный комплект Gerber-файлов и оригинальных прошивок, разработчик часто рискует столкнуться с «атакой третьей смены» — бесконтрольным выпуском нелегальных клонов устройства. Есть ли варианты защиты? Казалось бы, нет, однако... Есть... физика кремния, физически неклонируемые микродефекты кремния (PUF) и неповторимость литографии внутри FPGA. И это можно использовать как уникальный отпечаток устройства.
В этой статье я расскажу, как заставить наноструктурные особенности FPGA работать на безопасность вашего бизнеса, построить отказоустойчивую схему «Кристалл — Сервер» и жестко наказывать "не честного" производителя с помощью отложенного аппаратного саботажа.
Всем привет! Меня зовут Юрий, я руковожу группой прикладной разработки в департаменте мультивендорной поддержки YADRO. Мы занимаемся развитием собственного сервисного инструмента «Гегелло», который позволяет работать с диагностическими данными различного оборудования и визуализировать проблемы в системах.
Какую задачу решает платформа, почему это не просто «Grafana у нас дома» и что в основе архитектуры «Гегелло» — читайте в статье.
Кто хоть раз собирал сводный отчет из десятка табличек, тот знает, что самые важные данные чаще всего живут в чьем-то личном Excel-файле, актуальная версия которого лежит в каком-нибудь личном чате. Мы столько раз проходили этот круг, что решили сделать большой шаг в сторону управляемой работы с данными для себя и наших клиентов.
В этой статье расскажем, как создавали собственный продукт KORUS Data Input для организации корпоративных систем ручного ввода данных и что из этого получилось.
По репозиториям на Git часто видно: вложенные пайплайны в GitLab CI остаются редкой экзотикой, а в проде в основном живут линейные сценарии. Тем не менее я убежден, что грамотные downstream'ы прекрасно связывают процессы в единый поток, снимают ручной труд с команды и добавляют архитектуре гибкости. Конечно, запутаться в многоуровневой логике может даже опытный DevOps-инженер или тимлид, но чтобы вы не блуждали в сложной структуре, я подготовил для вас практическую шпаргалку по работе с ними.
Последние несколько лет я занимался сопровождением вендорской разработки, строил CI/CD преимущественно на базе Gitlab CI и мне есть что рассказать. Помните фильм «Начало»? Сегодня он станет нашим наглядным гидом по архитектуре наследуемых пайплайнов и, надеюсь, поможет вам взглянуть на многослойный CI‑конвейер под другим углом.
Сплиттер работает корректно, метрика посчитана, а p‑value уверенно опустился ниже 0,05 — результат кажется готовым к раскатке. Однако ошибка в оценке дисперсии способна превратить случайное различие в статистически значимое.
В этой статье разберём четыре типовых сценария, в которых тест подтверждает эффект, которого в данных нет, и посмотрим, как исправить расчёты.
Классический RAG хорошо ищет отдельные факты, но может пропускать исключения и связи между разными разделами документации. Я проверил альтернативный подход: мультиагентный граф, в котором роутер направляет запрос экспертам по отдельным доменам знаний.
В статье — архитектура на LangGraph, сравнение с наивным RAG на датасете из 40 вопросов, метрики качества, задержки и стоимость запросов. А главное — разбор, когда дорогой в эксплуатации агент может оказаться выгоднее дешёвого RAG за счёт экономии инженерного времени.
Промышленные производства во всём мире активно внедряют роботов, и Россия старается не отставать от этого тренда. В 2025 году плотность роботизации в стране достигла 29 роботов на 10 тысяч занятых. Это на 36% больше, чем было годом ранее, но даже с таким показателем мы только на 43-м месте в мире. Государство ставит цель: к 2030 году 145 роботов на 10 тысяч человек и 25-е место в мире.
Многие предприятия в России готовы к изменениям, у них есть потребность в роботах и возможности для их эффективного использования. Казалось бы, до технологичного будущего рукой подать. Но проблема в том, что рынок интеграторов — это чёрный ящик. Компании не понимают, как искать подрядчика, а подрядчики не знают, как выделиться среди конкурентов.
Хабр и Национальная ассоциация участников рынка робототехники (НАУРР) решили создать прозрачный рыночный инструмент — реестр интеграторов промышленных роботов. Под катом расскажем, как реестр может поспособствовать развитию рынка роботизации в России и как в него попасть интеграторам.
В какой-то момент у нас, как и у многих команд, появился соблазн проверить: а можно ли уже не просто просить AI «написать user story», а действительно встроить его в рабочий процесс аналитика? Например, дать агенту вводные по задаче, макеты в Figma, примеры документации и требования к оформлению, и получить на выходе нормальный Use Case, API-спецификацию, PlantUML-диаграмму и аккуратную страницу в Confluence.
Звучит красиво.
Особенно если вы когда-нибудь вручную переносили сценарии из заметок в Confluence, сверяли шаги с макетами, оформляли вкладки с HTTP-запросами, проверяли коды ошибок и пытались не забыть все вопросы, которые «надо потом уточнить».
В статье расскажу, насколько мы близки к этой утопии — как протестировали работу ИИ в реальном аналитическом процессе в нескольких кейсах: для подготовки Use Case, аналитических артефактов, публикации в Confluence и в работе с Figma.
Привет, Хабр! Меня зовут Кира, я бизнес‑аналитик клиентского сервиса ITSM 365 и куратор командной базы знаний.
Наш продукт развивается с каждым годом, и вместе с ним растет количество клиентских обращений: их становится больше, а сами вопросы — сложнее. Если в 2015 году один бизнес-аналитик разбирал около 300 кейсов в год, то сегодня — около тысячи. При этом средняя оценка работы с обращениями остается на уровне 4,9+.
Очевидно, что чем больше людей подключается к работе, тем сложнее сохранять единый уровень экспертизы, быстрее вводить новичков в работу и не терять знания, накопленные командой. Поэтому нам нужно было сделать так, чтобы с увеличением команды росла не нагрузка на опытных специалистов, а объем знаний, доступных каждому сотруднику.
В этой статье расскажу, какие принципы и инструменты помогают нам переиспользовать знания, делать клиентов более самостоятельными и справляться с растущим количеством обращений без потери качества.
Почти все сегодня знают про LLM и могут сравнивать модели, спорить о качестве ризонинга, важности контекста и стоимости токенов.
Но в среднестатистической компании обычно все ограничивается генерацией текстов, простым чат-ботом и редкой автоматизацией поддержки разработчиков, так как команды не знают, как подойти к выбору моделей и интеграции без лишних затрат.
Между тем инструменты для этого уже есть, например Evolution Foundation Models. И благодаря широкому пулу моделей помогают сделать продвинутый ИИ доступным для всех, а не только для сценариев разработки.
Эта статья для тех, кто на практике столкнулся с дефицитом рабочих ИИ-решений для неайтишных сценариев: для аналитиков, продактов, тимлидов и технических лидеров, которым нужно грамотно внедрить LLM в рабочие процессы от маркетинга до бэк-офиса.
Kafka часто появляется на System Design интервью, когда нужно асинхронно обрабатывать события и масштабировать систему.
Но за словами “добавим Kafka” скрывается много важных деталей: как выбрать ключ, сохранить порядок сообщений, распределить разделы между потребителями и не создать горячий раздел. В статье рассмотрим архитектуру Kafka, репликацию, смещения, повторные попытки и политики хранения.
Это вторая статья цикла. В первой части мы разбирали, как начать FinOps с точки ноль: посадить финансы и инженеров за один стол, договориться об общей картине затрат и собрать первые данные для прозрачности. Теперь переходим к следующему шагу: пилоту, ручной разметке ресурсов, поиску оптимизационного потенциала и правилам, которые не дают экономии расползтись обратно.
Переход с 1С:УПП на 1С:ERP требует аудита процессов, очистки данных, настройки интеграций и обучения команды. В статье: этапы миграции, сроки, способы снизить бюджет, риски переноса данных и рекомендации для запуска без простоев и сбоев учета в базе.
Это 2 часть материала про переход, 1 часть про самые распространенные заблуждения и ошибочные представления о системе 1С:ERP в статье https://habr.com/ru/companies/infostart/articles/1051952/
Мок‑экзамен, вопрос номер сорок с чем‑то. Сценарий: система должна классифицировать входящие обращения, и ни при каких условиях категория не может выходить за пределы фиксированного списка. Какой вариант обеспечивает это требование? Я уверенно тыкаю в ответ с формулировкой «добавить в системный промпт строгую инструкцию с перечнем допустимых категорий и явным запретом на другие значения».
Красным. Правильный ответ — валидация вывода на уровне приложения со схемой и retry‑логикой. Я смотрю на объяснение и ловлю себя на раздражении: ну промпт же тоже работает, я сто раз так делал. А потом листаю свои прошлые мок-результаты и вижу закономерность: я стабильно ошибаюсь в вопросах одного и того же типа. Не потому что не знаю материал — а потому что у меня в голове неправильно проведена одна граница.
Готовясь к CCA‑F (Claude Certified Architect — Foundations), я ожидал, что буду зубрить параметры API и лимиты контекста. Вместо этого экзамен методично бил меня по одному и тому же месту, пока я не сформулировал, во что именно я неправильно верил.
Идеи аспектно-ориентированного программирования до сих пор широко используются в современных языках и фреймворках — достаточно вспомнить их роль в экосистеме Spring. Однако при всей практической востребованности сама парадигма остается как будто в тени. Чтобы немного это исправить, мы публикуем перевод текста Грегора Кизалеса и его коллег из Xerox PARC — первого полноценного манифеста АОП, представленного на конференции ECOOP ’97 и заложившего основы для дальнейших исследований в этой области.
Работа с BIM-моделью ценна не только тем, что проектировщик получает трехмерное представление здания. Главная сила информационной модели проявляется когда геометрия начинает работать как источник данных: из нее можно получать экспликации, спецификации, ведомости и другие табличные отчеты, которые затем включаются в комплект проектной документации.
В nanoCAD BIM Строительство (рис. 1) эта задача решается через инструменты табличных отчетов и специфицирования. Они позволяют извлекать информацию из помещений, проемов, конструктивных и архитектурных элементов, настраивать состав полей, группировку, сортировку, формат вывода и оформление таблиц по шаблону.
Ниже мы разберем практический подход к созданию экспликации помещений и спецификации элементов заполнения проемов, а также особенности двух технологий формирования таблиц: динамических отчетов nanoCAD и классических спецификаций в формате *.dwg.
Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.
Одна из ключевых причин использования gRPC для связи между сервисами — строгий protobuf-контракт. Он даёт типизацию, фиксирует схему данных и снижает риск случайно сломать интеграцию. Но иногда случаются ситуации, когда эти плюсы загоняют нас в рамки. Например, когда сервис просто передаёт данные дальше, но его всё равно приходится обновлять из-за изменений, которые нужны только конечному потребителю. В таких случаях полезно знать, какие механизмы protobuf позволяют работать с контрактом более гибко, не отказываясь от него полностью. В статье расскажу о трёх из них и приведу примеры, для чего они могут применяться.
В современной строительной индустрии технологии информационного моделирования (BIM) становятся стандартом проектирования, позволяя автоматизировать рутинные процессы и повысить точность инженерных решений. Эффективным инструментом для реализации таких задач является программный комплекс nanoCAD BIM Строительство.
Ключевая идея BIM – это единая информационная модель, где каждый элемент содержит не только геометрию, но и атрибутивные данные. Все чертежи и спецификации генерируются автоматически на основе этой модели, что исключает расхождения между «рисунком» и «таблицей».
В этой статье представлено пошаговое руководство по созданию и оформлению свайного поля. Процесс разделен на три основных этапа:
1. Подготовительный: настройка рабочей среды и импорт необходимых профилей и спецификаций.
На этом этапе мы «учим» программу правилам оформления (как выглядит свая на плане, как нумеровать, какие параметры выводить в ведомость).
2. Моделирование: построение 3D-модели свайного поля с использованием Библиотеки объектов и заполнение параметров элементов.
Здесь мы насыщаем модель данными – это основа для всех последующих чертежей.
3. Оформление: автоматическая генерация плоских планов и вывод сопутствующих таблиц на лист чертежа.
Финальная стадия, где программа «собирает» данные из модели и представляет их в виде нормативной документации.
Эта методика позволяет инженеру значительно сократить сроки подготовки проектной документации и исключить ошибки ручного ввода данных.
Пройдя все шаги этого руководства, вы сможете сформировать точную модель и итоговый лист схемы свайного поля следующего вида.
Когда команда небольшая и все сидят в одном открытом пространстве, знания передаются почти сами собой — через разговор у кофемашины, ревью кода, общий чат. Пока команда маленькая, это терпимо, но как только появляется рост, удалёнка, параллельные проекты и новые сотрудники, хаос начинает стоить больших денег. Именно в этой точке большинство IT-компаний впервые задумываются о том, что «база знаний» — это не просто папка в Google Drive, а самостоятельная инфраструктурная задача.
Мы в Alpina Digital прошли этот путь и хотим рассказать, как это было.