Блог Владимира Ловцова

Кооператив vs найм: справедливая альтернатива, а не революция

Fri, 20 Mar 2026 00:00:00 GMT

Два стула

В ноябре 2025-го я сидел на двух стульях буквально. Днём — погружён в enterprise-контекст: бюджеты, FTE, roadmap на три квартала. Вечером — звонок с будущими участниками Артели, где мы проектировали модель распределения прибыли. Два мира, две системы стимулов, и я посередине.

Всплыла тема распределения результата: команда, которая построила realtime-платформу, генерирующую ощутимую долю прибыли направления, получит по итогам года бонус — достойный по корпоративным меркам, но занимающий лишь малую долю созданной ценности. Корпоративная логика здесь понятна: проект закладывает риски, окупает инфраструктуру, тянет неокупаемые направления — мультипликаторы есть и они честные. Но при серьёзном мультипликационном эффекте нельзя упускать другой факт: команды могут получать больше, чем сейчас в среднем по рынку — и мировая практика это подтверждает. Опционы, profit-sharing, бонусы привязанные к прибыли компании без жёсткого потолка — компании по всему миру идут на это именно потому, что удерживают тех, кто создаёт наибольшую ценность. Справедливо? По корпоративным меркам — более чем. По меркам созданной ценности — разрыв заметен.

Вечером на звонке один из участников Артели сказал фразу, которая всё расставила по местам: «Зарплата — оплата риска. Доля — оплата ценности». Корпорация платит тебе за то, что ты согласился на стабильность. Но если ты готов взять на себя часть риска — почему не получить часть upside?

Что не так с наймом (без эмоций)

Проблема не в злых начальниках. Проблема в структуре стимулов.

Инженер строит decision engine, который обрабатывает транзакции в реальном времени. Бизнес-ценность этой системы измеряется серьёзными суммами ежемесячно. Вознаграждение инженера — фиксированный оклад. Корпорация берёт на себя риск: инвестиции, инфраструктура, клиентская база. За это забирает upside. Наёмный сотрудник получает стабильность в обмен на отказ от доли в результате. Это не несправедливость — это структура. Но стоит спросить себя: устраивает ли тебя такой обмен?

Второе: отсутствие голоса. Ты можешь быть лучшим техлидом в компании. Но если новый директор решит «оптимизировать» — твоё мнение не учтут. Не потому что не уважают. Потому что структура так устроена. Решения принимают менеджеры, а у инженера нет системного механизма влияния — только личные отношения и политическое чутьё.

Третье: стабильность — это вероятность. Массовые увольнения последних лет показали: «стабильная работа» — это статистика, которая работает в твою пользу, пока работает. Смена стратегии, новый CEO, «оптимизация штата» — и статистика меняется. А ты это не контролируешь.

Кооператив: механика без лозунгов

Кооператив — организация, где работники являются совладельцами. Не формально, как в программах опционов, а по-настоящему: голосуют, видят финансы, распределяют прибыль. Кооперативная модель существует более ста лет — Mondragon в Испании с 65 000+ работниками-совладельцами, ESOP-компании в США, IT-кооперативы вроде Igalia в Испании. Это не утопия — это проверенная временем альтернатива.

Принцип	Что это значит
Совладение	Каждый участник владеет долей в результатах. Не опцион с cliff 4 года, а реальная доля
Прозрачность	Все финансы открыты. Каждый знает, сколько заработал кооператив
Демократия	Ключевые решения — голосованием. Один участник — один голос
Распределение по вкладу	Вознаграждение привязано к вкладу, не к должности
Взаимная ответственность	Нет «я просто работаю здесь»

Честное сравнение

Критерий	Корпоративный найм	Кооператив
Доход	Фиксированный, предсказуемый	Переменный, привязан к результату
Upside	Минимальный (бонусы, редко опционы)	Прямая доля в прибыли
Стабильность	Высокая (пока рынок хороший)	Средняя (зависит от команды)
Принятие решений	Top-down	Демократическое
Карьерный рост	Вертикальный (менеджмент)	Горизонтальный (экспертиза + вклад)
Бюрократия	Высокая	Низкая-средняя
Вход	Простой (устроился)	Сложнее (совпадение ценностей)
Выход	Простой (уволился)	Регулируемый (выкуп доли)
Масштабирование	Отработано	Сложнее, требует культуры

Ни одна модель не выигрывает по всем критериям. Кооператив — не «лучше». Он про другой набор компромиссов.

Digital Artel: что я строю и зачем

Я не ухожу из корпоративного мира. Работа в банковском проекте даёт опыт управления сложными системами и большими командами, который невозможно получить иначе. Но параллельно я строю IT-кооператив, потому что вижу: в IT эта модель может работать особенно хорошо.

Почему IT: низкие капитальные затраты (ноутбук и интернет), измеримый вклад (код, дизайн, аналитика — всё можно оценить), удалённая работа без привязки к офису, высокая маржинальность интеллектуального труда.

Первый год Артели — это выстраивание процессов. Как распределять прибыль? Мы попробовали три модели, прежде чем нашли рабочую.

Первая — поровну. Заработали — разделили на всех одинаково. Красиво, по-коммунистически, и абсолютно нежизнеспособно. Через два месяца стало ясно: один человек тащит проект на себе, другой подключается по вечерам на пару часов, а получают одинаково. Первый начинает тихо закипать. Второй искренне считает, что всё честно — ведь он же тоже участвует.

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

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

Как принимать решения? Голосование по каждому вопросу убивает скорость. Мы это проверили на себе: однажды потратили два часа, голосуя за выбор таск-трекера. Два часа жизни, которые никто не вернёт. Пришли к делегированию операционки рабочим группам, голосование только по стратегии. Как оценивать вклад? Это самый сложный вопрос, и мы до сих пор его настраиваем.

Были моменты, когда я думал: к чёрту, проще работать в классической модели. Когда двое участников не могли договориться о приоритетах, и вместо решения руководителя — бесконечная дискуссия. Когда переменный доход в плохой месяц вызвал стресс у человека с ипотекой. Когда кандидат, идеальный по навыкам, не прошёл по ценностям — и ты понимаешь, что потерял полезного специалиста ради культуры, которая пока существует в зачаточном виде.

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

Минусы (без розовых очков)

Демократия медленнее автократии. Это факт. Когда несколько человек голосуют по каждому вопросу, скорость страдает. Мы решаем это делегированием, но баланс между демократией и эффективностью — постоянная работа.

Free rider. В кооперативе сложнее расстаться с неэффективным участником — он совладелец. Нужны чёткие метрики вклада и механизмы ротации. Мы это прописали в уставе, но ещё ни разу не применяли. Теория и практика тут могут разойтись. А вот конкретная ситуация, которая подтолкнула к формализации: один участник месяц сидел на задаче, которую оценивал в «неделю максимум». Не саботировал — просто переключался на свои дела, потому что внешнего контроля нет, а внутренний у всех разный. В корпорации тимлид заметит на дейли. В артели, где все — равные партнёры, сказать «ты халтуришь» — это не управленческое решение, это конфликт между совладельцами. И разрешать его в разы сложнее.

Неравномерный доход. Нет фиксированной зарплаты — есть доля от прибыли. В плохой месяц зарабатываешь меньше. Для человека с финансовыми обязательствами — это серьёзный фактор. У нас был месяц, когда между двумя контрактами образовался разрыв в три недели. Для меня — неприятно, но терпимо, есть подушка. Для участника с ипотекой и ребёнком — реальный стресс. Он не ушёл, но разговор был тяжёлым. С тех пор мы ввели резервный фонд — процент от каждого контракта откладывается на сглаживание таких провалов. Корпорация решает это за тебя — стабильный оклад двадцать пятого числа. В артели ты решаешь это сам, и это требует финансовой дисциплины, которая есть далеко не у всех.

Культурный барьер. В России слово «кооператив» ассоциируется с 90-ми. Объяснять, что это международная модель с вековой историей, а не «кооператив Озеро» — утомительно, но необходимо. На одной из встреч потенциальный заказчик спросил: «А кооператив — это типа коммуна? Вы там все в одном доме живёте?» Без иронии — реально спросил. В голове у людей кооператив — это либо советский магазин, либо хиппи на ферме. Что это может быть группа профессионалов с прозрачным распределением прибыли и демократическим управлением — в картину мира не укладывается. Каждый такой разговор — маленькая просветительская работа. Устаёшь, но без неё модель не масштабируется за пределы узкого круга единомышленников.

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

Для кого это

Тебе подойдёт кооператив, если ты устал от бюрократии, но не хочешь фрилансить в одиночку. Если готов отвечать за общий результат. Если ценишь прозрачность больше, чем «стабильный оклад». Если умеешь работать как равный.

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

Оба варианта — нормальные. Нет «правильного» выбора.

Но вот что я заметил за год жизни на двух стульях: всё больше сильных инженеров задают вопрос «а почему я не владею результатом своего труда?» Раньше этот вопрос казался философским. Сейчас, когда один человек с AI-инструментами может заменить целый отдел, он становится экономическим. И ответ на него определит, как будет устроена IT-индустрия через десять лет. Я хочу быть среди тех, кто этот ответ формирует, а не среди тех, кто его получит по факту.

Подробнее о том, как устроена Артель и как присоединиться — на странице Digital Artel. А полный разбор тезиса о совладении AI и кооперативной модели — в манифесте.

По мотивам манифеста Digital Artel.

Ваш ДПУПП

AI в разработке: 30-60% ускорения — реальность или хайп?

Sun, 15 Mar 2026 00:00:00 GMT

Февральский эксперимент

Февраль 2025-го. Рабочий созвон, экран расшарен — тимлид пишет Flink-джобу для нового пайплайна обработки транзакций. Рядом открыт корпоративный AI-ассистент. Тимлид формулирует задачу, получает код, копирует в IDE. Через двадцать минут у него есть рабочий скелет стримингового пайплайна — маппинги, окна агрегации, watermark-стратегия. На это обычно уходит полдня.

Я смотрю на результат и думаю: ок, впечатляет. А потом замечаю, что сгенерированный код использует ProcessingTime вместо EventTime. Для нашей системы, где задержки между источниками могут достигать минут, это катастрофа. AI не знает, что у нас разнородные источники данных с разным latency. Он выдал технически валидный код, который в продакшене перемешал бы события из разных временных окон.

Этот момент задал тон всему нашему подходу к AI в команде. Не «ура, ускорение!» и не «фигня, не работает». А трезвый вопрос: где граница между ускорением и иллюзией ускорения?

Контекст: Decision Engine и 20 ТБ в сутки

Я руковожу кластером разработки платформы предодобренных персонализированных кредитных предложений ВТБ — Real-Time и Batch Decision Engine. Обработка 20 ТБ данных в сутки, 500K RPS в production, формирование офферов по всем кредитным продуктам для всей клиентской базы банка в реальном времени. Стек: Flink, Kafka, Tarantool, Scala, Python.

И здесь — классическая проблема enterprise Big Data. Скоуп недооценён на старте. Каждый спринт вскрывает новые зависимости. Требования меняются быстрее, чем команда реализовывает предыдущие. Интеграции с десятками банковских систем, регуляторные ограничения ЦБ, legacy-контракты.

Когда в конце 2024-го AI-инструменты дозрели до уровня «можно пускать в продуктовый код», мы начали эксперимент. Не приказом сверху — «теперь все используют AI-ассистент» — это путь к хаосу. А пилотом. Сначала аналитики — у них самые формализованные задачи. Через месяц показали результаты команде. Потом разработчики. Потом тестировщики.

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

Где деньги лежат

Бойлерплейт и шаблонный код — здесь AI просто зверь. CRUD, маппинги DTO, конфигурации сервисов, миграции БД. Раньше scaffolding нового микросервиса с REST API, валидацией, обработкой ошибок и логированием — 2-3 часа. Сейчас — 30-40 минут, включая ревью. Экономия 70-80%, и качество ревью при этом не страдает, потому что валидировать шаблонный код — задача механическая.

Рефакторинг — 50-60%. Миграция компонентов между версиями фреймворка, переименования с учётом зависимостей, смена паттернов. AI держит контекст всего проекта и не пропускает импорты в дальних файлах. Рутина на несколько дней сжимается в полдня.

Тесты — 60-70%. И вот тут неожиданный бонус: AI методично перебирает граничные случаи, о которых ты не подумал. Null-значения, пустые коллекции, максимальные размеры, concurrency-сценарии. Покрытие растёт в 3-4 раза быстрее. Но — и это важно — ты определяешь стратегию тестирования. Что тестировать, на каком уровне, какие инварианты. AI генерирует, ты думаешь.

Документация — 50-60%. Черновик по структурированным заметкам генерируется за минуты. Аналитик редактирует вместо того, чтобы начинать с пустого документа. Формализация требований из записей митингов — скелет user stories с acceptance criteria готов быстрее, чем ты допьёшь кофе.

Анализ данных для аналитиков — самый ранний и заметный эффект. Подбросить LLM выгрузку из базы, попросить найти аномалии — быстрее, чем писать SQL для каждой гипотезы. Два часа ручного анализа превращаются в двадцать минут валидации.

Где AI создаёт иллюзию

Архитектурные решения. AI предложит пять вариантов — и все будут технически корректны. Но выбор определяется вещами, которые не помещаются в промпт: политика организации, компетенции конкретных людей в команде, планы развития продукта на два года вперёд, регуляторные ограничения ЦБ, legacy-системы с обратной совместимостью. Ускорение — 10-20%, и то за счёт генерации вариантов для обсуждения, не за счёт принятия решений.

Дебаг распределённых систем. Race conditions, каскадные отказы, intermittent failures под нагрузкой. У нас был кейс: стриминговый пайплайн терял события при определённом паттерне нагрузки. AI видел код, но не видел графики Grafana, не понимал паттерны нагрузки, не знал, что этот конкретный топик Kafka переключается на другой брокер при перебалансировке. Диагностика таких проблем — детективная работа, и AI в ней ассистент, а не детектив.

Code review бизнес-логики. AI ловит null pointer exceptions, неоптимальные запросы, стилистические проблемы. Но пропускает ошибки в бизнес-процессах. Он не знает, что клиенту категории Premium скидка считается иначе, если это не описано явно. Он не знает, что status = 3 означает «клиент на ручной проверке из-за санкционных ограничений». Доменное знание — пока за человеком.

Матрица: что куда

Тип задачи	Экономия	Качество результата AI	Уровень контроля
Бойлерплейт, CRUD	70-80%	Высокое	Минимальный
Тесты, автотесты	60-70%	Среднее-высокое	Средний
Документация	50-60%	Среднее	Средний
Рефакторинг	50-60%	Высокое	Средний
Прототипирование	40-50%	Среднее	Высокий
Бизнес-логика домена	20-30%	Низкое-среднее	Обязательный
Архитектура	10-20%	Низкое-среднее	Обязательный
Дебаг сложных систем	10-15%	Низкое	Обязательный

Закономерность очевидна: чем формализованнее задача, тем выше эффект AI. Чем больше неявного контекста — тем ниже.

Как мы это внедряли (без лозунгов)

Начали с аналитиков. Собрали рабочие промпты в Сфере.Знания — «как генерить тест-кейсы», «как писать документацию», «как делать code review». Не заставляли каждого изобретать велосипед.

Ввели правило двойной проверки: любой результат AI проходит ревью человеком. Без исключений. Это не бюрократия — это гигиена. После случая с ProcessingTime vs EventTime никто не спорил.

Измеряли эффект честно. Не «нам кажется, что стало быстрее», а сравнение velocity в спринтах до и после. Первый месяц — результат нулевой. Люди тратили время на освоение инструментов, промпты были кривые, результаты AI приходилось переписывать. Второй месяц — начало роста. Третий — вышли на плато. К четвёртому месяцу сформировалась библиотека промптов и паттернов, которые реально экономили время. Кривая внедрения — классическая J-образная: сначала хуже, потом сильно лучше.

