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

Даже для опытных пользователей системы (продукт-оунеры, техлиды, CTO, руководители уровня B-1, сотрудники кост-менеджмента) это не всегда просто, тем более для новых. Значительная часть времени уходит не на работу в системе, а на поиск информации в разрозненных источниках: Excel-таблицы, письма, локальные заметки или уточнение деталей у коллег. Отсюда и появилась идея AI-ассистента как удобного способа получать ответы в одном месте, обычным человеческим языком.

Python почти стандарт для AI-проектов, но мы, как и большинство продуктовых команд в банке, используем JVM-стек: Kotlin, Java, Spring Boot. Поэтому осознанно выбрали развивать AI-ассистента в уже знакомом стеке. Это не просто техническое предпочтение. Мы хотели сохранить поддержку и масштабируемость внутри команды и  не привлекать новые компетенции, которых у нас пока нет.

Наш опыт может быть полезен командам, которые работают в JVM-среде и хотят внедрить AI без перехода на другой стек.

Привет, Хабр! Меня зовут Никита Чубаров. По трудовому договору я инженер-эксперт по разработке и сопровождению сервисов, а по факту DevOps-инженер с фокусом на доставку в платформенных командах, которые поставляют общие решения для десятка дочерних команд. Со временем эта доставка перестала быть прозрачной и предсказуемой, и всё больше напоминала космолёт, в котором пилот перед каждым запуском вручную подключает провода, проверяет давление в контурах и по списку нажимает десятки кнопок. Пока запусков мало, это ещё можно представить, но когда их становится сотни, а кораблей — десятки, такая схема быстро превращается в источник ошибок и выгорания.

Примерно в таком состоянии у нас находился Bootstrap Namespaces. В статье я расскажу, как мы прошли путь от сложной CI-оркестрации к декларативному управлению Bootstrap Namespaces через Argo CD и GitOps, какие проблемы это позволило убрать и какие новые ограничения пришлось принять.

В 2020–2021 годах казалось, что Agile-коуч нужен каждой компании. Стартапы, корпорации, банки, ритейл, госсектор одновременно приобщались к Agile: нанимали коучей, запускали трансформации и рисовали красивые роадмапы изменений.

А дальше что-то пошло не так.

С 2023 года вакансий стало меньше, требования ужесточились, а бюджеты начали сжиматься. И в комьюнити всё громче зазвучали вопросы: «Agile умирает или это взросление? А что будет с профессией Agile Coach дальше?».

Привет, Хабр! Меня зовут Константин Левкин, я Head of Agile в Райффайзен Банке. Не смог пройти мимо этой темы и решил основательно разобраться и собрать факты о том, что происходило в последние годы. Как изменился рынок труда, что происходит с зарплатами, ролями, какие региональные различия возникают и есть реальные результаты прошедших трансформаций. Хочу поделиться нарытыми данными и выводами на их основе. Совсем далёкие прогнозы в наши нестабильные времена делать опрометчиво, поэтому ограничусь своим видением изменений в профессии Agile Coach до 2029 года.

Во многих местах статьи есть умышленный уклон на данные рынка США, так как многие тренды в IT проходят путь США-Европа-Россия за 2-3 года. То есть та реальность и те данные в отчетах по рынку США сегодня, вполне могут стать нашей реальностью через пару лет.

Если сильно упростить, Agile прошёл тот же путь, что и многие управленческие идеи до него.

2019–2020
Agile это про команды. Scrum, спринты, ретроспективы, velocity.
Agile-коуч — это фасилитатор и тренер.

2021–2022
Рынок перегревается. Спрос растёт быстрее качества. Зарплаты Agile-коучей в США за два года вырастают на 30–50%.

Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?

Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.

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

Корпоративный архитектор — это «демон Максвелла», и его задача — бороться со сложностью ИТ-ландшафта. У нас в Банке это добрый демон, оперирующий подходами Just Enough Enterprise Architecture (JEEA) и Lightweight Architecture Governance (LAG). Именно корпоративные ценности и культура в Банке делают демона добрым. Поверьте мне, ведь я один из них.

Привет, Хабр! Меня зовут Дмитрий Клецких. Я Chief Enterprise Architect в Райффайзен Банке. До этого много лет работал корпоративным архитектором в других компаниях: МКБ, СБЕР, Транснефть, Правительстве Москвы. Поговорим об изменениях ИТ-ландшафта, организационных и технологических трансформациях, о роли архитекторов и изменении этой роли с приходом ИИ.

