Psdb сбербанк что это
За закрытой дверью фронтенда ЕФС
В этой статье мы расскажем о библиотеке компонентов Единой фронтальной системы (ЕФС) и как в целом устроен фронтенд платформы.
Одной из основных задач программы ЕФС является трансформация всех фронтальных систем к единому технологическому стеку. Фронтальная система в нашем контексте это интерфейс, через который любой пользователь взаимодействует с банком. Это может быть интернет-банк — многим известны приложения Сбербанк Онлайн и Сбербанк Онлайн для бизнеса, — банкоматы, терминалы, интерфейсы операторов в отделениях и call-центрах и другие системы, которыми пользуются многие тысячи клиентов и сотрудников банка в России.
Основная проблема, которую мы решаем, это замена устаревшего кода: фронтальных систем в банке много, у каждого своя архитектура, свой дизайн.
Очевидно, что это неудобно для всех: для клиентов, сотрудников и банка в целом.
Поэтому главная миссия фронтенда ЕФС – заменить существующую сборную солянку и привести все к единой кодовой базе, к единому технологическому стеку с удобным и понятным пользовательским сценарием.
Какие задачи стоят перед разработкой?
Как устроен фронтенд в ЕФС?
У нас есть команда разработчиков платформы ЕФС, а также прикладные разработчики, задача которых – реализовать бизнес-логику.
Команда платформы разрабатывает библиотеку UI-компонентов для внутреннего использования. Примеров подобной разработки довольно много — у таких компаний, как Google, Yandex, Avito, Mail.ru и др. также есть библиотеки компонентов. Команды же прикладных проектов используют эту библиотеку для реализации своих проектов, предоставляя фидбек в случае проблем.
В команде платформы сейчас 8 человек. Мы работаем двухнедельными спринтами, в конце каждого из них выпускаем новую версию библиотеки, в которой содержатся фиксы и, возможно, новые компоненты. У нас, разумеется, есть code review, свой code style – мы взяли лучшие практики программирования и адаптировали их под себя.
В качестве инструментария мы используем набор инструментов от компании Atlassian: JIRA для постановки задач, BitBucket для git-репозиториев и Confluence для документации.
Из чего состоит библиотека?
Поддержка браузеров
Целевыми браузерами являются IE8+. Сейчас IE8, если кто-то помнит, это как в свое время был IE6: ужасное API и ужасная отладка. Конечно, время, проведенное за дебагом в IE8, бесценно. Были случаи, когда разработчики проводили несколько дней в попытках найти, в каком месте возникала ошибка, потому что в IE8 очень скудный инструментарий для дебага и он показывает порой, что ошибка возникла совсем в другом месте.
Поддержка IE не случайна, нам приходится работать с железом из браузера: RFID-таблетки, различные принтеры, сканеры и т.д. В вебе нет единого стандарта по работе с железом: в далеком прошлом технологией для работы с ним был выбран ActiveX. Количество ПО, написанного с использованием ActiveX, колоссально, и это не дает нам в одночасье отказаться от поддержки IE и перейти в сторону современных браузеров. В планах — перевод устаревшего ActiveX на Java-апплеты и отказ от IE8.
Стек технологий
Мы своего рода стартап внутри крупной организации и наш стек технологий фронтенда не сильно отличается от большинства мировых стартапов: react, redux и PostCSS. Все эти технологии зарекомендовали себя с лучшей стороны, к тому же, они позволяют нам поддерживать IE8. Однако, мы не можем резко менять стек технологий, т.к. вокруг него завязана определенная архитектура приложений, например, именно React позволил нам разбить одно огромное приложение на сотни маленьких и подгружать их по требованию, используя SystemJS.
React
Это первая технология, которую мы выбрали по следующим причинам:
Во-первых, мы не обновляем версию React, потому что с какого-то момента они тоже отказались от поддержки IE8. Во-вторых, мы используем es3ify — это loader для webpack, который берет наш ES5 код и перегоняет в ES3. Он просто заменяет некоторые вещи, которые в IE8 не работают.
TypeScript
Второй технологией, которую мы выбрали, был TypeScript, вот почему:
Производительность
Во-первых, мы сделали компоненты «глупыми», то есть избавились от state, вынося его на прикладной уровень. Теперь прикладные разработчики решают, как менять state, а в наши компоненты только пробрасываются нужные props.
Есть библиотечный компонент Input, у него в state хранится value, в render он возвращает input и в onChange он меняет state. Не много ли кода для такого компонента? Однозначно много, давайте отрефакторим этот пример:
Код компонента стал короче, а на уровне выше есть компонент Form, который сам решает, как управлять состоянием компонента: через redux или через простейший setState. Input стал проще, и, соответственно, производительнее.
Второе, мы придерживаемся архитектуры чистых компонентов (PureComponent), т.е. все внешние свойства, внутренний state и контекст проходят проверку соответствия предыдущему состояния. Если состояние не изменилось, то нет смысла вызывать render лишний раз. Эту проверку мы осуществляем в методе shouldComponentUpdate, который добавили во все наши компоненты.
И третье, мы избавились от утечек памяти в коллбеках.
В данном примере у компонента есть коллбек onClick и в него передается стрелочная функция.
Если ее так задать, то здесь возникает утечка. В IE8 ее особенно видно, потому что при каждом повторном вызове render эта функция создается, она накапливается и возникают тормоза в компоненте. Немного изменим наш пример:
Сам код стал лаконичнее и к тому же, мы избавились от утечки, поскольку callback-функция больше не создается при каждом вызове render.
В планах на будущее — прекращение поддержки IЕ8, что позволит использовать более прогрессивные фронтенд-технологии. Кроме того, мы уже приступили к работе над масштабным проектом интеграции с мобильной платформой ЕФС, приступили к разработке гибридной библиотеки, позволяющая один и тот же код использовать и для web, и для мобильных устройств, используя React Native.
В следующий статье про фронтенд программы ЕФС мы расскажем про то, как мы используем Redux и как он стал сердцем нашей архитектуры, подписывайтесь на наш блог, чтобы не пропустить!
Идеи, предложения и пожелания – пишите, будем рады пообщаться с вами в комментариях к статье.
DevOps в Сбербанк-Технологиях. Инструментальный стандарт
В этой статье пойдет речь об организации инструментального стека DevOps на примере Сбербанк-Технологий и ППРБ. Статья предназначена для инженеров по автоматизации инфраструктуры, которым необходима объективная оценка структуры работ по внедрению DevOps — и для всех, кто хочет ознакомиться с их работой.
Не секрет, что в маленькой сплоченной команде организовать DevOps-процесс весьма просто. Более того, у современных грамотных разработчиков и админов, такой процесс может сложиться сам собой — как результат высокой культуры разработки и поддержки. Но что делать, если твоя маленькая команда из десяти человек начинает расти до конторы из сотен людей? Что делать, если в твоей организации уже несколько тысяч человек, а девопсом и не пахло? С этими вопросами мы обратились к сотрудникам компании Сбербанк-Технологии, имеющей положительный опыт внедрения практик DevOps в крупномасштабных проектах, и кое-что узнали.
Safe Harbor
Во-первых, небольшая оговорка. Многие спрашивают, зачем нам читать статьи о том, как это сделано в других компаниях? Они сделали так, а мы сделаем эдак, какая разница-то.
Продукты Сбербанк-Технологий используются, конечно, в Сбербанке, и от стабильности и безопасности их работы зависят наши с вами деньги. Появление этой статьи в том числе показывает, что компания достигла того момента в своем развитии, когда о внутренних технологических процессах уже можно рассказывать, и это абсолютно нормально. Это не какая-то security through obscurity, а по-настоящему хорошая, качественная отлаженная система — в этом её ценность, и ценность текста, который вы сейчас читаете. Это — вещь, которая действительно работает. С этим знанием можно делать все что угодно — например, один в один скопипастить такую же инфраструктуру себе. Или пойти работать в Сбербанк-Технологии, если вам вдруг понравилось жить с такой инфраструктурой.
Тем не менее, внедрение девопса в промышленную эксплуатацию мы обсуждать все же не станем. Давайте сделаем вид, что это не только из-за безопасности, а еще и потому, что внедрение всё еще идет, и некорректно здесь обсуждать результаты неубитого медведя. Предполагается, что внедрение девопса ППРБ на пром произойдет уже в конце этого, либо начале следующего года — возможно, о нем расскажут на JBreak/JPoint 2018. Давайте сконцентрируемся на настоящем.
В любом случае, в статье могут быть ошибки и недочеты. Данная статья не является официальной позицией компании Сбербанк-Технологии или Сбербанка. Полученная из этой статьи информация не может использоваться как основание для принятия любых коммерческих и других важных решений.
Масштаб проблемы
В чем особенность девопс-проектов СБТ (давайте называть организацию таким неформальным образом)? Конечно, это масштаб. В 2017 году количество сотрудников СБТ превысило 9800 человек, расположенных в 17 городах России.
Зачем нужна эта уйма людей, чем они вообще занимаются? (спросит любой нормальный человек). Формально это звучит вот так:
Что это значит с точки зрения инженера-инфраструктурщика, который занимается внедрением девопса? Глядите, у нас обычно есть, как минимум, следующий набор задач, которые необходимо поставить и решить:
Каждый из этих вопросов резко осложняется от увеличения масштаба. Можно быстро договориться об инженерных практиках внутри своей команды, но помирить между собой 8500 человек, имеющих совершенно разные взгляды на разработку — это челленж. Обычной галере тут бы и лапки, но СБТ умеет превозмогать.
То, что кажется одной команде свободой (например, свободой использовать стандартизованный пайплайн, в рамках которого можно не задумываться о ненужных мелочах), для другой выглядит как существенное ограничение свободы выбора инструментов. На красивых маркетологических презентациях по девопсу не любят рассказывать, что если одна команда делает Единую Всеобщую Платформу Всего, то еще 100 команд будут ее ненавидеть за необходимость использования этой стандартной платформы, а не любимой Скалы и Хаскеля. С другой стороны, если всем дать возможность выбирать разнородные решения, никогда не выйдет общего продукта.
Недостаточно весело. Давайте добавим еще немного сложности! Дело в том, что проекты типа Технологического Ядра ППРБ (один из основных проектов в СБТ) — это черезвычайно сложные самописные технологии, специально предназначенные для особого, кастомного процесса развертывания. (Об этом будет ниже). По сути, это собственная Java-платформа, и как любят шутить разработчики “еще немного — и напишем собственную Java-машину!”. Даже базы данных тут особые — GridGain и набор уникальных ноу-хау на тему, как этот GridGain вообще готовить. Эта сложность является частью предметной области, нельзя просто так взять и сказать “а давайте все выбросим и перепишем на Golang в виде трех микросервисов”. Это так не работает!
Таким образом, инструментальный стек является точкой баланса не только между различными культурами, но и различными подходами к проектированию и программированию — бездонная пропасть между высокоспециализированным технологическим стеком и желанием иметь стабильный, десятилетиями оттестированный софт для админинстрирования.
Поэтому каждый элемент инструментального стандарта CI/CD СБТ — это компромиссное решение. Эти решения, как правила дорожного движения, написаны кровью и годами. Пришло время показать этот инструментальный стандарт!
Инструментальный стандарт CI/CD
И вот сейчас вы удивитесь. Удивитесь его обычности. Как удивились мы в JUG.ru впервые увидев это, так удивились и архитекторы-инфраструктурщики СБТ, когда поняли, что выходит в результате. Вы же привыкли, что СБТ постоянно пишет какие-то невообразимые новые фреймворки, используя их странными способами, чтобы потом рассказывать об этом на конференциях? Не в этот раз. Оказывается, самый лучший способ (на данный момент, осень 2017 года) — использовать то, что используют все, и заполировать решение до зеркального блеска.
Для начала, взгляд сверху:
Такая же последовательность шагов есть примерно у всех современных проектов. ПСИ — это Приемо-Сдаточные Испытания.
Заранее извиняемся, что картинка плохо читается на мобильниках. В дальнейшем все эти пункты будут продублированы большими пиктограммами, так что вы ничего не потеряете.
Для многих является шоком то, что кодирование — чуть ли не самая важная и жирная часть стандартов CI/CD. Дело в том, что если исходный софт написан критически неправильно, то ему уже никакой “девопс”, ничего не поможет.
По этому поводу существует два основополагающих элемента, зависящих от роли:
Разработчики могут использовать то, что нужно для выполнения задачи. В качестве стандарта для Java-разработки, например, лучше взять те средства, которые используют во всем мире: Maven (собственно Java), Node Package Manager (для JS-фронта), JUnit и TestNG (тестирование). СБТ не разрабатывает своих собственных систем сборки не потому, что не может (чем мы хуже Google?), а потому что это нарушило бы идею общей точки равновесия. Слишком многие внешние по отношению к компании проекты (попробуйте прожить без Spring Framework!) завязаны на стандартные утилиты вроде Maven, и нарушать эту интеграцию бессмысленно.
Хранение детальных требований на этом этапе происходит на Wiki-подобной системе (н-р Confluence). Работа с задачами происходит на основе стандартной аджайл-терминологии (эпик, фича, юзер-стори, итп), нативно реализованных в выбранной системе управления задачами (н-р JIRA). Наличие этих двух систем критически важно для получения хорошего результата. Это правило записано кровью — даже маленькому проекту нужно сразу же выдавать вики и багтрекер.
Важно отметить, что здесь и далее, для разработки используются два различных репозитория:
В рамках идеи Infrastructure as Code, сейчас зачастую принято хранить скрипты развертывания вместе с проектом в одном репозитории. В результате длительной практики, в СБТ выбрали иметь отдельный репозиторий для скриптов развертывания, и при необходимости осуществлять сильную связанность программным способом. Это особенность связана исключительно с масштабом и необходимостью сложных связанных обобщенных конфигураций, когда один и тот же “скрипт” может работать с разными продуктами. Плюс это позволяет развести команды разработки и администрирования по зонам ответственности и уровням доступа. Конкретные настройки проектов и специализированные скрипты, конечно, хранятся вместе с проектами.
В качестве управляющей системы здесь и далее используется Jenkins. Кому-то он может не нравиться, по причине того, что это древний софт, обросший определенным количеством легаси, и имеющим серьезный футпринт по объему оперативной памяти, использованию процессора, и так далее. Но помните что мы говорили про точку баланса? Факт остается фактом, что при всех своих недостатках, прямо сейчас (осень 2017 года), Jenkins — это именно та система, которую согласны использовать все. В будущем это, возможно, изменится.
Кроме Дженкинса используется дополнительная система управления сквозным процессом развертывания, начинающаяся с этапа кодирования, и продолжающаяся вплоть до ПРОМа. Но это специальный внутренний софт, описывать который в данной статье не имеет смысла не только по причине недоступности в Open Source, но и потому, что он очень заточен под конкретные особенности СБТ. Есть предположение, что любая компания с достаточно большим пайплайном всегда пишет подобную систему. Для небольших проектов она может существовать в рудиментарном виде, в виде пачки скриптов, не зависящих от Дженкинса. При масштабировании на 10+ проектов, идущих в связке, она может превратиться в серьезный софт.
Важно, что репозиторий скриптов развертывания, дженкинс и инструменты сквозного управления доступны сразу же, начиная с этапа кодирования. Если кому-то из разработчиков будет нужно пойти на Jenkins и сделать там новый джоб — это нормально. Использование девопс-инструментов — это нечто настолько же свободно доступное и неотъемлемое, как дышать воздухом.
У многих разработчиков есть собственные DEV-стенды (сервера), на которых они могут проводить простое системное тестирование и любые удобные эксперименты вне своего компьютера. Конечно, эти стенды очень ограничены в ресурсах (им экономически бессмысленно выделять терабайт RAM), и на них никак нельзя провести интеграционное тестирование. Но для экспериментов — пойдет.
На этом этапе происходит несколько ключевых вещей:
По поводу ИБ мы тут распространяться не будем по понятной причине. Последнего кто говорил о безопасности забрало НЛО 🙂 Достаточно сказать, что все элементы CI/CD учитывают требования безопасности, и в случае чего там мышь не проскочит. Обычно безопасность понижает удобство использования инструментов CI/CD, поэтому это очень сложная тема, наполненная особыми инженерными компромиссами.
У каждого проекта есть свой собственный стенд (сервер), на котором можно и нужно тестировать готовые решения. Нельзя просто так взять и выкатить непроверенное решение на общее интеграционное тестирование. Стенд может выделяться как под весь проект целиком, так и под конкретного разработчика (для тестирования экспериментальных веток). Эти стенды имеют более серьезные ресурсы, чем личные DEV-стенды разработчиков, но все еще ограничены рамками разумного, т.к. полное воссоздание всей инфраструктуры на ресурсах, выделенных проекту, было бы невероятно сложно, долго и экономически бессмысленно. Поэтому нормального интеграционного тестирования тут не получится, да оно и не нужно.
Несколько важных моментов, которые происходят на этом этапе:
Интересной особенностью этих командных DEV стендов является то, что его уже нужно готовить по всем правилам: устанавливать внутренний софт, создавать тестовых пользователей, и так далее. Обычно стенд — это не один компьютер, а кластер из виртуальных машин, поэтому в этот момент тестируется еще и правильная инициализация кластера. По сути здесь происходит еще и мини-инсталляционное тестирование всего стека, начинающееся прямо с момента развертывания стенда.
Конечно, в использовании Энсибла существуют свои заморочки. Например, стандартная система ролей может оказаться излишне простой для сложного модульного проекта. В самой свежей версии есть экспериментальная поддержка вложенных ролей, но и её может не хватить (тем более что она действительно очень сырая и не протестирована на совместимость с другими фичами Энсибла). Если пытаться использовать Энсибл полномасштабно, как систему не только конфигурирования, но и управления целевыми системами, придется написать много дополнительного обвязочного софта, где сам Энсибл является всего лишь “SSH-ассемблером” для более высокоуровневых команд.
Кроме того, быстро выясняется, что девопсы, плотно работающие с Энсиблом, должны знать Python. Например, у вас есть какой-то самописный софт, который обладает черезвычайно сложной процедурой конфигурации, связанной с тонкой настройкой кластера, линукса, прикладного ПО, и так далее. Многие из этих операций требуют работы с малоизвестными и нативными функциями, для которых сообщество не написало готовых решений, да и не напишет никогда. Если описывать это в плейбуке на “чистом ямле”, это заняло бы десятки страниц текста. А лог этих операций был бы трудночитаемой кашей — в, частности это связано с отсутствием нормального управления ветвлением и соответствующей выдачи лога (время от времени вопрос поднимается в сообществе, но воз и ныне там). Более правильный способ решения этой задачи — написание Action Plugin и Module, весь сложный код в котором инкапсулирован в изящно написанный скрипт на Python. По сути, в самом плейбуке остаются только вызовы плагинов, содержащие высокоуровневые бизнес-параметры — по аналогии с утилитами командной строки GNU/Linux. Из этого напрямую следует, что инженер-инфраструктурщик (девопс, админ, разработчик — кто угодно, кто занимается этой задачей) обязан знать Python на достойном уровне. Не обязательно знать его так же хорошо, как специальный Python-программист, но уметь читать и багфиксить готовый код, и писать простые модули для Энсибла — это рецепт успеха.
Полученный результат зачастую, по сути, является не просто каким-то “скриптом”, а весьма сложным софтом, требующим специальной поддержки. Именно отсюда пошло изначальное разделение на пару репозиториев: один для кода продукта, другой для кода скриптов развертывания. Для репозитория скриптов развертывания можно вообще использовать какую-то другую, специальную систему управления репозиториями (например, не Atlassian Stash, а GitLab со специфичными настройками), чтобы добавить больше гибкости в управлении конфигурациями.
Кроме описанных выше инструментов, существует еще множество мелких. Например, некоторые проекты все еще используют не GridGain, а SQL базы — там можно подключить Liquibase для накатывания миграций. И так далее. Такие вещи уже очень зависят от специфики проекта, и, по возможности, их стоит стандартизировать. Например, если мы выбрали Selenium в качестве фреймворка для UI тестирования, именно его и стоит придерживаться, т.к. поддержка таких решений требует большой экспертизы.
На следующем этапе происходит чистое, правильное системное тестирование на выделенном стенде.
Здесь происходит две ключевых вещи:
Установка и настройка среды зачастую сама по себе выявляет множество удивительных вещей, которые сразу же отправляются на доработку. В основном, они касаются простоты и удобства администрирования. Системы имеют тенденцию со временем разрастаться, сложность настройки увеличивается, и рубить эти проблемы нужно на корню — прямо начиная с этого стенда.
Набор автотестов “чистого” СТ тестирования может отличаться от “грязного” DEV-тестирования в сторону увеличения строгости. Даже самый незначительный экспериментальный проект обязательно должен иметь тесты, хотя бы базовое smoke-тестирование. Если тестов нет, на интеграционное тестирование этот проект не пустят.
Интеграционное тестирование — самое большое, сложное и важное тестирование. По крайне мере, таким оно кажется разработчикам, потому что на этом этапе находится самое большое количество сложных багов 🙂 Провести его нужно максимально аккуратно, потому что любая ошибка затрагивает результаты работы не только конкретного проекта, а еще сотен, если не тысяч людей.
На этом этапе стенды моделируют реальную инфраструктуру, имеют полноценные (весьма большие) ресурсы, и получают полную поддержку системных администраторов.
Происходит несколько обязательных вещей:
Полностью протестированный готовый продукт выкладывается в специальное централизованное хранилище дистрибутивов. Вместе с ним прикладывается вся доступная документация и другие материалы. Полученные файлы замораживаются навсегда. Используются специальные средства для того, чтобы поменять их было невозможно никаким образом.
(Если вы вдруг захотите сами сделать такое хранилище, и пишите на Java, можно просто использовать Nexus).
Проведение приемо-сдаточных испытаний — это другая тема, опасно приближающаяся к тайным знаниям. Но на верхнем уровне тут все просто, происходит:
После прохождения этого этапа можно считать, что продукт готов к эксплуатации.
Ну и наконец, развертывание в настоящей промышленной эксплуатации, написать про которое, по очевидным причинам, нельзя. Да и не имеет смысла, т.к. описанный выше пайплайн дотянется до прома только в конце года. В данный момент при развертывании на пром используется процедура ручной установки, с использованием инструкций по установке, приложенных к дистрибутиву, которая выполняется специальными экспертами по развертыванию.
В случае автоматизированного развертывания, на этом этапе будет две вещи:
ВСЁ. Этого минимального набора инструментов уже достаточно, чтобы куча людей могла ужиться под одной крышей. Важно понимать, что этот инструментальный стандарт не ограничивает возможности разработчиков, а дает стабильную платформу для дальнейшего развития.
Технологическое Ядро ППРБ
Читатель, знакомый с докладами Сбербанк-Технологий на конференциях JUG.ru (кстати, следующая будет совсем скоро), может заметить, что история девопса вышеописанной схемой не заканчивается. Скорее, она ей только начинается.
Статья начиналась с общего инструментального стека именно потому, что данные решения очень специфичны для самих Сбербанк-Технологий, и знать о них, скажем так, нужно не всем. Для тех кто все еще с нами — продолжаем.
Инновационные решения, применяемые в Сбертехе, требуют особенных подходов к разработке. В качестве причин можно было бы назвать разношерстный технологический стек, потребность в аггрегации данных от множества подсистем, невероятное количество серверов, необходимых для обслуживания такого объема данных, отсутствие “выходных” и “ночи”, когда можно провести обслуживание, и так далее. Несмотря на необходимость организовать высокую производительность, отказоустойчивость, и обслуживаемость 24х7, полученные решения должны работать на стандартном железе и не требовать специальных суперкомпьютеров. Результирующее решение должно одновременно обладать признаками и централизованной, и децентрализованной системы. Сложная ситуация.
В результате было создано так называемое Единое Информационное Пространство. Это кластерная архитектура, в которой все узлы объединены между собой, каждый может общаться с каждым. Нет никакого дублирования и интеграции, все данные существуют в одном экземпляре и доступны всем модулям с любого узла в любое время. В качестве бэкенда этой системы используется in-memory data grid под названием GridGain. На сегодняшний день, это одна из лучших в мире систем хранения и обработки больших объемов бизнес-данных.
Именно с этой архитектурой администраторам и девопсам приходится сталкиваться при проведении любого интеграционного тестирования. Именно она работает на обслуживаемых ими стендах.
Совершенно очевидно, что управление такой системой ортогонально движению артефактов вдоль CI/CD пайплайна. Jenkins и Ansible можно использовать для инициации инфраструктурных операций, но на них нельзя записать сами операции. Это просто другой логический уровень.
Для большинства компонентов на этой картинке, имеется как некая “серверная” составляющая (запускаемая на серверах-координаторах), так и прикладные библиотеки, которые обычный прикладной софт использует для работы внутри кластера. По сути, Технологическое Ядро дает свое видение на большинство привычных для любого программиста или админа вещей: как хранить настройки приложений, как хранить данные, как организовывать взаимодействие между программами, и так далее. В каком-то смысле можно думать о нем как о легкой кластерной операционной системе, работающей на основе Java.
Чтобы развеять налет магии, на низком уровне все это работает на основе всем известных и понятных вещей, выложенных в OpenSource.
GridGain можно посмотреть на примере бесплатного Apache Ignite (в чем между ними разница? Недавно, в интервью JUG.ru, об этом рассказывал Владимир Озеров). Apache Kafka, ZeroMQ, даже Hyperic — все это находится в Open Source. Они выбраны не только потому, что писать самостоятельную замену — долго и дорого (СБТ, вероятно, справился бы), но и затем, что для всех этих инструментов уже есть сообщество и понимание, как их обслуживание правильно делать в смысле выстраивания процессов администрирования и девопса. Например, если вы вдруг являетесь экспертом по Apache Kafka или OpenStack — быстрей идите в СБТ, вы здесь нужны.
Но также надо понимать, что работа с этими инструментами — это не администрирование, а именно девопс. Необходимо колоссальное количество разработки, чтобы превратить эти компоненты в однородную платформу. Транспорт — это не просто Kafka, это специальная кластерная среда, которая использует Кафку как бэкенд. Уровень хранения — это не просто Ignite/GridGain, а специальный софт, использующий передовые ноу-хау СБТ, касающиеся работы с IMDG, на который ушло очень много сил лучших разработчиков. Всем этим компонентам нужно со стороны обслуживания дать однородный интерфейс управления и просмотра диагностики (для администраторов), и однородные Java-интерфейсы (для программистов). Использование этих инструментов требует понимания и культуры использования ото всех участников процесса — и от администраторов, и от программистов, и от специальных инженеров по автоматизации инфраструктуры, и так далее.
Как видим, наличие стандартизированного CI/CD пайплайна не ограничивает полет инженерной мысли, а дает ему площадку для беспроблемного результативного развития.
Заключение
В этой статье мы рассмотрели как инструментальный стандарт CI/CD Сбербанк-Технологий (который может адаптировать каждый), так и специфические для Сбербанк-Технологий решения (которые напротив, могут использовать далеко не все).
Надеемся, что статья оказалась полезной: тем, кто хочет построить что-то подобное у себя; тем, кому просто любопытно; тем, кто хочет пойти на работу в Сбербанк-Технологии и сомневается — будет ли ему там достаточно интересно и приятно работаться. Если у вас еще нет девопса, можно использовать этот текст как руководство, или показывать друзьям: глядите, вот так у нас все будет хорошо к концу года.
Если хочется узнать больше о девопсе, приходите на нашу конференцию DevOops 2017, которая состоится в Санкт-Петербурге 20 октября 2017. Кстати, Сбербанк-Технологии — золотой спонсор этой конференции.
Благодарности
В подготовке этого текста помогали сотрудники Новосибирского отделения Сбербанк-Технологий: Александр Перковский (заместитель директора центра компетенции ППРБ), Алексей Курагин и Егор Федоров (архитекторы Технологического Ядра и разработчики системы мониторинга), Олег Чирухин (архитектор и разработчик системы развертывания ППРБ.BPM), Александр Обливальный (инженер по автоматизации инфраструктуры ППРБ) и другие. Мы не можем перечислить здесь всех, но признаем, что ваш вклад был неоценим. Спасибо!