IT в ФинТехе. Как всё начиналось: боли, релизы и средневековая Чехия. Часть 1

Привет! 👋 Это новый выпуск из рубрики IT & Инсайты — здесь я делюсь разбором интересных и полезных материалов из мира технологий, управления и цифровой трансформации.

Сегодня — обзор свежего эпизода подкаста «Техно.Логично» с Алексеем Ульенковым, руководителем ИТ Розницы и МСБ, и Александром Черушниковым, ИТ-куратором платформ Розницы.

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

Что особено запомнилось:
1️⃣ Как менялись процессы в ИТ: от «чёрного ящика» к прозрачности

Один кейс из прошлого выглядел так:
👉 код отправляли внешнему вендору (например, Oracle),
👉 а «на местах» — собственные инженеры вручную разбирали, что изменилось,
👉 искали логику в кодовой базе,
👉 анализировали, какие параметры нужно подкрутить,
👉 и только потом формулировали, что именно надо исправить или донастроить.

💡 Представьте: вы не контролируете код, не видите, как он работает, и ждёте ответа от вендора — как от оракула (в прямом и переносном смысле 😉).
Процесс — медленный, хрупкий, с высоким риском ошибок и простоев.

2️⃣DevOps и эволюция процессов в финтехе:

Как менялась культура доставки изменений в продакшн:

🔹 Сначала — большие, но точечные релизы:
развивали 1–2 решения, тестировали, выпускали релизы раз в месяц.
→ Просто, но медленно и с задержками.

🔹 Потом — «большие релизы»:
один запуск на десятки систем, тестирование — неделями, стеки изменений — огромные.
→ Кажется, что «всё под контролем», но на деле — ложное чувство безопасности.
Один "крупный" баг = всё откатываем.

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

🚨 Ключевой инсайт:

«Чем чаще мы ставим — тем реже падаем.»
(и когда падаем — быстро встаём)

💡 В начале было сопротивление: «Так не принято», «Слишком рискованно».
Но результат доказал эффективность: меньше стресса, выше стабильность, быстрее изменение уходит к клиенту.

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

📌 Всё это — не теория, а реальная жизнь.
Истории, которые узнают многие, кто работает в корпоративном ИТ.

💬 А у Вас в команде были похожие кейсы?
— Когда код был «чёрным ящиком»?
— Или когда «большой релиз» внезапно рушил всё?
Делитесь в комментариях — интересно сравнить контексты!

📌 И да — вы наверняка задаётесь вопросом:

«При чём тут, вообще, средневековая Чехия?»

🔎 Ответ — во второй части. 😉 Поведую о том, как участники подкаста изменили культуру в кампании, внедрили DevOps и перестроили подход к разработке.


🎧 Подкаст рекомендую послушать по ссылке:
👉 https://vkvideo.ru/video-145457488_456239856


#ITИнсайты

IT в ФинТехе. Как всё начиналось: боли, релизы и средневековая Чехия. Часть 2 (если вы пропустили первую часть)

🎧 В этом выпуске — как команда изменила культуру, перестроила структуру и внедрила DevOps не ради моды, а ради результата.

3️⃣Будущее профессии: как нейросети меняют IT-культуру

Звучало провокационно, но логично:

Топовый разработчик с нейросетью в руках — почти в 100 раз эффективнее джуна.

💡 Не потому что он «умнее»:

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

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

4️⃣ Как развивалось IT в Газпромбанке: с чего начиналась трансформация

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

🔹 Всё началось с аудита текущих процессов.
И что он увидел?

❌ Разбалансированный ролевой состав:
— много архитекторов, тестировщиков, аналитиков и менеджеров,
— но катастрофически не хватало разработчиков — тех, кто пишет код и отвечает за его качество.

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

❌ Тестирование ради тестирования:
полигоны весом в десятки терабайт, сценарии, которые никто не понимал, и результаты, которые не ловили реальные баги.