В Райффайзен Банке 14 профессиональных сообществ и 262 Agile-команды. Все эти люди взаимодействуют между собой, создают артефакты и проекты с разной скоростью, качеством и своими решениями. Чтобы все это не превратилось в хаос, в корпорации начали выстраивать инженерные практики — для унификации/стандартизации решений.

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

Привет, Хабр! Вы когда-нибудь тратили слишком много драгоценного времени на поиск нужного testTag в иерархии Compose Screen? А потом ещё полдня чинили тесты после каждого чиха в UI? Или, может быть, несколько недель ждали, пока в дизайн-систему добавят недостающий тег или семантику, чтобы вообще начать писать свой UI-тест? Если вы хоть на один вопрос ответили «Да», эта статья для вас. Давайте навсегда покончим с этой рутиной и займемся более креативными задачами!

Цель статьи — НЕ представить очередной фреймворк написания UI-тестов для приложений на Android, а упростить их написание с помощью всем знакомого Page Object. Мы будем прятать рутину поиска нужных компонентов и одновременно повышать устойчивость тестов к изменениям. Всё для того, чтобы тесты стали удобнее, надёжнее и проще поддерживались.

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

В 2018 я впервые познакомился с Kotlin, и он мне практически сразу понравился. Да и как можно не полюбить язык, названный в честь тотемного животного всех программистов? Шучу, на самом деле в честь острова.

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

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

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

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

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

Термин «artificial intelligence» в английском языке означает не столько «интеллект», сколько «умение логически мыслить». Это значит, что ИИ — это не аналог человеческого интеллекта, способного познавать мир и понимать суть вещей (согласно определению Линды Готтфредсон), а лишь система, которая способна делать выводы, решать задачи, понимать сложные концепции, быстро осваивать новое и учиться на основе полученного опыта.

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

Всем привет!

Меня зовут Илья, я работаю в Райффайзен Банке. Мы пишем свои бэкенд-сервисы на Java и Kotlin, поэтому зачастую приходится переключаться с одного языка на другой. Из-за этого невольно начинаешь сравнивать подходы и механизмы одного языка с его JVM-собратом. Сегодня я бы хотел поговорить об одном из таких механизмов — пропагации ошибок и исключений.

Используете ли вы в своем коде исключения? Ответ кажется странным, так как исключения являются неотъемлемой частью Java. Но что, если я спрошу, используете ли вы исключения для управления логикой своей программы?

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

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

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

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

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

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

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

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

Привет, Хабр! Меня зовут Алёна, я senior фронтенд-разработчик отдела разработки ПО для розничного бизнеса в Райффайзенбанке. Недавно передо мной встала задача улучшения пользовательского опыта обработки ошибок запросов к бэкенду. Я решила комплексно исследовать эту тему на примере HTTP-клиента Axios.

Если при отправке запросов с помощью Axios возникает ошибка — клиентское приложение получает аргумент, который может быть экземпляром объекта, производного от системного класса Error, или любым типом. Он может содержать много информации и не всегда понятно, что самое важное для определения типа исключения и способа обработки. Поэтому я выделала 4 категории ошибок запросов, сделанных при помощи Axios, которые нужно по-разному интерпретировать.

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

Статья будет полезна не только дизайнерам, но и разработчикам. Так вы сможете посмотреть на себя и свою работу со стороны, понять, как вас воспринимают дизайнеры, и, возможно, пересмотреть свое отношение к дизайн-процессу. Давайте начнём!

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

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

В этой статье расскажу, как мы объединили несколько разных команд разработки Райффайзен Онлайн общим Observability и с помощью исключительно технических метрик отслеживаем здоровье бизнес-процессов. Как всё это помогает мгновенно находить первопричину сбоя. Как устроен OpenTelemetry и как с его помощью рассчитать доступность приложения в девятках, а также MTTR (Mean Time to Recovery).

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

Привет, Хабр! Я старший системный аналитик Федор Качан. Попробую рассказать, почему эмоциональный интеллект может быть важнее IQ. Зачем соблюдать баланс между IQ и EQ. Что такое эмоциональная шкала и как развить свой эмоциональный интеллект в любом возрасте.