Отдельная история — сопротивление. Двое разработчиков принципиально отказывались от AI-инструментов. Один — из соображений «я и так быстро пишу код». Второй — из опасений за качество. Мы не давили. Через два месяца первый увидел, что коллега с AI закрывает задачи заметно быстрее, и пришёл сам. Второй так и не пришёл — и это его право. Заставлять людей менять инструменты силой — путь к саботажу.

Безопасность по умолчанию. В regulated-окружении нельзя гнать реальные данные во внешние сервисы. Это требует отдельной работы по настройке: локальные endpoint-ы, обезличенные тестовые данные, правила работы с промптами, в которых нет конфиденциальной информации. Скучная работа, но без неё любой AI-эксперимент заканчивается звонком от службы безопасности.

Контекст решает всё. Файлы с правилами проекта, примеры кода, описание доменной модели — всё это кратно повышает качество генерации. AI без контекста — это рандомный генератор технически валидного, но бесполезного кода. AI с контекстом — это junior, который читал всю документацию и запомнил её лучше, чем ты.

Pet-проект как лакмусовая бумажка

Параллельно с enterprise я использую те же инструменты на собственном full-stack проекте. И вот что интересно: на pet-проекте ускорение ещё заметнее. Не потому что задачи проще — потому что нет организационных ограничений. Нет compliance, нет согласований, нет обезличивания данных.

Работающий MVP за сроки, несопоставимые с традиционной разработкой. Конкретный пример: мне нужно было реализовать сложную интеграцию нескольких внешних API с кешированием, обработкой ошибок, retry-логикой и rate limiting. В прошлой жизни — неделя работы минимум: изучить документацию каждого API, написать адаптеры, покрыть тестами, отладить граничные случаи. С AI — два вечера. Я описал контракты, описал поведение при ошибках, описал стратегию кеширования. AI генерировал код. Я ревьюил, корректировал, запускал. Самое интересное: AI нашёл edge case в документации одного из API, который я бы пропустил — несоответствие между описанием формата даты и реальным ответом. Машина прочитала доку внимательнее человека. Но — и это важно — она не знала, зачем мне эта интеграция и какие данные критичны. Это знал только я.

Но — и это ключевое — все решения о том, что строить, для кого, какую проблему решать, принимал я. AI кратно ускоряет execution, но не заменяет product thinking. Архитектуру pet-проекта я тоже определял сам, опираясь на опыт enterprise-систем. AI предлагал варианты, но финальное решение — человеческое.

Какие модели я сравнивал (на момент доклада, 2024)

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

ChatGPT (GPT-4, позже GPT-4o) — на тот момент лидер. Именно на нём я сформировал полноценный курс по системному анализу для T1 Digital Academy: структура, материалы, задания, критерии оценки. Ни одна другая модель на тот момент не справилась с задачей такого масштаба.

GigaChat (Сбер) — честно попробовал на аналогичных задачах. На генерации кода и простых текстов работал приемлемо, но на сложных задачах — формирование курса, архитектурный анализ — результат был значительно слабее. Модель не держала контекст на длинных сессиях, теряла нить рассуждения. Это не приговор — отечественные модели активно развиваются, и к 2026-му ситуация уже другая. Но на момент доклада разрыв был существенным.

Gemini (Google, тогда ещё Bard → Gemini Pro) — сильный в аналитике и работе с данными, но в генерации enterprise-кода отставал от GPT-4. Хорошо работал для research-задач.

Grok (xAI) — интересный инструмент для быстрых ответов и brainstorming, но для серьёзной генерации кода и длинных сессий на тот момент не дотягивал.

Вывод простой: для enterprise-задач на 2024 год ChatGPT (GPT-4/4o) был основным рабочим инструментом. Корпоративные AI-ассистенты, доступные внутри контура, покрывали базовые кейсы, но для сложных задач приходилось использовать внешние модели на обезличенных данных. Ситуация быстро меняется — и это хорошо для всех.

Множитель, а не замена

Формула, к которой мы пришли за полгода экспериментов: AI — это множитель. Он умножает эффективность квалифицированного специалиста. Хороший разработчик с AI — это отличный разработчик с турбонаддувом. Плохой разработчик с AI — это плохой разработчик, который теперь генерирует баги быстрее.

30-60% ускорения — не маркетинговая цифра. Это диапазон из трекера задач за шесть месяцев. Нижняя граница — на задачах с тяжёлым доменным контекстом. Верхняя — на формализованной рутине. Средняя температура по больнице — около 40%.

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

Через год эти цифры будут другими. Порог входа упадёт, инструменты поумнеют, контекстные окна вырастут. Но принцип останется: AI ускоряет execution, а не thinking. И чем глубже ты понимаешь предметную область, тем больше из него выжмешь. А если не понимаешь — он тебя похоронит быстрее, чем ты заметишь.

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

По мотивам доклада на АиУП 2024 и личного опыта внедрения AI в enterprise-разработке.

Ваш ДПУПП

Red Flags в найме глазами лида

Mon, 20 Oct 2025 00:00:00 GMT

Когда начинаешь слышать людей, а не слова

Несколько сотен собеседований за карьеру. Начинал как все — с паттернов проектирования и SQL-джоинов. Был уверен: найди технически сильного человека, остальное приложится.

Переломный момент — проект по построению event-driven платформы. Нанял разработчика, который на техническом интервью разложил архитектуру микросервисов так, что хотелось аплодировать стоя. Глубокие знания Kafka, Flink, понимание распределённых систем на уровне, который редко встречаешь. Оффер сделали в тот же день.

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

С тех пор я слушаю не ответы, а паттерны. Не что говорит кандидат, а как.

Важная оговорка: red flag — не приговор. Это сигнал о возможном несовпадении ценностей. Один и тот же человек может быть токсичным в одной команде и звездой в другой. Но если ты строишь конкретную культуру — нужно уметь распознавать то, что в неё не впишется.

Архетип 1: Раненый герой

Узнаёшь по тому, как много он рассказывает о предыдущем месте — и как мало хорошего в этих рассказах. Прошлый руководитель был некомпетентен, команда не понимала его идей, компания не ценила вклад.

Проблема не в негативном опыте — такое бывает. Проблема в позиции. Раненый герой не рефлексирует: он обвиняет. Спрашиваешь «а что бы ты сделал иначе?» — ответ сводится к «ну, если бы меня слушали...».

Почему это опасно для команды. Раненый герой приносит обиду с собой. Любой конфликт интерпретирует через призму прошлого. Руководитель принял решение без совещания — значит, опять не ценят. Коллега не согласился с подходом — значит, опять не слушают. Ты получаешь сотрудника, который воюет не с текущими проблемами, а с призраками предыдущей работы.

Как распознать. Попроси рассказать про самый сложный проект. Слушай не факты, а эмоциональную окраску. Если восемьдесят процентов рассказа — описание препятствий, созданных другими людьми, а не решений, найденных кандидатом — это сигнал.

Архетип 2: Одинокий кодер

«Мне бы просто писать код. Созвоны, ретро, планирования — это всё мешает работать.» Звучит как здоровый прагматизм. На практике — бомба замедленного действия.

Одинокий кодер не хочет быть частью команды. Он хочет быть наёмным подрядчиком: дали задачу — не трогайте до дедлайна. В стартапе из трёх человек это работает. В enterprise-разработке с десятками зависимых сервисов и несколькими смежными командами — нет.

У меня был такой. Сильный, быстрый, решал задачи в два раза быстрее остальных. За три месяца написал сервис, который никто в команде не мог поддерживать. Документации ноль. Тесты — «это очевидный код, зачем тесты». Когда он ушёл в отпуск, а в его сервисе нашли баг — команда потратила неделю на то, чтобы разобраться в коде, который один человек написал за день. Экономика отрицательная.

Как распознать. Спроси про code review. Если человек воспринимает ревью как формальность или, хуже, как нападение на компетенцию — сигнал. Хороший командный игрок видит в ревью инструмент, а не оценку.

Архетип 3: Гибкий в этике

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

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

Был случай. Разработчик из смежной команды подписал акт о проведении нагрузочного тестирования. Тестирование провели — на десяти процентах целевой нагрузки. В акте — «тестирование пройдено успешно». Формально — правда. По сути — ложь. На проде система легла в первый час. Разбор полётов длился дольше, чем само падение.

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

Архетип 4: Расфокусированная звезда

Знает React, Vue, Angular, Svelte. Пробовал Rust, Go, Elixir. Pet-проект на Haskell. На прошлой работе внедрял Kubernetes, до этого — CI/CD, ещё раньше — базы данных. Резюме впечатляет. Глубина — нет.

Расфокусированная звезда коллекционирует технологии. Каждые полгода — новый стек. Ни в одной теме нет глубины, достаточной для production-решений.

Почему это опасно. Enterprise требует глубины, не ширины. Когда Tarantool деградирует под нагрузкой — нужен человек, который знает внутренности, а не тот, кто «трогал на хакатоне». Когда Flink-джоба не укладывается в SLA — нужен эксперт, а не энтузиаст.

Был конкретный случай. Кандидат на позицию senior-разработчика, в резюме — внушительный список: Kubernetes, Terraform, Ansible, три облака, два языка. На вопрос «расскажи про самый сложный деплой» ответил историей, как настраивал Helm-чарт для простого CRUD-сервиса. Ок, копаю дальше: «Какие проблемы были с liveness/readiness пробами?» — «Ну, стандартные настроили, вроде работало.» «А если под не поднимается после деплоя — как дебажишь?» — долгая пауза и переход на рассказ о том, как он параллельно изучает Rust. Человек собрал впечатляющую коллекцию инструментов и ни одним не владел на уровне, нужном для решения реальных проблем в продакшене. Через полгода он снова сменит стек и напишет в резюме ещё одну строчку.

Как распознать. Возьми любую технологию из резюме, копни на два уровня. Не «что такое Kafka», а «как работает rebalancing консьюмер-группы и когда это становится проблемой». Расфокусированная звезда плывёт после первого уточняющего вопроса.

Архетип 5: Фантом результатов

Самый опасный, потому что самый скрытный. Мастер презентации. Красиво рассказывает о масштабных проектах, правильные buzzwords, нарратив о личном спасении ситуации.

Начинаешь задавать конкретику — «какой SLA?», «сколько событий в секунду?», «какие альтернативы рассматривали?» — ответы тают. «Ну, большой проект...», «Точные цифры не помню...», «Я отвечал за общее направление...».

Однажды собеседовал кандидата на сеньорную позицию. Резюме — космос: распределённые системы, высоконагруженные сервисы, архитектурные решения. Двадцать минут — блестящий рассказ. Потом я спросил: «Ты упомянул, что оптимизировал запросы к базе данных. Расскажи про самый сложный случай — какой был план запроса до и после?» Пауза. «Ну, мы использовали индексы...» — «Какие именно?» — «B-tree...» — «А почему не partial index? Данные ведь были с фильтрацией по статусу, как ты описывал.» Ещё одна пауза. Стало ясно: человек руководил проектом, где всё это происходило. Но не он это делал.

Как распознать. Метод STAR — Situation, Task, Action, Result. Проси конкретику: цифры, метрики, хронологию. Настоящий эксперт помнит детали проектов, в которых жил. Фантом — нет, потому что участвовал на другом уровне.

Архетип 6: Профессиональный собеседуемый

Отдельный вид, который я выделил недавно. Человек, который проходит собеседования как спорт. Идеальные ответы. Правильная структура STAR на каждый вопрос. Заготовленные истории под каждый тип вопроса.

Проблема: за отполированной презентацией не видно реального человека. Задаёшь нестандартный вопрос — секундное замешательство, потом переключение на ближайший заготовленный ответ. Как чат-бот, который не понял промпт и отвечает на ближайший похожий.

Я однажды собеседовал кандидата, который отвечал настолько гладко, что мне стало не по себе. Каждый ответ — как из учебника. Идеальная структура, правильные паузы, даже самоирония была заготовлена и отрепетирована. Я спросил: «Расскажи про ситуацию, когда ты облажался на проекте и не смог это исправить.» Он начал рассказывать историю — но в ней «облажался» плавно перетёк в «принял непопулярное решение, которое в итоге оказалось правильным». Я переспросил: «Нет, именно облажался. Без хеппи-энда.» Секунд пятнадцать тишины. Потом — «Ну, наверное, когда-то был такой случай, но я не помню деталей.» Человек, который не помнит свои провалы — либо ни разу не ошибался (невозможно), либо настолько отрепетировал самопрезентацию, что реальный опыт спрятался за фасадом.

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

Архетип 7: Внешний локус

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

«Менеджер не объяснил задачу». «Процессы у вас плохо выстроены». «Я бы сделал, но у нас так не принято». «До меня там уже всё сломали». Звучит как конструктивная критика. Но паттерн один: собственная зона управления отсутствует. Не потому что человек ленив — просто его внутренняя модель такова, что события происходят с ним, а не по его воле.

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

Почему это проблема. В банковской разработке, где инцидент требует root cause analysis и конкретного ответственного, такой человек парализует разбор. Не злонамеренно — он искренне описывает события как они «случились». Проблема в том, что команда не может учиться и меняться на основе анализа, в котором нет субъекта.

Как распознать. Попроси рассказать про провальный проект. Слушай, кто субъект предложений. «Мы не успели» — нормально. «Нас не предупредили, сроки поставили нереальные, архитектура была изначально неправильная» — каждое предложение без «я» и без действия. Один раз — ситуация. Три раза подряд — паттерн.

Рефлексивный подход

Я не использую архетипы как чёрный список. Это инструмент рефлексии — для себя. За годы найма я понял: идеальных собеседований не бывает, как не бывает идеальных кандидатов. Каждое интервью — это два человека, которые пытаются за час понять, смогут ли они вместе строить что-то сложное.

Каждый раз, когда вижу red flag, задаю три вопроса:

Паттерн или момент? Человек нервничает на интервью — нормально.
Несовместимо или непривычно? Разнообразие подходов — сила.
Могу ли работать с этим? Некоторые паттерны корректируются менторством. Другие — фундаментальны.

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

Способность работать в команде, брать ответственность и честно говорить о проблемах — это либо есть, либо нет. Технологии можно выучить. Характер — нет.

И последнее. Самый полезный вопрос, который я задаю себе после каждого собеседования: «А я бы хотел, чтобы этот человек принимал решения, когда меня нет?» Не «справится ли он с задачами» — справится, если технически силён. А именно: доверяю ли я его суждению? Готов ли я, чтобы он общался с заказчиком без моего присмотра? Чтобы он менторил junior-а? Чтобы он в три часа ночи на инциденте принял решение, которое я узнаю утром? Если ответ «нет» — неважно, какой у него стек.

Впрочем, я тоже проходил собеседования, где был раненым героем. Просто не замечал.

Если тема найма и управления командами тебе близка — я провожу менторинг для начинающих тех-лидов, где разбираем в том числе найм, удержание и построение культуры. А если ты из тех, кто хочет строить команды на принципах совладения — посмотри, как устроена Digital Artel.

Оригинал статьи: Red Flags в найме глазами лида на Habr

Ваш ДПУПП

Как перевести банковский продукт в realtime

Tue, 04 Mar 2025 00:00:00 GMT

Среда, 2:47 ночи. Дашборд горит красным.

Весна 2024-го. Мы прошли функциональное и интеграционное тестирование, выходим на прод — и тут начинается настоящее нагрузочное, только уже на боевом трафике. Tarantool начинает терять запросы на двадцатой минуте под реальной нагрузкой. Не сразу — сначала один таймаут из тысячи, потом два, потом десять. Красивая экспонента на графике, которая через полчаса превратит систему в тыкву.

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

Но это будет потом. Сначала — о том, зачем вообще ломать то, что работало.

Почему batch — это вчера

Банковская система предодобренных предложений работала в batch-режиме годами. Ночью прогоняются модели, утром формируются списки, днём клиенты получают SMS. Конверсия — доли процента. К моменту, когда человек видит предложение, он уже давно забыл, зачем заходил в приложение.

