Правильная технология для финтех-проекта с SLA 99,99%: Как минимизировать риски внедрения Open Source

Александр фон Розен: Наш бизнес — высоконагруженный финтех. Это не только процессирование платежей, но и обработка персональных данных в соответствии с Федеральным законодательством, выполнение различного рода аналитики и прочее — всего более 160 различных информационных сервисов. Мы обслуживаем более 20 млн клиентов по всей России и проводим более 1,8 млн платежей в сутки. При этом все время балансируем между сложностью решений, очень развитым интеграционным ландшафтом, растянутым Flow — один простой запрос пользователя порождает срабатывание очень сложной внутренней механики — и предоставлением высоких гарантий сохранения минимального времени отклика и управляемости, наш SLA превышает 99.99%.

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

Однако тогда опыта внедрения Kubernetes в индустрии еще накоплено не было, и те преференции, которые нам обещала эта технология, могли бы быть достигнуты и с помощью других средств, но с гораздо меньшими рисками. Только когда мы осознали, что это мейнстрим и что Kubernetes применяется очень многими крупными технологическими компаниями по всему миру, накопили внутреннюю экспертизу, провели R&D-цикл и изучили опыт профессионалов high-availability систем, мы все-таки решились внедрить эту технологию сразу для всех промышленных площадок и для сервисов.Витрина данных НОТА ВИЗОР для налогового мониторинга

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

Александр фон Розен: По опыту общения с инженерами различных проектов могу сказать, что в сфере финтеха мы были первопроходцами внедрения Kubernetes, и не только в Российской Федерации, но и в мире, по крайней мере среди бизнесов, с такими же, как у нас, финансовыми показателями и с такими рисками.

Выбирая эту технологию, мы допускали возможность определенной деградации и заблаговременно принимали соответствующие меры, чтобы «черные лебеди» не прилетели. Для поддержания SLA на требуемом уровне было решено осуществить внедрение таким образом, чтобы в случае выхода из строя всех подсистем Kubernetes работоспособность и управляемость инфраструктуры были сохранены. Для этого мы предусмотрели средства резервирования — определенный статический деплоймент, действующий, как с Kubernetes, так и без него.

Затем мы провели пилотное внедрение и опытную эксплуатацию на одной из наших демонстрационных площадок. Нагрузка там существенна и иногда сопоставима с нагрузкой в продакшн при проведении различных тестов.

Александр фон Розен: Изначально мы рассматривали коммьюнити-версию и ставили целью создание технологического стека с использованием единого подхода к реализации и эксплуатации всех наших финтех-информационных сервисов, и основных, и дополнительных, и аналитических. На тот момент у нас было четыре DevOps инженера, ответственных за соблюдение SLA 99,99% по 120 отдельным сервисам на нескольких промышленных площадках. Столкнувшись с существенным ростом нагрузки, мы решили заручиться сторонней экспертизой.

Александр фон Розен: Нам требовалась поддержка компетентной и сильной команды, готовой гарантировать, что ответы на наши вопросы будут предоставлены. Также нам нужен был контакт с инженерами, уже имевшими опыт внедрения Kubernetes. Кроме того, мы искали единомышленников, людей, которые любят свою работу, которые используют эту технологию, понимают проблемы клиента и хотят их решить, причем не только из-за денег, а потому что привыкли делать хорошо свою работу.

Так мы нашли компанию «Флант». По результатам нашего исследования рынка, она с огромным отрывом опережала всех остальных игроков, предоставляющих в России Kubernetes-платформу и экспертизу.

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

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

К тому же, санкционные риски в России в 2019 году очень выросли.

Александр Баталов: Упомянутый вами Red Нat пошел своим путем в решении задачи оркестрации. Пытаясь обогатить свою платформу новым функционалом, он, как и некоторые другие зарубежные вендоры, настолько далеко ушел от ванильной версии, что потерял совместимость. Обновления основной ветки на его платформу уже не устанавливаются, а конфигурации и настройки могут с ней не работать. Как результат, компания, выбравшая такого поставщика, попадает в полную зависимость от него: установить обновления Kubernetes или других компонентов без производителя платформы она уже не сможет.

Мы же, приступая к разработке Deckhouse, поставили перед собой задачу во что бы ни стало сделать так, чтобы эта платформа была всегда совместима с основной веткой развития Kubernetes. Так что каждый новый ее релиз обязательно проходит тесты на совместимость с эталонной версией. И помимо этого необходимого базиса, в нашей Kubernetes-платформе как в интеграционном решении есть все необходимые дополнительные компоненты для работы инфраструктуры в продакшн под нагрузкой.

