Мы очень давно — более 10 лет — говорим о безопасности k8s. Это второй опенсорс‑проект в мире после Linux, а в РФ только «ванильным кубом» пользуются более 53% компаний (не считая коммерческие и облачные Managed K8s), десятки best practices и подходов, а инструментов только под Security больше 100. 

Казалось бы, всё должно быть хорошо. 

Однако с безопасностью k8s всё ещё плохо. К примеру, судя по отчёту Red Hat “State of Kubernetes Security 2024” в 2024, 46% компаний понесли убытки из‑за недостаточной безопасности Kubernetes, в 9 из 10 организаций произошел минимум один инцидент, связанный с безопасностью контейнеров или Kubernetes. 

Причина проста — инструменты сами по себе не дают требуемого уровня безопасности. Поставить сканер — не значит быть защищенным. Включить политики — не значит, что они работают. Написать требования — не значит, что их будут выполнять. 

Здесь нужен системный подход. Меня зовут Александр, я лид направления безопасности K8S и облаков в Альфа‑Банке. С нуля стартовал, построил и сейчас сопровождаю и развиваю ИБ K8S. Моя статья об этом — как выстроить безопасность K8S как систему (функцию) в компании и масштабировать её в окружении сотен кластеров. Обсудим, какие процессы работают, какую зону ответственности должна занимать команда и как её собрать. 

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

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

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

Начну моё эссе с рассказа о себе.

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

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

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

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

Привет, Хабр! Меня зовут Роман Гатауллин, я младший специалист по разработке нейронных сетей в Управлении по разработке моделей глубокого обучения и прикладных исследований. В этом проекте я отвечал за time-series часть: эксперименты с Prophet и Temporal Fusion Transformer. Статью мы подготовили вместе с Иваном Семидетновым, специалистом по интеллектуальному анализу данных из Дирекции по разработке моделей общекорпоративных функций. Над задачей работали две команды, и ниже мы расскажем, как прогнозировали почасовой клиентопоток в отделениях и что из этого получилось.

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

В первую очередь изменила привычную модель взаимодействия предпринимателей с государством, к примеру, появились Единый налоговый счёт или обязательные уведомления об исчисленных сумма. В 2024 году команда внесла в интерфейс изменения, но они плохо отрабатывали, так как были внесены поверх старого интерфейса как косметическая доработка. Но интерфейс не отрабатывал как должен был и через некоторое время появился артефакт в виде исследования, на основе которого была создана концепция для редизайна. И только в 2026 году эта концепция была реализована.

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

И об этом я хочу рассказать.

Когда речь заходит о ЛЛМ и классификации, первая мысль — попросить модель сгенерировать класс через промптирование модели с описанием правил и добавлением примеров. Для небольшого количества классов это работает. Но для 100+ классов (или даже 20-30) — уже нет: контекст раздувается, модель галлюцинирует, а инференс может занимать десятки секунд. Мы решили использовать ЛЛМ иначе: не как генератор текста, а как энкодер, прикрутив сверху обычную классификационную голову.

В статье расскажу про нашу мотивацию использовать ЛЛМ как энкодер и покажу результаты на четырёх разных доменах банка, в рамках которых сравню генеративные модели с классическими энкодерами

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

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

Меня зовут Мия, я Digital Product Owner в корпоративном банкинге. Больше 20 лет в финтехе, сейчас развиваю продукты в корпоративном банке. Работаю на стыке UX, продукта и системной архитектуры: превращаю тяжелую банковскую логику в живые клиентские сценарии. ​Не верю в «фичи ради фич» и лишний балласт. Хороший продукт не путает человека, а помогает ему быстро принять решение и сделать следующий шаг. Вся суть — в умении вовремя спросить: для кого мы это делаем, какую задачу решаем и что будет потом.

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

— как «посадить осьминога» на кредитный комитет, чтобы сгенерировать продуктовые гипотезы;
— как сделать бюджетный CJM силами команды разработки;
— как метрика Time to Interactive помогла объяснить «призрачный» негатив клиентов, когда по бэкенд‑логам всё было «зелёное».

Привет! Меня зовут Серёжа, я дизайнер цифрового продукта в Альфа-Банке. Однажды я стал отвечать за вопросы по дизайну сразу для четырех команд. Мне постоянно писали в личные сообщения, и небольшая просьба что-то выяснить превращалась в полноценную консультацию, срочное дизайн-ревью сдвигало некоторые приоритетные задачи, и на свои дела времени не хватало. В этой статье я рассказываю, как я научился справляться с большим потоком задач с помощью книги Марка Форстера «Сделай это завтра», и как я адаптировал оригинальный метод под специфику работы продуктового дизайнера.

