Анализируй и проектируй
Мы с партнёром разработали концепцию Phase — архитектурный подход к построению бизнес-систем с ИИ-агентами. Этот текст не про то, что такое Phase — про то, почему он устроен именно так, а не иначе. Для каждого ключевого решения был альтернативный вариант. Здесь я разбираю, почему мы его отвергли.
Александр Либкинд, руководитель направления развития сервисов управления затратами и эксперт Практики FinOps, поделился материалом о том, почему ручная инвентаризация инфраструктуры редко приводит к устойчивой экономии и как перейти от разовых проверок к управляемой модели.
Поводом могут быть GPU-инстансы, тестовые окружения, неиспользуемые диски, свободные IP-адреса или любые другие ресурсы, которые продолжают потреблять бюджет после завершения задачи. Но проблема почти всегда шире, чем один тип инфраструктуры.
Если у ресурса нет владельца, команды, среды и приложения, компания не управляет затратами. Она просто периодически пытается разобраться, что можно отключить без последствий.
Сейчас главное уже понять, что почти никто не вскрывает замки и не ломает двери, и вообще количество преступлений без человеческих жертв стремительно снижается. В дом проще зайти вместе с хозяином. Да, произошло обесценивание человеческой жизни!
Дом или квартира превращается в средневековую тюремную камеру всего за несколько секунд, пока вы открываете входную дверь — неважно, выходите или заходите. Если уголовникам надоедает ждать, вам позвонит водопроводчик — классика, которая работает.
Наша рекомендация вас тоже не спасёт полностью, но практика показала, что она единственная действительно спасает. Шлюз — симбиоз механики и электроники, это не просто какая‑то сигнализация, это физическая защита!
Привет, Хабр! Сегодня я хочу поделиться своим опытом разработки ASOC платформы.
В статье я расскажу о преимуществах такого решения, затем опишу особенности реализации всех ключевых компонентов. Моя цель показать, что разработка собственных ИБ инструментов сегодня не является сложной задачей и, возможно, вдохновить кого‑то на самостоятельное улучшение практик AppSec и DevSecOps в своей компании.
С необходимостью запуска кода на сервере сегодня сталкиваются далеко не только профессиональные айтишники. В наше время популярна разработка через ИИ. Любой человек с идеей и доступом к моделям может быстро сгенерировать работающий код. Проблема в том, что люди зачастую слабо представляют, какие базовые уязвимости тащит за собой сгенерированный проект.
На стадии деплоя безопасность критична. Ниже мы разберём на примере защиты сайта и бота, как настроить сервер и проверить код на наличие самых базовых уязвимостей.
Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.
В статье - краткий разбор некоторых принципов моделирования данных простыми словами.
- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth
Почти все мы только учимся работать с агентами. Даже опытные команды иногда управляют агентами так, что те приносят больше вреда, чем пользы. HumanLayer сформулировал 12 принципов того, как делать и настраивать агентов правильно. Каждый пункт отвечает на вопрос, что работает хорошо, а что стабильно приводит к проблемам.
Несколько недель назад мы обсуждали Java-компонент, запускающий кластер Spark. Его основная задача — координация. Он поднимает всю необходимую инфраструктуру, прокидывает конфигурацию, дожидается нужных сигналов и отходит на второй план.
Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.
Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.
Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.
Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.
Привет, Хабр! В этой статье я хочу рассмотреть нейросети: как они обучаются, как работают и из чего состоят. На примере перцептрона с реализацией на python.
Эта статья — не очередной обзор готовых библиотек вроде PyTorch/TensorFlow, а разбор нейросетей с нуля. Вы узнаете, из чего состоят нейроны и слои, как данные проходят через сеть, как она учится на ошибках и почему не всё всегда гладко. Материал рассчитан на новичков, которые хотят узнать как работают простейшие нейросети со стороны математики.
В этой статье я делюсь нашим опытом переноса интеграций с монолита на микросервис: какие решения мы принимали и на что обращали внимание.
Статья будет полезна системным аналитикам, разработчикам и тимлидам, которые планируют или уже реализуют вынос интеграций из монолита в микросервисную архитектуру.
Всех приветствую. В сотовой связи я, страшно подумать, уже третий десяток лет. Начинал еще в двухтысячных, в сетях 2G. Своими руками довелось обслуживать как CDMAone от Qualcomm, так и GSM от Alcatel, а позже строил третье поколение на Ericsson и четвертое на Huawei.
Конечно, я стараюсь следить за всеми новостями рынка сотовой связи. И просто не мог пройти мимо свежего исследования «Технология 5G: обзор российского и мирового рынка» от команды Research & Insights Центра стратегии цифровых продуктов МТС. Исследование крайне любопытное, и я бы хотел особенно отметить несколько деталей, которые мне там показались важными. Спойлер: как раньше, сети уже не окупятся — придется придумывать новые модели монетизации. А еще у нас сложности с оборудованием и частотами.
По итогам вебинара «От затрат к прибыли: строим эффективную и окупаемую систему обучения сотрудников» разбираем, как компании автоматизируют корпоративное обучение на базе «1С:Электронное обучение. Корпоративный университет», какие процессы переводят из Excel в единую систему и за счет чего получают измеримый эффект.
На вебинаре Инфостарт Корпоративные решения и компания «Русские решения» разобрали, как эти задачи решаются с помощью «1С:Электронное обучение. Корпоративный университет». Эксперт по автоматизации корпоративного обучения Валерий Денисенко показал, как выстроить централизованную систему обучения и какие результаты получают компании после внедрения....
Проблема практически любого предприятия малого масштаба, ведущего бизнес более чем в двух рабочих валютах, очень проста — деньги уходят, деньги приходят, курсы меняются, а мы учитываем только рублёвые активы (в лучшем случае). При этом все наши операции по криптокошелькам представляют собой мистические артефакты, которые вроде как есть, но не попадают даже во внутреннюю отчётность для владельца бизнеса.
Так получилось, что я родился скромным Goфером и год назад начал работу над самописной ERP-подобной учётной системой для микробизнеса РФ…
Луковичную (onion) архитектуру обычно продают аргументом «легко поменять БД или фреймворк». Только базу в проде меняют раз в пятилетку, а чаще вообще не меняют — ради этого городить слои не выгодно.
Реальная ценность в другом, и она ежедневная: глядя на правку, ты заранее видишь её радиус. Поменял формат ответа одной ручки — изменение осталось в одном handler'е, соседние ручки и cron не задеты. Тронул бизнес-правило в сервисе — и сразу понятно, что эффект расходится на всё, что выше.
Понадобилось параллельно писать ещё в одно хранилище — горячий кэш, поисковый индекс, аналитическую базу рядом с основной — это добавляется в одном репозитории, и весь код, который через него пишет, начинает писать в оба места разом. Ничего не переписываешь и, главное, негде забыть: точка подключения одна, а не разбросана по всем местам, где идёт запись.
Каждый, кто хоть немного работал с объектно-ориентированными языками, наверняка сталкивался с принципом подстановки Лисков. При этом мало кто знает, откуда этот принцип взялся и в каком контексте Лисков его формулировала. Мы перевели ее доклад, прозвучавший на OOPSLA'87, чтобы дать каждому возможность обратиться к первоисточнику. Прочитав этот текст, вы увидите, насколько сложным и неочевидным было отношение Лисков к наследованию и как она связывала его с идеями абстракции, инкапсуляции и полиморфизма.
Последнее время в опенсорсе много драмы: продолжаются споры о системах ИИ, позволяющих за минуту переписать проект и изменить его лицензию на разрешительную, и опенвошинге, когда доступный код выдают за открытый. Теперь на первые полосы вышла новая проблема — массовый наплыв пулл-реквестов, сгенерированных системами ИИ [ситуацию уже окрестили «слопмагеддоном»]. Обстановка дошла до того, что мейнтейнеры закрывают возможность участия в развитии открытых проектов. Мы в Beeline Cloud решили обсудить проблему и то, как быть контрибьютерам и мейнтейнерам в сложившейся ситуации.
Если Вы безоговорочный поклонник искусственного интеллекта (Ai) в нынешней его трактовке и не приемлете другие решения, то я бы не рекомендовал читать и комментировать эту статью. Если Вы занимаетесь приложениями для банковской сферы, или для торговли, или создаёте чат-боты общего назначения, то эта статья, скорее всего, будет Вам не интересна. Разработчики игр, так же не найдут в этой статье ничего полезного.
Но, возможно, вы участвуете в проектах связанных с автоматизацией проектирования в машиностроении или создаёте экспертные системы медицинского назначения и тесно взаимодействуете с предметными специалистами (инженерами, технологами, врачами). В таком случае идеи и решения из этой статьи могут пригодиться в Вашей работе. Если же вдруг Вы связаны с преподаванием прикладных дисциплин не связанных с информационными технологиями, то подходы к формализации знаний и созданию прикладных приложений с минимальным привлечением ИТ-специалистов могут Вас заинтересовать и оказаться ещё одним инструментом закрепления знаний наряду с курсовым и дипломным проектированием.
В других ранее опубликованных статьях достаточно подробно обсуждались аспекты технологии поиска решений управляемого данными. Был предложен понятийный аппарат и дано определение информационного блока, как единицы формализации знаний предметной области.
Однако остались в тени некоторые важные детали. Полагаю, что данной публикацией удастся убедить читателя, что решение достаточно широкого класса задач возможно, простыми и не требовательными к вычислительным ресурсам средствами.
Итак, у вашего агента имеется набор инструментов, которыми он может пользоваться. Теперь нужно заняться их оркестрацией для решения реальных задач. Оркестрация не сводится к простому выбору того, когда и какие инструменты следует вызывать. Необходимо также создать правильный контекст для каждого вызова модели, чтобы действия были эффективными и обоснованными. Хотя простым задачам бывает достаточно одного инструмента с минимальным контекстом, более сложные рабочие процессы требуют тщательного планирования, чтения памяти и сборки динамического контекста для точного выполнения каждого шага. В этой главе мы рассмотрим стратегии оркестрации, создание контекста, выбор инструментов, исполнение, а также планирование топологий для построения агентов, способных эффективно и надежно решать многошаговые задачи из реальной практики. Как показано на рис. 5.1, суть оркестрации заключается в том, как система использует имеющиеся в ее распоряжении ресурсы для эффективной обработки пользовательских запросов.
В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.
Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.
В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.