Задача звучала просто: клиент совершает действие — банк реагирует за секунду. Не завтра, не через час. Сейчас.

Вот как выглядит разница на бумаге:

Параметр	Batch	Real-time
Латентность	12-24 часа	< 1 секунды
Свежесть данных	Вчерашний снимок	Текущий момент
Стоимость инфраструктуры	Ниже (ночные окна)	Выше (24/7 кластеры)
Сложность архитектуры	Линейная (ETL-пайплайн)	Экспоненциальная (event mesh)
Обработка ошибок	Перезапуск батча	Dead Letter Queue, ретраи, алерты
Масштабирование	Вертикальное (мощнее сервер)	Горизонтальное (больше нод)
Отладка проблем	Логи одного прогона	Распределённый трейсинг

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

Архитектурные решения: почему именно этот стек

Flink, а не Spark Streaming

Выбор стримингового движка — решение, которое будет стоить тебе нервов следующие три года. На столе были Apache Spark Streaming, Kafka Streams и Apache Flink.

Spark Streaming отпал за минуту — micro-batch с задержкой в секунды не вписывался в SLA. Kafka Streams рассматривали серьёзно: он легче, встроен в экосистему, не требует отдельного кластера. Но нам нужен был stateful processing с оконными функциями и сложной логикой обогащения. У Kafka Streams на тот момент с этим было туго.

Flink выиграл по трём критериям. Первый — нативная поддержка event time. Когда события приходят с задержкой (а из банковских систем они приходят с задержкой всегда), это не просто nice-to-have — это разница между правильным и неправильным решением по клиенту. Второй — exactly-once семантика из коробки. В банковском контексте потерянное событие — не метрика в дашборде, а потенциальная жалоба клиента и внимание регулятора. Третий — зрелый checkpoint/savepoint для fault tolerance. Система должна пережить падение ноды без потери состояния.

Цена: на российском рынке специалистов по Flink можно буквально пересчитать по пальцам. Рекрутинг превращается не в воронку, а в охоту.

Tarantool: скорость и предательство

Каждое событие нужно обогатить: профиль клиента, история операций, текущие лимиты, параметры продуктов. Классический путь — реляционная база. Но когда тысячи событий в секунду и SLA на обработку — десятки миллисекунд, PostgreSQL становится бутылочным горлышком.

Tarantool решил эту проблему красиво: in-memory хранилище с latency менее миллисекунды. Данные из основных систем реплицируются с минимальной задержкой, Flink-джобы обращаются за обогащением.

А потом наступила та ночь.

Баг проявлялся только под нагрузкой, близкой к production. В тестовой среде — идеально. На половине боевого трафика — идеально. На семидесяти процентах — спорадические таймауты. На целевых объёмах — деградация, которая за полчаса превращала систему в овощ.

Первая неделя дебага — ложные следы. Мы грешили на сеть, на JVM, на конфигурацию Flink. Вторая неделя — изоляция проблемы до конкретного паттерна конкурентных запросов в Tarantool. Конкретный сценарий: когда параллельные запросы на чтение и запись попадали в одну и ту же область данных с определённой частотой, in-memory движок начинал деградировать.

Помню совещание, где мы решали, что делать. Два варианта на столе: ждать фикса от сообщества (неопределённо долго) или экстренный пивот части архитектуры. Времени не было. Мы задокументировали баг, сообщили сообществу и за выходные переписали критический путь на связку PostgreSQL + кэширование.

Latency выросла с микросекунд до миллисекунд. Архитектура стала грязнее. Но стабильной. В банке предсказуемость важнее элегантности.

Kafka как нервная система

Apache Kafka — транспортный слой всей системы. Каждый микросервис публикует и читает события через топики. Три вещи, которые решает Kafka: развязка сервисов (каждый знает только про свои топики), replay (можно перечитать события для дебага) и масштабирование через партиционирование.

Kafka, кстати, была единственной технологией в стеке, которая ни разу не преподнесла сюрприза. Работает как швейцарские часы, если не лезть в настройки retention слишком часто.

Четыре языка в одном проекте — осознанный хаос

Java, Scala, Lua, SQL. Звучит как плохая шутка. Но за каждым выбором — прагматизм, не эстетика.

Java — основа микросервисов. Spring Boot, огромный пул разработчиков, зрелые библиотеки для Kafka.

Scala — Flink-джобы. Flink API на Scala выразительнее на порядок. Писать оконные агрегации на Scala — удовольствие. На Java — наказание.

Lua — хранимые процедуры в Tarantool. LuaJIT как встроенный язык — для сложной логики обогащения единственный вариант.

SQL — аналитические запросы и конфигурация правил в движке решений. Бизнес-пользователи модифицируют правила без разработчиков.

Цена: найти разработчика, который свободно читает Java и Scala — уже квест. А Lua-разработчики для Tarantool — штучный товар, который на открытом рынке не водится. Мы вырастили своих. Других вариантов не было.

Event-driven: красиво в теории, больно на практике

Event Sourcing для критических бизнес-событий. Каждое изменение — событие. Полная история, возможность воспроизвести любое состояние на любой момент. Must have для банковского аудита, который приходит в самый неподходящий момент и спрашивает, что именно произошло с клиентом 17 февраля в 14:23.

CQRS для разделения потоков. Запись через event pipeline, чтение из проекций в Tarantool и PostgreSQL. Независимое масштабирование нагрузки.

Dead Letter Queue — наш лучший друг в первые недели после запуска. Событие, которое не удалось обработать, не теряется — попадает в отдельный топик для анализа. В первую неделю на проде DLQ разбухла до размеров, которые мы не закладывали. Оказалось, legacy-системы присылали события в формате, который не соответствовал спецификации. Не иногда — в пяти процентах случаев. Пять процентов от миллионов событий — это много мусора в DLQ.

Главный подводный камень — eventual consistency. В event-driven системе нет гарантии, что все сервисы видят одинаковое состояние одновременно. Для банковских продуктов это страшно: нельзя предложить кредит, если данные о текущей задолженности клиента ещё не добрались до scoring-сервиса. Решение — явное управление порядком через timestamp и watermark во Flink. Работает, но добавляет слой сложности, который нужно объяснять каждому новому разработчику.

Провалы, которые нас научили

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

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

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

Провал четвёртый: мы недооценили backpressure. Утро понедельника, пиковая нагрузка. Upstream-система выгружает накопившиеся за выходные события пачкой. Kafka справляется — она всегда справляется. Flink начинает захлёбываться: checkpoint-ы растут, latency ползёт вверх, и через двадцать минут consumer lag разрастается до миллионов сообщений. Мы не заложили механизм backpressure, который корректно замедлял бы потребление при перегрузке. Пришлось вручную останавливать джобы, делать savepoint и рестартовать с ограничением скорости чтения. После этого инцидента backpressure-стратегия стала частью архитектурного ревью каждого нового Flink-джоба.

Что осталось после проекта

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

Технологии — десять процентов проблемы. Flink, Kafka, Tarantool работают. Девяносто процентов — координация между командами, согласование API-контрактов, интеграция с legacy и управление ожиданиями бизнеса, который хочет «как у Google, но за три месяца».

Технический долг в realtime-системе — не абстрактная метрика. Каждая задержка в обработке события влияет на бизнес-метрики прямо сейчас, в реальном времени. Мы выделяли двадцать процентов спринта на техдолг. Этого было мало.

Конкретный результат, ради которого всё затевалось: время от действия клиента до персонализированного предложения сократилось с 12-24 часов до 800 миллисекунд на 95-м перцентиле. Конверсия в целевое действие выросла кратно по сравнению с batch-режимом. Не буду называть точные цифры — NDA, — но разница была достаточной, чтобы бизнес-заказчик, который полгода скептически спрашивал «а зачем нам realtime?», после первого месяца в проде пришёл с запросом на расширение на ещё четыре продуктовых сценария. Лучшее доказательство, что архитектура работает, — когда бизнес просит ещё.

А ещё — production пахнет иначе, чем стенд. Аномалии, пики, битые данные из систем, которые последний раз обновлялись при Медведеве. Всё это проявляется только в бою. И если ты к этому не готов — бой проявится в тебе.

Оригинал статьи: Как перевести банковский продукт в realtime на Habr

По мотивам доклада на Saint HighLoad++ 2024, Санкт-Петербург.

Ваш ДПУПП

Разработка в финтех: 7 кругов ада

Sun, 04 Aug 2024 00:00:00 GMT

Почему Данте был бы отличным IT-руководителем

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

Я прошёл все семь кругов несколько раз. Каждый раз выносил уроки, которых нет ни в одном Agile-манифесте. Это не жалоба и не пугалка — это карта местности, чтобы ты не шёл вслепую.

Круг первый: Найм

«Оставь надежду, всяк сюда входящий» — Данте, Ад, Песнь III

В стартапе ты публикуешь вакансию, через неделю — три собеседования, через две — человек на борту. В банке найм — отдельный проект со своим таймлайном и stakeholder-ами.

Согласование штатной единицы. Формирование требований через HR-систему. Публикация через корпоративный рекрутинг. Фильтрация резюме. Собеседования, которые нужно согласовать в календарях пяти человек. Оффер через юридическую проверку. Security check. Онбординг с получением доступов — сам по себе две-три недели.

В начале 2024-го мне нужен был Scala-разработчик с опытом Apache Flink. На российском рынке таких специалистов — буквально единицы. Первый подходящий кандидат появился через два месяца. Пока шли согласования оффера — он принял другой. Второй кандидат нашёлся ещё через месяц. К моменту, когда он сделал первый коммит, прошло четыре с половиной месяца. Проект к тому времени уже горел.

Итого: от осознания потребности до первого рабочего коммита — три-четыре месяца. А проект нужен был вчера.

Как выживать. Нанимай с опережением — и учись распознавать red flags. Если знаешь, что через квартал понадобятся ещё люди — начинай сейчас. Формируй кадровый резерв. Строй отношения с рекрутингом — они приоритизируют тех, с кем нормально работать. И главное — будь готов растить экспертизу внутри. На рынке нужного специалиста может просто не быть.

Круг второй: Бюрократия

«Здесь стонов слышно не было, лишь вздохи» — Данте, Ад, Песнь IV

Банк — регулируемая организация. ЦБ, аудиторы, служба безопасности. Каждое изменение в production — задокументировано, согласовано, одобрено. Не прихоть менеджмента — требование регулятора.

Простой деплой превращается в квест: RFC, согласование архитектурного комитета, оценка рисков от ИБ, подтверждение от бизнес-владельца, запись в change-календаре. Одно несогласованное звено — деплой не состоится.

Помню первый релиз нового сервиса. Код готов, тесты зелёные, API согласованы, команда на низком старте. Деплой назначен на четверг. В среду вечером ИБ вернула замечания по документации — формулировка в одном разделе не соответствовала внутреннему стандарту. Перенос на следующую неделю. Переписали раздел. В понедельник — новые замечания, уже от архитектурного комитета. Итого: от готового кода до прода — три недели бумажной работы.

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

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

Круг третий: Меняющиеся требования

«Их гонит вечный ветер, не давая покоя» — Данте, Ад, Песнь V

Бизнес-заказчик приходит с идеей. Ты фиксируешь scope, оцениваешь сроки, планируешь ресурсы. Через две недели: «А мы подумали, и нужно ещё вот это». Через месяц — ещё раз. Через два — scope вырос вдвое, дедлайн прежний.

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

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

Как выживать. Контрактуй scope письменно и с подписью. Change request — не бюрократия, а инструмент прозрачности. Каждое изменение = пересмотр сроков и ресурсов. Бизнес имеет право менять требования, но должен понимать цену. И проектируй систему так, чтобы она переживала эти изменения — модульность не для красоты, а для выживания.

Круг четвёртый: Дефицит ресурсов

«Толкают тяжести, крича друг другу» — Данте, Ад, Песнь VII

Ты спроектировал систему, которая требует четырёх серверов с определёнными характеристиками. Подал заявку. Через месяц — два сервера с другими характеристиками. Через два — ещё один, но в другом дата-центре.

Реальная история: мы ждали серверы для нагрузочного тестирования три месяца. Когда получили — оказалось, что конфигурация не соответствует заявке. Оперативки вдвое меньше. Заявку на докомплектацию подали заново. Ещё месяц. В итоге нагрузочное тестирование проводили на железе, которое не соответствовало production-конфигурации. И баг в Tarantool, который мы нашли позже, вполне мог проявиться раньше — если бы инфраструктура была правильной.

Люди — ещё более дефицитный ресурс. Тебе нужен разработчик со знанием специфического стека, а на рынке таких единицы. DevOps-инженер, который знает корпоративный Kubernetes, загружен на трёх проектах одновременно.

Как выживать. Проектируй с учётом ограничений, а не в вакууме. Работающая система на двух серверах лучше идеальной архитектуры, которая никогда не получит нужное железо. Растите T-shaped людей внутри команды — когда каждый может подхватить смежную задачу, вы не парализованы отпуском одного человека.

Круг пятый: Конфликты

«Угрюмы были мы в сладости света» — Данте, Ад, Песнь VII

Над одним продуктом в крупном банке работают десятки людей из разных подразделений. У каждого свои KPI, приоритеты, понимание «правильного». Конфликты неизбежны.

Бизнес хочет быстрее, разработка — качественнее. Архитектурный комитет хочет стандарты, команда — свободу. Тестирование хочет полный регресс, бизнес — деплой завтра. ИБ хочет всё заблокировать, разработка — доступ ко всему.

Самый запоминающийся конфликт: смежная команда поменяла формат API без предупреждения. В пятницу вечером. Наш сервис начал складывать события в Dead Letter Queue — тысячами. Дежурный поднял тревогу, мы откатили их изменение, а в понедельник начался разбор. Оказалось, что у них был свой дедлайн, и «мы думали, вы уже перешли на новый формат». Никто не проверил. Никто не написал в чат. Урок: контракт между командами — это не документ в базе знаний, а живой процесс.

Как выживать. Конфликт — не проблема, а индикатор дисбаланса. Ищи win-win. Строй личные отношения с лидами смежных команд. Эскалируй, только когда всё остальное исчерпано. И заведи общий канал для breaking changes — серьёзно, это спасает.

Круг шестой: CI/CD в enterprise

«В открытых гробах, в пламени лежат» — Данте, Ад, Песнь IX

В стартапе — GitHub Actions за день, деплой по кнопке. В банке CI/CD — корпоративная платформа с регламентами, ограничениями и очередями.

Корпоративный CI/CD pipeline с кастомными плагинами. Docker-образы только из внутреннего registry. Зависимости только из корпоративного Nexus — и если там нет нужной версии библиотеки, ты не просто её добавляешь, а подаёшь заявку на включение в белый список. Доступ к prod — через отдельный pipeline с ручным одобрением.

Первый деплой нашего нового сервиса занял неделю. Не потому что код был плохой — потому что нужно настроить pipeline, получить доступы, зарегистрировать сервис в service mesh, настроить мониторинг и логирование по корпоративным стандартам. Второй сервис — три дня: мы уже знали маршрут. Третий — день. Кривая обучения крутая, но она есть.

Как выживать. Начинай настройку CI/CD в первый день проекта. Создай внутреннюю документацию по pipeline — для следующих сервисов процесс будет втрое быстрее. Автоматизируй линтеры, тесты, security-сканирование. И самое главное — подружись с командой, которая владеет платформой. Они знают обходные пути.

Круг седьмой: Поддержка

«Мы подошли к потоку красной крови» — Данте, Ад, Песнь XII

Прошёл шесть кругов, продукт на проде, заказчик доволен. Расслабиться? Нет. Теперь — самый длинный круг.

Инциденты в три часа ночи. Деградация из-за роста данных. Баги, которые проявляются только в определённых сценариях. Мелкие доработки, которые превращают стройную архитектуру в лоскутное одеяло.

