При словах «open source» многим представляются либо энтузиаст, коммитящий по вечерам в любимый проект, либо небольшая компания, зарабатывающая поддержкой открытого продукта. Но если задумываться только о них, то упустишь важный и интересный сегмент сообщества. Когда-то слова «энтерпрайз» и «open source» казались антонимами, а теперь крупные корпорации не только активно используют OSS-проекты, но и сами контрибьютят в них.
Сбертех со временем всё активнее проявляет себя в OSS-сообществе, и мы решили расспросить их об этом. Как сочетаются строгая банковская специфика с опенсорсным духом свободы? Какие возникают требования к Open Source, которых может не быть у других компаний? Есть ли в Сбертехе сотрудники, которые в качестве основных рабочих задач пишут открытый код? Каковы планы и желания на будущее? Антон Чураев, курирующий направление Free&Open Source, рассказал нам обо всём этом и не только.
Олег: Привет, Антон. Давай немного познакомим с тобой. Расскажи о себе: кто ты, чем занимаешься?
Антон: Я — инженер, который, правда, разрабатывает только в свободное время. Сейчас я выстраиваю в Сбертехе практики и компетенции по развитию и применению Free & Open Source продуктов. Нужно понимать, что это немного разные вещи.
— Да, я понимаю, пару раз при общении со Столлманом назвал Free как Open и после этого выслушал такую лекцию, что запомнил на всю жизнь :-) Хорошо, а какая у тебя должность?
— Куратор развития Free & Open Source. И опенсорс-энтузиаст :)
— Можешь чуть подробней расшифровать про «компетенции по внедрению Open Source»? Звучит как какой-то набор тайных знаний.
— Мало кто представляет себе, что означает Open Source для корпораций. С одной стороны, это инновации и отсутствие необходимости разрабатывать commodity, концентрация на конкурентных преимуществах своих продуктов, переиспользование и сокращение затрат. Зачастую это проекты, фактически уже ставшие индустриальными стандартами. Взять тот же Hadoop — он у всех на слуху, все его знают, он уже давно является стандартом. Или самые распространённые базы данных — в пятерке находятся три опенсорсных продукта — MySQL, PostgreSQL и MongoDB.
Но мало кто задумывается, что использование OpenSource подразумевает немало скрытых затрат. Нельзя сказать, что вот мы нашли что-то с открытым кодом и решили все наши проблемы. Например, есть большие вопросы по «правовой гигиене». При работе с вендорским ПО всё предельно ясно: взял лицензию, работаешь по ней и пользуешься поддержкой. При работе с Open Source очень многое даётся на откуп разработчикам и пользователям. В таком случае правовые и юридические вопросы встают на одно из первых мест. К тому же в России есть нюансы. Если во всём мире понятие интеллектуальной собственности довольно сильно развито и все понимают что это очень важно, что есть конкретный владелец, то исторически в России всё сложилось по-другому. Здесь мы относимся к интеллектуальной собственности не так бережно и уважительно, хотя это крайне неправильно. А если ты не можешь обеспечить «гигиену» использования Open Source, ты не можешь обеспечить качество его использования.
— А можно уточнение? Какой правовой статус имеют лицензии типа GPL в России? Например, GPL не допускает модификации под локальное законодательство и в нём не указаны территориальные ограничения. Поэтому такой договор не совместим с правовым режимом, установленным на территории РФ, и это очень-очень плохо.
— Я не хочу разделять лицензии по каким-то зонам. Сбербанк — глобальная компания, поэтому ПО может использоваться и на территории США, и на территории Евросоюза. И, насколько я понимаю (я не юрист, но в меру своих знаний), при нарушении ограничений лицензий правообладателя на территории, например, США, мы будем отвечать по законодательству США. Учитывая это, нужно очень аккуратно подходить к обеспечению прав и выполнению требований на чужую интеллектуальную собственность. Уважительно относиться к авторам, которые нам позволили использовать свой труд, за счёт которого мы ускорились, оптимизировали решения, решили свои задачи и в итоге предоставили качественный сервис нашим клиентам. Давайте соблюдать права и требования. Это — первая задача.
— А вторая?
— Вторая задача — информационная безопасность. Понятно, что большинство лицензий содержит дисклеймер о том, что автор/разработчик/контрибутор не отвечает за возможный вред, который будет нанесён при эксплуатации данного софта. Это правильно, это — ответственность, которая переходит на потребителя и требует от него зрелости. Не бывает всё бесплатно.
За эту ответственность нужно платить и, конечно, работать с этими рисками. Не все компании это умеют. У нас же есть очень сильный департамент информационной безопасности — нам повезло. Поэтому мы серьезно подходим к наличию уязвимостей и вредоносному коду в целом. Все, кто планирует использовать Open Source, должны учитывать все риски — не только правовые, но и в части информационной безопасности.
— Какие лицензии вы любите?
— Академические.
— O! Давай конкретней. Вот есть MIT/BSD и т.п., а есть вирусные копилефтные лицензии типа Affero GPL. Что из этого?
— Ну, хорошо. Нельзя любить или не любить лицензию. Продукт делается под определенную задачу и будет использоваться определенным способом. Твоя задача при использовании опенсорса — сделать так, чтобы ты предоставлял свой продукт или сервис без нарушения прав третьих лиц. При этом, конечно, ты можешь пользоваться копилефтами (например, GPL), если ты обеспечишь их использование так, что они не будут нарушать ограничения и чьи-либо права. Конечно, возникает меньше сложностей при использовании академических лицензий, просто потому что они несут меньше ограничений и следовательно, их проще соблюсти. «Академическими» я для краткости называю MIT, BSD, Apache и др.
— Окей, а информационной безопасностью приходится заниматься обычным разработчикам? Или она выделена в отдельный департамент?
— Все разработчики должны понимать основы информационной безопасности и принципы её обеспечения для своих систем. Но в нашем случае мы работаем с отдельными разработчиками, которые специализируются на угрозах информационной безопасности. Причем мы к ним обращаемся не только по вопросам анализа опенсорс-продуктов, а также по анализу алгоритмов, дизайна решений.
— Понятно, что эти специальные безопасники знают всё. А что нужно знать обычному разработчику в этом плане? Какие базовые поинты?
— Модель возникновения угроз, защита каналов, защита данных. Что подвержено угрозам: может, это пользовательский интерфейс или передача данных по сети (у нас всё распределенное, поэтому это очень важный вопрос). Базовые инструменты вроде шифрования, SSL, TLS, аутентификации, авторизации, работы с токенами и так далее. Много знать не надо.
— Ходят слухи, что ты имеешь какое-то отношение к Apache Ignite :-)
— В части контрибьютинга это основной проект, которым я занимаюсь в настоящий момент. Участие в Apache Ignite относится ко второй моей задаче — обеспечить взвешенное инвестирование во Free и Open Source проекты. Это подразумевает как грамотное использование продуктов (понятно, что использование библиотек — это инвестиция, мы как пользователи повышаем привлекательность продукта), так и разработку, контрибьютинг.
Для меня, наверное, эта задача даже более значима. Мы отдаём дань тем продуктам, которые используем у себя в компании, и благодаря которым выстроили очень много продуктов и систем. Мы стараемся их улучшить и обеспечить возможность использования в таких компаниях, как наша: оптимизировать, довести до энтерпрайзного состояния.
Apache Ignite — это не единственный проект, но мы очень интенсивно контрибьютим именно в него, потому что на базе Apache Ignite строится одна из ключевых платформ в банке. Ignite — это распределенный вычислительный грид, позволяющий хранить и обрабатывать в памяти данные, и фактически — это основа ИТ-ландшафта нашего бизнеса. Поэтому мы крайне заинтересованы в его развитии.
— Многие знают, что в Сбертехе используется GridGain, а ты говоришь об Apache Ignite. В чём разница между ними?
— GridGain является open core-продуктом, построенным на базе открытого ядра, которым и является Ignite. А GridGain — это набор плагинов к этому ядру, которые упрощают процедуры сопровождения и эксплуатации, обеспечивают ряд важных требований информационной безопасности и надежности. Но, по сути, ядро — наиболее значимая часть, а плагины позволяют эксплуатировать всё это в реальном энтерпрайзе. И в банке эксплуатируется уже GridGain.
— Раз Ignite открытый, можно о нём немного поговорить, да? Вы его только эксплуатируете или что-то допиливаете, взаимодействуете с разработчиками?
— Мы интенсивно его дорабатываем. Направления задач чётко определены, например, обеспечение производительности с учетом специфики Сбербанка: большие масштабы, океан данных, высокая операционная активность. Поэтому должно быть быстро и много. Под этим я подразумеваю и latency, и throughput.
Второе — это обеспечение надёжности, т.е. доступности и отказоустойчивости.
Третье — это эффективность эксплуатации, управление TCO. Учитывая масштабы Сбербанка, даже незначительное сокращение использования ресурсов, например, дисков на какой-нибудь процент, на наших масштабах даёт колоссальную экономию.
И четвёртое — задачи по функциональному развитию. Фактически, основное — это развитие интерфейсов и интеграции с другими компонентами технологического стека Сбербанка. Это полезно и важно с точки зрения выстраивания зрелой и комплексной ИТ-архитектуры.
Отдельно стоит задача по устранению техдолга и дефектов (которые бывают всегда). Её, наверное, можно отнести к надёжности.
— Давай пробежимся по этим пунктам для уточнений. Ты говоришь, что вы работаете над улучшением производительности, latency, throughput, вот этого всего. Вопрос — а у Ignite есть с этим какие-то проблемы? В смысле, там есть что дорабатывать или это уже идеальный продукт?
— Нет, нельзя считать продукт идеальным. В каждом релизе мы гоняем как общие бенчмарки, так и микробенчмарки на конкретных компонентах, всё время работаем над производительностью, — в этом вопросе нам нельзя останавливаться. Задача сложная, потому что компоненты и решения уже довольно сильно затюнены, перфоманс почти на пределе железа. Это добавляет сложностей, но всегда есть возможности для улучшений. У нас есть разные use cases, появляются новые пользовательские задачи, в которых существует возможность оптимизации. Например, оптимизировать стример под конкретный характер данных. Есть задачи по оптимизации сетевого слоя, который, опять же, зависит от отдельных кейсов. Поэтому всегда нужно держать руку на пульсе.
— Ты говорил, что вы контрибьютите назад в сообщество. И все эти решения по поводу различных кейсов и оптимизации для них — какой-то tradeoff. Когда мы берем наши трейдоффы и выносим в сообщество, может оказаться, что у людей в сообществе несколько другие условия, другие приоритеты. Как организовать взаимодействие и всё-таки законтрибьютить код, который нужен для своих кейсов?
— Другие заказчики с другими задачами. Абсолютно верно, что это стандартная проблема. Всё сильно зависит от архитектуры решения. Если в решение заложена, например, возможность делать подключаемые расширения, плагины, библиотеки под разные пользовательские решения — можно будет выкрутиться. Например, если есть какой-то компаратор, то пользователь может всегда разработать решение, которое будет передавать этот компаратор на вход, и это решит задачу исходя из конкретных условий. Повторюсь, что возможности очень зависят от архитектуры. Неправильно просто грубо нарисовать код и лепить под нашу задачу, не задумываясь о других клиентах — такие пулл-реквесты не проходят ревью.
Все понимают, что такое Open Source-проект, и в целом, влиять на него можно. Конечно же, есть сообщества, в которых явно присутствуют корпорации, которые влияют на развитие в своих интересах, но если мы играем в чистый Open Source, то его корректно будет сравнить с меритократией (власть достойных). Докажите, что ваше решение хорошее, и тогда оно будет принято. Действовать, как зачастую бывает в закрытой разработке, то есть с позиции «я начальник, я так сказал» не выйдет.
— Один из самых интересных кейсов, которые на публике рассказывал Сбертех — Единый Семантический Слой. Огромный объем данных, размазанных по in-memory grid. Насколько это повлияло на открытую часть Ignite и насколько эти наработки интересны сообществу?
— Да, такие разработки ведутся, и мы очень интенсивно работаем над задачами по обеспечению масштабирования и доступности. Мы нашли кейсы, в которых текущая схема управления топологией не оптимальна, т.к. её временная сложность растёт от числа узлов не совсем так, как мы бы хотели. Это несколько усложняет достижение цели.
— Насколько помню, архитектура кластера — кольцо. То есть когда мы присоединяемся к кольцу, то в начале идём к координатору и потом идём по кольцу, пока не найдём хвост. И чем больше элементов, тем больше время, так?
— Да, вроде того. При этом при увеличении числа узлов в топологии растёт как размер сообщений, которые передаются по кольцу, так и число переходов между участниками. Нельзя сказать, что кольцо — плохое решение, но в некоторых случаях оно не подходит. Поэтому, начиная с конца 2017 года, мы в сообществе дорабатываем управление топологией, чтобы пользователи могли выбрать схему управления топологией: кольцо (иногда оно подходит идеально) или звезда на Zookeeper.
— А откуда взялось вообще кольцо? Зачем оно? Где оно идеально?
— Это замечательное решение на топологиях 100-200 узлов в одном ЦОДе. Позволяет просто и надежно синхронизировать все узлы, они просто идут по порядку. Если мы переходим к звезде, то они начинают работать параллельно, быстрее, но при этом синхронизировать их становится намного сложнее. То есть кольцо может быть стабильнее и надежнее, согласись?
— Да, конечно. А можно сделать так, чтобы эту топологию можно было менять каким-то параметром в конфете, как настройку?
— Да, мы сейчас так и делаем, включаем в релиз обе топологии. Вероятно, уже предложенные реализации покрывают не все кейсы пользователей, и как только появятся новые, мы постараемся обеспечить их эффективную обработку.
— Насколько понимаю, это довольно сложная доработка. И эту доработку делают люди в Сбертехе, в рабочее время, или по вечерам в своё удовольствие?
— Это делает сообщество, куда входят сотрудники СБТ, основной задачей в рабочее время которых является контрибьютинг в этот проект. Задача по топологии затрагивает одно из ключевых решений в ядре продукта, поэтому основная нагрузка легла на мейнтейнеров DiscoverySPI, но, надеюсь, что участие наших разработчиков также положительно повлияло на результат.
— Ну то есть это люди, которые в рабочее время решают задачу, но одновременно являются членами сообщества.
— Да, наиболее значительная часть работы наших разработчиков проходит в сообществе. Но я вижу от наших ребят и такие коммиты, которые появились в час-два-три ночи.
— И у эти сотрудников не будет проблемы от того, что они работают в банке, на закрытой системе, и одновременно коммитят в опенсорс?
— Нет, не будет. Все участники являются официальными корпоративными контрибьюторами. Создание направления и решение об инвестициях принималось на уровне руководства компании, и да — эта группа выделенных корпоративных контрибьюторов, которые в соответствии со всеми нормами компании и ТК осуществляют развитие Open Source продуктов в интересах компании. Да — это развитие и Open Source, да — это в рабочее время, и в нерабочее время тоже, но это уже если сообщество сильно просит.
— Мы сейчас говорили о неких внешних делах, которое решает сообщество. Но скорей всего, в компании нужно делать свои собственные интеграции, улучшать для каких-то своих кейсов… Много написали чего-то своего? Или это только маленькие допилки?
— Если говорить про проект Apache Ignite, то за последний квартал наш вклад в проект составил 8-10 процентов от всех изменений, и мы стремимся увеличивать этот процент. Написали много, и это не только развитие и оптимизация существующего функционала, мы также работаем над новым функционалом для проекта. Для сообщества это вызов, а для нас ответственность, так как после его включения у сообщества в какой-то мере появляется задача по его поддержке.
Задачи могут появляться не только из сообщества, но и от пользователей внутри компании: архитекторов, команд разработки и сопровождения. Развитие проекта по этим задачам также заметно влияет на продукт.
— А вот, допустим, было несколько докладов от сбертеховской программы ППРБ по поводу своего «особого фэн-шуя». Нужно ли писать какие-то дополнительные тулы и админки, чтобы это поддерживать?
— Интерфейсы для эксплуатации постоянно развиваются. Консоль управления того же Oracle привычнее для сопровождения и пока что обладает большей функциональностью. Нужно ли её полностью воспроизводить — это другой вопрос.
— А в открытом виде можно посмотреть консоли управления?
— Да, конечно. Web Console опубликована, Visor, CLI — всё публично.
— А если более глобально на это посмотреть, какие вообще направления и цели есть?
— Сейчас мы больше фокусируемся на развитии Apache Ignite, что отвечает приоритетным задачам компании. Но наш технологический стек на нём не заканчивается. Мы работаем с множеством Open Source проектов, где видим возможности для развития, и нам есть что предложить для улучшения этих проектов. Надеюсь, что они будут интересны не только нам, но и другим пользователям. Для каждого проекта мы определяем необходимый объем нашего участия (от исправления дефектов до изменения архитектуры), оцениваем наличие у нас нужных компетенций, готовность и заинтересованность сообщества в сотрудничестве. В результате всего этого понимаем объем требуемых ресурсов с нашей стороны. Для проекта ценность нашего участия в том, что мы можем предложить кейсы очень крупного банка. Проекту это может дать серьезный толчок для роста. У нас такие кейсы уже есть.
— Ты сказал, что можно принести юзкейсы крупного банка. Чем эти юзкейсы будут отличаться от юзкейсов чего-нибудь другого?
— Основное отличие Сбербанка от остальных — требования по надёжности, то есть availability, durability, fault tolerance и т.д.
— И безопасность, наверное.
— Да, безопасность — отдельная тема. Мы надеемся, что можно довести Open Source проект и перейти рубеж адаптации к этим требованиям. Иначе он будет очень долго искать юзкейсы. Не все сталкиваются с теми требованиями, что есть в банке.
— А есть какие-нибудь популярные, у всех на слуху продукты, которые до таких масштабов ещё пилить и пилить? Например, какое-нибудь распределённое файловое хранилище, ceph?
— Ну да, ceph — хороший пример. Проект хороший, замечательный, очень зрелый, но его еще можно улучшить.
— А вы внутри используете внутри какие-нибудь виртуалки для разработчиков? Чем это управляется?
— OpenStack.
— Насколько понимаю, OpenStack — это такая штука, которую реально можно дорабатывать. Вы что-нибудь с ней делаете, или как ванильный его поставили, так и работает?
— OpenStack мы пока что не дорабатывали, но определенно, это интересное направление, как и Cloud Foundry, контейнеры.
— А что у вас с контейнерами?
— У нас с ними замечательно :-) Мы понимаем, что на наших масштабах для обеспечения эффективной утилизации и управления ресурсами мы должны внедрять (и внедряем сейчас) контейнеризацию приложений. Здесь также встаёт вопрос о вовлечении в развитие этих проектов, потому что повышение конкурентных преимуществ — задача, полезная и нам, и самому проекту.
— Давай поговорим о людях.
— Учитывая амбиции и текущие ожидания банка, мы в какой-то момент превратимся в одного из крупных корпоративных контрибьюторов в Open Source и будем заметны на мировом уровне.
Но есть проблема, что сильных системных разработчиков на рынке мало. И в компании тоже, так как банк всегда больше концентрировался на прикладной разработке, разработке бизнес-приложений.
— То есть готовые технологии особым образом склеивались и решались конкретные бизнес-задачи?
— Да, решались, скорее, бизнес-задачи: выдача кредита, расчет скоринга и т.д. Конечно, мы делали и делаем уникальные решения с точки зрения клиентского опыта, производительности, надежности, безопасности. Но мы подходим к пределу предлагаемых вендорами решений и можем столкнуться с приближением конкурентов. Поэтому сейчас мы и говорим о разработке собственной платформы, интенсивном поиске и использовании инноваций проектов Open Source, что, в свою очередь, требует уже экспертизы в системной разработке.
У нас в стране есть хорошая база в части подготовки студентов. Их готовят к тому, что необходимо в системной разработке. Их не готовят писать бизнес-процессы, их готовят искать и оценивать решения, дают отличную математическую и алгоритмическую подготовку. Эти знания и навыки крайне важны нам сейчас. В решаемых нами сейчас задачах многое, что было бы второстепенным при прикладной разработке, выходит на первый план, в основном вопросы эффективности решений.
Но, к сожалению, так как системная разработка долгое время была не востребована (за исключением крупных ИТ-компаний, таких как Касперский, Мэйл, Яндекс) — до масштаба хотя бы сотни контрибьюторов мы будем расти долго. Разработчиков, которые могут эффективно заниматься системной разработкой, крайне мало, хотя при наличии хорошей академической базы необходимые навыки можно нарастить.
Второе — это опыт и глубокие знания языков программирования.
Третье — требования к коммуникабельности, потому что мы работаем в сообществе. Здесь нет начальника, который говорит разработчику «делай», здесь есть сообщество, которое говорит «может быть, приму» или «скорее, не приму». Проблема другая, и мы под нее перестроились. От разработчика никто не требует код, он сам должен убедить сообщество принять его работу, его вклад. Куда сложнее принимать критику, общаться, ревьюить, объяснять и быть публичным. Быть полезным для других членов сообщества — основное требование, которое мы предъявляем.
— А какая мотивация должна быть у человека, который должен заниматься всем этим? Многие приходят на работу, работают с восьми до пяти с обязательным обедом по указаниям начальника… и всё, что ты описал, не очень хорошо в эту схему ложится.
— Мотивация в развитии. Мы пристально смотрим на кандидатов, пытаемся определить, понимают ли они себя, и насколько хорошо понимают, куда они хотят прийти и зачем мы им. Мы предоставляем разработчикам возможность развиваться, иметь публичную репутацию на глобальном уровне, которая не обнуляется при переходе к другому работодателю (и такая репутация намного ценнее). У таких разработчиков ценности естественно выровнены с нашей командой и компанией, они понимают, почему хотят работать с нами, а не просто проводить рабочее время в офисе.
Но тех, кто может эффективно работать в открытом сообществе, очень-очень мало.
Работа в сообществе и развитие Open Source отличаются от работы остальных разработчиков компании. У наших контрибьюторов процессы в большей степени интегрированы с комьюнити, мы в первую очередь смотрим на него. И только потом уже пытаемся наши внутренние корпоративные процессы перестроить под ожидания сообщества. Если другие решают проблемы внутренней бюрократии, то мы решаем проблемы взаимодействия с сообществом.
— А зачем ты этим занимаешься? В чём твоя мотивация?
— Для меня это вызов и возможность положительно повлиять на ИТ Сбербанка, повысить его конкурентоспособность. Но, что также крайне важно, – это возможность повлиять в целом на развитие ИТ за счет вклада в открытые проекты. Конечно же это всё связано с основными коммерческими целями компании — развитие бренда, повышение ROI, построение Платформы и т.д., поэтому это направление востребовано руководством банка.
— Вообще, как-то в России системное программирование не очень популярно. Часто слышу, что люди говорят: если я займусь системным программированием, то в результате нигде не найду себе работы. Всем полезно создавать сайты, знать какие-то базовые вещи типа Spring и Hibernate, а если я полезу изучать многопоточность, то это ой, никому в этой стране не нужно, а за рубеж еще надо ехать. А такая деятельность, как у вас может, как минимум, может повысить популярность эти компетенций. Хотя бы потому, что с ними можно пойти к вам.
— Возможно, именно поэтому на рынке больше хороших прикладников, чем системных разработчиков. Я очень рад, что нам удалось собрать текущую команду, где все ребята очень яркие. Поражает, как они мыслят и работают, они могут решить практически любую задачу. Я надеюсь, что мы сможем привлечь еще больше талантливых разработчиков. Поэтому точно нельзя сказать, что в России никому не нужны системные разработчики.
Автор: Олег Чирухин