Меня зовут Саша Черток, руковожу отделом безопасности контейнерных и облачных технологий в Альфа-Банке. Расскажу, как вывести организацию в облако, даже если она максимально зарегулирована.

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

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

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

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

Каждые несколько лет (а сейчас уже и чаще) разработчиков снова хоронят.

Сначала нас должны были заменить визуальные конструкторы. Потом no-code. Потом low-code. Потом автогенерация CRUD. Потом Copilot. Теперь, кажется, пришёл финальный босс в виде больших языковых моделей, которые за вечер могут накидать backend, frontend, Docker Compose, миграции, OpenAPI, Kafka, PostgreSQL, Redis, авторизацию, тесты, README и компилятор на сдачу.

А если открыть любую соцсет, то везде: «Я сделал SaaS за 20 минут», «нейросеть написала мне приложение», «один промпт заменил команду разработки»…Всё выглядит так, будто профессии действительно место в музее рядом с перфокартами и дискетами, так как теперь обычный пользователь интернета может навайбить энтерпрайз ПО, банковское мобильное приложение и агрегатор такси. И всё это только за утро. 

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

Я наблюдал ситуации, когда компания формально соответствует требованиям регулятора, регулярно проходит аудиты, имеет утвержденные Политики, настроенные СЗИ, выделенный SOC и несколько сотен страниц Регламентов на случай любой проверки.

Но однажды, после первого инцидента, выяснялось, что:

— Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
— SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
— Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
— Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

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

Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.

Одна из самых дорогих встреч в нашем календаре выглядела совершенно обычно. Раз в неделю 20-25 человек собирались на 1,5 часа, чтобы оценить задачи. Раз за разом встреча повторялась, забирая время разработчиков и техлидов, а результат строился на уже известной команде информации: описаниях задач, истории похожих работ и прошлых оценках.

Мы отдали эту работу агенту, которого назвали Эстима. Через 1,5 месяца пилота сходимость его оценки с ручной достигла 95%. После этого встречу отменили, валидацию оставили техлидам и получили экономию около 20 человеко-дней в месяц.

Именно Эстима помогла команде поверить в практическую ценность AI. За ней появились агенты для работы с Jira, ревью кода, разработки, тестирования, аналитики и AppSec. Вместе они постепенно изменили наш PDLC.

Привет, Хабр! Меня зовут Михаил Чернов, я старший IT-лидер направления развития IT взыскания в Альфа-Банке. В этой статье расскажу о нашем опыте перестройки производственного процесса на AI-рельсы, включая пилоты, ограничения и вопросы, на которые мы пока ищем ответы.

Всем привет, я Михаил Салахов, руководитель направления архитектуры решений. В сфере информационных технологий работаю больше 20 лет, и последние 5 занимаюсь архитектурой в Альфа-Банке. За свою карьеру успел поучаствовать в огромном количестве проектов в различных ролях от инженера программиста до руководителя технического подразделения.

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

— Архитектор решений — кто это?
— Чем занимается архитектор решений и какие границы ответственности?
— Откуда приходят архитекторы решений?
— Откуда брать знания?
— Что ждет на собеседовании?
— Как пережить онбординг?
— Как проходит первый год архитектора решений?
— Рабочий день архитектора решений
— Каковы перспективы у архитектора решений?

Несколько раз в год отдел оптимизации офисного пространства Альфа‑Банка думает над тем, как разместить сотрудников бэк‑офиса по локациям на несколько лет вперёд. Раньше ребята делали это вручную: было медленно (месяц работы), больно (Excel) и неоптимально (никто не мог гарантировать, что найденная рассадка удовлетворяет всем ограничениям).

Коллеги хотели автоматизировать ручную работу — с этим они и пришли к нам. 

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

В какой‑то момент я осознал, что у меня много источников данных, есть мощная машинка в виде MacBook Pro M4 Max со 128 гигами оперативки, и надо как‑то это объединить, чтобы эффективно использовать. Всё же такую покупку согласовывали под использование ИИ, а не просто так я решил потратить деньги.

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

