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

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

Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.

Почему технический прогресс превращается в системный коллапс?
Всё дело в парадоксе Джевонса — эффекте, при котором повышение эффективности не ведёт к экономии, а запускает цепную реакцию роста.
И в эффекте Черномырдина — когда «лучше» на бумаге становится «как всегда» в реальности. Это не философия. Это — диагноз.

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

Чек-лист для аудита проекта внутри.

Практическое руководство по работе со сложными клиентами — с примерами из нефтегаза, госсектора, бизнеса и стартапов.

Эта статья — концентрированный опыт нашей команды аналитиков из компании Rubius, накопленный за годы работы в заказной разработке. Здесь нет теории из учебников — только проверенные на практике методы общения с «Генералами», «Истериками», «Цезарями» и другими сложными типами заказчиков.

Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов

Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.

Потом пришёл сценарий: «Отменить заказ»

Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...

• Если доставка уже в пути - нужно создать возвратную накладную

• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы

• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже

• Если клиент повторил платёж - восстановить резерв и доставку

И я решил:

Самая сложная логика тут не в доменах, а между ними.

А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.

Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.

Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.

Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В этой статье я вы найдете экспертизу по A/B-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке статистических гипотез. А еще тут есть материалы, который мы даем на курсе экспериментов.

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

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

Когда мы проектируем ИИ-агентов, мы обычно начинаем с анализа пользовательского опыта: клики, воронки, метрики.
Но что, если сам этот опыт — не отправная точка, а результат?

Что если то, как человек взаимодействует с системой, уже определяется невидимыми структурами — теми, что работают до любого действия, до любого выбора?

Именно здесь на помощь приходит Иммануил Кант — не как философ в парике, а как первый системный архитектор опыта.

Он бы не стал спрашивать: «Каков опыт пользователя?»
Он спросил: «Что именно делает возможным опыт?»

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

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

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

Прошло целых два года, как команда NSR Specification твердо пообещала добиться автоматизации экспертизы цифровых информационных моделей (ЦИМ) за счет создания машинопонимаемых представлений требований стандартов проектирования. На тот момент мы очень хотели регулярно рассказывать о промежуточных результатах, но слишком увлеклись разработкой. Ежедневно возникали новые и новые проблемы, в муках рождались способы их решения, в спешке писались задачи на разработку, когда заканчивались слова мы рисовали картинки, потом, дрожащими руками тестировали новый функционал, с азартом отлавливали баги, умело замаскированные под фичи... Каждый раз нам казалось, что осталось только дождаться свежего релиза, и все, мы победили. Оглядываясь назад, мне все чаще кажется, что мы были немного сумасшедшими, раз взялись за эту задачу. Но это, наверное, к лучшему. Если бы тогда, в 2023 году мы знали обо всех сложностях, с которыми нам предстоит столкнуться, то сегодня не смогли бы похвастаться работающим решением. Теперь то уж точно нам есть о чем рассказать: решение работает и уже обкатано на нескольких пилотных проектах.

В этой статье я детально опишу свой опыт создания «большого» (по меркам приложений которые можно получить из ИИ) с помощью ИИ.

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

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

Иногда JSON выглядит рабочим, но под капотом он полон сюрпризов: лишние уровни вложенности, запутанные поля и непонятные даты. Разбираем пример и доводим структуру до ума.

Представьте, что у вас есть кнопка, которая запускает в работу не просто нейросеть, а целый аналитический отдел. Один AI-агент лезет в Google изучать тренды, второй — шпионить за конкурентами, третий — анализировать ваши внутренние данные, а четвертый, на основе всего этого, генерирует три готовые стратегии. Звучит как научная фантастика? А я расскажу, как собрал именно такую систему на принципах мультиагентных систем, с «боссом-оркестратором» и даже собственной базой знаний.

Погрузимся в мир, где AI — это не просто чат, а целая виртуальная команда.

Привет Хабр, меня зовут Алина, и я HR-lead компании SSP SOFT (мы занимаемся заказной разработкой). Написать пост про особенности найма сеньоров мне помог наш райтер Сергей, а на саму идею — сподвиг случайно встреченный на просторах интернета пресс-релиз из заглавной иллюстрации. Не буду останавливаться на названии этой компании, его легко загуглить по фразам из скрина. Важно другое — коллеги по отрасли написали про избыток сеньоров на рынке труда в 2Q/2025 г., что казалось немыслимым еще пару лет назад. А как принимают на работу сеньоров, если речь идет не о массовом наборе, а точечно, под конкретные проекты? Об этом я и хотела порассуждать в этом посте.

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

Теперь это значит только одно — оправданий больше нет. Отсидеться не получится. Не бойтесь, что ИИ убьет творчество. Бойтесь мира, в котором правила его использования и этику его применения напишут те, кто в творчестве ничего не понимает, пока вы стояли в стороне. Раньше можно было сказать “у меня нет возможности, чтобы воплотить идею”, теперь единственный честный ответ — “у меня нет идеи, достойной воплощения”.

Ко мне тут пришло одно уважаемое айтишное издание и попросило комментарий на тему технического долга. Как бы, сразу возникают два вопроса. Вопрос номер раз — им это зачем? И вопрос номер два — а я тут при чем? (есть люди, которые гораздо лучше в теме разбираются). Но как-то они сами не сказали. А я как-то не спросил…

Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.

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

Современные инструменты творят чудеса. AMASS за полчаса соберет карту субдоменов компании, Nuclei проверит тысячи уязвимостей по готовым шаблонам, а Metasploit поможет получить доступ к системе парой команд. Скорость впечатляет, но есть нюанс. Автоматизация отлично справляется с рутиной и шаблонными задачами, а вот креативное мышление пока остается прерогативой человека. Найти цепочку нестандартных действий, которая приводит к компрометации системы, или понять, что безобидная на вид уязвимость может обанкротить компанию — такое машинам не под силу.

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

Привет, Хабр! Меня зовут Артем Якимчук, я инженер-исследователь в Сколтехе и аспирант в области промышленной робототехники.

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

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

В этом материале по мотивам моего доклада для True Tech Day я расскажу, как язык встречается с моторикой и почему LLM становятся новым мозгом для роботов. Будет любопытно и, возможно, немного футуристично. Поехали!

Дисклеймер для тех, кто не смотрел «Друзей»

Моника Геллер — персонаж культового ситкома 90-х, безумно одержимая порядком. Её чек-листы для чек-листов, лейблы на лейблах и фетиш сортировки по цвету и размеру превратили её в мем про педантизм. Но именно Моника в сериале всегда вытаскивала друзей из провалов: когда нужно было за 3 часа организовать свадьбу, найти документы за 5 лет или просто понять, кто последний брал фондюшницу.

В реальной жизни мы живём не в квартире с purple дверью, но законы Моники работают лучше любого скрам-майнд-сета.