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

ИИ: Гонки на лафетах

Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.

Это просто зарисовка не о разработке обертки, а о различных системах AI.

UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))

Прибыль Samsung от производства чипов на фоне спроса на ИИ выросла в 48 раз

Аналитики ожидают, что подразделение Samsung увеличит свою рекордную прибыль в течение следующих нескольких кварталов, поскольку контрактные цены продолжают стремительно расти на фоне ограниченного предложения. Они указывают на рост экспорта полупроводниковых приборов из Кореи в 2,8 раза за первые 20 дней апреля.

Полный текст новости по ссылке: https://www.kommersant.ru/doc/8633092

1. Просто значение немного удивило: 48. Даже немногим лучше чем ответ на все вопросы Вселенной!😁

2. Радует (лично меня, как желающего увеличить память своего ПК) новость от производителя оборудования для литографии. Количество литографического оборудования, заказанного для производства чипов памяти, за последний год превысило число заказов для производства CPU.

   2.1. Год назад литографы, в основном, заказывали для производства CPU.

   2.2. Ссылку на новость про литографическое оборудование сходу не нашёл. Но это было примерно месяц назад, тут же на Habr.

3. IMHO сугубо, много желающих включиться/вложиться в производство памяти. Через сколько времени пойдет производство памяти на максимум, вот тут предположения высказывать не возьмусь. Но желающих заработать на этом (и не только этом) "железе" много!

Любая система всегда существует в двух основных контекстах: пользовательском и админском. Есть еще контекст ошибки, но сейчас не про него.
Контекст – это не домен, наоборот это часть домена.

Речь не только про разработку и ИТ.  Канализация, кран, автомобиль, самокат, футбольный мячик - это применимо к любой системе физического мира.

Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.

Админский контекст имеет интерфейсы и контракты, которые недоступны в пользовательском контексте. Задача админского контекста обеспечить целостность, консистентность настроек системы для корректной и непротиворечивой работы в пользовательском контексте.

К чему эта мысль?

Если для вашей системы внутри одного домена/поддомена нужно 2 админских или пользовательских контекста, то скорее всего у вас проблемы в архитектуре системы. 2 варианта:

1. разделить домены, создав тем самым два слабосвязанных домена со своими контекстами. Это сделает домены проще, их легче поддерживать.

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

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

Не дублируйте контексты для домена, это плохо кончится.

Препарируем Lit и находим родовые травмы

Задействованы самые современные веб-стандарты, однако:

• Заявляется отсутствие VDOM, однако он есть, со всеми вытекающими.

• Любое исключение капитально ломает весь компонент.

• Неизбежные конфликты имён компонент всё ломают.

• Адовые тормоза и потребление памяти из-за привязки к DOM.

• Тонны бойлерплейта, если нужна кастомизация хотя бы стилей компонент.

Поблагодарить: https://boosty.to/hyoo
Обсудить: https://t.me/giper_dev

РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube.  Слайды.

Цели седьмого процесса по ГОСТ Р 56939—2024:

5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

22 преля состоялся TechCommPod Online Meetup, а сегодня уже можно посмотреть его в записи!

• АРИНА БАЛЕРИНА рассказала, кто такие техписатели. Как понять, что это ваше. Как стать одним из них.

• ЕКАТЕРИНА ПАВЛОВА провела мастер-класс по созданию сайта-визитки в Gramax.

• ДМИТРИЙ РАЗВОЗЖАЕВ показал свой зоопарк из AI-агентов.

• КОНСТАНТИН МАКУШЕВ порассуждал про паттерны и антипаттерны в документации.

В самом конце наши замечательные спикеры поделились откровенными историями самых эпичных ошибок в своей карьере.

Если пропустили эфир —  не страшно, мы все записали и уже залили на две площадки:

• Youtube: https://youtu.be/5wvMrNh07IY

• VK Видео: https://vkvideo.ru/video-237909665_456239018

Если вы были в эфире (или после просмотра записи) — пожалуйста, заполните анкету обратной связи. Это позволит подготовить для вас другие интересные и полезные мероприятия: https://forms.gle/juvvvxPQEoVMZuz37

РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения

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

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.

Цели шестого процесса по ГОСТ Р 56939—2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Из сильного специалиста — в руководителя: 11 открытых уроков про управление, архитектуру и карьерный рост

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

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