Три часа ночи, алерт в PagerDuty. Latency скоринг-сервиса выросла в пять раз. Дежурный поднимается, смотрит дашборды — всё красное, причина неочевидна. Оказалось: одна из legacy-систем начала присылать события в изменённом формате после своего ночного релиза. Про который нас, разумеется, не предупредили. Десериализация не падала — она работала медленно, парсируя нестандартные поля. Тихая деградация — самый опасный вид.

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

Как выживать. Закладывай поддержку в архитектуру с первого дня. Observability — не опция, а требование. Runbook на каждый алерт. Knowledge base, которая обновляется. Ротация дежурств, чтобы не было одного «хранителя знаний», без которого всё встаёт.

Карта выживания

Круг	Боль	Тактика выживания	Типичная цена
1. Найм	Найти нужного человека за разумное время	Нанимай с опережением, расти внутри	3-4 месяца на позицию
2. Бюрократия	Согласования убивают скорость	Шаблоны, автоматизация документации, личные связи	20-30% времени команды
3. Требования	Scope плывёт, дедлайн — нет	Change request, письменные контракты, модульность	Перепроектирование раз в квартал
4. Ресурсы	Нет серверов, нет людей	Проектируй под ограничения, T-shaped люди	Месяцы ожидания
5. Конфликты	KPI разных команд не совпадают	Win-win, личные отношения, общие каналы	Неделя на разбор инцидента
6. CI/CD	Корпоративная платформа — не GitHub	Документация, автоматизация, дружба с платформой	Неделя на первый деплой
7. Поддержка	Ночные инциденты, отток людей	Observability, runbooks, ротация дежурств	Бесконечность

Восьмой круг, про который Данте не написал

Данте остановился на девяти кругах. Он не знал про production deployment в пятницу вечером. Про change freeze перед новогодними праздниками, когда бизнес-заказчик «очень просит последнюю маленькую фичу». Про миграцию на новую версию Kubernetes в банковском контуре, когда у тебя нет admin-прав, а у тех, кто имеет — нет контекста про твой сервис.

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

Только не деплой в пятницу. Серьёзно. Даже если очень просят.

Оригинал статьи: Разработка в финтех или как пройти 7 кругов ада на Habr

Ваш ДПУПП

Saint HighLoad++ 2024: Опыт перевода банковского продукта в реалтайм

Sat, 15 Jun 2024 00:00:00 GMT

Зал на восемьсот человек. Два микрофона. Первый слайд.

Июнь 2024-го, Санкт-Петербург, Saint HighLoad++. Я стою за кулисами и пересчитываю людей в зале. Восемьсот — это когда лиц уже не видно, только масса. Рядом Владимир Аврамов, ведущий разработчик проекта, спокойный как удав. Он будет показывать код. Я — рассказывать, как мы чуть не убили проект своими архитектурными решениями.

Тридцать минут на два года работы. Нужно выбрать, что рассказывать: красивую архитектуру из документации или правду. Мы выбрали правду. Слайды с красивыми квадратиками забудут через час. Историю про то, как ты в пятницу вечером откатывал релиз — запомнят. За это нас потом благодарили в кулуарах больше, чем за любой технический слайд.

Зачем лид и разработчик вместе на сцене

Совместный доклад — осознанный выбор. Одно дело — слайды с квадратиками и стрелочками. Другое — когда разработчик открывает IDE и показывает, как конкретный Flink-оператор ведёт себя под нагрузкой. Аудитория HighLoad++ — инженеры. Им нужен код, а не маркетинг.

Формат работал так: я даю контекст — бизнес-задача, ограничения, почему приняли такое решение. Аврамов показывает, как это решение выглядит в коде и что происходит, когда на него наступают в проде. Зал получает объёмную картину: стратегия и тактика одновременно.

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

Архитектура на салфетке

На HighLoad++ народ ценит конкретику. Вот схема, которую мы показывали — она жила в нашей документации ровно в таком виде:

┌──────────┐    ┌─────────┐    ┌──────────────┐    ┌───────────┐    ┌──────────┐
│  Событие │───>│  Kafka  │───>│  Flink Job   │───>│  Kafka    │───>│ Канал    │
│  клиента │    │ (вход)  │    │ (обработка + │    │ (выход)   │    │ доставки │
└──────────┘    └─────────┘    │  обогащение) │    └───────────┘    └──────────┘
                               └──────┬───────┘
                                      │ < 1 ms
                               ┌──────┴───────┐
                               │  Tarantool   │
                               │ (справочники,│
                               │  профили)    │
                               └──────────────┘

Событие клиента летит в Kafka, Flink обрабатывает в потоке, обогащает данными из in-memory хранилища, применяет бизнес-правила и возвращает решение. Красиво. На слайде. На практике каждый компонент преподнёс свой сюрприз, кроме Kafka — она единственная вела себя прилично.

Технология	Роль	Плюс	Риск
Flink	Stream processing	Exactly-once, stateful	Кадровый голод в РФ
Tarantool	In-memory хранилище	Latency < 1 ms	Молодое сообщество
Kafka	Транспорт	Надёжность, масштаб	Минимальный

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

Баг, который мы показали залу

Самая рискованная часть доклада — честный рассказ о провале. Мы показали, как нашли баг в Tarantool на нагрузочном тестировании. Как in-memory хранилище начинало деградировать под определённым паттерном конкурентных запросов. Как мы за выходные переписали критический путь.

До пивота:   Flink ──> Tarantool (< 1 ms)  ──> решение
После:       Flink ──> PostgreSQL + Kafka   ──> решение
                       (5-15 ms, зато стабильно)

Когда я показал этот слайд, в зале кто-то присвистнул. Latency выросла на порядок. Архитектура стала грязнее. Но мы получили предсказуемость.

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

Вопросы, которых мы не ждали

Готовясь к докладу, мы ожидали вопросов про Flink, партиционирование Kafka, maybe про Lua в Tarantool. Реальность удивила.

Первый вопрос из зала: «А как вы продали бизнесу пивот с Tarantool? Это же сдвиг сроков.» Не технический вопрос — управленческий. Отвечал я: честно рассказал, что показали бизнесу два варианта — ждать фикс с неопределёнными сроками или потерять в latency, но выйти в прод вовремя. Бизнес выбрал предсказуемость. Всегда выбирает.

Второй: «Четыре языка в одном проекте — как вы делаете code review?» Аврамов взял этот: рассказал, что ревьюер Scala-кода должен понимать, как этот код взаимодействует с Lua-процедурами в Tarantool. Cross-функциональность из модного слова превращается в ежедневную необходимость. Мы не нашли универсальных людей — мы вырастили их внутри команды.

Третий вопрос запомнился больше всего: «А вы бы сейчас снова выбрали Flink?» Я ответил — да, но с оговоркой. Flink — правильный инструмент для задачи. Проблема не в инструменте, а в том, что людей, которые умеют с ним работать, на российском рынке почти нет. Если ты не готов растить экспертизу внутри — не лезь.

Что я украл у других докладчиков

Конференция — это не только твой доклад. Это десятки чужих.

На одном из выступлений инженер из другой компании рассказывал, как они решили похожую задачу на Kafka Streams — без Flink. Проще, дешевле, меньше кадровых рисков. Latency выше, но в их SLA укладывались. Я сидел и думал: а мы могли бы так? Честно — нет. Наш SLA требовал другого уровня. Но вот что зацепило: их архитектура была на порядок проще в эксплуатации. Kafka Streams работает как библиотека внутри приложения — никакого отдельного кластера, никакого JobManager, никакого шаманства с checkpoint-ами. У нас на поддержку Flink-инфраструктуры уходило время целого инженера. У них — ноль, потому что инфраструктуры как отдельной сущности не было. Я тогда записал в блокнот: для следующего проекта с менее жёстким SLA — Kafka Streams, без обсуждений.

Другой доклад — про observability в event-driven системах. Автор показал подход к distributed tracing, который мы потом частично внедрили у себя. До конференции мы трейсили события «по старинке» — correlation ID через все сервисы. После — добавили span-ы и структурированную метрику на каждый этап обработки. Конкретно: раньше при инциденте инженер открывал Kibana, искал по correlation ID, собирал картину по логам из пяти сервисов вручную. После внедрения span-ов — открыл trace в Jaeger, увидел всю цепочку с таймингами. Время диагностики инцидентов сократилось втрое. Казалось бы, очевидная вещь. Но пока не увидишь, как это работает у другой команды на живом примере — откладываешь на «потом».

Это то, ради чего стоит ездить на конференции. Не ради бейджика «спикер», а ради того, чтобы посмотреть на свою систему чужими глазами.

Подготовка: два человека — двойная сложность

Совместный доклад звучит как «разделили работу пополам, стало проще». На практике — ровно наоборот. Сольный доклад ты репетируешь перед зеркалом. Совместный — синхронизируешь с живым человеком, у которого свой ритм, свои привычки, своё понимание тайминга.

Мы начали готовиться за два месяца. Первый прогон — катастрофа. Я говорю три минуты, передаю слово Аврамову, он говорит семь. Я пытаюсь вернуть темп — он ещё не закончил мысль. Суммарно — сорок пять минут вместо тридцати. На HighLoad++ тебе не дадут лишних пятнадцать минут. Тебя просто снимут со сцены.

После четвёртого прогона мы ввели жёсткий протокол: каждый блок — с таймером, переходы — по ключевым фразам. Я заканчиваю предложением, которое логически подводит к коду. Аврамов начинает с того, что показывает экран. Никаких «а ещё хочу добавить» — всё, что хочешь добавить, вписываешь в слайды до выступления. Шестой прогон вошёл в двадцать восемь минут. Седьмой — в тридцать ровно.

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

Что изменилось после доклада

Подготовка к выступлению заставила нас систематизировать то, что мы знали интуитивно. Когда ты рисуешь архитектуру для слайда — ты вдруг видишь места, где стрелочки идут не туда. Где компонент делает слишком много. Где нет fallback-а.

После конференции мы провели внутренний ретро по архитектуре. Три решения вышли из этого ретро. Первое — формализовали fallback-стратегию для каждого внешнего компонента. Если Tarantool лёг — система переключается на PostgreSQL автоматически, а не по звонку дежурного. Второе — переработали мониторинг: вместо алерта «Tarantool latency выросла» — алерт «Tarantool latency выросла, fallback активирован, бизнес-импакт: снижение конверсии на X%». Контекст вместо сырых цифр. Третье — запустили внутренний tech talk для смежных команд. Оказалось, что половина проблем на стыках — из-за того, что люди просто не знали, как работает соседний сервис.

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

Шрамы вместо слайдов

В enterprise нельзя ставить на единственную технологию без плана B. Какой бы классной она ни была на бенчмарках. И нельзя ставить на одного специалиста, который «всё знает». Знания должны быть в системе, а не в голове.

Если готовишь доклад — рассказывай правду. Залу не нужна твоя идеальная архитектура. Им нужны твои шрамы. Потому что у них свои, и они хотят знать, что не одни такие.

И ещё: если есть возможность выступить вдвоём — пробуй. Да, подготовка в два раза сложнее. Да, нужно синхронизироваться. Но зал получает два взгляда на одну систему — стратегический и тактический. А ты получаешь партнёра, который не даст тебе приукрасить на сцене. Потому что он был рядом, когда всё ломалось, и он знает, как было на самом деле.

По мотивам доклада на Saint HighLoad++ 2024, Санкт-Петербург.

Ваш ДПУПП

Tech Lead — новый вызов для аналитика

Fri, 15 Mar 2024 00:00:00 GMT

Октябрь 2023. Мне говорят: «Формируй команду с нуля — новое направление, конфигуратор персонализированных предложений». Несколько лет я рос на графовой платформе Mirion — от старшего аналитика до IT-лида, прошёл объединение команд прикладных сервисов Big Data. А теперь — чистый лист: ни людей, ни архитектуры, ни процессов. Первое, что я делаю — открываю рабочий мессенджер и пишу руководителю: «Принял. Начинаю нанимать». Второе — закрываю мессенджер и минут десять молча смотрю в монитор, осознавая, что весь мой аналитический опыт не подготовил меня к этому.

Я аналитик. Был аналитиком — с 2021 года рос в Иннотехе на графовой платформе, потом возглавил объединённую команду прикладных сервисов Big Data. А теперь мне надо собрать команду разработки нового продукта и возглавить её. На Analyst Days 2024 я рассказал эту историю — как аналитик стал IT-лидом, а потом руководителем кластера. Без прикрас.

Развилка, которую не видишь

Аналитик, который перерос уровень «напиши ТЗ» — что дальше? Я знаю минимум шесть направлений, и каждое ломает привычный образ мышления по-своему:

Направление	Фокус	Что качать
Product Manager	Рынок, метрики	Бизнес-стратегия, unit-экономика
Product Owner	Бэклог, приоритеты	Scrum, стейкхолдер-менеджмент
Tech Lead	Команда, архитектура	Код, CI/CD, people management
Архитектор	Системный дизайн	Интеграции, NFR, паттерны
Аккаунт-менеджер	Клиент, контракт	Переговоры, финансы
Консультант	Экспертиза, методология	Публичность, фреймворки

Большинство аналитиков даже не рассматривают техническую ветку. Кажется, что для этого нужен computer science за спиной и десять лет опыта в разработке. Это миф, и я — живое доказательство.

Почему именно Tech Lead

Мой путь был нелинейным. Я знал полный цикл разработки не из книжек, а из практики — сам автоматизировал, сам разворачивал, сам дебажил. Работал с данными в Nestlé, выстраивал data quality процессы в Kerama Marazzi, потом стал ведущим аналитиком в ВТБ. На каждом этапе залезал глубже, чем требовала должность: там, где аналитик обычно останавливается на диаграмме процесса, я шёл смотреть, что происходит в коде.

Аналитик видит продукт глазами бизнеса. Разработчик — глазами кода. Tech Lead должен видеть обоими одновременно. Если ты вырос из аналитики — бизнесовый глаз натренирован. Осталось прокачать технический. Это проще, чем разработчику учиться понимать бизнес, — я убедился на собственном опыте.

Строительство с нуля: пять месяцев боли

С октября по февраль — пять месяцев непрерывного найма. Десятки собеседований. Вот как это выглядело на практике.

Первые два кандидата — идеальные резюме. Senior-разработчики с опытом в enterprise. На собеседовании оба отвечали по учебнику. Я был в восторге, пока не задал один вопрос: «Расскажи про ситуацию, когда ты был не согласен с решением команды. Что делал?» Первый ответил: «Я делаю как скажут». Второй: «Я обычно работаю один, мне так продуктивнее». Оба были технически сильны. Обоим отказал.

Худшее собеседование — кандидат, который соврал про опыт с графовыми базами данных. Я это понял на третьей минуте технического вопроса, но провёл интервью до конца из вежливости. Потом час злился на себя за потраченное время. С тех пор ввёл правило: если за пять минут понимаю, что не подходит — честно говорю и заканчиваю. Уважение к чужому времени важнее социального комфорта.

Момент, когда команда «склеилась» — январь. К тому моменту собралось ядро из четырёх человек. Мы сели обсуждать архитектуру графовой платформы, и впервые за три месяца я почувствовал, что не вытягиваю процесс в одиночку. Люди спорили друг с другом, предлагали альтернативы, дополняли мысли. Не кивали, а думали. Это был тот момент, когда я понял: команда — есть.

Главный урок найма: собирать команду — не про «нанять лучших». Про «нанять тех, кто будут работать вместе». (Подробнее о паттернах, которые я научился видеть на собеседованиях — в red flags найма.) Звёздный разработчик, который не умеет коммуницировать, разрушит команду быстрее, чем создаст ценность.

Навыки, которых не было

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

CI/CD нюансы. Я знал, что pipeline существует, знал его этапы. Но когда разработчик приходит с вопросом, почему сборка падает на конкретном stage — нужно разбираться на уровне конфигурации. Не чинить самому, но понимать, что происходит — обязательно. Первый месяц я тратил вечера на изучение конфигов Jenkins и GitLab CI, чтобы на утренних стендапах не выглядеть идиотом.

