Всем привет! Меня зовут Михаил Пашедко, я backend-разработчик в Авито в команде Автотека. В статье расскажу, как небольшой эксперимент на пару спринтов стал полноценным направлением разработки — и показал, как в зрелой компании можно запускать живые, «стартаперские» инициативы, не теряя при этом контроль над качеством.
Привет, Хабр! Я Михаил Викторов, старший инженер-программист в Контуре. В рамках одной из активностей в нашей компании возникла задача исследовать, как Low-code-платформы могут быть полезны сильным командам классических разработчиков. У меня на тот момент отношение к таким решениям было скорее скептическим, сформированным предыдущим карьерным опытом. Тем не менее, я с интересом взялся за эту тему — в частности, давно хотел посмотреть N8n вживую. В последние пару лет я регулярно сталкивался с упоминаниями этой платформы в разговорах и статьях, обычно в формате: «техническую часть стартапа можно не учитывать — за день соберём всё на N8n».
В этой статье я сознательно смотрю на Low-code с позиции code‑first разработчика – без попытки объявить визуальные платформы «злом» или «серебряной пулей». На примере двух платформ, N8n и Dify, я попробую разобраться, где Low-code действительно полезен профессиональной разработке в крупных компаниях, а где проходят границы его разумного применения.
Как перевести мышление человека в JSON, положить в нейросеть и перестать писать бессмысленные промпты.
В современном мире разработки информационных систем всё чаще требуется не только высокое качество, но и оперативность выполнения задач. Заказчики ждут результата не через год, а «вчера». Это диктует необходимость повышать производительность системных аналитиков на этапе разработки требований, не снижая качества создаваемых артефактов. Одним из ключевых инструментов ускорения процессов становится ИИ, выступающий не просто как помощник, а как когнитивный партнёр по мышлению.
В этой статье я постараюсь объяснить, что такое причинно-следственная связь, как она касается моей работы бизнес-консультанта и бизнес-аналитика, а также причем тут IDEF0 , BPMN и остальные инструменты.
В предыдущей статье я показал, как документ можно превратить в сеть смыслов и получить «живую» онтологию знаний. С помощью своего семантического ритуала я разбираю текст на термины и связи, и документ растворяется в графе, оставляя после себя осмысленную модель. Такой подход к знаниям убирает двусмысленность: ключевые понятия вынесены в онтологию, язык проекта становится частью архитектуры, и команда работает в едином контексте. В итоге сложные системы перестают зависеть от «шума» неверно понятых слов и начинают вести себя предсказуемо.
Теперь я иду дальше и развиваю концепцию живых онтологий – на этот раз применяя её к управлению процессами. Что, если моделировать процессы так же, как семантику текста? Могу ли я описать процесс как совокупность понятий, связей и состояний – и сделать так, чтобы эта модель реально исполнялась?
В этой статье я покажу, как я реализовал идею: описал процесс как онтологическую модель и подключил n8n как движок, который исполняет эту модель. Внутри: минимальная метамодель, разбор реального workflow и короткий эпизод “как выполнение одной задачи активирует следующий этап”
Как говорится, в споре рождается истина. И этот случай не стал исключением. Часто проектирую запросы, консультирую аналитиков, сама консультируюсь у разработчиков и заметила, что иногда мы по-разному понимаем некоторые аспекты REST. Когда я стала погружаться в тему, то материала набралось столько, что одной статьей не обойтись. Понимание мифов позволяет делать более осознанный выбор при проектировании.
С вами Дарья Борисова, системный аналитик из ПСБ, и я начинаю цикл статей «Мифы о REST».
Многие компании в процессе своего развития успешно осваивают начальные этапы TOGAF ADM: формируют видение, разрабатывают целевые модели, создают планы переходов. Но настоящая ценность архитектуры рождается не на слайдах, а в ежедневной работе ИТ-команд. Именно здесь возникает критический разрыв: хорошие архитектурные артефакты остаются невостребованными, потому что непонятно, как их применять в реальных процессах разработки, тестирования и эксплуатации. Стратегические архитектурные решения (принципы, стандарты, целевые состояния) формализованы, но не оказывают реального влияния на операционную деятельность команд. Причина — отсутствие четких механизмов внедрения этих решений в рабочие процессы.
Этот разрыв преодолевается там, где архитектурное мышление интегрируется с методологией управления ИТ-процессами. Агрегация компетенций корпоративного архитектора и ИТ-методолога превращает ADM из теоретического цикла в работающий механизм трансформации.
Современные распределённые системы часто сталкиваются с задачей управления большим количеством заданий - будь то обработка данных, интеграции или выполнение фоновых задач.
В этой статье рассмотрим архитектуру подсистемы управления заданиями, реализованную на принципах микросервисной архитектуры. Подсистема управляет заданиями на загрузку данных из внешних источников, то есть задачу интеграции с поставщиками данных.
В статье не будет технических деталей, будут даны только принципиально важные детали реализации и критически важные параметры.
Элементы уровня технологий (Technology Layer) описывает инфраструктурные сервисы, компоненты и физические ресурсы, необходимые для поддержки приложений и бизнес-процессов.
Этот уровень отвечает на вопрос: "На каком технологическом фундаменте всё работает?"
Знакома ли вам ситуация, когда команда неделями спорит о дизайне решения, собирает тонны данных, проводит бесконечные исследования, собирает бесчисленное количество встреч? Запуск постоянно откладывается. Вместо быстрых экспериментов - совещания и пересчеты. Продукт практически не развивается, инновации остаются на бумаге.
Это не просто "data-driven", а уже аналитический паралич - болезнь современных data-driven компаний, когда стремление к 100% уверенности парализует саму возможность принимать решения.
Парадокс в том, что паралич возникает именно в тех командах, которые хотят делать всё правильно. Они изучали про data-driven подход, внедрили аналитику, наняли высококомпетентных специалистов. И утонули в данных.
Давайте разбираться, почему это происходит и как вернуть команде способность двигаться вперед.
Каждый год объем корпоративных данных растет процентов на 30–40, а к 2028 году глобальная сфера данных, по прогнозам IDC, достигнет почти 400 зеттабайт. Проблема в том, что большинство этих данных нельзя просто выкинуть. Логи нужны для аудита, датасеты для переобучения моделей, архивы проектов для юридических требований. Хранить все это на горячих дисках в продакшене ну просто очень дорого. Держать в облаке, впрочем, тоже. Причем с каждым годом все дороже. И что же выбрать?
Давайте разберем, как выглядит работа с MCP, на реальном примере из опыта моего дата-консалтинга. В этой статье теории не будет, только практика, много скриншотов и пара лайфхаков.
Всем привет! Меня зовут Артемий, я работаю SRE-инженером в команде RTP (real time processing) Clickstream в Авито. Сегодня мы хотим поделиться нашей историей о том, как мы переехали в Kubernetes, развернув Apache Flink с помощью Flink k8s operator.
Всем привет, меня зовут Алекс Гусев. В этой публикации я продолжаю формализовать свой личный опыт взаимодействия с агентом OpenAI Codex при разработке программного обеспечения. Речь пойдёт о практическом использовании файлов AGENTS.md как инструмента организации контекста проекта в долгоживущих и структурно сложных системах.
Некоторое время назад я с позором провалил собеседование на системного архитектора в один банк. Интервьюер просто до глубины души был оскорблен мои низким техническим уровнем. Ему максимально не понравилась схема интеграции со СМЭВ, которую я пытался изобразить. В итоге я решил немного подтянуть теорию, почитать учебники, попроходить Mock‑собеседования... Да, ну, нет, всё это слишком сложно! Вместо этого я решил запилить инструмент моделирования, добавить в него Enterprise Integration Patterns и прикрутить ИИ, чтобы он сам рисовал все эти дурацкие модели.
Затем я давал Gemini 3 Pro тестовые задания на проектирование архитектуры. В процессе я возможно и сам немного подтянул свои знания. Результат вы можете увидеть в статье, возможно эти модели будут для вас полезны. Вручную я их практически не правил, только иногда задавал уточняющие вопросы. Со мной всё итак ясно, а как вы считаете прошла бы Gemini собеседование на архитектора? На сколько удачно она справилась с этими тестовыми заданиями? Возможно на ваших собеседованиях задачи были сложнее и интереснее?
Привет всем. Данная статья адресована начинающим свой путь в системном анализе и призвана помочь ответить максимально просто на один из самых частых вопросов системному аналитику на собеседовании. Мне данный вопрос задали на 3х из 5ти технических интервью, а это значит, что в теме надо разобраться. Поехали!
Вопрос: на сайте есть форма с полем поиска чего-либо по названию и кнопка, при нажатии на которую должен быть выведен результат поиска. Проблема в том, что пользователь не помнит название. Как реализовать поиск?
Тема управления в организации достаточна многогранна и касается различных сторон деятельности сотрудников и организации их работы. В настоящей статье рассмотрим, какие возможности появляются в компании для повышения эффективности ее деятельности при совершенствовании механизма управления с применением информационных технологий.
В каждой компании складывается такая система управления, которая должна обеспечить ее деятельность наилучшим, т.е. наиболее эффективным способом, позволяющим успешно реализовать намеченную цель и выполнять возникающие при этом задачи. А всегда ли так получается? К сожалению, не всегда имеющаяся в компании система управления является наиболее оптимальной для выполнения стоящих перед руководством задач. Причиной этого является отсутствие ясного понимания о том, что входит в систему управления, какое предназначение у элементов системы управления, как они формируются, как они воздействуют на сотрудников и между собой.
Механизм управления позволяет реализовать заложенный в элементах управления потенциал путем формирования и направления информационных потоков, на основании которых руководителями принимаются решения и которые, будучи доведены до сотрудников, воздействуют на них. Для точного понимания определим, что такое управление (процесс управления) в организации.
Процесс управления – это целенаправленное воздействие субъекта управления на объект управления при помощи специальных инструментов и ресурсов управления, необходимое для достижения определенной цели путем решения ими поставленной задачи (определение автора). При этом субъектом и объектом управления в организации являются сотрудники.
Рынок рекрутинга и поиска работы в России столкнулся с беспрецедентным изменением правил. В начале недели hh.ru, монополист на рынке онлайн-трудоустройства, начал рассылать сообщение о блокировке доступа к своему публичному API для сторонних сервисов. Это решение, по сути, перекрывает кислород десяткам компаний, которые годами строили бизнес на автоматизации.
Что стоит за этим шагом и как выживут игроки в новой реальности - вопрос, который сейчас волнует всю индустрию и пользователей самих продуктов.
Сегодня хочу разобраться в ситуации и посмотреть, как компании будут выходить из этого положения. Надеюсь, получится интересно.
Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.
Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».
