Я не очень понимаю, почему об этом мало кто рассказывает.

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

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

Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.

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

Значение данных для эффективного управления организацией расчет с тех пор как больше ста лет назад Фредериком Уинслоу Тейлором были заложены основы научной организации труда. Появление компьютеров позволило вывести их обработку и использование на принципиально новый уровень. Объем используемых человечеством данных растет по экспоненте. По прогнозам экспертного сообщества их объем уже через три года (в 2025 году) достигнет 180–200 Зеттабайт.

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

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

Здесь мы приходим ко вполне предсказуемому, но все еще неочевидному для многих выводу: управление современной организацией невозможно без создания системы управления данными и, в частности, системы управления КАЧЕСТВОМ данных.

У нас в Газпромбанке сложилась довольно интересная ситуация. Банк относительно недавно начал активно работать с розницей, которая как локомотив начала тянуть все внутрибанковское IT и менять характер работы всех подразделений.

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

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

Корпоративное хранилище в ГПБ существует с девяностых. Тогда оно создавалось исключительно под задачи регуляторной и текущей отчетности. Соответственно и архитектура была такой, чтобы соответствовать требованиям этих задач

Изначально мы использовали SAP ASE. В нем была реализована довольно сложная бизнес-логика, и все работало довольно неплохо, но старая система не потянула бы расширение, не хватало производительности. Также были пробелы и в документировании — из-за огромного легаси, о котором даже спросить было некого.

По мере развития IT-ландшафта и появления новых систем, росли требования заказчиков, ставились новые задачи. В 2009 году стало понятно, что надо менять подход к работе с КХД, аналитическую платформу и инструменты по работе с хранилищем. Выбрали новые: SAP IQ, а в качестве «интеллекта» — DataStage (тогда он еще не принадлежал IBM). 

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

После летнего затишья начинается череда ИТ-конференций (ближайшие — Saint HighLoad, TeamLead Conf и TechTrain). Мы решили помочь всем, кто собирается впервые примерить на себя роль спикера. Вместе с руководителем нашего DevRel&TechPR Алиной Романовской и фаундером компании «Глагол» Артемом Гусевым сделали гайд для тех, кто хочет выступать на конфах и митапах, но не знает как.

Этой весной правительство запустило программу льготной ипотеки для IT-специалистов. С ее помощью кредит на жилье можно взять по ставке до 5%. Но для этого нужно соблюсти несколько условий. Сделали короткую памятку по главным.

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

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

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

Под катом шесть вопросов, их задают себе системные архитекторы Газпромбанка, когда хотят понять, пора пилить микросервисы или можно обойтись монолитом.

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

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

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

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

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

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

Реактор сегодня - это стильно, модно, молодежно. Почему многие из нас практикуют реактивное программирование? Мало кто может ответить однозначно на этот вопрос. Но эта статья рассказывает не об этом, а о проблемах, которые реактор может создать даже опытному программисту и о методах их решений. Берем под контроль количество одновременно выполняемых задач, правильно распределяем задачи в пуле и достигаем отличных результатов с параллельной обработкой в reactor.