Глубина code review. Просматривать pull request и реально ревьюить код — разные планеты. Первое время я пропускал архитектурные проблемы, замечая только стилистические — неправильные имена переменных, отсутствие комментариев. Серьёзные вещи — утечки абстракций, нарушения SOLID, неэффективные запросы — проходили мимо. Пришлось вырабатывать насмотренность: читать чужой код системно, задавать себе вопрос «а что будет, если нагрузка вырастет в десять раз?» на каждом merge request.

Оценка задач. Аналитик оценивает свою работу — одна переменная. Лидер оценивает работу команды — система уравнений. Зависимости, параллельность, риски, технический долг. Мои первые оценки были чудовищно неточными. На одну задачу я заложил неделю — заняла три. На другую — три дня, делали две недели. Со временем выработал подход:

Декомпозируй до задач не крупнее трёх дней — на этом уровне ошибка предсказуема
Добавь буфер 20-30% на интеграционные сюрпризы
Учти «невидимые» задачи: code review, деплой, согласования, больничные
Проверяй оценку с тем, кто будет делать — лидер всегда оценивает хуже исполнителя

Умение говорить «нет»

Это заслуживает отдельного раздела, потому что «нет» — самый недооценённый навык руководителя.

Конкретный случай. Бизнес приходит с задачей: нужен новый отчёт в системе принятия решений. Срочно. «К пятнице». Сейчас вторник. Я смотрю на бэклог — команда загружена на спринт вперёд, один разработчик на больничном. Прежний я, аналитик-угодник, сказал бы «попробуем». Новый я говорит: «Нет. Если вставим это в текущий спринт, сдвинем релиз платформы на две недели. Давай обсудим: этот отчёт важнее релиза?»

Заказчик, конечно, не обрадовался. Но когда я показал зависимости на доске — конкретные задачи, которые придётся подвинуть, конкретные риски — разговор перешёл в конструктивное русло. Отчёт ушёл в следующий спринт. Релиз вышел вовремя. А заказчик с тех пор приходил не с «надо к пятнице», а с «какие у вас ближайшие окна?»

Каждое «да» без оценки последствий — это долг, который копится. Команда сгорает, качество падает, технический долг растёт. Лидер, который не умеет говорить «нет» — не лидер, а буфер между бизнесом и командой. Причём буфер одноразовый.

Удержание: как не потерять тех, кого собирал пять месяцев

Когда рынок штормит, конкуренты переманивают, а корпоративные процессы давят — удержать ключевых людей становится задачей номер один. Терять их после пяти месяцев найма — немыслимо.

Первое, что сработало — матрица компетенций. Не формальная табличка для HR, а рабочий инструмент, который мы обсуждали на каждом one-on-one:

Компетенция        │ Текущий │ Целевой │ Как прокачать
───────────────────┼─────────┼─────────┼──────────────────
System Design      │  ██░░░  │  ████░  │ Архитектурные ревью
Kafka/Streaming    │  ███░░  │  ████░  │ Задача X в спринте
SQL оптимизация    │  ████░  │  ████░  │ Поддерживать
Менторинг          │  █░░░░  │  ███░░  │ Онбординг новичка

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

Второе — прозрачность. Я не скрывал от команды сложности проекта. Когда люди понимают контекст решений — они принимают трудности как часть работы, а не как произвол начальства. «Мы берём эту задачу, потому что без неё не пройдём аудит» звучит иначе, чем «берём, потому что я так решил».

Третье — ротация задач. Разработчик, который полгода пилил только ETL, получает задачу на API. Медленнее в моменте, но удерживает интерес и расширяет экспертизу. Человек, которому скучно — уже одной ногой на собеседовании в другой компании.

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

Карьерный парадокс

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

Разница — в масштабе:

Навык	Аналитик	Tech Lead
Декомпозиция	Требования и user stories	Стратегия и roadmap
Вопросы	Стейкхолдерам	Себе и команде
Системный взгляд	Продукт	Люди + процессы + технологии
Коммуникация	Бизнес ↔ Разработка	Команда ↔ Руководство ↔ Бизнес
Ответственность	За документ	За результат команды

Что бы я сделал иначе

Если бы я мог вернуться в тот октябрь и дать себе три совета:

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

Проси помощи раньше. Первые два месяца я пытался разобраться во всём сам — CI/CD, архитектура, процессы. Из гордости. Пока не понял, что спросить совета у коллеги-тимлида — это не слабость, а нормальный рабочий инструмент.

Не бросай техническую практику. Когда погружаешься в управление, руки перестают писать код. А потом на code review ты не можешь дать полноценный фидбэк, потому что отстал от стека. Нужно находить время на технические задачи, даже если это два часа в неделю.

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

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

Если ты сам на пути от аналитика к тех-лиду и хочешь ускорить рост — я провожу менторинг именно для таких переходов.

По мотивам несостоявшегося доклада на Analyst Days 2024 — заявка была принята, но выступление не случилось из-за отсутствия времени на подготовку. Материал написан по итогам того же опыта.

Ваш ДПУПП

IT-конференции для аналитиков: гайд практика

Mon, 22 Jan 2024 00:00:00 GMT

Ноябрь 2021. HighLoad++ в Москве. Я стою в очереди за кофе между секциями и случайно начинаю разговор с мужиком в чёрной толстовке. Обсуждаем event sourcing — он рассказывает, как его команда обожглась на eventual consistency в платёжной системе, я — как мы строили data-платформу в банке. Через двадцать минут мы сидим на подоконнике, рисуем архитектурные схемы на салфетке. Через три месяца этот разговор приводит к тому, что меня рекомендуют на роль, которая определила следующие три года карьеры.

Я не планировал нетворкинг. Не готовил elevator pitch. Просто стоял в очереди за капучино.

С тех пор я выступал на HighLoad++, Analyst Days, Инфостарте, ЛАФ, Saint HighLoad++ и ещё нескольких площадках. Руковожу сообществом аналитиков, которое выросло до более чем двух тысяч человек. И могу ответственно сказать: конференции изменили мою карьеру сильнее, чем все курсы и сертификации вместе взятые.

Зачем на самом деле ходить на конференции

Когда я впервые пошёл на конференцию, я думал, что главная ценность — в докладах. Пришёл, послушал, записал тезисы, ушёл. Как YouTube, только офлайн и дороже. Я ошибался. Контент ты найдёшь в записях. Конференция — это среда, в которой происходят вещи, невозможные в других форматах.

Скрытый рынок труда

Лучшие позиции не появляются на HeadHunter. Они заполняются через рекомендации. Когда руководитель ищет лида, он сначала спрашивает окружение: «Знаешь кого-нибудь?» Конференции — место, где формируется это окружение. Я лично знаю людей, которые получили ключевые карьерные позиции через конференционные знакомства. Один из них — я сам, с тем разговором за кофе.

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

Тренды — из вопросов, не из слайдов

Доклад расскажет про технологию. Вопросы из зала расскажут, какие проблемы реально волнуют индустрию. Когда на трёх разных конференциях в вопросах звучит одна тема — это тренд. Не из Gartner Hype Cycle, а из практики.

На конференциях последних лет повторяющаяся тема — переход от batch к realtime в enterprise. Два года назад спрашивали единицы. Потом — каждый второй. Это говорит мне больше, чем любой аналитический отчёт. Я строю системы реального времени — и знаю, что тренд реальный, потому что слышу одни и те же боли от разных компаний.

Постмортемы дороже мастер-классов

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

Доклады формата «мы внедрили ML и конверсия выросла на 40%» — красивые, но бесполезные. Ты не знаешь контекст, не знаешь, сколько раз до этого модель не взлетела. А вот «мы три месяца строили ML-модель, она оказалась хуже эвристики, и вот почему» — это реальная ценность.

Синдром самозванца — лечится живым контактом

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

Когда после доклада подходят несколько человек и говорят «у нас точно такая же проблема, как вы решили?» — это лучшее лекарство. Оказывается, твой опыт — не банальный. Он реально кому-то нужен.

Личный бренд строится не в соцсетях

Ты не станешь известным после первого доклада. Но ты станешь «тем парнем, который рассказывал про NER в банке» для тридцати человек. В следующий раз — для ста. Через год тебя узнают. Через два — приглашают. Личный бренд в IT — не подписчики, а репутация среди тех, чьё мнение имеет значение. Конференции — стартовая площадка.

Карта конференций: куда идти

За годы участия и организации я собрал свою карту площадок. Вот субъективная оценка — из зала и из-за кулис.

Конференция	Масштаб	Качество докладов	Нетворкинг	Для кого
HighLoad++	3000+	Высокое, строгий отбор	Отличный	Архитекторы, техлиды, senior
Analyst Days	500-800	Высокое, специализированное	Хороший	Аналитики всех уровней
TeamLead Conf	1000+	Хорошее	Отличный	Тимлиды, руководители
Saint HighLoad++	1500+	Высокое	Хороший	Тот же профиль, питерская аудитория
Инфостарт	1000+	Среднее, но сильные управленческие треки	Хороший	1С-экосистема + менеджеры
ЛАФ	200-300	Хорошее, нишевое	Отличный (камерность)	Лидеры и аналитики в финансах
PyCon Russia	500+	Хорошее	Хороший	Python-разработчики
Митапы / локальные	30-50	Разное	Лучший для старта	Начинающие спикеры

Крупные мультиформатные — HighLoad++, Analyst Days, TeamLead Conf. Строгий отбор программного комитета. Если хочешь выступить — готовь заявку за три-четыре месяца, и будь готов к трём раундам правок.

Нишевые — Инфостарт, ЛАФ, PyCon. Меньше масштаб, но глубже погружение в тему. Проще попасть в программу как спикер. Именно здесь я набивал первый опыт выступлений — аудитория лояльнее, обратная связь конкретнее.

Митапы — часто недооценены, но это идеальная тренировочная площадка. Тридцать человек, доброжелательная атмосфера, вопросы после доклада. Если тебе страшно выступить на большой конференции — начни с митапа. Через два-три выступления страх уходит.

Как выжать максимум

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

До. Изучи программу. Выбери три-четыре доклада, которые реально релевантны твоей работе. Посмотри, кто из спикеров интересен — можно написать заранее в Telegram и договориться о встрече. Серьёзно — спикеры обычно рады, когда к ним приходят с конкретным вопросом, а не с «расскажите что-нибудь интересное».

Во время. Чередуй секции с кулуарным общением. Самые ценные разговоры происходят у стендов с кофе, не в залах. Записывай не тезисы доклада — они будут в записях — а свои мысли: что применимо к проекту, с кем поговорить, что попробовать в понедельник.

После. В течение суток напиши всем, с кем обменялся контактами. Не «было приятно», а конкретику: «Обсуждали ваш подход к event sourcing, хочу попробовать у нас, можно будет спросить совета?» Конкретика конвертирует случайное знакомство в рабочий контакт. Абстрактная вежливость — нет.

Сообщество > конференция

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

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

Конкретный пример. Вечер пятницы, аналитик из финтеха пишет в чат: «Ребята, у нас интеграция с внешним сервисом через SOAP, документация на китайском, дедлайн в понедельник. Кто-нибудь парсил WSDL от китайских платёжных систем?» Через двадцать минут откликаются трое. Один кидает свой парсер. Другой — контакт человека, который делал похожую интеграцию год назад. Третий — ссылку на репозиторий с примерами. В понедельник интеграция работает. Попробуй получить такую помощь на StackOverflow в пятницу вечером по московскому времени. А в сообществе, где все друг друга знают хотя бы по никам — это рабочая ситуация.

Ещё один случай: через сообщество человек нашёл работу. Не через вакансию — через обсуждение. Он несколько месяцев отвечал на вопросы про процессную аналитику, давал развёрнутые ответы, делился шаблонами документации. Когда в одной из компаний открылась позиция лида аналитиков — его порекомендовали трое участников чата, не сговариваясь. Потому что все видели его экспертизу в деле, а не в резюме.

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

Военная история: когда доклад идёт не по плану

На одной из нишевых конференций у меня произошло то, чего боится каждый спикер. Показываю слайд с архитектурой — и из зала встаёт человек. Не вопрос задаёт — а заявляет: «Это неправильная архитектура. Мы делали похоже и у нас всё упало.» Зал притих. Двести пар глаз на мне.

Первый импульс — защищаться. Второй — который пришёл через секунду — принять. Я сказал: «Расскажи, что упало и при каких условиях.» Он рассказал. Оказалось, у них была другая нагрузка, другие SLA, другая инфраструктура. Его опыт был валидным — для его контекста. Мой — для моего. Мы десять минут обсуждали различия прямо в зале. Модератор нервничал, тайминг поехал, но аудитория была вовлечена так, как не бывает при обычном формате «слайды-вопросы».

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

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

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

Оригинал статьи: IT-конференции для аналитиков на Habr

Ваш ДПУПП

Импульс 2023: Синергия сообществ — повышаем результативность IT-команд

Wed, 15 Nov 2023 00:00:00 GMT

Три команды, одна библиотека, ноль общения

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

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

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

На конференции Импульс 2023 я рассказал, как мы это сделали. Здесь — расширенная версия.

Парадокс масштаба: больше людей — меньше толку

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

В стартапе из пяти человек ты — 20% компании. В корпорации из пяти тысяч — статистическая погрешность. И это порождает три боли, которые я слышу от разработчиков и аналитиков постоянно.

«Меня не замечают». Ты сделал крутую штуку, но за пределами команды об этом знает ноль человек. Признание ограничено ежегодным ревью, где менеджер ставит оценку по шаблону.

«Мои результаты ничего не значат». Ты закрыл спринт, выкатил фичу, оптимизировал процесс. На уровне компании — незаметно. Корпоративная машина перемалывает индивидуальный вклад в безликие метрики.

«Я не знаю, что делают соседние команды». Тот самый случай с тремя библиотеками. Соседи решают ту же задачу. Другая команда наступала на те же грабли полгода назад. Но горизонтальных связей нет — только вертикаль через руководство, которое тоже не в курсе деталей.

Корень один: отсутствие горизонтальных коммуникаций.

Как гильдии получили зелёный свет

Идея не нова — Spotify описал guilds и chapters ещё в начале 2010-х. Но между «прочитать статью про гильдии» и «запустить их в компании с тысячами сотрудников» — пропасть.

Мне повезло с контекстом. Проект техно-гильдий стартовал под менторством CTO T1 Group — в рамках кластера, который я строил с нуля. Не «я предложил, и все согласились» — нет. Я пришёл к CTO с конкретными цифрами: вот три команды, вот дублирование, вот потерянные человеко-месяцы. Вот аналогичные кейсы по другим технологиям. Вот план, как это исправить системно, а не точечно.

CTO дал добро и, что важнее, дал политическое прикрытие. Потому что без поддержки сверху любая горизонтальная инициатива умирает на второй неделе — когда участникам говорят «у тебя спринт горит, какие гильдии?».

Три формата: от стандартов к делу

Мы выделили три формата горизонтальных связей — каждый со своей ролью.

Формат	Формализация	Что делает	Пример
Компетентностный центр	Высокая	Задаёт стандарты и best practices	«Все API документируем в OpenAPI 3.0»
Сообщество	Средняя	Горизонтальный обмен знаниями	Митап по Kafka: кто какие грабли нашёл
Техно-гильдия	Практическая	Конкретные задачи, измеримый результат	Общая библиотека интеграции за 2 недели

Три формата не конкурируют, а дополняют друг друга. Компетентностный центр определяет «что правильно». Сообщество обсуждает «как применить». Гильдия берёт и делает.

Какие гильдии мы построили

За полгода мы запустили гильдии по ключевым технологиям и практикам. Не абстрактные «клубы по интересам», а рабочие группы с конкретными задачами.