Александр Баталов: Начиная с 2018 года, мы занимались контейнерами и Kubernetes, и как сервисная компания имели довольно большой опыт эксплуатации различных высоконагруженных инфраструктур. Платформа Deckhouse тогда представляла собой набор инструментов, которые использовались внутри нашей компании. И так было примерно до конца 2018 года, когда решили сделать ее отчуждаемой, то есть представить как самостоятельный продукт для того, чтобы помочь крупным компаниям в решении задачи оркестрации.

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

ЕДИНЫЙ ЦУПИС был одним из первых заказчиков. Благодаря ему мы приобрели очень полезный и ценный для нас опыт, на основании которого во многом улучшили наш продукт. Так, мы разработали систему доставки продукта и отработали систему бесшовных обновлений. Kubernetes обновляется минимум 4 раза в год, это влечет за собой появление новых релизов нашей платформы. Для того, чтобы переход с версии на версию был безопасным и максимально комфортным для пользователей, нам была нужна отлаженная система обновления.

Александр Баталов: Она у нас довольно сложная. Мы никогда не выпускаем обновления сразу для всех. Наш релизный цикл подразумевает, что сначала новая версия Deckhouse апробируется на тестовых внутренних контурах. Потом мы запускаем ее на некритичных сервисах: на контурах разработки, может быть, на каком-то ненагруженном, некритичном продакшене — там, где в случае простоя никаких серьезных последствий не будет.

И до действительно высоко нагруженных систем обновление «доезжает» только в тот момент, когда мы уверены в том, что оно всецело отлажено и все баги устранены. Кейсов, когда в запуске на промышленных окружениях проявляются какие-то баги, у нас практически нет. Решение с каскадным обновлением очень хорошо себя зарекомендовало и действительно позволяет обеспечивать надежность и качество.

Александр Баталов: Он высоконагруженный, это финтех, ответственная зона. И в целом, сложность сервисов, технологический стек, нагрузки действительно требовали очень серьезных компетенций. К счастью для нас, уровень профессионализма коллег из ЕДИНОГО ЦУПИС оказался очень высоким, нам было просто работать, потому что мы быстро находили общий язык и приходили к взаимопониманию. И это не могло не сказаться на общем результате. Несмотря на очень высокие требования, проект получился результативным, не растянутым во времени, эффективным, благодаря высокой квалификации команд с обеих сторон.

Так что партнерство с проектом ЕДИНЫЙ ЦУПИС для нас очень важно. И мы благодарны коллегам за то, что они были максимально открыты в фидбеке и инвестировали свое время, свои ресурсы в развитие и улучшение наших внутренних процессов. Так что этот проект до сих пор для нас очень знаковый, особенный и любимый.

Александр фон Розен: Наша платформа растет, и сейчас мы выпускаем примерно 20 релизов в сутки. Сейчас мы эксплуатируем в промышленных нуждах четыре критичных кластера Kubernetes, реализованных на платформе Deckhouse, которые используются именно в продуктах. И у нас, наверное, около 10 вспомогательных кластеров для инфраструктурных нужд. Так что проект активный, он развивается и используется для тестирования, исследования, процессов CI/CD.

Александр фон Розен: Если бы мы стали сами разрабатывать такую платформу, то потратили бы очень много времени и сил, конечно же. Чем нам понравился продукт «Фланта»? Во-первых, практически все, что было сделано коллегами, нам действительно было нужно. И мы бы, скорее всего, сделали что-то аналогичное. Во-вторых, коллеги глубоко погружены в особенности своего продукта и готовы предоставить полную экспертизу. И третье. Коллеги выпустили свой продукт под Open Source-лицензией, что существенно снизило любые риски. Если бы продукт был проприетарным, то мы бы подумали миллион раз и, скорей бы, его не внедрили.

Кроме того, очень мощный аргумент в пользу Deckhouse для нас — возможность возврата к ванильной версии Kubernetes, которая является эталонной и не содержит патчей и доработок.

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

Разработка собственного решения не всегда целесообразна для бизнеса. Конечно, на рынке есть истории успеха технологических команд, которые создали собственное решение для оркестрации. Но для этого требуется труд более 50 инженеров, которые занимаются только разработкой платформы, как минимум, в течение 3-4 лет. Умножьте их зарплаты на время, и вы получите стоимость решения. И случаи, когда создание собственной платформы удавалось, можно считать ошибкой выжившего. А сколько историй о том, как люди пошли этим путем и не пришли ни к чему?

Статистика об этом умалчивает, а мы регулярно получаем запросы от клиентов, пытавшихся что-то сделать своими силами, разочаровавшихся и готовых взять проверенное решение, которое много где внедрено и за разработкой которого стоит понятная команда. Это путь предсказуемый и по затратам, и по результату, и по времени. Что подтверждает пример ЕДИНОГО ЦУПИС.