① Управление командой

➡ 22 апреля, 20:00 — «Делегирование без боли: как перестать быть „главным исполнителем“ и не скатиться в микроменеджмент»
_{Для тех, кто уже руководит или только переходит в управление и хочет перестроить свою роль без потери контроля.}

➡ 28 апреля, 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
_{Если хочется не просто ставить задачи, а реально влиять на вовлеченность и результат команды.}

➡ 30 апреля, 20:00 — «Как управлять тимлидами?»
_{Урок для тех, кто уже управляет не только исполнителями, но и руководителями внутри команды.}

② Карьерный рост в управление

➡ 29 апреля, 20:00 — «Разрешите себе карьеру технического директора»
_{Полезно тем, кто уже вырос из роли сильного технического специалиста и думает о следующем карьерном шаге.}

➡ 30 апреля, 19:00 — «МОК‑интервью на позицию Руководитель Проектов»
_{Практический формат для тех, кто готовится к переходу в управление проектами или хочет проверить себя на интервью.}

➡ 12 мая, 18:00 — «Какие метрики использует технический директор?»
_{Для тех, кто хочет понять, как на уровне CTO смотреть на эффективность команды, процессов и продукта.}

③ Продукт, проекты и аналитика

➡ 29 апреля, 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»
_{Хороший урок для тех, кто работает на стыке продукта, маркетинга и стратегии и хочет лучше понимать зоны ответственности.}

➡ 7 мая, 20:00 — «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
_{Полезно тем, кто хочет глубже разобраться, как аналитика влияет на устойчивость и качество продуктовой разработки.}

➡ 12 мая, 19:00 — «Управление ресурсами в условиях жестокого дефицита»
_{Актуально для тех, кто работает в условиях перегруженных команд, ограниченного бюджета и постоянных компромиссов.}

④ Архитектура и изменения

➡ 30 апреля, 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»
_{Для тех, кому важно понимать архитектуру не только как набор схем, а как инструмент управления изменениями.}

➡ 14 мая, 19:00 — «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров»
_{Для тех, кто хочет лучше понимать, как продвигать решения в сложной организационной среде, а не только проектировать их.}

﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋

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

☛ [Перейти к каталогу]

ИИ это – это все понимают по-разному

ИИ это – это все понимают по-разному в силу своей осведомлённости и понимания. Можно ли считать проявлением ИИ и называть умным устройством смартфон (умный телефон). Очевидно, что это средство автоматизации (упрощения и ускорения) каких-то житейских процессов. Конечно, удобно получать подсказки по ходу ввода текста или напоминания о днях рождения, но причём здесь ум.

Удобно ли получать рекомендации от браузера (типа зацелую до смерти), вопрос спорный. Идея это по большей части коммерческая, навязывающая услуги и мнения. Логичней умный интерфейс браузеров именовать хитрым.

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

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

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

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

P.S.

Сможет ли ИИ выжить без электричества? А ведь перспектива не такая уж и призрачная…

P.P.S.

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

Встраивание вычислений в PostgreSQL: PL*, extensions, а теперь и WASM

В рамках выступления на PG BootCamp Russia 2026 Дмитрий Дорофеев, главный конструктор Luxms, рассказал о том, как сегодня развивается встраивание вычислений в PostgreSQL: от классических процедурных языков (PL/pgSQL, PL/Python и других) до новых возможностей с использованием WebAssembly (WASM).

В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM. 

На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.

Посмотреть видео выступления можно на нашем сайте.

Вебинар «BI + ETL + КХД за 1,5 млн: как Modus закрывает весь стек корпоративной аналитики»

21 апреля в 12 по МСК приглашаем на вебинар, на котором эксперты ИТ-интегратора «Белый код» расскажут, как малому и среднему бизнесу внедрить BI-систему за 1,5 миллиона рублей.

Одна из задач, с которой к интегратору приходит малый и средний бизнес, — внедрение BI в рамках ограниченного бюджета. При этом есть жесткие требования, например, единая экосистема BI + ETL, без «зоопарка» инструментов, а также нативная работа с 1С как основным источником данных. 

На вебинаре специалисты поделятся практикой внедрения в сегменте МСБ, а также ответят на вопросы. 

