Содержание:
Это вторая статья про создание в Газпромбанке сервисной цифровой платформы (СЦП). Здесь я расскажу, как появление СЦП радикально изменило процессы разработки, а заодно – и взаимодействий ИТ и бизнеса в ходе проектов информатизации.
Особенности технической реализации СЦП
В предыдущей статье мы рассказали, что такое СЦП и почему это очень важный для банка проект. А в этом материале остановимся на технических деталях.
К СЦП, как и к любой технологической платформе предъявляются жесткие требования по доступности и отказоустойчивости.
Один из ключевых факторов обеспечения высокой доступности — исполнение ПО кеширующего слоя в формате In-memory Data Grid. Технология In-memory Data Grid (IMDG) предполагает хранение данных в оперативной памяти распределенного кластера, что позволяет получить отказоустойчивый слой кеширования данных. Решение платформы кеширования СЦП Газпромбанка запущено в облаке виртуальных серверов, на каждом из которых под IMDG выделено около 512 Гб оперативной памяти. Сервера распределены по разным ЦОДам банка в отказоустойчивой конфигурации с репликацией и резервированием.
Система IMDG создана на основе программного продукта Tarantool компании Mail.Ru, который обеспечивает шардирование данных, то есть возможность их горизонтального масштабирования. Набор данных разбивается на части, которые распределяются по множеству нод, на каждом из которых находится экземпляр сервера базы данных Tarantool. Подход позволяет достичь высокой отказоустойчивости СЦП.
Кроме того, модуль VShard, который отвечает за горизонтальное масштабирование в СУБД Tarantool, включает ряд других полезных возможностей для шардирования и оркестрации распределенного хранилища данных. Механизм Change Data Capture (CDC) дает возможность собирать информацию из разных источников и направлять их на дальнейшую обработку (процесс ETL (Extraction, Transformation, Loading)). Механизм полезен для интеграции кеширующего слоя с разными корпоративными информационными системами, выступающими источниками данных для СЦП.
Это важно, поскольку далеко не все прикладные системы, особенно те, которые принято причислять к классу legacy, поддерживают современные интеграционные решения типа брокера сообщений Apache Kafka. Нередко приходится описывать интеграционные процессы буквально вручную, и здесь помогает функционал CDC.
Работой над постоянным улучшением IMDG занята отдельная команда, которая, помимо прочего, разрабатывает и оптимизирует программные интеграции.
Для достижения максимально высокой производительности платформы необходимо применять целый спектр инструментов. Один из них — chaos-тестирование, оно позволяет эмулировать отказы системы под нагрузкой, причем в реальных условиях продуктивной эксплуатации.
Большая проблема разработки высокопроизводительных систем заключается в том, что даже тщательно продуманный код под высокой нагрузкой может вести себя непредсказуемо. И даже нагрузочное тестирование здесь не даст 100% уверенности в том, что все будет так же хорошо в реальной продуктивной среде. Ведь в реальных условиях работают сотни таких сервисов, и многие связаны друг с другом с помощью синхронного или асинхронного API. Значит, если какой-то сервис на продакшене превысил заданное время отклика, связанный с ним сервис может не сработать так, как нужно — вплоть до отказа на стороне клиента.
Вот почему в работе СЦП большую роль играет оптимизация процессов обработки данных. Собственно, для этого мы используем chaos-подход. Этот стиль оптимизации можно назвать проектированием на отказ: изначально создавать систему так, что отказ любого компонента никак не повлияет на соседние. На наш взгляд, это обязательная практика при проектировании нагруженных распределенных систем.
Система IMDG создана на основе программного продукта Tarantool компании Mail.Ru, который обеспечивает шардирование данных, то есть возможность их горизонтального масштабирования. Набор данных разбивается на части, которые распределяются по множеству нод, на каждом из которых находится экземпляр сервера базы данных Tarantool. Подход позволяет достичь высокой отказоустойчивости СЦП.
Кроме того, модуль VShard, который отвечает за горизонтальное масштабирование в СУБД Tarantool, включает ряд других полезных возможностей для шардирования и оркестрации распределенного хранилища данных. Механизм Change Data Capture (CDC) дает возможность собирать информацию из разных источников и направлять их на дальнейшую обработку (процесс ETL (Extraction, Transformation, Loading)). Механизм полезен для интеграции кеширующего слоя с разными корпоративными информационными системами, выступающими источниками данных для СЦП.
Это важно, поскольку далеко не все прикладные системы, особенно те, которые принято причислять к классу legacy, поддерживают современные интеграционные решения типа брокера сообщений Apache Kafka. Нередко приходится описывать интеграционные процессы буквально вручную, и здесь помогает функционал CDC.
Работой над постоянным улучшением IMDG занята отдельная команда, которая, помимо прочего, разрабатывает и оптимизирует программные интеграции.
Для достижения максимально высокой производительности платформы необходимо применять целый спектр инструментов. Один из них — chaos-тестирование, оно позволяет эмулировать отказы системы под нагрузкой, причем в реальных условиях продуктивной эксплуатации.
Большая проблема разработки высокопроизводительных систем заключается в том, что даже тщательно продуманный код под высокой нагрузкой может вести себя непредсказуемо. И даже нагрузочное тестирование здесь не даст 100% уверенности в том, что все будет так же хорошо в реальной продуктивной среде. Ведь в реальных условиях работают сотни таких сервисов, и многие связаны друг с другом с помощью синхронного или асинхронного API. Значит, если какой-то сервис на продакшене превысил заданное время отклика, связанный с ним сервис может не сработать так, как нужно — вплоть до отказа на стороне клиента.
Вот почему в работе СЦП большую роль играет оптимизация процессов обработки данных. Собственно, для этого мы используем chaos-подход. Этот стиль оптимизации можно назвать проектированием на отказ: изначально создавать систему так, что отказ любого компонента никак не повлияет на соседние. На наш взгляд, это обязательная практика при проектировании нагруженных распределенных систем.
Как мы выстраиваем параллельную разработку в СЦП
На платформе СЦП работают несколько сотен микросервисов и поддерживается около 500 сценариев волеизъявления. Точные цифры вряд ли кто-то сможет назвать, потому что в каждый момент времени одна из множества команд может завершить разработку очередного сервиса. Это именно то, ради чего затевалось создание сервисной цифровой платформы: все команды работают параллельно, самостоятельно берут в пользование готовые микросервисы, выполняют разработку и выводят микросервис в продакшн. Семейство инфосервисов тоже постоянно пополняется. Ведь при выводе на рынок нового продукта обычно нужен и новый инфосервис, который будет отображать необходимые данные. Его также выкладывают в продакшн, и им начинают пользоваться другие команды.
Платформа позволяет командам автономно разработать сценарий волеизъявления, новый функционал, новый UI для него и вывести в продакшн. На платформе появляются новые интеграции с этим сценарием, которым мы выставляем API для использования разными командами.
Наглядный пример. В рамках платформенного стрима мы разрабатываем типовой функционал, техническую «трубу» для процессинга активных заявок клиентов. Что это подразумевает?
Команды через технический слой API пользуются нужными возможностями платформы. Есть, например, сервис гарантированной доставки в backend — команде не надо задумываться об этом аспекте работы. Достаточно сообщить, что заявка готова к отправке, и платформа самостоятельно убедится в том, что заявка попадет в backend и пройдет нужную обработку. Или, как в примере с электронной подписью, команде достаточно указать у себя в сценарии «Здесь должна быть подпись», и платформа сама запросит подпись, отправит документ клиенту на подпись и выполнит другие шаги.
Этот пример хорошо демонстрирует, как нам удалось построить обезличенный конвейер по процессингу входящих заявок: платформа предоставляет технический сервис и ничего не знает о бизнесе.
Платформа позволяет командам автономно разработать сценарий волеизъявления, новый функционал, новый UI для него и вывести в продакшн. На платформе появляются новые интеграции с этим сценарием, которым мы выставляем API для использования разными командами.
Наглядный пример. В рамках платформенного стрима мы разрабатываем типовой функционал, техническую «трубу» для процессинга активных заявок клиентов. Что это подразумевает?
Команды через технический слой API пользуются нужными возможностями платформы. Есть, например, сервис гарантированной доставки в backend — команде не надо задумываться об этом аспекте работы. Достаточно сообщить, что заявка готова к отправке, и платформа самостоятельно убедится в том, что заявка попадет в backend и пройдет нужную обработку. Или, как в примере с электронной подписью, команде достаточно указать у себя в сценарии «Здесь должна быть подпись», и платформа сама запросит подпись, отправит документ клиенту на подпись и выполнит другие шаги.
Этот пример хорошо демонстрирует, как нам удалось построить обезличенный конвейер по процессингу входящих заявок: платформа предоставляет технический сервис и ничего не знает о бизнесе.
Как достигается высокое качество параллельной разработки
В ситуации, когда множество взаимоувязанных процессов исполняется автоматически, возникает много «подводных камней» — как раз потому, что команды работают независимо друг от друга. Чтобы обеспечить защиту от потенциальных проблем на этапе рабочей эксплуатации информационных систем, в банке предусмотрены мероприятия контроля качества всех ведущихся разработок ПО. Они реализуются на базе концепции Quality Gates, которая предполагает разбиение процесса разработки на этапы, и на каждом проводится проверка на соответствие определенным критериям.
В числе таких критериев — уровень покрытия сервиса тестами: если этот уровень не достигает 70%, текущая сборка ПО дальше не пропускается. Есть контрактные тесты, которые проверяют совместимость двух микросервисов и их способность взаимодействовать без проблем. Проверка класса API first помогает убедиться, что сервис выставил спецификацию интерфейса. То есть разработчику мало написать новую программную интеграцию, нужно еще провести всесторонние тесты работоспособности.
Гарантией работоспособности сложного и постоянно развивающегося микросервисного механизма становится максимальная автоматизация проверок на самых ранних этапах разработки. Такой подход в теории называется Shift Left и подразумевает сдвиг тестовых проверок как можно ближе к началу разработки. Так удается значительно снизить себестоимость исправления ошибок по сравнению с традиционным методом тестирования уже готового продукта. Сводится к нулю и количество конфликтов в коллективе, ведь все знают, как могут обостриться отношения между бизнес-командой, у которой горят сроки выпуска продукта, и группой тестирования, чьи требования мешают ускорить процесс.
Наша команда тестирования не столько участвует в «пожаротушении», сколько работает над улучшением стандартов тестирования, чтобы качество разработки стало еще выше. Выделенная команда в этом случае — идеальное решение: заниматься качеством разработки по остаточному принципу от решения бизнес задач практически нереально.
В числе таких критериев — уровень покрытия сервиса тестами: если этот уровень не достигает 70%, текущая сборка ПО дальше не пропускается. Есть контрактные тесты, которые проверяют совместимость двух микросервисов и их способность взаимодействовать без проблем. Проверка класса API first помогает убедиться, что сервис выставил спецификацию интерфейса. То есть разработчику мало написать новую программную интеграцию, нужно еще провести всесторонние тесты работоспособности.
Гарантией работоспособности сложного и постоянно развивающегося микросервисного механизма становится максимальная автоматизация проверок на самых ранних этапах разработки. Такой подход в теории называется Shift Left и подразумевает сдвиг тестовых проверок как можно ближе к началу разработки. Так удается значительно снизить себестоимость исправления ошибок по сравнению с традиционным методом тестирования уже готового продукта. Сводится к нулю и количество конфликтов в коллективе, ведь все знают, как могут обостриться отношения между бизнес-командой, у которой горят сроки выпуска продукта, и группой тестирования, чьи требования мешают ускорить процесс.
Наша команда тестирования не столько участвует в «пожаротушении», сколько работает над улучшением стандартов тестирования, чтобы качество разработки стало еще выше. Выделенная команда в этом случае — идеальное решение: заниматься качеством разработки по остаточному принципу от решения бизнес задач практически нереально.
Как изменились взаимоотношения бизнеса и ИТ после внедрения СЦП
Как я упоминал, отделение бизнес-разработки от технического функционирования платформы — это архитектурное решение, которое дает компании много плюсов. Самые очевидные — повышение скорости и качества разработки, потому что все устают от постоянных проблем в продуктиве, свойственных традиционной разработке.
Однако после платформенной трансформации бизнес столкнется с нововведениями, к которым он может быть не готов. Дело в том, что параллельная разработка требует от бизнеса серьезной трансформации своей деятельности: если раньше взаимодействие с разработчиками происходило в формате «заказчик — исполнитель», то теперь в бизнес-команде должен работать свой Java-специалист, свой DevOps-инженер, аналитик, Frontend-разработчик. Именно им платформа предоставляет свои разнообразные умные и продвинутые сервисы, готовые библиотеки, стандарты и лучшие практики разработки. И только в этом случае реализуется та параллелизация разработки, которая радикально снижает time-to-market, общую стоимость разработки и значительно повышает качество этой разработки. Причем переход на платформенную парадигму, как и на Agile, нельзя осуществлять кусочно: на новых принципах нужно выстраивать работу всей организации.
За большие плюсы на уровне всего бизнеса компании приходится платить повышением стоимости содержания собственной команды разработки. Но в сухом остатке — отличные растущие показатели консолидированного отчета PNL (Profits and Loss statement), отражающего соотношения прибылей и убытков, и новый уровень корпоративной культуры разработки во всех бизнес-подразделениях. Цель точно оправдывает средства.
Однако после платформенной трансформации бизнес столкнется с нововведениями, к которым он может быть не готов. Дело в том, что параллельная разработка требует от бизнеса серьезной трансформации своей деятельности: если раньше взаимодействие с разработчиками происходило в формате «заказчик — исполнитель», то теперь в бизнес-команде должен работать свой Java-специалист, свой DevOps-инженер, аналитик, Frontend-разработчик. Именно им платформа предоставляет свои разнообразные умные и продвинутые сервисы, готовые библиотеки, стандарты и лучшие практики разработки. И только в этом случае реализуется та параллелизация разработки, которая радикально снижает time-to-market, общую стоимость разработки и значительно повышает качество этой разработки. Причем переход на платформенную парадигму, как и на Agile, нельзя осуществлять кусочно: на новых принципах нужно выстраивать работу всей организации.
За большие плюсы на уровне всего бизнеса компании приходится платить повышением стоимости содержания собственной команды разработки. Но в сухом остатке — отличные растущие показатели консолидированного отчета PNL (Profits and Loss statement), отражающего соотношения прибылей и убытков, и новый уровень корпоративной культуры разработки во всех бизнес-подразделениях. Цель точно оправдывает средства.
