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

Обсуждения неудачных примеров README-файлов и документации — одна из популярных тем на профильных площадках и форумах [вкупе с другими «вечнозелеными» спорами в ИТ]. Мы в Beeline Cloud решили посмотреть, что думают о проблеме плохой документации разработчики и ученые, может ли ИИ улучшить ситуацию, что такое «нейросетевой ридмитит» — и как можно «доработать напильником» сгенерированные инструкции.

Продолжение истории. Во второй части речь пойдет про поиск пути к своему симулятору: затронем мультиагентные системы "прошлого" (MAS), акторную модель (actor model), современную игровую архитектуру ECS и Data-Oriented Design. Что взлетело, что не взлетело, и почему гибридная архитектура показалась подходящей для трёхуровневой модели управления из первой части. Все это с историческими отсылками к Хьюитту, Армстронгу и Эктону.

TL;DR. Мы выкатили открытый бенчмарк MELT-1 — он меряет не сколько модель знает в идеальных условиях (MMLU & co), а сколько она проживёт под дрифтом распределения и сколько стоит держать её живой. Три оси: $/1M успешных решений, часы до деградации без ретрейна, p99-латентность сенсор→актуатор под 40 °C. 30 суток непрерывного инференса, 5 сидов, два температурных профиля, sensitivity-анализ. На closed-loop manipulation наш агент (Metabolic AI, non-transformer) против Llama-class 7B INT8 показал 9.4× по стоимости, 8.5× по выживанию под дрифтом, ~1600× композитно. Архитектура закрыта — патент на стадии экспертизы. Бенч открытый: харнесс, сцены, оракул, sensitivity-скрипты, опубликованный VAE-энкодер дрифта. Прогоните своих агентов и положите рядом. PDF с полной методологией и threats to validity — в конце статьи.

Миграции базы данных вроде бы есть, Liquibase подключен, changelog лежит в репозитории, CI зелёный, релизы проходят регулярно. Значит, процесс под контролем?

Не всегда…

Вчера автор побывал на прекрасной конференции Backend Talks 360 от компании Yandex и не в силах спокойно спать, не ответив конструктивной критикой на доклад Ильи Абрамова о работе Яндекс.Диска, автор принялся писать очередной "В интернете кто-то не прав". Что из этого вышло - добро пожаловать под кат.

Всем привет! Я Лена Кочнева, бизнес-аналитик в телеком-компании, выпускница курса по бизнес-анализу в Яндекс Практикуме, а в прошлом — актриса и преподавательница английского. В этой статье хочу рассказать, что меня сподвигло на перемены и как я на них решилась. Поделюсь, как выбирала новую специальность среди десятков вариантов, как училась и в итоге получила офер без коммерческого опыта.

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

Привет! Я - функциональный архитектор Enterprise-продуктов и ИТ-комплаенс лид. В моей практике — проектирование сквозных ИТ-ландшафтов, управление миллионными финансово-налоговыми рисками и регулярная защита долгосрочной ценности проектов перед C-level.

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

Кошелек Миллера в межкомандных переговорах: как перестать взрывать мозг оппонентам.

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

В психологии этот лимит называется «кошельком Миллера» (закон Джорджа Миллера, 7±2, а в современных реалиях клипового стресса — строго 3–4 единицы информации) .

Если вы вводите в первой главе книги 10 персонажей, ваш роман назовут суррогатом, потому что читатель запутается в именах. Но почему-то на кросс-функциональных встречах мы совершаем это сумасшествие регулярно: вываливаем на коллег 5 графиков, 8 юридических рисков и 12 пунктов дедлайнов за раз, а потом удивляемся, почему они «переобуваются» и включают защиту.

Сегодня мы в Beeline Cloud подготовили подборку примечательных опенсорсных решений, упрощающих управление «флотом» интеллектуальных помощников и ИИ агентов — все благодаря наглядным графическим интерфейсам. Инструменты в списке помогут выстроить пайплайн выполнения задач и распределять их между ИИ-агентами.

Когда Илон Маск говорит об опасности ИИ, он рисует картину восстания машин. Терминаторы. Скайнет. Красные глаза в темноте.

Это не страшно. Это глупо.

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

Как? Через экономику. Через работу. Через код.

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

Представьте, что эти девятьсот девяносто уволенных человек перестали покупать.

Привет, Хабр! Меня зовут Сергей Тимакин, сейчас учусь на первом курсе онлайн-магистратуры «Специалист по работе с данными и ИИ» НИЯУ МИФИ в партнёрстве с Яндекс Практикумом и параллельно работаю в Озоне аналитиком данных. В этой статье я расскажу, как я столкнулся с трудностями в понимании слоёв и моделей данных — и как разобраться в этой теме.

В последней части про модели конкурентности JVM языков мы сравним разные подходы друг с другом. И ответим на вопрос “А зачем теперь тред пулы, если есть столько модных концепций: корутины, файберы, виртуальные потоки ?”

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

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

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

А потом проходит несколько лет.

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

Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм.

И начинается археология.

Почему так происходит?

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

Рано или поздно сложную систему приходится объяснять человеку со стороны: новому разработчику, техлиду, архитектору или ревьюеру. И тут часто начинается боль: репозитории уже показали, основные сущности вроде бы объяснили, но всё ещё непонятно, как данные проходят через систему.

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

Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

Автор более 30 лет в ИТ. Начинал инженером-разработчиком в крупном банке, затем несколько лет в международном вендоре консультантом и функциональным архитектором внедрения известной ERP системы. Последние 25 лет в крупной российской компании выступаю в различных проектных ролях на проектах у заказчиков: архитектором, функциональным руководителем, системным аналитиком, руководителем проектов, директором проектов внедрения различных ERP.

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

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

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

Мое хобби – фундаментальная физика. Поразмышлять на тему фундаментального и монументального отлично получается по утрам в Измайловском парке во время прогулки с собачкой, либо по дороге на работу/с работы. В вагонах московского метро ничто не отвлекает от чтения текстов трудов Ньютона или Эйнштейна. 

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для IT-директоров и финансовых руководителей. Только «виноват» не конкретный человек, а не оптимально работающая инфраструктура, а ответ на вопрос «что делать?» — внедрять FinOps.

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

Привет! Я Иван Воробьев, системный аналитик Далее. Часто нам приходится работать со сложными системами не только с нуля, но и на саппорте. И для аналитика это кардинально разные контексты, риски и косты ошибок. 

На поддержке каждый error стоит сильно дороже, а допустить его в разы проще. В этой статье расскажу, что точно повредит ваш прод при доработках и как этого избежать. 

ИИ-тесты - это один из самых простых, эффективных и надёжных методов использования искусственного интеллекта в компаниях и организациях. В статье рассмотрим реальный кейс, и на примере простого промпта сгенерируем тесты для проверки знаний правил habr.

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

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

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

Предлагается критерий оценки AI-моделей на основе метрики самовосстановления системы из минимального информационного “семени”