В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz.
Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.
Привет! Меня зовут Маша Иванова, я старший аналитик монетизации в Авито. В статье расскажу, как несовершенство процесса логирования приводит к ошибкам в данных, как это влияет на достоверность аналитики и что мы разработали, чтобы предотвратить такие проблемы. Материал будет интересен аналитикам, QA-инженерам и разработчикам.
Вам интересно, какую нагрузку способен выдержать n8n, прежде чем он поднимет белый флаг? Мы выжали из него все соки — и результаты впечатлили.
Когда вы работаете с критически важными бизнес-процессами, вам необходимо знать свои пределы. Поэтому мы недавно провели тестирование различных вариантов развертывания n8n — имитируя высокую нагрузку и максимально используя ресурсы, чтобы выяснить, какие конфигурации показывают наилучшие результаты.
Независимо от того, управляете ли вы небольшим проектом или инжинирингом в мультинациональной компании, стресс-тестирование значительно помогает предотвратить простои, узкие места и невыполнение обязательств. Это бенчмарк-исследование и видео наглядно покажут, на что способен n8n и где он начинает давать сбои!
Известно, что каждая компания проходит определенные этапы в своей деятельности с момента ее возникновения до момента ее ликвидации. И, конечно, каждый владелец не желает, чтобы детище его рук и приложенных усилий, зачастую очень больших, прекратило свое существование и старается отодвинуть этот момент как можно дальше (см. Рис. 1).
Игровой движок Quake невероятно сильно повлиял на технологию разработки игр. Он активно лицензировался, в том числе, для использования в таких топовых играх как «Half-Life», «Call of Duty» и «Star Wars: Jedi Knights». Вероятно, наиболее серьёзное влияние оказали те многочисленные разработчики, которые научились писать игры, занимаясь его моддингом, а затем принесли с собой его принципы в другие студии, обогатив ими развитие других движков.
Большая часть того, что уже написано о движке Quake — это информация с акцентом на технологию 3D-рендеринга или многопользовательские сетевые игры. Но почти без внимания остаётся инновационная система объектов — парадигма, с опорой на которую дизайнеры уровней создают динамические взаимодействия, не прибегая к написанию кода.
В этой статье будет сделан краткий обзор системы объектов, сложившейся в Quake, и рассказано, на основе каких принципов она была спроектирована. С моей точки зрения особенно интересно, насколько сильно эта философия схожа с принципами, заложенными в основу UNIX. Оба решения можно резюмировать как системы, в каждой из которых есть одна базовая субстанция (в UNIX это файл) и язык, на котором можно описывать сочетание простых поведений, комбинирующихся в эмерджентном порядке (оболочка).
Когда мы охватили пониманием основные слои архитектуры, возникает следующая дилемма, как связать все полученные артефакты в единое завершенное пространство замысла.
Нередко можно наблюдать ситуации, когда очень интересные и перспективные концепции гинут в болоте непонимания, только лишь из-за оторванности генератора идеи от общего уровня сознания профсообщества.
По всей вероятности, нужна какая-то подводка. А очень может быть, сначала надо открыть людям целый новый мир, и только потом, в его свете, доносить идею.
На практике использование разнородных артефактов разных уровней абстракции является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и так далее по цепочке до “железа”. В предыдущих разделах мы использовали:
Хабр, привет!
Сегодня я хочу поделиться с вами не просто еще одним кейсом или историей успеха. Это будет подробный, почти детективный разбор одной из самых принципиальных и поучительных историй в практике нашей компании INTEKEY. Речь пойдет о том, как слепая вера в «инновации» и массовый хайп чуть не привели нашего клиента к финансовому провалу в почти полмиллиарда рублей, и о том, как холодный, системный подход к логистическому проектированию, данные и трезвый расчет помогли принять единственно верное решение.
Это не теория и не маркетинговая сказка. Это реальный проект, с реальными цифрами, диалогами и сложными решениями. Меня зовут Владимир Финк, я генеральный директор компании INTEKEY, и эта история началась несколько лет назад, когда мы только выводили на рынок нашу WMS-систему. Мы тогда были молодыми и голодными, но уже тогда в нашем ДНК было заложено правило: сначала думаем, потом — делаем. И, как оказалось, это был наш главный козырь.
Привет! Меня зовут Гильметдинов Ильнур, ведущий эксперт Дирекции роботизации банка Уралсиб.
Сегодня хочу рассказать о вызове, с которым мы столкнулись в самом начале пути масштабирования RPA внутри банка: как научить коллег, не имеющих опыта в программировании, не просто пользоваться роботами — а создавать их самостоятельно?
Это звучит амбициозно — и даже немного наивно. Но именно с этого начался наш путь к созданию внутреннего курса по RPA на платформе PIX.
Рефакторинг исторического кода с переходом на сервисную архитектуру напоминает игру в дженгу — надо аккуратно перестроить существующий проект и не сломать его. Но если вы меняете архитектуру с учётом жёстких требований PCI DSS в финтех-проекте, то одновременно с игрой в дженгу вам нужно балансировать на шаре и решать сложные уравнения. В этом мы убедились на собственном опыте.
Меня зовут Анатолий Яшкир. Я руководитель разработки финтеха ВКонтакте. В этой статье расскажу о специфике финтеха и нашем кейсе рефакторинга исторического кода с переходом на сервисную архитектуру.
Всем привет, я ведущий разработчик в ИТ-команде «Северстали» Сидоров Артём. Сегодня хочу рассказать, как мы с командой реализовали систему контроля качества нашей частной сети LTE.
Сбор телеметрии нужен для отслеживания состояния сети, если качество сети проседает в какой-то области, то нужно провести работы по восстановлению работоспособности LTE. Также это понимание, какой версии прошивка, какая сим-карта стоит в модеме на текущий момент.
Всем привет! В первой части https://habr.com/ru/articles/958356/ мы познакомились с форматом XBRL-CSV2, который позволяет упаковать сложность XBRL-отчетности в простые и удобные для обработки CSV-таблицы. Мы обсудили, как данные и их метаописания (маппинг) преобразуются из XML-представления в реляционное.
Но сбор данных — это только половина дела. Вторая, не менее важная часть — это их проверка на целостность, непротиворечивость и соответствие бизнес-правилам. В классическом XBRL за это отвечает формульный слой (Formula Layer). Сегодня мы поговорим о том, как мы превратили эти формулы в исполняемые SQL-скрипты, создав так называемый «слой отделяемых формул».
С помощью ИИ вполне можно сгенерировать сайт‑визитку или игру в крестики‑нолики, составить план отпуска или сделать более сложные вещи. А как насчёт того, чтобы сгенерировать ПО для управления атомной станцией или самолётом? Или как насчёт планирования не отпуска, а проекта на сотни человеко‑лет? Это в принципе возможно и можно ли доверять результатам работы ИИ?
В статье сначала будет немного теоретических рассуждений на эту тему, идея банальная: сложные задачи нужно декомпозировать. Затем рассмотрим это на конкретном примере, разобьём разработку приложения для HR отдела на три шага: 1) описание процесса приёма сотрудников на работу, 2) описание модели состояний для кандидата при прохождении собеседований, 3) генерация кода.
В заключении опишем профит от моделирования, если вы используете ИИ. И профит от ИИ, если вы занимаетесь моделированием.
Привет! Меня зовут Женя Орлов, я руковожу NLP-разработкой в red_mad_robot. Мы экспериментируем с мультиагентными системами и изучаем, как LLM ведут себя в разных архитектурах. В процессе накопилось много наблюдений и рабочих инсайтов — хочу поделиться тем, что помогает нам при проектировании AI-агентов.
В последнее время внимание инженеров и исследователей привлекают агентные архитектуры — системы, где LLM координирует работу внутренних инструментов и других моделей. Разберём два основных подхода к построению агентных систем.
В статье Архитектура высоконагруженной платформы Magnit F&R было рассказано о ключевых архитектурных принципах и решениях.
Сегодня хочу поделиться практическим опытом: как в Magnit Tech изменилась концепция Data Lakehouse, где она блестяще сработала — и где подвела.
Я, Алексей Соболеков, лид архитектуры F&R.
И это история о том, как красивая теория сталкивается с физикой доступа к данным.
В каждой компании независимо от ее размера и вида деятельности проводятся совещания. Многие сотрудники, да и руководители разных уровней считают, что совещания отнимают много времени и зачастую зримого результата от них не наблюдается. Тем не менее они регулярно проводятся. Проведение совещания — это прихоть руководителя компании или что‑то другое, что необходимо для деятельности компании?
Прежде всего давайте посмотрим, для чего и с какой целью проводятся совещания. Это же не просто прихоть руководителя любого уровня, который хочет показать свою значимость перед подчиненными?
Необходимо отметить, что вопрос работы руководителей, находящихся на разных уровнях управления, с точки зрения функционирования механизма управления практически нигде не изучается и не рассматривается по очевидной причине — отсутствие точного и ясного понимания, что такое процесс управления и как функционирует система управления. Существующие исследования, которые имеются и затрагивают этот аспект деятельности руководителей (процесс управления), с одной стороны, отрывочные и не системные, а с другой стороны не ясен вопрос, а что здесь изучать.
Обычно авторы рассматривают человеческие аспекты деятельности руководителей в компании и оценка общих результатов их работы на основе числовых показателей деятельности компании. Это тоже важно и нужно, но без ясного понимания, каким образом руководитель осуществляет свою функцию управления — целенаправленное воздействие на сотрудников, нельзя понять, насколько эффективно его управление, как он это реализует и как это может отразится на результатах деятельности компании.
Привет, Хабр! Меня зовут Николай Бушков, я работаю архитектором в команде Engineering Productivity R&D в Т-Банке (группа «Т-Технологии»). В начале лета я выступал на конференции MTS True Tech Day c докладом «Не эксперимент, а стратегия: путь к системному использованию AI в SDLC». А сейчас хочу поделиться текстовой версией описания сценариев использования искусственного интеллекта (ИИ) в программной инженерии, которые реализуются у нас в компании. Уверен, наш опыт будет полезен многим для генерации и фильтрации идей применения ИИ, а также сравнения их с положением дел в ваших рабочих процессах. В конце статьи кратко сформулирую наше видение дальнейшего развития и приглашу поучаствовать в исследовании ИИ в инженерной культуре России.
Вечные переделки и продукты, не решающие реальные проблемы? Возможно, вашей команде не хватает фазы Discovery.
Из этой статьи вы узнаете, как внедрить фреймворк, который делит работу на две четкие стадии: Исследование (Discovery) и Реализация (Delivery).
На практическом примере разберем:
- Как провести глубинное исследование проблемы до написания первой строчки кода.
- Что входит в процессы бизнес- и системного анализа на каждом этапе.
- Шаги внедрения фреймворка на вашем проекте.
Перестаньте тушить пожары и начните создавать востребованные продукты.
Business Process Model and Notation (BPMN) — это стандартизированное графическое представление, предназначенное для облегчения визуализации, понимания и взаимодействия сложных бизнес-процессов. Этот метод предоставляет целостную структуру, обеспечивающую единообразие описания между различными участниками, эффективно устраняя разрыв между технической и нетехнической аудиториями. BPMN использует набор стандартизированных символов, позволяющих компаниям системно описывать свои операционные потоки. Такая наглядность особенно важна в средах, где критичны оптимизация процессов и соблюдение регламентов, — она дает ясное представление о том, как действия, события и точки принятия решений взаимосвязаны внутри процесса.
С другой стороны, нестандартные инструменты автоматизации, такие как платформа n8n, предлагают иной подход к автоматизации рабочих процессов. В отличие от BPMN, который придерживается формальной нотации, n8n представляет собой low-code среду, ориентированную на гибкость и индивидуальную настройку. Подобные инструменты позволяют создавать сценарии автоматизации, соединяя различные приложения и сервисы без необходимости глубоких знаний в программировании. Такие среды особенно привлекательны для гибких рабочих процессов, где часто происходят итеративные изменения и требуется интеграция со множеством систем. Нестандартные инструменты нередко удовлетворяют уникальные бизнес-потребности, которые стандартизированные методологии, такие как BPMN, могут охватывать не полностью, предлагая тем самым альтернативное решение для оркестрации процессов.
У каждого, кто работает с высоконагруженными системами, своя коллекция боевых шрамов. Знаете эти истории про инциденты, когда всё идёт совсем не по плану? У меня тоже есть такая — очень показательная. Правильные инструменты, лучшие практики, опытная команда — и всё равно куча проблем. Это хороший повод рассказать, почему даже самых продвинутых инструментов может быть недостаточно, когда не видишь всей картины.
В этой статье я разберу различные проблемы, связанные с нагрузкой, и методы борьбы с ними, а потом покажу, как всё это рассыпалось при столкновении с реальностью.
Представьте, что вы покупаете мотоцикл. Чего вы от него ожидаете? Чтобы он мог разгоняться до 180км/час и при этом не разваливался? Чтобы к нему можно было прикрепить коляску? И не забудем про систему безопасности.
Эти требования не описывают основную функцию мотоцикла — перемещать человека из точки А в точку Б — но они важны для удовлетворения ваших потребностей, как водителя.
Точно так же, как у мотоциклов, да и любой другой техники, у программных продуктов есть свои нефункциональные требования. То есть атрибуты качества, которые будут удовлетворять потребности конечного пользователя.
В этой статье рассмотрим те нефункциональные требования, которые влияют на деньги и важны для бизнеса и менеджеров.
