Анализ и проектирование систем *

30+ движков за две недели, реальные замеры на Apple M4, и почему ElevenLabs за $5.57/час — это приговор для бизнеса

Сижу на очередном рабочем созвоне. Обсуждаем архитектуру нового сервиса. Технически я всё понимаю — документацию на английском читаю без словаря, код ревьюю, в слаке переписываюсь нормально. А вот когда надо открыть рот и сказать что‑то сложнее «I agree» — начинается цирк. Пауза. Подбираю слова. Коллега уже ответил за меня.

Знакомо?

Я CTO, серийный предприниматель, последние годы плотно работаю с AI‑интеграциями. И вот парадокс: могу собрать систему автоматического обзвона клиентов с клонированием голосов, а сам на созвоне звучу как иностранец с разговорником.

Решил наконец закрыть этот гештальт. Полез искать real‑time переводчик. Что‑то типа: я говорю по‑русски, собеседник слышит английский. И наоборот. В реальном времени, без пауз на 10 секунд.

И тут началось интересное.

Всем привет! Меня зовут Саша, я тимлид в DWH MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

Недавно ребята из Datalens проводили вебинар в честь выпуска Public API, в котором я принял участие. Эта статья — развернутая версия моего доклада об интеграции Datalens с OpenMetadata.

TLDR: https://semagram.io/

Всё началось с того, что меня сократили на работе, и я несколько месяцев подряд не мог найти новую работу. Так получилось, что крупнейший работодатель региона Amadeus (хотя я работал даже не там) - решил заморозить найм и тоже сократить добрую часть консультантов именно в тот момент, когда я отрицательно трудоустроился. В итоге на рынке высвободилась большая масса айти-специалистов, которую не могли трудоустроить другие компании (а кто-то из них, возможно, и сам напрягся “а? Amadeus сокращает найм и внедряет ИИ? На всякий случай тоже заморозим найм”). Я оказался в общей массе.

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

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

Привет, Хабр!

Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»

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

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

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

Сталкивались уже с EvaTeam (российский аналог Jira)? Чувствуете боль при работе с бизнес-процессами (workflow)? Думаю я могу вам немного помочь

Привет, Хабр!

Я техлид группы разработки шины обмена данных в компании «Передовые Платежные Решения». И помимо этого, неформальный лидер команды внутренних ИИ проектов. В статье хочу поделиться нашим опытом внедрения ИИ с нуля: как за 6 месяцев команда из 12 разработчиков (backend, без опыта с ML/ AI) создала и вывела в пилот голосового ИИ-ассистента.

Статья может быть полезна компаниям, которые с интересом смотрят на внедрение ИИ, и выбирают между «сделать самим» или «нанять/ привлечь экспертизу со стороны». Или хотят сделать похожий внутренний продукт.

Подавляющее большинство вредоносного ПО использует DNS-протокол для связи с командными серверами, эксфильтрации данных или перенаправления трафика. При этом почти 60% организаций не осуществляют мониторинг DNS-трафика на регулярной основе. Между тем защита DNS это довольно крупный продуктовый домен в сфере информационной безопасности. Мировой рынок DNS Security уже оценивается в $1,6–2,0 млрд и растёт на 10–14% ежегодно. Разбираемся, что стоит за этой технологией, кто её развивает за рубежом и в России, и чего от нее ждать в ближайшие годы.

40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.

Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.

Разберём механизм и приёмы, которые экономят время и код.

Если вы только начинаете работать с требованиями, эта статья для вас.

Бизнес говорит на языке стратегических направлений. «Комплексная трансформация», «синергетический эффект», «актуализация векторов развития» — эти формулировки звучат весомо, но за ними не всегда видна конкретная задача. Как из таких фраз сформулировать понятные требования для разработки? В статье разбираем 6 типичных ловушек и даём конкретные вопросы, которые помогут услышать реальную задачу.

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

Обычно документацию делают по одному из двух путей – либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий – ЕСПД и КСАС), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета.

Но как же её правильно сделать?

Мой ответ - начинать надо с синопсиса документов.

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

