Инженерная культура Росбанка: что это и какие у неё принципы
Привет, Хабр! Меня зовут Кирилл Покладов, я ИТ-директор корпоративного, инвестиционного и депозитарного бизнеса в Росбанке. В этом посте я расскажу про инструмент, который помогает нашему банку развиваться быстрее и бороться со стереотипом о том, что все банки неповоротливы, а любой релиз там занимает уйму времени. Этот инструмент — наша инженерная культура.
Что такое инженерная культура
Инженерная культура — это набор практик, паттернов поведения и принятия решений, который помогает достичь максимальной эффективности процесса разработки. В основе инженерной культуры несколько ключевых целей.
Быстрый выход в прод — мир стремительно меняется, и наши продукты не должны отставать.
Современные подходы к разработке — стремимся к уровню мировых технологических гигантов.
Надежность и безопасность продуктов — внедряем современные практики, такие как SRE (Site Reliability Engineering), как в Google, и Chaos Engineering, как в Netflix.
Разнообразие и сложность задач — так разработчики чувствуют больше сопричастности к проектам.
Повышение ценности сотрудников — как результат работы с использованием инженерной культуры.
Принципы инженерной культуры
С целями разобрались, теперь очередь за принципами, которые помогают их достигать. Принципы сформулированы максимально просто и понятно, но под собой имеют глубокое значение.
Работаю в полях, подаю пример
Каждый из нас, от директора до новичка в команде, призван не бояться «запачкать руки» и погружаться в задачи на полную глубину.
У меня в департаменте более 100 систем, которые мы постоянно дорабатываем и сопровождаем. Объем изменений огромный, решения по развитию нужно принимать постоянно. Я сам курирую и подробно разбираю многие проекты, но, конечно, крупным отдаю приоритет. К каждому из них подхожу тщательно: изучаю архитектуру, проверяю состав команды, вместе с ней верстаю бюджет и участвую в составлении планов развития.
Решая повседневные проблемы, я стараюсь быть в контексте происходящего: участвую во внутрикомандных митапах, провожу звонки с командами и решаю возникающие у ребят сложности. Мой пример не единичный для Росбанка, по такому принципу работают и другие команды. Передаю слово команде «Ситуационный центр» — главному ИТ-менеджеру Сергею Терещенко и главному специалисту Артёму Шнайдеру:
Наша команда занимается мониторингом ИТ-систем банка 24/7, координацией решения и сопровождения инцидентов, а также обеспечивает бесперебойную работу телекоммуникации. Наши дежурные смены используют несколько практик, которые отражают принцип «Работаю в полях, подаю пример»:
лидеры команд практически ежемесячно выходят в смену;
организованы ежедневные «пятиминутки» для обсуждения и помощи в решении текущих вопросов, предложений, инцидентов;
раз в неделю лидеры команд ходят на встречи «один на один» для обмена опытом и обсуждения текущих вопросов.
Делаю как для себя
Этот принцип помогает нам разрабатывать качественно и с прицелом на будущее, продумывая каждую деталь. Например, Центр компетенций развития сервисов и практик разработки Росбанка разработал систему оформления техдолга. Подробнее об этом расскажет руководитель центра Захар Фролов:
Техдолг оформляется в бэклоге в виде задач, маркируемых разными способами: с помощью заранее определенных лейблов (Labels) или с помощью отдельного поля Component/s с заранее определенным именем. Затем задачи, относящиеся к техническому долгу, проходят тот же цикл оценки и декомпозиции, что и оставшиеся задачи в бэклоге.
По своему опыту мы рекомендуем брать в каждый спринт не менее 15% задач техдолга, чтобы избегать его накопления, в некоторых случаях больше, однако не всегда этот объем удается согласовать с заказчиком. Команды согласуют объем задач техдолга в каждом спринте, а затем стараются выполнять их строго в ранее согласованном порядке от спринта к спринту.
Использование общепринятого подхода к отслеживанию задач техдолга позволяет определить его объем в разрезе команды, продукта, направления для принятия управленческих решений и планирования работы команды.
Развивая существующее, предлагаю новое
Мы не рассматриваем текущие решения как наилучшие по умолчанию и всегда ищем лучшее среди новейших подходов и инструментов. При этом не спешим ломать старое, что уже себя зарекомендовало. Например, в Росбанке внедряем Chaos Engineering — встречи, где различные ИТ-команды могут провести управляемый эксперимент в виде paper test. По итогам после условного решения инцидента команда дополняет свои мониторинги и сценарии реагирования.
Об опыте Chaos Engineering расскажет главный специалист отдела внутрибанковских систем Дмитрий Ступин:
В нашем банке есть PWC (IFRS9) калькулятор, который рассчитывает резерв по методологиям международных стандартов финансовой отчетности. Калькулятор имеет пользовательский интерфейс для параметризации и контроля.
Обмен данными идет через ODPP (Online data processing platform) и файлы, выгружаемые из CDWH. Сам калькулятор предоставляет результаты своих расчетов в виде данных в таблицах баз MSSQL. Калькулятор разработан на платформе .NET Framework 4.6
В этой конфигурации для примера приведу paper test, где рассматривалась ситуация «Обрыв/потеря связи БД с приложением» (недоступность порта). Были выдвинуты гипотезы:
При кратковременном обрыве сессии с БД (потеря связи, недоступность порта) приложение работает штатно:
После восстановления соединения с БД сервис тоже восстанавливает работу без каких-либо проблем с приложением.
После восстановления соединения с БД сервис становится активен, но не соединяется повторно с БД, не обрабатывает входящие пакеты, и в логах мы видим отсутствие соединения.
Эти гипотезы были проверены на тестовом сервере приложения. По итогу проверки оказалось, что при кратковременной потере связи приложения с БД веб-приложение работает и активно, а сервисы при этом находятся в состоянии Running. Но когда связь с БД восстанавливается, приложение не обрабатывает запросы от БД, хоть и находится в статусе Running. В логах видим, что приложение по факту не работает и после восстановления соединения не переподключается. Возникает ошибка:
WARN NServiceBus.Transports.SQL Server.Sql Server Polling DequeueStrategy An exception occurred when connecting to the configured SQLServer instance System.Data.SqlClient.SqlException (0×80131904)
По итогам теста мы получили подтверждение второй гипотезы. На основании этого был настроен мониторинг в Zabbix, который проверяет лог на наличие ошибки и при ее появлении отправляет предупреждение на почту и в телеграм для рестарта сервиса.
Развиваюсь и делюсь опытом
Поддерживая и развивая друг друга, мы вкладываемся в наше будущее. Зная, за что отвечают и в чем сильны наши коллеги, мы обращаемся к ним за помощью, создавая единую команду, где каждый ценен.
На этом принципе основаны наши гильдии — профессиональные ИТ-сообщества, где инженеры обмениваются опытом, перенимают лучшие практики и прокачивают компетенции. Одни специалисты организуют и участвуют в различных HR-мероприятиях, например, постановке целей и оценке профессионального развития. Другие помогают поддерживать стандарты по стеку технологий и разрабатывают единые стандарты профессии в банке. Третьи помогают развивать профессию посредством образовательных митапов и конференций. DevOps, Java, QA, архитектура, администраторы, аналитика — это только часть направлений, по которым у нас есть гильдии.
Если вам интересно узнать о гильдиях больше, посмотрите запись митапа «Профсообщества в корпорациях: как, зачем и почему?», который проходил в офисе Росбанка в «Москва-Сити». Помимо Александра Денисова, директора департамента ИТ-поддержки пользовательских сервисов и клиентов цифровых сервисов Росбанка, в нем приняли участие эксперты из СБЕРа, Тинькофф и Aston.
Это далеко не все принципы инженерной культуры Росбанка. Об остальных я расскажу в следующей части материала. А пока я буду рад обсудить с вами, какие внутренние процессы увеличивают эффективность разработки в вашей компании.