Гильдия	Фокус	Первый результат
AirFlow	Оркестрация ETL/ELT процессов	Общие DAG-шаблоны, единый подход к мониторингу
Camunda	BPM и автоматизация процессов	Библиотека переиспользуемых воркеров
Kafka	Потоковая обработка данных	Стандарты схем сообщений, конвенции именования топиков
PostgreSQL	Базы данных, оптимизация	Гайд по индексации, чеклист ревью миграций
Backend-разработка	Архитектурные паттерны, код-стандарты	Та самая общая библиотека интеграции
Аналитика	Стандарты документации, data quality	Единые шаблоны ТЗ, сокращение возвратов на 30%

Каждая гильдия — это 5-15 человек из разных команд, которые встречаются раз в две недели на полтора часа. Не «поговорить о высоком», а решить конкретную задачу. С первой встречи — артефакт на выходе.

Гильдия по Kafka, например, начала с того, что собрала в одном месте все грабли, на которые наступили разные команды при работе с Kafka в продакшене — включая опыт нашей realtime-платформы. Получился документ на 20 страниц — я не шучу. Двадцать страниц боли, каждая из которых кому-то стоила ночного дежурства.

Шестизначный эффект за пять месяцев

Как считали? Конкретными кейсами.

Гильдия backend-разработчиков: три команды объединили усилия по библиотеке интеграции. Минус два человеко-месяца дублирования. Гильдия аналитиков: стандартизировали шаблоны документации, время на онбординг новых аналитиков сократилось, количество возвратов ТЗ упало. Гильдия PostgreSQL: общий гайд по индексации предотвратил минимум два инцидента с производительностью, которые в прошлом квартале стоили команде ночных дежурств и хотфиксов.

Прямая экономия измерялась в процентах от бюджета с суммой, превышающей шесть нулей — и это при затратах, которые были на порядки меньше. А есть ещё вещи, которые в рубли перевести сложнее, но которые стоят дороже.

Бизнес-эффекты, которые не посчитаешь в рублях

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

У нас двое участников гильдий получили повышение в течение полугода. Не потому что «участвовал в гильдии» — а потому что гильдия сделала их достижения видимыми.

Конвейер компетенций. Новый сотрудник подключается к гильдии и получает доступ к накопленным знаниям: записям встреч, решённым кейсам, экспертам, которые готовы ответить. Знания не теряются при увольнении ключевых людей — они зафиксированы в артефактах гильдии.

Стандарты снизу. Стандарты, навязанные сверху, саботируются. Это аксиома. Когда гильдия сама договаривается о code style, подходе к тестированию, формате документации — люди следуют этим договорённостям, потому что сами их создали. Разница между «мне сказали делать так» и «мы решили делать так» — огромна.

Диагностика: когда сообщество умирает

Не всякое сообщество приживается. Я видел достаточно мёртвых чатов с надписью «Гильдия по X», чтобы составить диагностическую таблицу.

Экспресс-тест: два и более симптома — сообщество в зоне риска.

Симптом	Причина	Лечение
Люди уходят после 3-й встречи	Нет конкретных задач, только «обсуждение»	Каждая встреча = артефакт на выходе
Приходят одни и те же 3 человека	Нет поддержки руководства	Явное выделение времени в спринте
Чат есть, активности нет	Создано для галочки руководителем	Переформулировать KPI с «запустить» на «результат»
Обсуждения без решений	Нет фасилитатора с полномочиями	Назначить лидера гильдии, дать ему право принимать решения
Участники молчат на встречах	Страх критики или политика	Ввести правило: первые 3 встречи — без руководителей
Результаты не доходят до команд	Нет процесса распространения	Лидер гильдии презентует итоги на командных стендапах

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

Как запустить гильдию: проверенный чеклист

Если хочешь попробовать у себя — вот минимум, который работает. Проверено на реальных людях в реальной корпорации.

Найди боль, а не тему. Не «давайте сделаем гильдию по Kotlin», а «три команды пишут одинаковые интеграции — давайте объединим усилия». Боль — мотиватор. Тема — нет.
Собери ядро: 3-5 активных людей. Не нужны десятки. Нужны люди, которые будут генерировать повестку и делать работу между встречами.
Договорись с руководством. Два часа в неделю на участника. Без явного согласования люди будут выбирать спринт — и будут правы.
Первая встреча = конкретная задача. Не «познакомимся и обсудим формат», а «сделаем общий шаблон для X». Артефакт в конце первой встречи — это сигнал: здесь не болтают, здесь делают.
Измеряй и показывай. Сэкономленные часы, объединённые библиотеки, стандартизированные подходы. Покажи цифры через месяц. Руководству — чтобы не закрыли. Участникам — чтобы видели смысл.
Не бойся закрывать. Если гильдия решила свою задачу — закрой её. Лучше три живых гильдии, чем десять зомби-чатов.

Самое сложное — не запустить, а не убить

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

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

Отдельная головная боль — ротация участников. Человек, который был движущей силой гильдии по Kafka, уходит в другую компанию. И выясняется, что вся энергия группы держалась на одном энтузиасте. Встречи продолжаются по инерции ещё два-три раза, потом превращаются в формальность, потом тихо умирают. Мы наступали на эти грабли дважды, пока не ввели правило: у каждой гильдии — минимум два со-лидера, и каждые три месяца один из них ротируется. Это не элегантно, это бюрократия. Но бюрократия, которая спасает живое сообщество от смерти при потере одного человека.

Сообщество — это не событие, а процесс. Кто готов к процессу — получит результаты. Кто ждёт, что оно «само заработает» — получит ещё один мёртвый чат в корпоративном мессенджере. А три команды в соседних кабинетах продолжат писать одну и ту же библиотеку.

По мотивам доклада на Импульс 2023 (внутренняя конференция T1).

Ваш ДПУПП

API от А до Я: теория и практика

Fri, 20 Oct 2023 00:00:00 GMT

Спецификация, которая чуть не убила интеграцию

Осень 2021-го. Новый проект — и в первые же дни мне дают на ревью API-спецификацию от смежной команды. Открываю Swagger-файл. Все эндпоинты — POST. Все. Включая получение данных клиента, включая проверку статуса, включая удаление. POST /api/client/get, POST /api/client/delete, POST /api/client/getStatus. Статус-коды: 200 на всё, включая ошибки — ошибка кладётся в body как JSON-поле "error": "not found". Версионирования нет. Пагинации нет. На вопрос «а где документация по полям?» — ссылка на Excel-файл в шаре, датированный прошлым годом.

Я не преувеличиваю. Это не худший API, который я видел в enterprise. Это средний. И когда я начал преподавать курс по системному анализу, я понял почему — людей просто не учат проектировать API. Учат слово «REST», но не объясняют, что за ним стоит.

Протоколы: таблица вместо тысячи слов

Прежде чем разбирать ошибки — карта территории. Потому что «API» — это не только REST, и выбор протокола определяет всё остальное.

Критерий	REST	SOAP	GraphQL	JSON-RPC	gRPC
Формат данных	JSON (обычно)	XML (строго)	JSON	JSON	Protobuf (бинарный)
Транспорт	HTTP	HTTP, SMTP, JMS	HTTP	HTTP, WebSocket	HTTP/2
Контракт	OpenAPI/Swagger	WSDL	Schema + SDL	JSON Schema	.proto файлы
Типизация	Слабая	Строгая	Строгая	Слабая	Строгая
Кеширование	HTTP-кеш из коробки	Нет	Сложно (один URL)	Нет	Нет
Стриминг	SSE, WebSocket отдельно	Нет	Subscriptions	Нет	Bidirectional
Порог входа	Низкий	Высокий	Средний	Низкий	Средний
Где живёт	Везде	Enterprise, госы, банки	Фронтенд-тяжёлые приложения	Внутренние вызовы	Межсервисное взаимодействие

В банке ты встретишь всё. Один интеграционный слой может общаться с SOAP-сервисами ядра АБС, REST API для мобильного приложения, gRPC между собственными микросервисами и JSON-RPC для внутренних утилит. Идея «давайте всё переведём на REST» разбивается о реальность: ядро АБС переписывать никто не будет.

REST: что на самом деле имел в виду Филдинг

REST — не протокол. Это архитектурный стиль. И большинство «REST API» в продакшене — не REST, а HTTP API с JSON. Разница принципиальна.

Настоящий REST подразумевает statelessness (сервер не хранит сессию), единообразный интерфейс через HTTP-методы, адресацию ресурсов через URI, и HATEOAS (гипермедиа как движок состояния приложения). Последний пункт не реализует почти никто, и это нормально — для большинства задач он избыточен.

HTTP-методы — вот где начинается веселье. GET — получить, идемпотентный. POST — создать, не идемпотентный. PUT — заменить целиком, идемпотентный. PATCH — обновить частично. DELETE — удалить, идемпотентный. Каждый несёт семантику, и эта семантика — не декорация. Прокси, кеши, мониторинг — все полагаются на правильное использование методов. Когда ты делаешь POST /getUser, ты ломаешь не только эстетику, ты ломаешь инфраструктуру.

Статус-коды — вторая боевая зона. 200 (ок), 201 (создано), 204 (ок, без тела), 400 (клиент ошибся), 401 (не авторизован), 403 (нет прав), 404 (не найдено), 409 (конфликт), 500 (сервер умер). Возвращать 200 на ошибку с описанием в body — значит превратить HTTP в тупой транспорт и убить всю семантическую инфраструктуру, которую тебе дали бесплатно.

SOAP: динозавр, который переживёт нас всех

В стартапах SOAP — мем. В банке — суровая реальность. WSDL-описание контракта, envelope-header-body структура, WS-Security для шифрования и подписи, WS-ReliableMessaging для гарантированной доставки. Строгая типизация через XSD-схемы.

Я работал с интеграциями, где SOAP-сервис ядра АБС не менялся годами — и все новые системы были обязаны подстроиться. Менять сервис, обслуживающий миллионы транзакций в день, потому что «REST моднее» — идея, от которой бизнес справедливо шарахается.

Когда выбирать SOAP: строгая типизация контрактов критична, нужна транзакционность и гарантия доставки, интеграция идёт с системами, которые говорят только на SOAP. В банке третий пункт перекрывает все остальные.

GraphQL и JSON-RPC: нишевые, но полезные

GraphQL решает реальную проблему: мобильному клиенту нужны три поля из объекта, а REST возвращает пятьдесят. Один endpoint, клиент контролирует структуру ответа, встроенная типизация через schema. Но сложность переезжает на сервер, кеширование через одинаковые POST-запросы — боль, а глубоко вложенные запросы могут положить базу.

JSON-RPC — когда взаимодействие описывается как «вызвать функцию с параметрами», а не «операция над ресурсом». Внутренние сервисные вызовы, утилиты, всё, что не ложится на ресурсную модель REST.

gRPC: когда миллисекунды решают

gRPC стоит в таблице, но заслуживает отдельного абзаца — потому что в микросервисной архитектуре он всё чаще становится стандартом де-факто. Protobuf вместо JSON — бинарная сериализация, строгая типизация через .proto-файлы, HTTP/2 с мультиплексированием и двунаправленным стримингом. На нашем банковском проекте (подробнее о realtime-архитектуре) gRPC использовался для связи между scoring-сервисом и движком решений: там, где REST давал 15-20 мс на вызов, gRPC укладывался в 2-3 мс. При тысячах вызовов в секунду разница между «работает» и «не укладывается в SLA».

Цена входа — генерация клиентов и серверов из .proto, отсутствие человекочитаемого формата (забудь про curl для дебага), и необходимость gRPC-gateway, если нужен доступ из браузера. Но для межсервисного взаимодействия внутри периметра — лучшего варианта я пока не встречал.

Как я выбираю протокол

Четыре вопроса, которые экономят недели споров:

Кто потребитель? Внешний партнёр — REST, потому что его поймут все. Внутренний сервис с жёсткими требованиями к контракту — SOAP или gRPC. Мобилка с десятком разных экранов — GraphQL.

Что диктует ландшафт? Если корпоративный ESB работает на SOAP, добавлять GraphQL ради одного сервиса — безумие. Если все микросервисы на gRPC — REST-сервис будет выглядеть как чужак.

Кто будет поддерживать? REST — проще найти людей. GraphQL — нужна экспертиза. SOAP — нужны люди, которые не боятся XML и умеют читать XSD.

Какие требования к надёжности? Нужна транзакционность — SOAP. Допустимы retry и eventual consistency — REST.

Однажды эти четыре вопроса спасли меня от месяца бессмысленной работы. Команда фронтенда пришла с запросом: «Нам нужен GraphQL, мы устали тянуть лишние поля». Я задал первый вопрос — кто потребитель? Оказалось, у сервиса ровно два клиента: мобилка и внутренний бэк-офис. Оба потребляли по три эндпоинта. Выигрыш от GraphQL — ноль, а стоимость поддержки schema, резолверов и N+1-проблем — вполне реальная. Мы добавили два query-параметра для выбора полей в существующий REST и закрыли вопрос за день. GraphQL — отличная технология, но для двух потребителей с тремя запросами это как арендовать фуру, чтобы отвезти пакет молока из магазина.

Пять API-ошибок, которые я встречаю в каждом проекте

1. Глаголы в URL

/getUsers, /createOrder, /deleteAccount. HTTP-метод уже содержит глагол. GET /users = «получить пользователей». POST /orders = «создать заказ». Когда я вижу POST /createUser — я знаю, что проектировщик скопировал URL из какого-то туториала 2010 года.

В нашем проекте мы ловили это на ревью. Один из разработчиков сделал POST /calculateRisk — и формально это не ресурсная операция, это процедура. Мы долго спорили. В итоге решили: POST /risk-assessments — создаёшь объект «оценка риска», и это ложится на ресурсную модель. Но спор был полезный — он показал, что REST не для всех задач.

2. Всё через POST

Та самая спецификация из начала статьи. POST на чтение, POST на удаление, POST на всё. Почему так делают? Потому что «POST точно работает через все прокси» и «не хочу разбираться в идемпотентности». Ленивое решение, которое аукается на каждом следующем этапе: нельзя кешировать GET-запросы, нельзя безопасно ретраить, нельзя отличить чтение от записи в мониторинге.

3. 200 OK на ошибки

{
  "status": 200,
  "error": true,
  "message": "User not found"
}

Я видел это в продакшене крупного банка. API Gateway честно проксирует ответ, мониторинг видит 200, алертов нет. А клиент не получает данные. Мы неделю искали, почему у аналитической витрины пропадают данные — оказалось, upstream-сервис возвращает 200 с ошибкой в body, и наш ETL-процесс считает это успехом.

4. Нет версионирования

/api/users вместо /api/v1/users. Первые полгода всё хорошо. Потом бизнес просит добавить поле, которое ломает обратную совместимость. И начинается: либо ломаем всех потребителей разом, либо вводим хаки с optional-полями и conditions в документации. В банковской системе, где к одному API могут ходить десятки потребителей — это не теоретическая проблема, а инцидент на проде.

5. Нет пагинации

Endpoint, который возвращает все записи. На тестовом стенде их сто — работает. В продакшене — миллион. Один неудачный запрос — и сервис лежит под OOM. У нас это случилось с эндпоинтом выгрузки операций клиента. Разработчик добавлял его «на потом, пагинацию прикрутим позже». «Позже» наступило в виде инцидента в три часа ночи.

Бонус: практика на Telegram-боте

В курсе по системному анализу я даю задание: построить Telegram-бота на Flask. Telegram Bot API — отлично документированный REST API. Flask принимает webhook (POST с JSON), парсит сообщение, обрабатывает команду, отправляет ответ через api.telegram.org.

Один проект — и студенты на практике осваивают HTTP-методы, JSON-сериализацию, вебхуки, аутентификацию через токен, обработку ошибок. Теория API перестаёт быть абстракцией, потому что бот либо работает, либо нет. Никакого «ну, в принципе правильно».

Зачем тебе это знать

У меня был джуниор-аналитик, который пришёл согласовывать интеграцию с внешним партнёром. Партнёр прислал Swagger-спецификацию. Парень открыл файл, посмотрел на стену эндпоинтов и честно сказал: «Я не понимаю, что здесь написано». Не потому что глупый — он был толковый. Просто никто никогда не объяснял ему, что такое path parameter, чем отличается 201 от 200, зачем нужен Bearer-токен в заголовке и почему поле nullable: true в схеме ответа — это не мелочь, а архитектурное решение.