Александр фор Розен: По каким-то ключевым вопросам, примерно раз в месяц, потому что у нас есть свои компетенции, и мы стараемся к инженерам контрагента по каждому поводу не бегать, а развиваться самим. Мы сталкивались с определенными багами в сторонних опенсорсных продуктах, напрямую не поддерживаемых «Флантом», но в которых его инженеры хорошо разбираются. И вот как раз опыт коллег был для нас очень-очень ценен. В некоторых случаях мы закрывали эти баги быстрей, чем крупные поставщики услуг, например, Azure, тогда еще работающий на российском рынке.

Александр Баталов: С проектом ЕДИНЫЙ ЦУПИС мы работаем вместе с 2019 года, и, как я уже отмечал, степень владения технологией у этого партнера очень высока. Другие клиенты обращаются к нашей техподдержке гораздо чаще. Мы всегда адаптируем ее под потребности той или иной компании. Так что не стоит считать, что к нам можно обращаться раз в месяц и не чаще.

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

Отмечу также, что поддерживаем мы и пользователей версии Community Edition платформы Deckhouse. Для них у нас есть публичный телеграм-канал. Там, конечно, у нас нет никаких жестких обязательств по ответу, но тем не менее мы стараемся по мере возможностей не оставлять обращения пользователей без внимания.

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

Александр фон Розен: Использование Task-трекинга — это золотой стандарт индустрии, так что если вам инженер контрагента говорит: «Заведите, пожалуйста, тикет», — это правильно. Но если время вашей реакции на любые аномалии должно составлять считанные минуты, (у нас, например, девопсы готовы за 60 секунд подключиться к решению проблемы в любое время дня и ночи), то тикет-система здесь станет препятствием, потому что на заведение тикета уходит много времени.

В этом случае самое ценное, что у вас может быть, — это прямой канал связи с инженерами контрагента, в котором они присутствуют, бодрствуют и готовы оперативно вам ответить. И коллеги из «Фланта» такой канал предоставляют. Вы просто можете взять и написать в общем внутреннем чате: «Ребята, нам нужна ваша помощь». И вам сразу ответит человек, который в большинстве случаев понимает, о чем идет речь. Это очень высокий уровень, хотя бы в силу того, что инженеры подобной квалификации, как правило, не любят дежурить. А потом вы сможете хоть один инцидент в систему завести, хоть десять.

Александр фон Розен: С точки зрения программного обеспечения, импортозамещение предполагает внедрение вместо ПО, разработанного в недружественных странах, продуктов, произведенных в странах дружественных или, что крайне желательно, на территории Российской Федерации, как платформа Deckhouse.

Когда мы говорим об Open Source, мы имеем в виду, скорее, подходы к имплементации, чьи-то наработки. Большинство современных проприетарных программных продуктов на самом деле созданы на основе Open Source. Кто-то из вендоров это признает, кто-то не любит об этом говорить, но это, скорее, данность. И я считаю, что проприетарный подход уже несостоятелен: нельзя удержать плод работы многих тысяч квалифицированных инженеров, закрытым от общества. Он все равно станет всеобщим достоянием.

Александр Баталов: К сожалению, сейчас в России под импортозамещением многие понимают копирование решений глобальных вендоров и тем самым автоматически ставят себя на второе или третье место в технологической цепочке. Мы, когда разрабатывали Deckhouse и в 2021 году вносили его в Реестр отечественного ПО, не задавались целью воспроизвести чье-то решение, мы делали самостоятельный продукт, основанный на нашей экспертизе и опыте эксплуатации высоконагруженных систем, максимально полезный и для нас, и для его будущих пользователей.

Что касается Open Source, то его сейчас многие боятся использовать, в частности, из-за возможных закладок в коде. Есть миф, что поскольку в такого рода проекты может добавлять код кто угодно, в него легко внедрить зловредные фрагменты.

Я бы хотел посоветовать выбирать Open Source продукты, с которыми активно работают эксперты, знающие каждый винтик внутри. Такие эксперты могут нивелировать все риски, связанные с возможными проявлениями каких-то недружественных посылов. Вклад разработчиков «Флант» в развитие в Kubernetes самый большой в России, то есть в этой технологии мы разбираемся очень хорошо. И в своей работе перед тем, как включать какие-то компоненты, всегда анализируем их на наличие уязвимостей, каких-то косвенных негативных факторов, устраняем все, что находим.

«Флант» первым в России начал популяризировать Kubernetes среди технических специалистов, и до сих пор это единственная компания на российском рынке, которая входит в топ-200 контрибьютеров технологии.

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