Привет, Хабр! Меня зовут Кирилл Покладов, я ИТ-директор корпоративного, инвестиционного и депозитарного бизнеса в Росбанке. В этом посте я расскажу про инструмент, который помогает нашему банку развиваться быстрее и бороться со стереотипом о том, что все банки неповоротливы, а любой релиз там занимает уйму времени. Этот инструмент — наша инженерная культура.
Что такое инженерная культура
Инженерная культура — это набор практик, паттернов поведения и принятия решений, который помогает достичь максимальной эффективности процесса разработки. В основе инженерной культуры несколько ключевых целей.
Быстрый выход в прод — мир стремительно меняется, и наши продукты не должны отставать.
Современные подходы к разработке — стремимся к уровню мировых технологических гигантов.
Надежность и безопасность продуктов — внедряем современные практики, такие как 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 (0x80131904)
По итогам теста мы получили подтверждение второй гипотезы. На основании этого был настроен мониторинг в Zabbix, который проверяет лог на наличие ошибки и при ее появлении отправляет предупреждение на почту и в телеграм для рестарта сервиса.
Развиваюсь и делюсь опытом
Поддерживая и развивая друг друга, мы вкладываемся в наше будущее. Зная, за что отвечают и в чем сильны наши коллеги, мы обращаемся к ним за помощью, создавая единую команду, где каждый ценен.
На этом принципе основаны наши гильдии – профессиональные ИТ-сообщества, где инженеры обмениваются опытом, перенимают лучшие практики и прокачивают компетенции. Одни специалисты организуют и участвуют в различных HR-мероприятиях, например, постановке целей и оценке профессионального развития. Другие помогают поддерживать стандарты по стеку технологий и разрабатывают единые стандарты профессии в банке. Третьи помогают развивать профессию посредством образовательных митапов и конференций. DevOps, Java, QA, архитектура, администраторы, аналитика — это только часть направлений, по которым у нас есть гильдии.
Если вам интересно узнать о гильдиях больше, посмотрите запись митапа «Профсообщества в корпорациях: как, зачем и почему?», который проходил в офисе Росбанка в «Москва-Сити». Помимо Александра Денисова, директора департамента ИТ-поддержки пользовательских сервисов и клиентов цифровых сервисов Росбанка, в нем приняли участие эксперты из СБЕРа, Тинькофф и Aston.
Это далеко не все принципы инженерной культуры Росбанка. Об остальных я расскажу в следующей части материала. А пока я буду рад обсудить с вами, какие внутренние процессы увеличивают эффективность разработки в вашей компании.