💬 И тут прозвучало легендарное сравнение:

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

🔹 То есть:
— нет единой платформы,
— нет общих стандартов,
— нет культуры непрерывной доставки,
— но много договорённостей, ритуалов и иерархии.

📌 Именно с таких «неудобных правд» начинается настоящая трансформация — не с красивых презентаций, а с честного анализа.

А дальше — путь:

от вендорной зависимости → к внутренней разработке,
от гигантских релизов → к частым выкаткам,
от ручного управления → к автоматизации и DevOps.

💡 Главный урок:
Невозможно построить современное IT поверх устаревшей культуры.
Сначала — люди, структура, мышление. Потом — технологии.

✅ Итог
Ценность этого подкаста для меня, что герои:
— поднимают вопрос о сопротивлении и с чем сталкивались при внедрении новых практик,
— не скрывают неудач,
— и показывают, как новая ИТ-культура строится по кирпичику.

🎧 Рекомендую к прослушиванию всем, кто в корпоративном IT, DevOps, управлении командами или цифровой трансформации.

👉 https://vkvideo.ru/video-145457488_456239856
💬 Делитесь впечатлениями — что запомнилось вам?

#ITИнсайты

🧱 Я перестал ждать всплеска эмоций. Теперь я просто делаю

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

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

Со временем пришло понимание:
Рутинная работа — это не про вдохновение.
Она требует другого подхода.
Не всплеска энергии, а устойчивости.
Не гениального решения, а монотонного следующего шага.

⏱Мне лично помогла техника Pomodoro:
25 минут — фокус на задаче, таймер включен.
И в эти 25 минут я не герой, не гений, я просто — работник.

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

Например:

❇️Отключаешь уведомления → Больше фокуса. Меньше утечек энергии.
❇️Коммитишь и пушишь код каждый день → Через пару месяцев проект обретает осмысленность и видна чёткая история прогресса.
❇️Вводишь процесс мерджреквеста и ревью в команде → Через полгода — меньше хаоса, через год — рост продуктивности.
❇️Стабилизируешь сон, находишь баланс между тренировками и отдыхом, начинаешь считать и контролировать калории → Через 3–6 месяцев чувствуешь себя заряженным энергией.
❇️Учишь новое и постепенно применяешь → Навык закрепляется, а не исчезает в «я потом».

Да, это сложно — делать снова и снова,
когда уже не интересно,
когда хочется бросить,
когда «всё и так понятно».

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

Терпения.
И — вперёд!🏃‍♂️‍➡️➡️

Выкладываю это видео уже после 23:00, но в субботу — значит, в дедлайн уложился🔥

Это 11 видео — и в нём я покажу как полностью уйти от WSL и зависимостей.
Запустим вместе Airflow в Docker — один файл, одна команда, и Airflow, PostgreSQL, MinIO — всё в одном стеке.

Показываю:

❇️Как настроить WSL в Windows
❇️Как устроен docker-compose.yml построчно
❇️Как запустить Airflow в Docker
❇️Где и как задаются логин/пароль для Airflow
❇️Как добавить свой DAG и увидеть его в UI

Это идеальный способ быстро поднять окружение для обучения, тестов или CI.

Приятного просмотра — и пусть ваш docker-compose up будет зелёным в трее! 🐳

🎥 Смотреть видео:
▶️ VK: https://vkvideo.ru/video-231048746_456239028
▶️ Youtube: https://youtu.be/x1KlJJzHU-o?si=0NN-uWJUosu4MW2H

P.S. Как Вам новая обложка к видео?☺️

#КакРаботаютДанные #Airflow

Мониторинг ML-систем: как не проспать падение прода
Привет! 🚀
Сегодня в выпуске #ITИнсайты — еженедельная рубрика с разбором докладов, подкастов и практик из мира IT.

