Анализируй и проектируй
Внешний сервис может вернуть 500 вместо ожидаемого 400, принять запрос с ошибкой или ответить успешным статусом, но потерять часть данных внутри ответа.
Разберём, какие негативные сценарии стоит проверять заранее, как проектировать слой защиты между системами и почему надежная интеграция начинается с анализа того, как она может сломаться.
Что бы мы ни делали, в результате генерируются данные. А когда ничего не делаем, тоже генерируются – только другие. Все, что сгенерировали, потом анализируют, проверяют, изменяют, продают и используют для генерации новых данных. В 2026 году глобальный объем данных достиг 200 зеттабайт, около половины из них сгенерировал частный сектор.
При этом данные становятся разнообразнее и сложнее. Двадцать лет назад пользовательский клик фиксировался тремя полями: идентификатором пользователя, временем и самой операцией. Сегодня за тем же действием могут стоять запрос к нескольким сервисам, bounce rate, информация об авторизации, реакция на рекламу, пользовательские сценарии и куча чего еще. И чем больше появляется сценариев, тем больше данных нужно собирать и обрабатывать.
Привет, меня зовут Дмитрий Кузняков, я отвечаю за развитие платформы данных для BI-аналитики в Goodt (ИТ-холдинг LANSOFT), и в этой статье я расскажу, почему мы выбрали подход федерации данных для своего продукта Insight.
Для описания архитектуры важно выбрать подход, который будет понятен всей команде. Одним из них является нотация C4, разработанная Саймоном Брауном.
Данная статья — это продолжение и значительное дополнение моей предыдущей статьи по C4, опубликованной в 2023 году. Здесь я детально разобрала для вас каждый уровень и элемент нотации, распространённые ошибки и спорные вопросы, а также инструменты для создания диаграмм, в частности графический редактор Draw.io и Structurizr для создания C4 через код.
Внутри — много схем, картинок и практических примеров для монолитной и микросервисной архитектуры, готовый код Structurizr и промпт для ИИ. Статья организована таким образом, чтобы вы могли открыть её, последовательно пройти все разделы и самостоятельно разобраться с C4.
Статья будет полезна системным и бизнес-аналитикам, архитекторам, разработчикам, менеджерам проектов и всем, кто участвует в проектировании архитектуры систем.
За годы работы с MES-проектами не раз наблюдал одну и ту же сцену: разработчик показывает отчёты, дашборды, тренды и прослеживаемость. Заказчик — технолог или начальник производства — кивает, видит на экране полезный функционал, но не воспринимает это как отдельную единицу проекта, которая оценивается и закладывается в бюджет.
Разница в понимании базовых слов — «отчёт», «мнемосхема» — не пустяк. От неё напрямую зависит оценка трудоёмкости: сколько процессов и интеграций описывать, сколько экранов и ролей закладывать в смету. Пока стороны по-разному понимают эти термины, границы системы и техническое задание согласовать не получится. А это влечет за собой риски срыва проекта при его старте.
Практический разбор архитектуры AI‑ассистента, который постепенно вырос в production‑систему: управление состоянием диалогов, разделение каналов и бизнес‑логики, оркестрация NLU, LLM и ручной поддержки, а также Inbox/Outbox для надёжной обработки сообщений.
Статья показывает, как эти компоненты связались в единый lifecycle пользовательского сообщения и почему архитектура в итоге стала важнее самой AI‑части.
Всем привет! Я Дмитрий Пономарев, разработчик ESB ИТ-интегратора «Белый код»! Сначала всё выглядело довольно просто: забираем данные по REST API, обрабатываем и сохраняем в PostgreSQL. Проблемы начались, когда объём таблицы вырос до десятков миллионов строк, а несколько миллионов записей пришлось регулярно проверять заново.
В одном из проектов мы столкнулись именно с такой задачей. DATAREON Platform должен был получать данные через REST API, сохранять их в PostgreSQL, хранить историю состояний и каждый день повторно проверять актуальные записи. На небольших объёмах схема работала нормально, но после роста данных стало ясно: последовательная обработка и вычисление актуальной версии записи «на лету» больше не укладываются в рабочее окно.
В этой статье разберём, как мы перестроили интеграцию: вынесли актуальность записи в отдельный признак, добавили специализированные индексы PostgreSQL, распараллелили обработку через воркеры DATAREON и предусмотрели безопасное восстановление после сбоев. В итоге производительность промышленной актуализации удалось довести примерно до 1,1–1,2 млн объектов в час.
В одном из проектов я с нуля собирал BI-аналитику платных медицинских услуг. В отчёте нужно было показывать динамику доходов и помогать находить расхождения в данных. Когда первые страницы были готовы, визуально всё выглядело вполне убедительно: показатели считались, графики строились, фильтры переключались, явных ошибок на экране не было.
На этом месте очень хочется считать основную работу законченной. Отчёт открывается, ничего не падает, цифры похожи на правду. Можно показывать пользователям.
Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.
Во время проверки я выявил существенные расхождения. Точную сумму, внутреннее устройство систем и причины отдельных несоответствий я здесь не раскрываю. Важно другое: на самом графике не было никакого признака, что с данными что-то не так. Линия динамики оставалась аккуратной, карточки выглядели нормально, а ошибка проявлялась только при сверке результата с исходными данными и логикой процесса.
После этого я перестал воспринимать проверку BI-отчёта как обычный просмотр готового интерфейса. Проверять нужно не картинку, а весь путь цифры: от записи в источнике до значения, которое увидел пользователь.
На последней фразе заказчик улыбнулся. Автоматика системы «Умный Дом» в доме ему была нужна, но облака, голосовые помощники и удалённое управление доверия не вызывали. От нас он хотел понять, есть ли у домашнего оборудования путь к его личным устройствам.
В проекте были проводная шина, IP-шлюз и локальный сервер визуализации. Управление с личного телефона обсуждалось, но заказчик согласился на отдельный планшет. Для автоматики мы предусмотрели локальную работу без постоянного выхода в интернет и соединений с личной сетью.
Привет, Хабр! Меня зовут Саша, я пишу курс «Аудиоанализ, распознавание и генерация речи» в Яндекс Практикуме, работаю ML-инженером в аудиодомене и вообще послеживаю за индустрией.
Пару месяцев назад вышла статья по генерации речи от Alibaba — Qwen-Audio-3.0-TTS. И вот что примечательно: в таблице результатов на SEED-TTS-Eval есть строка Human, и это не какая-то модель-гуманоид, а настоящая живая человеческая речь, прогнанная через тот же бенчмарк, что и все системы в сравнении. Так сказать, контрольная точка отсчёта.
Так вот, у человека там ошибка 1,26, а у модели, про которую эта статья, — 0,84. На этой строчке я застрял и сел делать разбор, потому что за ней, возможно, стоит проблема поинтереснее самой модели. Вечная проблема метрик.
Под катом попробуем разобраться, что у них там происходит.
В предыдущей статье мы разобрали пятое базовое понятие BABOK — Контекст (Context). Мы выяснили, что контекст — это не фоновое знание, а структурированный анализ среды, который определяет границы возможного решения.
Теперь цепочка почти замкнута: мы нашли нужных людей (Stakeholders), поняли что им нужно (Needs), спроектировали переход (Change), выбрали решение (Solution) и убедились, что оно жизнеспособно в данной среде (Context). Остаётся один — финальный и, пожалуй, самый честный — вопрос:
А зачем всё это было нужно? И как мы поймём, что оно сработало?
Именно на него отвечает шестое и последнее базовое понятие BABOK — Ценность (Value). Оно завершает цепочку. Разберём, что такое ценность в понимании BABOK и почему без её измерения работа аналитика технически никогда не завершена.
Как человек, что все еще верит в возможности FIRE на рынке РФ, я задался вопросом: что будет с вашим рентным портфелем, если наступит затяжной рыночный кризис, а вы продолжите ежемесячно изымать деньги на жизнь? Исследование показало, что стандартные способы инвестиций имеют склонность к обнулению капитала со временем (иногда лишь ускоряя это обнуление). А значит, было бы неплохо придумать модель долгосрочного инвестирования, что и рассматривается в статье. Будет интересно, если: хотите увидеть, как математика побеждает рыночный хаос (обывателям); забрать готовые модули бэктестера к себе в продакшен (новичкам, как я); имеете собственное видение по теме/любителям подсказать словом (созидателям и/или действующим квантам).
Мы много писали о роли ИИ в аналитике и разработке ПО. Теперь решили выпустить несколько материалов о том, как ИИ меняет кибербезопасность — вместе с нашей Red Team / pentest‑командой. Начинаем с перевода The Cybersecurity Industry Is Entering Its Third Era. При этом руководитель нашей Red Team на вопрос о главном изменении последних лет отвечает ещё короче: скорость.
Ранее в «Базовые модели надежности отказоустойчивого кластера» [2] были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous‑Time Markov Chain) отказоустойчивого кластера (fault‑tolerant cluster).
Предлагаемый ниже практикум «Промпт‑инжиниринг для моделей надежности отказоустойчивого кластера» имеет цель популяризации практических расчетов надежности «подручными средствами» — через ИИ/AI (искусственный интеллект через AI‑чат, например, ChatGPT). Задача — формализовать промпты для формирования модели надежности и проведения по ней расчета стационарного коэффициента готовности, Кг.
Промпт (prompt) — запрос, текстовая инструкция, которую пользователь даёт нейросети.
Промпт‑инжиниринг — практика проектирования, итерации и верификации текстовых инструкций (промптов) для получения предсказуемых, точных и воспроизводимых результатов от больших языковых моделей (LLM).
Коэффициента готовности, напомним [1], что Кг — численно равен вероятности застать систему (в данном случае кластер) в одном из ее работоспособных состояний (сложение вероятностей каждого такого состояния). Предлагаемые подходы могут быть применены и для других сложных резервируемых структур с учетом ограничений СТМС: случайный процесс «без памяти» с дискретными состояниями и непрерывным временем, а также экспоненциальное распределение времён до отказа/восстановления, независимость отказов компонентов, см. [6], [7].
Специализированные для расчетов надёжности пакеты RAS (Reliability, Availability, and Serviceability) типа SHARPE, MEADEP, RAScad, CARMS, RAPTOR и тому подобное позволяют строить и рассчитывать сложные модели. Есть более простые системы (и бесплатные), которые можно использовать для рассмотренных ранее моделей надежности отказоустойчивого кластера, например, relind.ru. Можно использовать универсальные средства (не специализированные под расчет надёжности), например, для расчета марковских цепей, или расчеты делать непосредственно в Matlab и Mathcad и подобных. Однако все это требует достаточно высокий «порог входа» и имеет встроенные в конкретный soft‑продукт ограничения, как, по существу, так и по визуализации.
Аналитика сейчас изменяется, если раньше чтобы понять в каких регионах сильнее всего снизились те же продажи, либо выросла текучесть нужно было неплохо так шарить за сбор данных, их обработку и статистику, то сейчас всё намного проще.
Мало того, что ИИ позволяет обрабатывать и разбирать данные намного быстрее, чем это делалось вручную, так еще и современные BI системы уже позволяют внутри себя задавать вопросы к данным. Это я узнал не так давно, так как сам с этим не сталкивался еще, но это натолкнуло меня на размышления аналитического бытия.
Долго выбирал что взять в первый практический разбор/демонстрацию возможностей своего инструмента. Решил остановиться на разборе изменений Правил продажи.
С 1 сентября действуют новые Правила продажи товаров - ПП № 657. Прежние, ПП № 2463, утратили силу. Это не поправки, а новый документ: в начало добавили три пункта, и дальше вся нумерация сдвинулась на три.
Наверняка его уже всесторонне разобрали, но я решил показать возможный новый способ.
Фича популярна у самых ценных клиентов и связана с высоким удержанием — но достаточно ли этого, чтобы сделать её основой продукта? Разбираем, почему корреляция в метриках может вводить в заблуждение, какие данные нужны для проверки гипотезы и как принимать продуктовые решения на основе экспериментов.
Как выбрать лучшее средство для разработки приложений? Такой вопрос может возникнуть не только в IT компании, но и в учебном заведении. Автор попытался критически взглянуть на пройденный им путь по выбору low-code платформы для учебного процесса МЭИ.
Мы собирались начать автоматизацию закупок с одного завода: провести пилот, отладить решение и потом тиражировать его на остальные предприятия. План выглядел профессионально и безопасно – пока директор по закупкам не оценил пересечение процессов четырёх заводов в диапазоне 40–60% в зависимости от площадки и участка процесса. Это был не формальный расчёт, а суждение человека, который видел закупочную работу всех предприятий. Его хватило, чтобы увидеть риск: один завод не был уменьшенной копией остальных. Выбрав его пилотом, мы могли сначала автоматизировать значительную часть локальной специфики, а затем переделывать решение при каждом тиражировании.
Продолжение разбора 24 миллионов оценок из Rate Me: как средняя оценка зависит от возраста оцениваемого, почему мужчины и женщины по-разному реагируют на разницу в возрасте, и проверка мифа о взаимности - щедрых оценщиков не оценивают щедрее. Три графика, полный массив, без сэмплирования.
Lenovo Tab M11 на моём столе загружается с внутренней памяти в Kubuntu.
KWin работает через DRM/KMS, Mesa рисует через Panfrost, звук идёт через PipeWire, сетью занимается NetworkManager. Bluetooth виден как обычный hci0, сенсоры — как IIO, камеры — как V4L2. Стилус работает с давлением и наклоном.
Камеры тоже завезли: задняя умеет полноценно фотографировать не только в jpg, но и в RAW, и писать видео 1080p/30fps, а еще обе камеры при этом доступны обычным Linux‑приложениям как /dev/video-rear и /dev/video-front.
Android? Отправлен за 101-й километр.
Такого плана в начале у меня не было.