Вы узнаете:

• Почему BI сам по себе не решает проблему разночтений в данных

• Какие организационные изменения нужны, чтобы аналитика начала работать

• Modus ETL: как устроена загрузка и обработка данных

• Modus BI: аналитический портал без лишней сложности

• Структура проекта за 1,5 млн рублей: стоимость лицензий, этапы проекта и результат

Спикеры вебинара

• Андрей Рыжик, product owner BI-направления компании «Белый код»

• Наталья Лобанова, коммерческий директор компании «Белый код»

📌Дата и время: 21 апреля 12:00 МСК (онлайн)

Участие бесплатное, требуется предварительная регистрация.

Принять участие

💥 Новое в Gramax💥

Gramax Enterprise Server:

• Новая кнопка входа в приложение. Кнопка входа теперь на главной странице в правом верхнем углу. 

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

• Новый вид настроек для проверок по стайлгайду. Теперь проверки вынесены в панель администрирования: Модули → Стайлгайд.

• Шаблоны для экспорта без ограничений. В настройках пространства убрали ограничение на количество шаблонов Word и PDF.   

Другие улучшения:

• Улучшения поиска. Добавили возможность поиска только по разделу и статье. Также теперь в поиске показывается контент из диаграмм и лучше учитывается структура таблиц.

• Неподдерживаемые форматы в предпросмотре. Раньше в окне предпросмотра можно было открывать только изображения и диаграммы. Теперь для остальных файлов появилась кнопка Открыть в поддерживаемом приложении — при ее нажатии файл откроется во внешнем приложении.

• Превью PPTX-файлов. В редакторе и на портале можно открыть презентации в режиме предпросмотра.

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

Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new

Бесплатные ресурсы по ключевым темам ML

Делимся подборками материалов для тех, кто только начинает свой путь в машинном обучении или готовится к техническому собеседованию. Линейные модели, NLP, ML в бизнесе и компьютерное зрение — каждая статья закрывает одну тему. 

Внутри вы найдёте полноценные курсы, которые знакомят с ML с нуля, а также видеолекции, иллюстрированные гайды и статьи от практикующих инженеров. Все материалы собирал старший датасаентист и наставник курса «Специалист по Data Science» Данила Ляпин.

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

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

Машинное обучение в бизнесе. Подборка посвящена A/B-тестированию, бутстрапу, кросс-валидации и ансамблевым методам — эти четыре темы образуют ядро практического Data Science. Здесь есть материалы и для специалистов с опытом, и для абсолютных новичков.

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

Если пока не актуально, сохраняйте в закладки — возможно, пригодится в будущем.

Зачем продукту исследования

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

Поговорили с Илоной, продуктовым дизайнером Project Ruler, о том, как команда использует исследования в работе и какие выводы из этого делает.

• конкурентный анализ

• глубинные интервью

• древовидное тестирование

• опросы

• юзабилити-тестирование

3️⃣ Как выглядел конкурентный анализ?

Мы использовали его как основу для гипотез. Смотрели не просто интерфейсы конкурентов, а конкретные сценарии: как пользователь выполняет задачу → куда идет → что видит.

Разложили все по критериям UX/UI, собрали в единую базу и выделили паттерны и антипаттерны. После этого уже было с чем идти к пользователям.

4️⃣ Какую пользу получили от глубинных интервью?

Мы пообщались примерно с 10 респондентами. Интервью помогли проверить гипотезы, понять реальные процессы пользователей и собрать неочевидную информацию.

Дополнительно прогоняли обезличенные данные через ChatGPT и находили то, что сами могли упустить.

5️⃣ Зачем понадобилось древовидное тестирование?

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

Мы смотрели, как пользователи проходят сценарии, где путаются и куда кликают по интуиции.

6️⃣ Что оказалось самым неожиданным?

Вот несколько ключевых мыслей:

• Уведомления раздражают — 8 из 10 пользователей их просто выключают и потом переживают, что что-то пропустили.

• Пользователям нужно меньше, чем кажется — основные сценарии: список или доска задач, карточка задачи и смена статуса.

• 8 из 10 пользователей не списывают трудозатраты — это стало поводом пересмотреть приоритеты и не перегружать продукт лишним функционалом.

