Привет! Меня зовут Анна и я QA-инженер в Банки.ру. В этой статье я расскажу о том, как мы сделали инструмент нагрузочного тестирования доступным для каждого инженера в компании.

Представьте: команда запускает новый микросервис, который будет отдавать информацию о банковских продуктах. Сервис покрыт автотестами, билды зеленые, все работает штатно. Но через пару часов после деплоя в прод сервис начинает падать под наплывом пользователей, время ответа превышает 10 секунд, разделы лежат, ПАНИКА!

Знакомо? У нас было подобное. В статье расскажу подробно про наш опыт!

Привет! Меня зовут Антон, я iOS-разработчик в Банки.ру. Когда я только начинал изучать Combine, он казался для меня магией. Пара команд – и вот у тебя уже есть какие-то данные. Чтобы Combine перестал оставаться черным ящиком давайте заглянем внутрь. Эта статья – мое виденье этого фреймворка.

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

Давайте рассмотрим Combine изнутри!

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

8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.

Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂.  А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.

Всем привет! Меня зовут Артем, я фронтенд разработчик в Банки.ру. Недавно перед нашей командой встала задача внедрить SSO-аутентификацию через Keycloak для клиентских сервисов. Помимо базовой настройки важно было полностью переработать стандартные формы входа, чтобы они соответствовали корпоративному стилю и UX-требованиям.

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

Привет! Меня зовут Андрей, я разработчик из команды контента в Банки.ру.

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

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

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

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

– Почему часть важных изменений в команде не приживается и откатывается к началу, хотя, кажется, мы все вместе нашли консенсус?
– Да каким образом мы снова не попали в сроки проекта, хотя у нас прекрасная опытная команда.
– Какова причина нежелания команды переходить на актуальный стек? Или наоборот, почему члены команды упорно тащат в ключевой проект сырые фреймворки и необкатанные подходы?
– Снова по итогам проекта у нас переусложненная и запутанная архитектура. Что мы делаем не так?

Давайте разбираться!

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

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

Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру. Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).

Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.

В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить,  что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему — технический долг и как с ним работать.

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

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

Привет! Это Александр, DevOps инженер из Банки.ру. В прошлой статье я рассказал про сборку сетевого хранилища на базе XPenology. Сегодня продолжу тему Proxmox и XPenology и поделюсь историей о неудачном апгрейде инженерными CPU мини-ПК Lenovo из первой статьи и чем она закончилась.

Всем привет! Меня зовут Женя. Я инженер поддержки бизнес-приложений в компании Банки.ру.
Не так давно мы в направлении Мобайл решили прокачать технический и продуктовый мониторинг и с этой целью начали использовать Zabbix. В результате всю логику алертинга перенесли из Grafana в новый инструмент. Благодаря этому и родилась идея поделиться опробованными фишками Zabbix с сообществом. 

В этой статье я:

• расскажу об интересных возможностях Zabbix;
• поделюсь кейсами их использования и примерами настроек;
• сравню Zabbix и Grafana и расскажу, как мы применяем их в тандеме.

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

Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про Dependency Inversion Principle, потому что это, пожалуй, один из самых важных принципов SOLID, понимание которого дает ключи к архитектуре программного обеспечения. 

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

Привет! Меня зовут Илья, я iOS-разработчик в компании Банки.ру.

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

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

В статье разберем следующие темы:

• Что такое цвет и WOW-эффекты с ним
• Дискретизация и квантование
• Цветовые модели
• Цветовое пространство
• HEX-квиз и выводы

Всем привет! Меня зовут Павел, я Head of Development в Банки.ру. Сегодня хочу погрузиться с вами в, кажется, уже давно заезженные темы: Single sign-on, OAuth, OpenID и нюансы их реализации. 

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

Я решил восполнить этот пробел и подготовил именно такой материал.
В этой статье погрузимся в теоретическую часть и рассмотрим: 

– основные Flow OAuth 2.0 и отдельно Authorization Code Flow with Proof Key for Code Exchange;
– OpenID Connect (OIDC);
– Single Sign-On или SSO: схему реализации и применение SSO в мобильных и веб-приложениях.

Привет! С вами снова Александр, DevOps из Банки.ру. Прошлая статья «Домашний сервер на базе Proxmox» вызвала интерес сообщества и бурное обсуждение в комментариях. 

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

Привет! Меня зовут Бальцер Вадим, я QA-инженер в команде android направления Банки.ру. Сегодня поделюсь нашим опытом внедрения автотестов обратной совместимости и интеграции их в CI. 

В материале расскажу: 
1) зачем нашей команде понадобились автотесты для контроля обратной совместимости API, почему мы выбрали Postman CI.
2) с чего начали: базовые вещи + полезные советы для начинающих.
3) есть ли жизнь за гранью проверок схемы.
4) CI и интеграция с ТестОпс.
5) к чему пришли и какие перспективы видим.

Также добавлю примеры примеры кода и небольшие советы, которые могут пригодиться, если вы еще только присматриваетесь к Postman как к инструменту автоматизации проверок API.

Привет! Меня зовут Андрей, я Head of Platform в финансовом маркетплейсе Банки.ру. Со мной Борис Зырянов, go/php разработчик. Сегодня расскажем о том, как мы разработали и внедрили процесс создания сервисов одной кнопкой. 

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

В материале расскажем: 

– как работал старый подход и с чем были сложности; 
– какая схема пришла на замену и как все работает; 
– что планируем делать дальше.

Всем привет! Меня зовут Фарид, я занимаюсь iOS-разработкой в компании Банки.ру.

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

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

В этой статье мы: 

1) пройдёмся по основным подходам к поиску утечек; 
2) попробуем найти способ сделать его обнаружение утечек менее болезненным;
3) выясним, можно ли каким-то образом застраховаться от утечек в будущем развитии проекта.

Привет! Меня зовут Лев, я руководитель интеграционной разработки в финансовом маркетплейсе Банки.ру.

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

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

1. В чем заключалась проблема в управлении секретами, как мы её решили и как могли бы улучшить этот процесс.
2. Какие способы хранения секретов существуют и как их можно интегрировать.
3. Как можно реализовать хранение через Vault.
4. Что такое политики доступа и как они применяются к структурам секретов.
5. Варианты реализации, которые наилучшим образом подходят для нашей конкретной ситуации.

Привет! Меня зовут Александр Щербаков. Я DevOps команд страхования в Банки.ру. На своём карьерном пути я успел поработать эникейщиком, системным администратором и, наконец, DevOps‑инженером с несколькими командами разработки. Как и любой инженер, я стремлюсь постоянно совершенствоваться: получать новые знания, изучать как устоявшиеся, так и только появившиеся технологии.

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

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

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