В этой статье вы узнаете:

• Математическую основу множественной линейной регрессии – от уравнения гиперплоскости до метода наименьших квадратов;
• Разбор полного кода на Python с использованием scikit-learn на реальном датасете Advertising (200 наблюдений);
• Как интерпретировать коэффициенты модели;
• Сравнение с простой линейной регрессией – насколько лучше работает множественная модель;
• Расширение до полиномиальной регрессии, когда линейности недостаточно.

Почему требований нет (и это нормально).

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

Требования очень редко полностью попадают под характеристики...

Мы часто думаем, что плохой интерфейс — это про кнопки, цвета или сетку. Но чаще он ломается не из-за пикселей. А из-за того, что дизайнер не учитывает, как на самом деле работает мозг.

Пользователь — не машина. Он устает. Спешит. Тревожится. Делает выводы на основе первых впечатлений.

И вот здесь включаются когнитивные искажения. Разберём 5 самых опасных для UX.

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

В этой статье – сразу два пути: от простой Excel-сезонки, которая неожиданно обыграла Prophet и классику на длинном горизонте, к ансамблю на базе TSMixer и от наивной веры в средний MAPE – к нормальной системе оценки качества с rolling backtest, bias, EOM и деградацией по горизонту.

Это не лонгрид про ML ради ML, а история о том, как сделать прогноз рабочим инструментом бизнеса.

Привет, Хабр!

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

Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.

В начале пути всё это выглядело довольно прямолинейно. LLM же обучены на массе источников в интернете, умеют читать код, у нас есть фреймворки для аудита. Казалось, напишем крутой промпт, загрузим его в модель и будем пожинать плоды.

Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.

Ошибка 1: Один запрос обо всём

Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее. 

Привет, Хабр!

Последние месяцы я строил систему, которую внутри называю «аниме-заводом»: на вход она получает исходный эпизод, а на выходе собирает готовый YouTube Shorts с динамическим кадрированием, субтитрами, постобработкой и метаданными для публикации.

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

В статье я покажу, как устроен этот пайплайн, почему я пошел в модульную архитектуру вместо end-to-end black box, где система ломалась и какие решения в итоге сделали ее реально рабочей.

Выкатили mcp llm ассистента во fusion360. Я сразу попробовал сделать то, что проектировал уже 60 раз и пытался автоматизировать сам - лестницу(деревянную).
Смотрим какой Vibe-design в 2026

Всем привет! Это команда Яндекс Практикума. Недавно мы провели исследование рынка, чтобы узнать актуальные требования к джуниор СА. Для этого мы поговорили с нанимающими тимлидами и синьорами из крупных и средних компаний, проанализировали вакансии и опросили выпускников курса «Системный аналитик» — джунов, которые недавно проходили процесс найма.

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

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

Солнечные панели до сих пор вызывают скептицизм, и во многом этот скептицизм оправдан: КПД современных фотоэлектрических модулей редко превышает 17–25 %, а это означает, что большая часть солнечного излучения, падающего на поверхность панели, просто рассеивается в виде тепла, не превращаясь в электроэнергию. Если добавить к этому потери в инверторе, соединительных кабелях и аккумуляторах, реальная эффективность всей системы оказывается ещё скромнее – и скептики получают очередной повод для сомнений.

Одним из наиболее распространённых инструментов борьбы с этими потерями стали MPPT-контроллеры, которые в реальном времени отслеживают точку максимальной мощности на вольт-амперной характеристике панели и удерживают режим работы вблизи неё вне зависимости от температуры, облачности и уровня освещённости. Это действительно работает – но лишь до тех пор, пока панель хоть как-то освещена, потому что никакой алгоритм не способен извлечь энергию из излучения, которое на панель просто не попадает. Если в девять утра панель жёстко закреплена под углом на юг, а Солнце ещё висит низко на востоке, MPPT-контроллер честно выжмет максимум из скудного косого света – но этот максимум будет несопоставимо меньше того, что могла бы дать панель, повёрнутая прямо на Солнце.

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