Он провёл встречу с партнёром и согласовал интеграцию «на словах». Без вопросов про формат дат, без уточнений по пагинации, без обсуждения поведения при таймаутах. Через два месяца, когда дошло до разработки, выяснилось, что половина договорённостей не совпадает с тем, что написано в спеке. Ещё месяц на пересогласование. Классика.

Если ты аналитик — умение читать API-спецификацию не опционально. Это как умение читать чертежи для инженера. Без этого ты не проектируешь интеграцию, а играешь в испорченный телефон между бизнесом и разработкой.

Оригинал статьи: API от А до Я на Habr

Ваш ДПУПП

NER-сервисы в бизнесе: от теории к практике

Tue, 26 Sep 2023 00:00:00 GMT

«Переведите мне менеджера»

Простое предложение. Шесть слов. И NER-система должна понять: это «переведите деньги» или «переключите на менеджера»? «Менеджер» — это имя, должность или тип операции? Контекст решает. Но контекст — это именно то, что машине даётся хуже всего.

Клиент пишет в чат банка: «Здравствуйте, меня зовут Алексей Петров, хочу перевести 50 000 рублей на счёт жены». Четыре сущности для обработки: имя, сумма, валюта, тип операции. Оператор call-центра извлекает их интуитивно. Но оператор обрабатывает один запрос за раз, устаёт, ошибается, уходит на обед. При тысячах обращений в час ручная обработка не масштабируется.

Named Entity Recognition — автоматическое извлечение структурированных сущностей из неструктурированного текста. В банковском контексте это не академическое упражнение. Это разница между операторами, которые вбивают данные руками, и системой, которая предзаполняет карточку обращения за миллисекунды.

Почему это сложнее, чем кажется

На первый взгляд — задача для регулярного выражения. На второй — нет.

Имена. «Алексей Петров» — просто. «А. Петров» — уже сложнее. «Передайте Петрову» — нужна лемматизация. «Мне Лёша звонил по поводу перевода» — нужно понять, что «Лёша» — имя. «петров алексей» в нижнем регистре без пунктуации — регулярка сдаётся.

Суммы. «50 000 рублей» — очевидно. «Пятьдесят тысяч» — конвертация числительных. «Полтинник» — сленг. «50к» — интернет-формат. «Пятьдесят тысяч рэ» — комбинация. Каждый вариант — отдельный паттерн, и их бесконечно много.

Валюты. «Рублей», «руб.», «рэ», «деревянных» — один и тот же рубль. Плюс мультивалютность в одном предложении.

Интенты. «Хочу перевести», «скиньте на карту», «закинуть на счёт» — transfer. «Переведите мне менеджера» — routing. Без контекста не отличишь.

Три подхода: сравнение

Критерий	Rule-based	ML-модели	Гибридный
Precision	Высокая (на известных паттернах)	Средняя-высокая	Высокая
Recall	Низкий (только явные паттерны)	Высокий	Высокий
Время разработки	Дни	Недели-месяцы	Недели
Нужны размеченные данные	Нет	Да, много	Частично
Поддержка	Правила растут, конфликтуют	Переобучение модели	Правила + переобучение
Отладка	Прозрачная	Чёрный ящик	Частично прозрачная
Устойчивость к новым форматам	Низкая	Высокая	Средняя-высокая

Rule-based: быстрый старт, медленная смерть

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

Но через полгода система правил превращается в монстра. Новый формат ввода — новое правило. Правила конфликтуют. Изменение одного ломает три других. У нас был набор из нескольких сотен правил для извлечения сумм — и каждый новый edge case добавлял хрупкости.

ML: мощно, но дорого

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

Проблемы: нужны размеченные данные, и много. В банке это означает работу с персональными данными — compliance-ад. Модель — чёрный ящик: когда она ошибается, понять причину и объяснить бизнесу «почему» — задача нетривиальная. И нужна инфраструктура для обучения и inference.

Гибридный: то, что работает в продакшене

Правила обрабатывают очевидные случаи с высокой точностью. ML подхватывает остальное. Pipeline: текст проходит rule-based модуль, извлекает сущности с высокой confidence. Нераспознанное уходит в ML-модель. На выходе — объединённый результат с приоритизацией по confidence score.

Именно этот подход мы использовали. Начали с правил — получили быстрый результат и базовую точность. По мере накопления размеченных данных подключили ML.

Python-стек для русского NER

Экосистема NER-инструментов для русского языка зрелая. Вот что мы использовали.

spaCy — фреймворк для NLP. Токенизация, лемматизация, POS-tagging, базовый NER из коробки. Модель ru_core_news_sm — отправная точка, но для банковской специфики нужна дообучка.

import spacy

nlp = spacy.load("ru_core_news_sm")
doc = nlp("Алексей Петров хочет перевести 50000 рублей")

for ent in doc.ents:
    print(f"{ent.text} -> {ent.label_}")
# Алексей Петров -> PER
# 50000 рублей -> MONEY

Базовый пример работает. Но «Лёша хочет скинуть полтинник» — уже нет. Тут нужна дообучка или гибридный подход.

pymystem3 — обёртка для Mystem от Яндекса. Лучший морфологический анализатор для русского языка по моему опыту. Когда нужно понять, что «Петрову» — дательный падеж от «Петров»:

from pymystem3 import Mystem

m = Mystem()
lemmas = m.lemmatize("Передайте Петрову документы")
# ['передавать', ' ', 'петров', ' ', 'документ', '\n']

pymorphy2 — морфологический анализатор для нормализации словоформ. Приведение к начальной форме, определение рода, числа, падежа. Работает в связке со spaCy.

Наш production pipeline: текст токенизируется spaCy, морфология обогащается через pymystem3, rule-based модуль извлекает жёсткие паттерны (ИНН, телефоны, стандартные суммы), ML-модель обрабатывает всё остальное.

Кейсы из продакшена

Извлечение ФИО

Одна из самых сложных задач для русского языка. Имя может быть в любом падеже, в любом порядке (ФИО, Имя-Фамилия, только Имя), с сокращениями или без.

Наш подход: словарь русских имён и фамилий (порядка трёхсот тысяч записей) в сочетании с морфологическим анализом. Pymystem3 определяет существительное с признаками имени собственного. Правила проверяют контекст: «меня зовут» или «я» перед словом — вероятность имени выше.

Суммы и валюты

Мы написали конвертер числительных, обрабатывающий десятки вариантов: от «пятьсот двадцать три рубля сорок копеек» до «523.40 руб.» и «523р40к». Отдельная задача — разделители тысяч: «50 000» vs «50,000» vs «50000».

Словарь валют — более ста вариантов написания для двадцати основных валют, включая сленг.

Случай с «менеджером»

Определение intent — не только сущности, но и понимание, что клиент хочет. «Хочу перевести» — transfer. «Покажите баланс» — balance_inquiry. «Заблокируйте карту» — card_block.

Rule-based подход тут работает на удивление хорошо — набор операций банка конечен. Мы создали таксономию из примерно пятидесяти intent-типов и для каждого — набор триггерных фраз. ML добавляет обработку нестандартных формулировок.

Инцидент, который нас научил

Март 2023-го. Мониторинг показывает падение precision NER-сервиса с 94% до 78% за неделю. Recall при этом не изменился. Что произошло?

Оказалось, маркетинг запустил акцию для клиентов. В обращениях массово появились фразы вроде «хочу оформить Мультикарту Плюс с кэшбеком 5%». NER начал классифицировать «Мультикарту Плюс» как ФИО — «Мультикарта» попадала под паттерн имени собственного с заглавной буквы, «Плюс» — под фамилию.

Правила, которые полгода работали безупречно, сломались на новом контексте. Мы добавили словарь продуктов банка в исключения rule-based модуля. На это ушёл день. Но сам факт — NER-система, которую ты не кормишь актуальным контекстом, деградирует молча. Мониторинг метрик — не опция, а необходимость.

Метрики и реальность

Лабораторные цифры: precision 94%, recall 91%. Продакшен — ниже, потому что реальные клиенты пишут с опечатками, без знаков препинания, на смеси русского и английского. И запускают акции с продуктами, названия которых NER-система принимает за имена.

Но ключевая бизнес-метрика — не accuracy модели, а снижение нагрузки на операторов. NER-сервис предзаполняет карточку обращения: имя клиента, тип запроса, ключевые параметры. Оператору остаётся подтвердить или скорректировать. Время обработки обращения сократилось ощутимо. А это — метрика, которую бизнес понимает и за которую платит.

Три вещи, которые я усвоил

Начни с правил, масштабируй через ML. Правила дают быстрый результат и базовую точность. ML подключай, когда накопишь размеченных данных. Не наоборот — ML без данных — это деньги в огонь. Мы начали с rule-based и за первые две недели закрыли примерно семьдесят процентов кейсов. Оставшиеся тридцать — нестандартные формулировки, сленг, опечатки — копились три месяца, пока мы не набрали достаточно размеченных примеров для ML-модели. Если бы начали сразу с ML — три месяца сидели бы без рабочего продукта, объясняя бизнесу, почему «модель ещё учится».

Инвестируй в данные, не в модели. Качество размеченного датасета определяет потолок. Простая модель на чистых данных бьёт сложную на грязных. Всегда. Мы потратили месяц на разметку: два аналитика, чёткие гайдлайны, перекрёстная валидация. Скучно? Адски. Но когда подключили ML — модель сразу показала приемлемый результат. У коллег из смежной команды, которые сэкономили на разметке и скормили модели то, что было — precision был на пятнадцать пунктов ниже.

NER — это pipeline, а не модель. Токенизация, нормализация, rule-based extraction, ML extraction, постобработка, валидация. Каждое звено влияет на результат. И каждое может незаметно сломаться, когда маркетинг запустит очередную акцию.

Деплой NER в банке: отдельный вид боли

Написать NER-сервис — полдела. Запустить его в банковской инфраструктуре — вторые полдела, и они сложнее первых.

Первое: всё on-premise. Никаких облаков, никаких внешних API. Это один из кругов ада финтех-разработки, к которому стоит быть готовым. Модель, данные, inference — всё крутится внутри контура. Это значит: ты сам поднимаешь инфраструктуру для обучения, сам настраиваешь GPU-сервера (если они вообще есть), сам следишь за версионированием моделей. В облаке ты нажал кнопку — получил endpoint. В банке ты пишешь служебку на выделение ресурсов, ждёшь две недели, получаешь сервер, на котором стоит не та версия CUDA.

Второе: compliance. Размеченные данные содержат персональные данные клиентов. Каждый датасет — через согласование с ИБ. Каждый доступ к данным — логируется. Нельзя просто скопировать выгрузку на рабочий ноутбук и разметить в удобном инструменте — всё делается на изолированном контуре, в специальной среде, с ограниченным набором инструментов. Мы размечали данные в интерфейсе, который разработали сами, потому что ни один внешний инструмент разметки не прошёл проверку безопасности.

Третье: latency. NER-сервис стоит на критическом пути обработки обращения клиента. Клиент написал в чат — система должна за миллисекунды предзаполнить карточку. Не за секунды — за миллисекунды. А ML-модель, даже лёгкая, на CPU выдаёт десятки миллисекунд. Мы оптимизировали inference через ONNX Runtime, батчили запросы, кешировали результаты для типовых фраз. Каждая миллисекунда — это UX оператора, а UX оператора — это время обработки обращения, а время обработки — это деньги.

Четвёртое: мониторинг деградации. Модель не ломается со звуком. Она тихо начинает ошибаться — и ты узнаёшь об этом, когда операторы начинают жаловаться, что «система опять бред несёт». Мы построили pipeline мониторинга: precision и recall считаются на выборке каждый день, алерты при падении ниже порога, еженедельный отчёт для бизнеса. Автоматизация не заменяет ручную проверку, но хотя бы даёт шанс поймать проблему раньше, чем её поймает клиент.

NER в банке — это не ML-задача. Это инженерная задача, обёрнутая в compliance, latency-требования и реальность, в которой маркетинг запускает акции, не предупредив IT. Кто к этому готов — строит продукт. Кто нет — строит прототип, который никогда не доедет до прода.

Оригинал статьи: NER сервисы в бизнесе на Habr

Ваш ДПУПП

Analyst Days 15: Узри, падаван, путь данных

Sat, 15 Apr 2023 00:00:00 GMT

Аналитик, который не работает с данными, — не аналитик

Апрель 2023-го, Москва, Analyst Days 15. Зал человек на двести, третий доклад после обеда — время, когда аудитория обычно клюёт носом в телефоны. Я выхожу на сцену и первым слайдом кидаю тезис: «Аналитик, который не работает с данными руками, — не аналитик». Тишина на полсекунды. Потом — шум. Кто-то в первых рядах кивает. Кто-то на галёрке краснеет и скрещивает руки. Вижу, как девушка в третьем ряду открывает Telegram — видимо, уже строчит возмущённый пост в чат конференции. Значит, попал в нерв. Значит, можно продолжать.

Повторю этот тезис здесь, в начале, чтобы сразу было понятно: это не мотивационная статья про «данные — новая нефть». Это разговор о том, что ты обязан уметь, если называешь себя аналитиком.

Аналитик — это не человек, который рисует схемы в Miro и пишет user stories в Jira. Аналитик — это человек, который понимает данные. Умеет прочитать SQL-запрос и понять, что он делает. Может открыть лог и найти аномалию. Знает, чем отличается LEFT JOIN от INNER JOIN не по определению из учебника, а по эффекту на бизнес-отчёт — когда один даёт 10 000 строк, а другой 8 500, и эти пропавшие 1 500 — клиенты без транзакций, которых ты молча выкинул из аналитики.

Если ты не работаешь с данными руками — ты менеджер, который говорит словами про данные. Это другая профессия. Она тоже нужна. Но это не аналитика.

После доклада ко мне подошёл парень лет двадцати пяти, представился системным аналитиком из финтеха и спросил: «А что, прямо SQL надо знать? У нас для этого дата-инженеры есть». Я ответил вопросом: «А когда дата-инженер в отпуске и бизнес просит срочно проверить цифру в отчёте — ты что делаешь? Ждёшь?» Он замолчал. Вот ради этой паузы и стоит выходить на сцену.

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

IT как кровеносная система

Бизнес любит метафоры. Data-driven, digital transformation, AI-first — красивые слова на слайдах стратегий. Но за каждым стоит простая вещь: данные должны течь. Из точки A в точку B, в нужном формате, в нужное время, с нужным качеством.

IT-системы — это кровеносная система организма-бизнеса. Данные — кровь. Если где-то тромб — участок отмирает. Если кровь загрязнена — весь организм страдает. Метафора банальная, но я за годы работы не нашёл более точной.

На VTB-проекте я это прочувствовал буквально. Мы строили систему персонализированных предложений для клиентов — на тот момент в batch-режиме, но уже тогда закладывали фундамент для того, что позже стало real-time движком. Если данные о клиенте приходят с задержкой — предложение уже нерелевантно. Если данные грязные — предложение не просто нерелевантно, а оскорбительно. Представь: клиент только что закрыл кредит и получает SMS с предложением рефинансирования. Тромб в кровеносной системе.

Три агрегатных состояния

Данные существуют в трёх состояниях, и переходы между ними — суть работы любой IT-системы.

  DATA                INFORMATION              KNOWLEDGE
  (сырьё)             (контекст)               (решения)
 ┌─────────┐   структура   ┌─────────────┐   аналитика   ┌──────────────┐
 │ Логи    │──────────────>│ Сигналы     │──────────────>│ Основания    │
 │ Клики   │   + контекст  │ Метрики     │  + экспертиза │ для действий │
 │ События │               │ Алерты      │               │              │
 └─────────┘               └─────────────┘               └──────────────┘
      90% компаний               ▲
      застревают здесь ──────────┘