В целом Hermes выглядел идеально: есть память, скиллы, которые он пишет сам (ну и ты, конечно, тоже можешь написать), простота установки и использования, крон‑задачи. В общем, полный комплект.

Я радовался, что всё работает. Потом понял, что это была видимость работы, и разочаровался. Пересмотрел подходы и переизобрёл то, о чём, естественно, писали не раз, но зато у меня всё стало работать.

В статье не буду рассказывать о том, как установить Hermes, подключить Codex и наслаждаться. Будут локальные модели, виртуалки, шишки и преодоление в истинно инженерном стиле.

Казалось бы, на дворе 2026 год, есть статьи про доступность (и ещё больше на английском) и, собравшись организовать повышение доступности у себя в отдельно взятом «корпоративном микрорайоне», просто берёшь, читаешь, сталкиваешься с тем, что о процессах организации разработки и тестирования accessibility мало что есть, но не останавливаешься, так как молод, полон сил и наивен, и проживаешь год, полный удивительных приключений и невыносимой радости бытия.

Меня зовут Шуст Иван, за мной закреплено более 15 продуктовых команд, что делают фичи ежедневного входа, профиля, истории операций и связанные с безопасностью. Поэтому я, как лид, имею прямое отношение к процессам внедрения accessibility в Альфе, проживший последний год, пытаясь наладить и внедрить процессы accessibility, расскажу о всех граблях, которые мы собрали. Вы узнаете о рабочих подходах при работе с доступностью и как делать вот точно-точно не надо. 

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

Меня зовут Роман, я работаю продактом в Альфа-Банке. В первые дни работы ко мне перешла команда разработки, которая сформировалась буквально за 2 месяца до меня. Прошлый продакт работал на 3 команды, времени на всех не хватало, поэтому команда встретила меня холодно. Как я это понял? По ретро — несмотря на то, что мы не закрывали планируемые задачи на спринт, у всех «все было хорошо» и «обсуждать нечего», а ребята больше работали как одиночки, чем как команда. 

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

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

Или как один лотерейный билет превратился в несколько сотен требований, десятки интеграций и пять месяцев Discovery.

Когда мне предложили заняться разработкой с нуля цифрового сервиса Альфа‑Мании, я была уверена, что понимаю задачу. Что может быть проще? Клиент открывает мобильное приложение банка, выбирает лотерейный билет, оплачивает его, ждет розыгрыш и, если цифры в лотерейном билете совпали — получает выигрыш. На первый взгляд всё выглядело как вполне стандартный цифровой продукт: несколько экранов мобильного приложения, интеграция с партнером, немного аналитики, немного CRM‑коммуникаций и привычная продуктовая работа.

Я никогда так не ошибалась.

Через несколько месяцев я уже обсуждала особенности прогрессивной шкалы НДФЛ, разбиралась в требованиях к онлайн‑кассам, участвовала в проработке процессов идентификации победителей и спорила с коллегами о трактовке отдельных пунктов законодательства о лотереях. 

При этом ТЗ всё ещё не было.

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

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

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

Меня зовут Анастасия Солдатова, я технический лидер системной аналитики в Альфа-Банке, и в этой статье я расскажу, как мы собирали нашу базу, на какие грабли наступили, и как вы можете сделать аналогичный работающий инструмент за 6 недель. И вот у вас есть нормальная база знаний, которая превращает ИПР из гадания на кофейной гуще в конструктор с понятными деталями.

Что будет, если платить детям за то, что они помыли посуду? Будут ли их мотивировать только деньги? Или есть что-то важнее?

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

И, кажется, ни одна функция детского банка не вызывала столько споров, как задания: «А что дальше? Будем платить детям за уборку комнаты? За пятёрки? За то, что они вообще соизволили вынести мусор?»

Для многих детских задания выглядят именно как семейный маркетплейс, где ребёнок выставляет счёт за каждое полезное действие. Когда мы начинали делать эту фичу в Альфа-Банке, мы тоже боялись скатиться к «Вынеси мусор — получи 50 рублей». Но что, если это будет не про оплату действий, а про развитие самостоятельности?

У нас две аудитории: родители (которые хотят быть наставниками, а не банкоматами) и дети 6–13 лет (для которых карта — первый опыт обращения с деньгами). Привет, меня зовут Алексей Богомолов, я дизайнер цифровых продуктов, я расскажу, как мы стартовали с парой неочевидных гипотез и о том, как некоторые результаты нас сильно удивили.