• Даже простые действия неочевидны — например, многие не понимали, куда кликать, чтобы сменить пароль.

• Некоторые функции почти не используются — оказалось, что диаграмма Ганта большинству не нужна.

• Блок «Недавние» очень востребован — пользователи прямо просили его добавить.

7️⃣ Был момент, когда исследования помогли не продукту, а вашей команде?

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

8️⃣ Какой главный вывод из всего этого опыта?

Когда ты внутри продукта, очень легко влюбиться в свои идеи. Но исследования показывают, что это не всегда то, что нужно пользователю.

А еще исследования экономят ресурсы: лучше проверить гипотезу заранее, чем потом переделывать уже реализованный функционал.

Биомимикрия в дорожном строительстве.

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

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

Автоматизация облачных сценариев в эпоху искусственного интеллекта — одна из тем доклада на GoCloud 2026 ☁️

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

Также покажу, как одни и те же блоки выполняются в разных окружениях и как ИИ-ассистент ускоряет сборку полного цикла: от архитектуры и непрерывной интеграции до бизнес-логики приложений.

Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru

Трек: Приложения и разработка

📅 Когда: 9 апреля в 12:50–13:30 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Практическое применение eBPF: serverless-платформа с поддержкой TCP-приложений

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

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

→ Смотрите видео на любой удобной платформе: VK Видео, Rutube и YouTube.

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

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

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

TransRussia| SkladTech 2026: системный подход к автоматизации и роботизации. Итоги Выставки

Завершилась выставка TransRussia | SkladTech 2026 (17–19 марта, «Крокус Экспо»). Команда INTEKEY участвовала в деловой программе и общалась с заказчиками, интеграторами и поставщиками.

В этом году разговоры на площадке стали заметно более прикладными: меньше абстрактных тем вроде «цифровой трансформации» и больше конкретики — о сроках окупаемости, экономике проектов и управляемости решений.

Основные тренды, которые обсуждали эксперты и участники:

🔸 Роботизация как новая норма. Государство целенаправленно ускоряет автоматизацию складов через субсидии, льготы и возможные регуляторные требования. На рынке уже доступно более 30 типов складских роботов, 22 из которых — российского производства.

🔸 Экономика и скорость. Компании жёстко оценивают проекты: ожидаемый срок окупаемости — до 1 года, запуск базового функционала — за месяцы, а не годы. Вырос запрос на предсказуемость работы систем при росте нагрузки.

🔸 Сначала система, потом технологии. Чтобы избежать разрыва между внедрением и реальным эффектом, нужна другая последовательность: сначала цели и процессы, затем архитектура (WMS, интеграции, оборудование), и только потом — поэтапное внедрение.

🔸 Коллективное принятие решений. Выбор решений стал более системным: собственник оценивает экономику, IT — архитектуру, а логистика — применимость в операциях. Это снижает количество «теоретически правильных», но плохо работающих проектов.

В рамках сессии «Эволюция склада» Денис Сумелев (INTEKEY) и коллеги из Nikoliers, «Магнита» и КСЛ обсудили, как подготовиться к обязательной роботизации и выстроить процессы для быстрого получения экономического эффекта.
По итогам выставки INTEKEY вошла в топ-3 Product Award 2026 — премии, отражающей практический интерес рынка к представленным решениям.

💬 На что вы в первую очередь смотрите, оценивая проект автоматизации: на срок окупаемости или на функциональность?

Всем привет. Начал писать открытую книгу про архитектуру безопасных AI-агентов.

Делаю не обзор фреймворков и не коллекцию «магических демо», а практический инженерный reference: control plane, policy boundaries, tool gateway, memory, observability, evals, approval flows, governance и production-подход к агентным системам.

Уже выложил первые главы и каркас книги - https://agent-axiom.github.io/agent-arch

Репозиторий - https://github.com/agent-axiom/agent-arch

Буду очень рад критике по существу:

• где архитектура спорная,

• где не хватает важных разделов,

• где формулировки слишком сырые,

• что стоит добавить из практики эксплуатации и безопасности.

Если тема близка - вливайся: issues, comments, corrections, PRs, ссылки на сильные источники и контрпримеры из реальных production-систем.

Хочется сделать не просто набор заметок, а полезный community-driven reference для тех, кто строит надежных и безопасных AI-агентов.