Data — сырой материал. Логи, транзакции, сигналы датчиков, клики. Строка в логе user_id=12345, action=click, timestamp=1681548000 ничего не значит вне контекста.

Information — данные в контексте. Когда ты знаешь, что user_id=12345 — это VIP-клиент, action=click — это клик на кнопку «закрыть счёт», а timestamp — это 10 минут после неудачного звонка в поддержку, строка из лога превращается в сигнал тревоги.

Knowledge — информация, подкреплённая опытом и паттернами. Ты знаешь, что за последний квартал 40% клиентов, кликнувших «закрыть счёт» после звонка в поддержку, действительно ушли. И ты знаешь, что удержание обходится в пять раз дешевле привлечения. Теперь у тебя не сигнал, а основание для действия.

Переход от Data к Information требует структуры и контекста. Переход от Information к Knowledge требует аналитики и экспертизы. Большинство компаний застревают на первом переходе, накапливая терабайты данных, которые никогда не станут информацией.

Четыре роли — одна таблица

Одна и та же таблица в базе выглядит совершенно по-разному в зависимости от того, кто на неё смотрит.

Роль	Видит	Ключевой вопрос	Мыслит категориями
Аналитик	Бизнес-сущности	«Что данные значат для бизнеса?»	Связи, закономерности
Разработчик	Структуры, индексы	«Как эффективно записать/прочитать?»	Производительность
Тестировщик	Граничные случаи	«Что сломается при плохих данных?»	Отказы, исключения
DevOps	Потоки, объёмы	«Данные вообще доходят?»	Инфраструктура

Сухая таблица. Давай наполню её жизнью.

Один пример: таблица транзакций

Возьмём transactions — стандартная таблица в банковской системе. Поля: id, client_id, amount, currency, timestamp, status, merchant_id, category.

Аналитик смотрит и думает: «Средний чек по категории groceries за Q3 вырос на 12%. Это инфляция или изменение поведения? Надо кросс-табулировать с client_segment и посмотреть, кто именно стал тратить больше». Он видит бизнес-историю в числах.

Разработчик смотрит и думает: «Запрос с JOIN на merchants и GROUP BY по category за квартал — это full scan на 200 млн строк. Нужен партишн по timestamp и составной индекс (category, timestamp). Иначе дашборд будет грузиться три минуты». Он видит производительность.

Тестировщик смотрит и думает: «А что если amount отрицательный? А если currency = NULL? А если timestamp в будущем? А если status = 'pending' уже три дня?» Он видит всё, что может сломаться.

DevOps смотрит и думает: «Таблица растёт на 5 млн строк в сутки. Через два месяца упрёмся в дисковое пространство. Репликация отстаёт на 30 секунд — для real-time дашборда это критично». Он видит инфраструктуру.

Одна таблица — четыре мира. Проблемы начинаются, когда эти миры не пересекаются. Аналитик проектирует модель, не думая о производительности. Разработчик оптимизирует запросы, не понимая бизнес-смысла. Тестировщик проверяет форматы, не зная, какие данные критичны. DevOps мониторит доступность, не видя, что данные текут, но уже невалидные.

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

Когда данные врут: история из банковского мира

Начало 2022-го. Мы запускаем новый модуль персонализированных предложений. Всё тестировано, всё вылизано. Первая неделя в проде — метрики красивые. Конверсия растёт. Руководство довольно.

Вторая неделя — аномалия. Один из сегментов клиентов показывает конверсию в три раза выше ожидаемой. Звучит как победа? Мы тоже так подумали. Секунд на тридцать.

Потом полезли в данные. Оказалось, что ETL-процесс, загружающий клиентские сегменты, при ошибке парсинга молча проставлял дефолтный сегмент — «VIP». Молча. Без ошибок в логах, без алертов. Просто тихо превращал обычных клиентов в VIP-ов.

Итог: несколько тысяч клиентов получили VIP-предложения, на которые не имели права. Часть воспользовалась. Откат занял неделю. Разбор полётов — ещё две. Финансовый ущерб я озвучивать не буду, но он измерялся не в тысячах.

Мораль: данные не врут. Данные — это то, что в них записали. Врут процессы, которые эти данные обрабатывают. (Подробнее о рисках и управлении данными — в докладе про BANI-мир.) И если ты, аналитик, не понимаешь, как данные попали в таблицу — ты не можешь интерпретировать то, что в ней лежит.

Четыре паттерна: карта территории

За годы работы с data-intensive системами я выделяю четыре фундаментальных паттерна. Это не теория — это ежедневная реальность.

Хранение. Где живут данные, как долго, в каком формате. Реляционные базы, документные хранилища, озёра данных, in-memory кэши. Выбор хранилища определяет 80% архитектурных решений дальше по цепочке. Ошибка здесь — самая дорогая.

Обработка. Batch или stream, ETL или ELT, SQL или код. Каждый подход имеет свою нишу. Batch — для аналитики за период, stream — для реакции в реальном времени. Натянуть batch на real-time задачу — классический антипаттерн, который я видел минимум в пяти проектах. Каждый раз заканчивается одинаково: переписыванием с нуля.

Передача. API, очереди сообщений, файловый обмен, репликация. Каждый стык между системами — потенциальная точка отказа. В enterprise интеграции — главный источник боли. У нас на проекте десятки интеграционных потоков, и каждый хотя бы раз ломался в самый неудобный момент.

Документирование. Метаданные, data lineage, каталоги данных, data contracts. Без документации данные превращаются в чёрный ящик. Через полгода никто не помнит, что значит поле flag_3 в таблице temp_data_final_v2. Я не шучу — я видел такие таблицы. В продакшене. В банке.

Выбор хранилища = 80% архитектурных решений далее
Ошибка в хранении = самая дорогая ошибка
Batch + Real-time = гибридная архитектура (Lambda/Kappa)
Документирование = то, что все пропускают и все потом жалеют

Тезис, с которого начали

Аналитик, который плохо работает с данными, — не аналитик. Я начал с этого и закончу этим, только жёстче.

Рынок полон людей, которые называют себя аналитиками и при этом не могут написать SQL-запрос сложнее SELECT * FROM. Которые не знают, что такое индекс. Которые не понимают разницу между batch и stream. Которые рисуют красивые диаграммы, но не могут объяснить, откуда взялись числа на дашборде.

Это не аналитики. Это люди, которые разговаривают про данные. Разница — как между хирургом и человеком, который посмотрел видео об операции на YouTube.

Если ты аналитик — разберись, как данные хранятся, обрабатываются, передаются и документируются. Научись читать SQL. Научись находить аномалии в данных руками, а не только через готовый дашборд. Пойми, как ETL-процесс может молча превратить твои данные в мусор.

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

По мотивам доклада на Analyst Days 15, 2023.

Ваш ДПУПП

Analyst Days 14 / Импульс 2022: Не крась траву — риски и ценность данных в BANI мире

Sat, 15 Oct 2022 00:00:00 GMT

5000 продавцов, которые никуда не ходили

Крупная FMCG-компания, B2B-сегмент. Несколько тысяч торговых представителей. CRM, аналитические дашборды, прогнозирование спроса — полный набор. Руководство смотрит на графики покрытия территории и видит красивую картину: визиты к клиентам растут, активность на максимуме.

Одна проблема: часть визитов никогда не происходила.

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

Фиктивный визит ──> Ложный прогноз ──> Лишние закупки ──> Перепроизводство
   продавца           продаж              сырья            ──> Убытки
                                                               в фин.плане
     GARBAGE IN ─────────────────────────────────────────> GARBAGE OUT

Четыре шага от вранья в CRM до дыры в финансовом плане. GIGO — Garbage In, Garbage Out. Принцип, который знают все и игнорируют большинство.

Этот кейс я привёл на Analyst Days 14, Импульс 2022 и ЛАФ 2022. И каждый раз после доклада ко мне подходили люди и говорили: «У нас то же самое, только в другой обёртке».

Не крась траву

Есть старый армейский анекдот. Командир говорит: «Завтра приезжает генерал, территория должна быть зелёной». И солдаты красят траву зелёной краской. Формально — требование выполнено. По сути — идиотизм.

С данными в корпорациях — то же самое. Можно написать политику управления данными, повесить на стену, отчитаться. Это и есть — красить траву. А можно выстроить процесс: назначить ответственных, внедрить контроль качества, автоматизировать проверки, обучить людей. Посадить газон.

Разница видна не сразу. Крашеная трава выглядит прилично на фотографии. Но после первого дождя краска смывается. А газон — растёт.

Эта метафора будет красной нитью через всю статью. Каждый раз, когда увидишь решение, которое выглядит красиво на слайде, но не работает в реальности — ты знаешь, что это. Краска на траве.

BANI: мир, в котором мы работаем

VUCA устарел. Добро пожаловать в BANI — более точную модель текущей реальности.

BANI	Значение	Что это значит для данных
Brittle (хрупкий)	Системы ломаются внезапно и каскадно	Один сбой в источнике обрушивает всю цепочку отчётности
Anxious (тревожный)	Неопределённость парализует решения	Без качественных данных менеджеры решают на страхе и интуиции
Non-linear (нелинейный)	Малое на входе = огромное на выходе	Ошибка в справочнике = миллионы в некорректных отчётах
Incomprehensible (непостижимый)	Мы не понимаем, почему так	Сложность систем превышает способность человека их отследить

Это не модный акроним для презентаций. В BANI-мире качество данных — вопрос выживания бизнеса. Не «было бы неплохо», а «без этого ты слепой».

Нелинейность — самое опасное свойство. В FMCG-кейсе ошибка одного продавца — мелочь. Ошибка тысячи продавцов, усиленная через прогнозную модель — катастрофа. Система не деградирует плавно. Она работает нормально, нормально, нормально — а потом ломается вся сразу.

Кейс из банковского мира: когда справочник убивает отчётность

FMCG — чужая территория. Расскажу про свою.

В банковском проекте мы столкнулись с классикой жанра: расхождение справочников между системами. Один и тот же клиент в CRM — «ООО Ромашка», в АБС — «Ромашка ООО», в аналитическом хранилище — два разных клиента. Потому что ETL-процесс матчил по точному совпадению названия.

Масштаб проблемы стал виден, когда бизнес попросил отчёт по кросс-продажам. Сколько клиентов, которые взяли кредит, также имеют расчётный счёт? Ответ по данным: 40%. Ответ по реальности: 65%. Разница — четверть клиентской базы, которую система не смогла склеить.

На основе этих 40% строились прогнозы, планировались маркетинговые кампании, выделялись бюджеты. Крашеная трава. Красивые цифры на дашборде, за которыми — мусор.

Мы починили это через граф-платформу: построили систему, которая матчит сущности не по точному совпадению, а по совокупности признаков — ИНН, адрес, телефон, паттерны транзакций. (Подробнее о том, как мы строили data-intensive платформу в банке.) Но это заняло месяцы. А ущерб от кривых отчётов накапливался годами.

Фреймворк: как не красить траву

Классификация данных и ISO 27000

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

ISO 27000 даёт рамку: какие данные храним, кто имеет доступ, что произойдёт при утечке, какие регуляторные требования соблюдаем. Не обязательно сертифицироваться — достаточно использовать как чеклист.

DAMA: десять областей управления данными

DAMA International систематизировала управление данными в десять областей. Не теоретическая конструкция — практический каркас. Вот он в сжатом виде:

Область	Суть	Красный флаг (ты красишь траву, если...)
Data Governance	Роли, ответственности, политики	...политика есть, но никто не знает, кто data owner
Data Architecture	Где какие данные живут	...архитектура нарисована год назад и не обновлялась
Data Security	Защита от несанкционированного доступа	...у всех аналитиков доступ ко всем таблицам «для удобства»
Data Modeling	Концептуальные, логические, физические модели	...модель данных живёт в голове одного человека
Data Storage	Хранение, ретенция, архивирование	...никто не знает, сколько данных хранится и зачем
Master Data	Эталонные данные без дублей	...один клиент живёт в пяти системах как пять разных записей
Data Integration	Потоки между системами	...ETL написан 5 лет назад, автор уволился
Data Quality	Полнота, точность, актуальность	...нет ни одной метрики качества данных
Metadata	Данные о данных, lineage	...поле `flag_3` в таблице `temp_data_final_v2`
DWH и BI	Аналитика и визуализация	...дашборд есть, но никто не верит его цифрам

Ни одна компания не покрывает все десять идеально. Но знать, где ты находишься на каждой шкале — уже половина решения. А если в колонке «красный флаг» ты узнал свою компанию три и более раз — у тебя не проблема с данными. У тебя бомба замедленного действия.

Экспоненциальный рост: почему завтра будет хуже

Объём данных растёт экспоненциально. Каждый год — больше, чем за все предыдущие. Компании генерируют данные быстрее, чем успевают их обработать. Про управление качеством — молчу.

Типичная картина в enterprise: десятки источников данных, каждый со своим форматом. Справочники дублируются между системами и расходятся через месяц после синхронизации. Мастер-данные живут в Excel на рабочем столе менеджера. ETL-процессы написаны пять лет назад и автор давно уволился.

Конкретный пример из банковского контекста: за два года работы над data-платформой объём данных в аналитическом хранилище вырос с 8 до 47 терабайт. Не потому что бизнес вырос в шесть раз — а потому что подключали новые источники, добавляли историчность, хранили промежуточные расчёты. При этом количество людей, отвечающих за качество этих данных, осталось прежним: полтора аналитика и DBA, у которого это было пятой приоритетной задачей. Данные росли экспоненциально, а ресурсы на управление ими — линейно, в лучшем случае.

Проблема не в технологиях. Технологии для управления данными существуют давно. Проблема в организации: нет ответственных, нет политик, нет процессов. Данные — ничьи. А то, что ничьё — то и не нужно никому. Пока не взорвётся.

Чеклист: газон вместо краски

Если после прочтения хочешь проверить, красишь ли ты траву — вот минимум.

Ты знаешь, какие данные у тебя есть и кто за них отвечает? Если нет — начни с инвентаризации. Не нужна идеальная каталогизация — нужен хотя бы список критичных источников с именами ответственных.
Есть ли у тебя data quality метрики? Полнота, актуальность, консистентность. Если нет — ты не знаешь, насколько можно доверять отчётам. Ты принимаешь решения на вере, а не на данных.
Мастер-данные живут в одном месте или в пяти Excel-файлах? Если второе — ты красишь траву. У тебя нет единого источника правды, а значит, у каждого подразделения — своя правда.
Кто последний раз проверял ETL-процессы? Если «никто не помнит» — у тебя бомба замедленного действия. ETL, который никто не мониторит, рано или поздно начинает молча терять или искажать данные.
Что происходит, когда источник данных падает? Если ответ «узнаём, когда бизнес жалуется на отчёт» — ты реактивен. А в BANI-мире реактивность = потери.
Твои аналитики умеют работать с данными руками? Если нет — перечитай мою статью про путь данных. У тебя не аналитики, а рисовальщики дашбордов.
Есть ли у тебя data lineage — хотя бы на салфетке? Можешь ли ты за пять минут ответить, откуда берётся цифра в конкретной ячейке отчёта? Через какие системы прошла, какие трансформации пережила, когда обновлялась в последний раз? Если нет — ты не знаешь, чему верить. Я видел ситуацию, когда два отчёта для одного и того же бизнес-заказчика показывали разные цифры по одной метрике — просто потому, что один брал данные из реплики с задержкой в сутки, а другой из оперативной базы. Оба были «правильные». Оба врали.

Не крась траву. Посади газон.

В BANI-мире данные — единственная опора для принятия решений. Если опора гнилая — рухнет всё, что на ней стоит. И рухнет не плавно, а сразу. Потому что BANI.

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

Газон — это скучно. Газон — это data governance, метрики качества, ответственные за данные, мониторинг ETL, master data management. Это не блестит на слайдах. Это не впечатляет на совещании. Но после первого дождя — а он будет — газон стоит. А краска смывается.

По мотивам доклада на Analyst Days 14 / Импульс 2022.

Ваш ДПУПП