Сегодня разбираем доклад Владимира Кочеткова — «Мониторинг ML-систем в production». Неважно, запускаешь ты ML-модели или другой любой API — мониторинг критичен. Этот выпуск — про то, как ничего не пропустить.

О чём доклад?
Мониторинг ML-систем — не просто про метрики, а про то, как на самом деле следить за жизнью модели после запуска.

Почему это важно?
Рабочая система — это не разовый запуск и без мониторинга:

❗️не узнаешь, что сервис уже 3 часа "падает", а ты спишь.
❗️не заметишь дрейф данных,
❗️ пропустишь падение качества,


Жизненный цикл модели
Мониторинг — не опция, а обязательная часть цикла:

1️⃣Тестирование
2️⃣ Внедрение (MVP, альфа-тесты)
3️⃣Мониторинг в продакшне

Что мониторим?
Три кита:

✅Трафик — сколько запросов приходит?
✅Ошибки — по статус-кодам (500, 400 и т.д.), с мета-информацией.
✅Ресурсы — нагрузка на железо в пиковые моменты.

Главные угрозы в ML-системах

По качеству данных и модели:
🔹Аномалии данных: выбросы, битые форматы, пропуски — всё, что ломает предобработку.
🔹Дрейф данных (data drift): распределение входных признаков изменилось (например, пользователи стали младше).
🔹Дрейф концепции (concept drift): связь между признаками и целевой переменной сместилась ("старый" признак перестал быть значимым, например, рекомендация билетов в кино и театр в период пандемии).

👉Без эталонного датасета и анализа на свежих данных — вы слепы. Модель работает, но даёт мусор.

По инфраструктуре и сервису:
🔹Рост латентности: запросы начинают обрабатываться дольше.
🔹Ошибки 5xx/4xx: сбои на уровне API или бэкенда.
🔹Переполнение очередей: Kafka, RabbitMQ — задержки обработки.
🔹Недостаток ресурсов: не хватает CPU, памяти, GPU.
👉 Эти проблемы могут не затрагивать модель напрямую, но делают её бесполезной — сервис просто не отвечает.

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


📌 Ключевые выводы по докладу
✅ Мониторинг — это про "когда и где", а не только "что".
✅ Нужен единый интерфейс, а не Python-скрипты и логи в консоли.
✅ Grafana — лучший выбор для внутренних систем.
✅ WhyLabs — сильный в анализе моделей, но не для железа.

💡 Совет от меня☺️
Настройте шаблон логирования для всех систем. Пусть все метрики пишутся одинаково — так будет проще автоматизировать для построения графиков и метрик в Grafana.

🎧 Рекомендую к прослушиванию:
— ML-инженерам
— DevOps
— Тимлидам
— Тем, кто отвечает за стабильность сервисов

📺 Доклад: https://vkvideo.ru/video-164555658_456241612

💬 Делитесь в комментариях — какие инструменты используете вы для мониторинга?

#ITИнсайты

Снятся ли хакатоны электроовцам?🐑

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

И ловлю себя на мысли:

Я автоматически увеличиваю объём задания, потому что при решении будет использоваться LLM.

На пару минут даже офигел.

🔹 Больше не требуется проектировать задачу для человека.
🔹 Теперь нужно ставить задачу для человека + ИИ.

LLM меняют не только процесс решения, меняется сама логика постановки задачи.

На секунду стало неприятно и внутренне неудобно:
— А что нас ждёт, если за последние лет 5-7 такой скачок?
— Когда мы перестанем понимать, что внутри кода?

Обдумав, вспомнил:

Технологии всегда пугали. Потому что они двигают нас вперёд.
Именно этот дискомфорт — признак того, что развитие продолжается.

Когда-то преследованию подвергались книгопечатание, потом радио, телевидение и интернет. А теперь это классика☺️

Сейчас очередь искусственного интеллекта.
Интересно жить в эпоху ожившего киберпанка.

Но даже в примере с хакатоном, киберпанк добавляет следующие вопросы:

🔸 Как проверить понимание, а не навык генерации?
🔸 Как пройти по грани обдумывания, а не копипаста?
🔸 Как создать задачу, где ИИ — помощник, а не замена?

Это одновременно напрягает и мотивирует. Мир развивается.
Скорость прогресса иногда пугает.
Но чаще — безумно интересно☺️.

📌 А вы в рабочих процессах используете ИИ?
— Если да — поделитесь, как.
— Если нет — поясните, почему.

Делитесь в комментариях 👇

#БудниПрограммиста

ИИ в команде: опыт внедрения

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

На этот раз — разбор доклада разработчика из K2 Cloud, где массово внедряют аналоги GitHub Copilot.
Выделил основные части и краткое МЕМО по ним.

Зачем нужен Copilot?
✅+25% к производительности за $10/мес с пользователя — мощный экономический аргумент. (это, конечно, по словам разработчиков Copilot b и их метрикам, и скорее всего можно смело делить на 2:D)
✅Менеджеры охотно поддерживают внедрение, тогда как разработчики сначала скептически относились к технологии. (я лично, всеми руками за!)

Проблемы безопасности
🔹Компания не может использовать SaaS-решения вроде GitHub Copilot из-за политик информационной безопасности. Поэтому фокус — на open-source аналогах, которые можно развернуть локально.

Среди open-source вариантов был выбран ContinueDev, так как имел большее количество скачиваний среди open-source конкурентов (2 млн против ~100 тыс. у других).

⚙️ Как это работает?
● Система собирает контекст: текущий файл, соседние, недавно открытые.
● Отправляет запрос модели (например, Llama или Villa).
● Получает подсказку по шаблону fill-in-the-middle.
● Выводится прямо в IDE.

ContinueDev добавляет ещё чат и "агентов", которые могут выполнять действия — но они пока слабо используются.

Что показала аналитика?
❇️За месяц — 185 тыс. запросов на автодополнение.
❇️Чатом почти не пользовались: контекст часто терялся, ответы были слишком общими.
❇️При задержке >10 сек — подсказки исчезали, что сильно раздражало.
❇️Оптимальная скорость для работы при автоподсказке — 2–3 секунды.

Выбор и обучение модели
● В момент сбора статистики использовали Qwen2.5 Code (в видео есть подробное обоснование).
● Полное дообучение требует 124 ГБ VRAM — дорого.
● Широкое распространение получили методы LoRA/QLoRa, которые обучают только небольшую часть весов, экономя ресурсы. (информативно было это послушать)

В итоге отказались от дообучения: ждут выхода Qwen3 Code, который должен быть ещё лучше (и пройспойлерю, так оно и оказалось😁)

Copilot vs Open Source

✅GitHub Copilot явно впереди: больше контекста, ранжирование подсказок, обучение на принятом коде.
❌ Open-source решения пока уступают в удобстве, индексации кодовой базы и стабильности.

Также интересно было узнать, что качество работы зависит от IDE разработки, так как VsCode лучше оптимизирован для работы с ИИ-плагинами. Так как для локальной разработки я сам юзаю VsCode удивился, узнав, что на данный момент это лидер рынка в этом сегменте☺️👍

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

Удивило, что редко пользовались чатом, скорее всего из-за несовершенства модели 2.5 Coder, так как 3 версия эти задачи классно решает. Сам лично считаю чат классной возможностью расширить свои знания.

🔗Полное видео доклада: https://www.youtube.com/watch?v=3IjRw3f8RDo

💬 P.S.
Сам постоянно пользуюсь LLM в качестве быстрого погружения в тему, настройке различных инструментов (например, на днях быстро поправил настройки keycloak для конкретного клиента) и уточнения по логам ошибок.

Как вы используете ИИ в повседневной жизни и работе?
— Если да — чем и как?
— Если нет — что мешает?

#ITИнсайты