Denis Tv
33 years old.
#golang #go #developer #it #sport #swimming
Сейчас работу не ищу.
Можно скроллить страницу, чтобы увидеть больше инфы 🌝
Коротко о главном
— Основной язык программирования Go, начал писать с 2017 года, полностью перешел в 2018
— Профилирую приложение с помощью pprof, если возникают разного рода странности
— Дебажу код с помощью delve (который идет в поставке с Goland и интегрирован в среду)
— Пишу table-driven тесты на Go, люблю это дело
— Принципы и подходы, которыми руководствуюсь при проектировании приложений: DDD, SOLID, KISS, DRY, но без фанатизма
— Код пишу используя ООП парадигму и следую основным паттернам проектирования.
— Имею общие представления о работе операционных систем, конкурентности, процессах, потоках, механизмах синхронизации доступа к общим ресурсам, механизмах межпроцессного взаимодействия.
— Есть навыки администрирования Linux. Владею командной строкой на уровне, необходимом для повседневной работы и написания скриптов автоматизации рутинных задач, деплоя приложения. Использую bash, docker, makefile, git
— Не безразлично внутреннее устройство Linux (организация файловой системы, управление памятью, планирование процессов)
— В общих чертах есть представление о стеке TCP/IP и его протоколах
— Нравится DevOps подход. Мне не все равно, как мое приложение работает в проде или на тестовом окружении. Готов разбираться, дебажить, чинить, настраивать.
Компания моей мечты:
— Прозрачная оценка моей работы
— Регулярная обратная связь от руководителя (что делаю хорошо, что можно улучшить для достижения больших результатов)
— Быстрая коммуникация
— Профилирую приложение с помощью pprof, если возникают разного рода странности
— Дебажу код с помощью delve (который идет в поставке с Goland и интегрирован в среду)
— Пишу table-driven тесты на Go, люблю это дело
— Принципы и подходы, которыми руководствуюсь при проектировании приложений: DDD, SOLID, KISS, DRY, но без фанатизма
— Код пишу используя ООП парадигму и следую основным паттернам проектирования.
— Имею общие представления о работе операционных систем, конкурентности, процессах, потоках, механизмах синхронизации доступа к общим ресурсам, механизмах межпроцессного взаимодействия.
— Есть навыки администрирования Linux. Владею командной строкой на уровне, необходимом для повседневной работы и написания скриптов автоматизации рутинных задач, деплоя приложения. Использую bash, docker, makefile, git
— Не безразлично внутреннее устройство Linux (организация файловой системы, управление памятью, планирование процессов)
— В общих чертах есть представление о стеке TCP/IP и его протоколах
— Нравится DevOps подход. Мне не все равно, как мое приложение работает в проде или на тестовом окружении. Готов разбираться, дебажить, чинить, настраивать.
Компания моей мечты:
— Прозрачная оценка моей работы
— Регулярная обратная связь от руководителя (что делаю хорошо, что можно улучшить для достижения больших результатов)
— Быстрая коммуникация
— Ну и само собой, драйвовая команда
Карьера
2024-настоящее время
ID
Автоматизация крупного ритейла и промышленные роботы
Автоматизация крупного ритейла и промышленные роботы
Лидер стека Go
За что отвечаю:
— Развитие лидов команд, обмен опытом, ИПР лидов
— Помогаю лидам команд развивать опыт и экспертизу разработчиков в их командах
— Работаю с проблемами команд, собираю регулярную обратную связь
— Отвечаю за метрики эффективности разработчиков по стеку
— Стандартизация (всеобъемлющая в рамках стека). Задаю общий вектор в плане унификации библиотек, приемов, подходов к разработке, инструментов
— Развиваю внутренний обмен опытом между go-разработчиками компании (внутренние митапы, сообщество)
— Отвечаю за политику подбора, грейды.
— Помогаю при кросс-командных взаимодействиях для решения проблем гошных команд
— Выступаю заказчиком со стороны команд разработки для направления, которое развивает внутренние платформенные решения
— Помогаю лидам команд развивать опыт и экспертизу разработчиков в их командах
— Работаю с проблемами команд, собираю регулярную обратную связь
— Отвечаю за метрики эффективности разработчиков по стеку
— Стандартизация (всеобъемлющая в рамках стека). Задаю общий вектор в плане унификации библиотек, приемов, подходов к разработке, инструментов
— Развиваю внутренний обмен опытом между go-разработчиками компании (внутренние митапы, сообщество)
— Отвечаю за политику подбора, грейды.
— Помогаю при кросс-командных взаимодействиях для решения проблем гошных команд
— Выступаю заказчиком со стороны команд разработки для направления, которое развивает внутренние платформенные решения
2021-2023
Руководитель группы разработки платежных сервисов.
Что сделал:
— Задокументировал все основные микросервисы команды, процессы, написал несколько десятков разных инструкций с подробным описанием технических процессов
— Разработал архитектуру системы, которая позволяет автоматизировать интеграции с платежными шлюзами. Она позволяет интегрировать новые платежные системы без написания шаблонного кода путем конфигурирования flow интеграции в унифицированном yml-формате.
За счет этого существенно уменьшается объем однотипного кода, который необходимо поддерживать команде и вдвое сокращаются общие затраты на разработку в рамках квартала. Интеграций десятки и регулярно появляются новые.
— Между делом внедрил в проект PaymentProcessing (Go) контекстное логирование, которое позволяет связывать сообщения, уходящие в хранилище логов по каким-то важным идентификаторам и обогащать протягиваемый сквозь систему контекст дополнительными данными.
Это позволило упростить отладку и изучение проблем на проде. Например: найти все сообщения с ошибками с user_id=123. Или найти все сообщения в системе логирования, в которых есть request ушедший в платежную систему с "paysystem_id=123 && user_id=123", а затем посмотреть response от этой платежной системы, который был принят уже в рамках другого процесса, но относящийся к этой бизнес-транзацции.
— Взаимодействие с бизнесом, сбор требований
— Управление командой из 5 человек (2xDev, 2xQA, 1xAutoQA)
— Выстраивание процессов команды
— Проведение код-ревью
— Менторство, развитие сотрудников
— Проведение регулярных встреч 1x1
— Планирование итераций, работы в рамках квартала
— Проведение рабочих встреч, фасилитация
— Контроль за выполнением ключевых целей команды
— Задокументировал все основные микросервисы команды, процессы, написал несколько десятков разных инструкций с подробным описанием технических процессов
— Заонбоардил 6 новых человек в команду
— Задокументировал все основные микросервисы команды, процессы, написал несколько десятков разных инструкций с подробным описанием технических процессов
— Разработал архитектуру системы, которая позволяет автоматизировать интеграции с платежными шлюзами. Она позволяет интегрировать новые платежные системы без написания шаблонного кода путем конфигурирования flow интеграции в унифицированном yml-формате.
За счет этого существенно уменьшается объем однотипного кода, который необходимо поддерживать команде и вдвое сокращаются общие затраты на разработку в рамках квартала. Интеграций десятки и регулярно появляются новые.
— Между делом внедрил в проект PaymentProcessing (Go) контекстное логирование, которое позволяет связывать сообщения, уходящие в хранилище логов по каким-то важным идентификаторам и обогащать протягиваемый сквозь систему контекст дополнительными данными.
Это позволило упростить отладку и изучение проблем на проде. Например: найти все сообщения с ошибками с user_id=123. Или найти все сообщения в системе логирования, в которых есть request ушедший в платежную систему с "paysystem_id=123 && user_id=123", а затем посмотреть response от этой платежной системы, который был принят уже в рамках другого процесса, но относящийся к этой бизнес-транзацции.
2018-2021
Senior golang developer команды разработки финансовых инструментов.
Технологии: Golang, Apache Kafka, Postgres, Prometheus, Grafana, Kubernetes, Docker, Swagger, Rancher, Zipkin, Graylog, Gitlab, Jenkins
Над чем работал:
1. Микросервис, отвечающий за данные финансовых инструментов и расписания бирж (отчетности, финансовые показатели, цены, ...)
— Сделал сбор ключевых метрик по приложению
— Реализовал поддержку распределенного трейсинга на базе zipkin
— на 70% зарефакторил проект, применив практики DDD, что существенно упростило понимание кода.
2. По касательной, микросервис отвечающий за стриминг цен с бирж в реальном времени
— всякое по мелочи
Технологии: Golang, Apache Kafka, Postgres, Prometheus, Grafana, Kubernetes, Docker, Swagger, Rancher, Zipkin, Graylog, Gitlab, Jenkins
Над чем работал:
1. Микросервис, отвечающий за данные финансовых инструментов и расписания бирж (отчетности, финансовые показатели, цены, ...)
— Сделал сбор ключевых метрик по приложению
— Реализовал поддержку распределенного трейсинга на базе zipkin
— на 70% зарефакторил проект, применив практики DDD, что существенно упростило понимание кода.
2. По касательной, микросервис отвечающий за стриминг цен с бирж в реальном времени
— всякое по мелочи
2017-2018
Senior developer, команда разработки платежных систем.
Спроектировал микросервис процессинга платежей и в течение месяца разработал полностью рабочий прототип с одной, основной интеграцией с платежным шлюзом.
Ключевые особенности микросервиса:
— Простая и расширяемая архитектура, которую можно объяснить на пальцах любому новому разработчику в команде
— Интеграция нового платежного способа сводится к написанию отдельного процессора транзакций, реализующего простой интерфейс, принимающего на вход саму транзакцию и отдающему на выходе структуру с результатом процессинга, в которой хранится текущий результат обработки (in-process, paid, failed) и некоторый контекст
— Возможность определения произвольного Flow процессинга под любой платежный метод в рамках процессора транзакций (типичный пример, 3DS авторизация, подразумевающая ряд редиректов на разные страницы, либо один из механизмов выводов через PayPal, в рамках которого может быть до 5 различных редиректов на роуты как на стороне PayPal, так и на нашей стороне для подтверждения транзакции)
— Заявки на ввод/вывод от пользователя связаны со множеством отдельных транзакций 1:N. Есть интерфейс генератора транзакций и при необходимости, можно написать любую кастомную логику, например, пустить часть транзакций через первого поставщика, а другую часть через второго, в зависимости от каких-либо бизнес-требований (более выгодная комиссия, доступность поставщика в данный момент и так далее)
— Микросервис был выделен из монолитного приложения. Это позволяет существенно упростить его вынесение в скоуп PCI-DSS требования которого мы обязаны соблюдать, поскольку работаем с банковскими картами клиентов. Контролировать маленький микросервис с ограниченной функциональностью и несколькими точками входа гораздо проще, чем огромное монолитное приложение, к админке которого имеет доступ половина компании.
Технологии: Golang, PHP, RabbitMQ, Postgres, Elasticsearch, Kibana, Docker, Ansible, Bash, Rancher, Gitlab, Jenkins, Nginx
Над чем работал:
— Billing. Внутренняя система для работы с платежами клиентов, различная бизнес-логика по проведению платежей.
— Crypto services (Bitcoin, Ethereum). Инфраструктура для проведения платежей в популярных блокчейн-сетях.
Ключевые особенности микросервиса:
— Простая и расширяемая архитектура, которую можно объяснить на пальцах любому новому разработчику в команде
— Интеграция нового платежного способа сводится к написанию отдельного процессора транзакций, реализующего простой интерфейс, принимающего на вход саму транзакцию и отдающему на выходе структуру с результатом процессинга, в которой хранится текущий результат обработки (in-process, paid, failed) и некоторый контекст
— Возможность определения произвольного Flow процессинга под любой платежный метод в рамках процессора транзакций (типичный пример, 3DS авторизация, подразумевающая ряд редиректов на разные страницы, либо один из механизмов выводов через PayPal, в рамках которого может быть до 5 различных редиректов на роуты как на стороне PayPal, так и на нашей стороне для подтверждения транзакции)
— Заявки на ввод/вывод от пользователя связаны со множеством отдельных транзакций 1:N. Есть интерфейс генератора транзакций и при необходимости, можно написать любую кастомную логику, например, пустить часть транзакций через первого поставщика, а другую часть через второго, в зависимости от каких-либо бизнес-требований (более выгодная комиссия, доступность поставщика в данный момент и так далее)
— Микросервис был выделен из монолитного приложения. Это позволяет существенно упростить его вынесение в скоуп PCI-DSS требования которого мы обязаны соблюдать, поскольку работаем с банковскими картами клиентов. Контролировать маленький микросервис с ограниченной функциональностью и несколькими точками входа гораздо проще, чем огромное монолитное приложение, к админке которого имеет доступ половина компании.
Технологии: Golang, PHP, RabbitMQ, Postgres, Elasticsearch, Kibana, Docker, Ansible, Bash, Rancher, Gitlab, Jenkins, Nginx
Над чем работал:
— Billing. Внутренняя система для работы с платежами клиентов, различная бизнес-логика по проведению платежей.
— Crypto services (Bitcoin, Ethereum). Инфраструктура для проведения платежей в популярных блокчейн-сетях.
2015-2017
Sandbox.
Спроектировал, разработал систему “Sandbox”, которая предназначена для создания и управления изолированными средами в помощь тестировщикам и разработчикам.Исходная проблема заключалась в том, что команд и людей было очень много, а тестовых стендов на всех не хватало и люди часто мешали друг другу, ломая стенды, после чего тратили огромное время на поиск и решение проблем с ними.
Возникла необходимость в инструменте, который позволит создавать изолированные тестовые среды по требованию, повторяя реальную production-инфраструктуру.
В результате чего проблемы на одном стенде не будут затрагивать другие и тестировщики смогут параллельно тестировать задачи на собственных стендах, не блокируя друг друга.
Это был совершенно новый проект в компании. Мне выпал хороший случай оказаться первым, кто начал над ним работать, имея полную свободу действий и возможностей в выборе инструментов.
Что было реализовано:
1. Сборка на лету в отдельной виртуальной машине разворачиваются на лету в отдельной виртуальной машине во внешнем облаке по требованию. Как только сборка становится не нужна, виртуальная машина вместе со всеми контейнерами уничтожается.
2. Конструктор микросервиса. С его помощью разработчик мог создать свой микросервис через веб-интерфейс, указав из каких компонентов он состоит. Например, за несколько минут можно было набросать конфигурацию простейшего микросервиса, состоящего из контейнера с приложением, контейнера с базой данных и контейнера с брокером очередей сообщений. Система уже содержала дефолтные часто используемые компоненты, которые можно просто выбирать из списка. Если нужного компонента нет, разработчик может подключить свой docker-образ, размещенный во внутреннем хранилище docker-образов
3. Собственное хранилище docker-образов. Docker-образы компонентов микросервисов собираются командами самостоятельно с помощью CI и размещаться в общем хранилище образов Registry на наших мощностях (для понимания картины, суммарный объем всех образов был >5TB)
4. Маппинг портов приложений. В интерфейсе управления компонентами микросервиса можно настраивать публикацию портов, которые маппятся на хост-машину, после чего компонент микросервиса становится доступен извне.
5. Возможность управлять переменными окружения на уровне компонентов микросервиса. Переменные окружения могут быть переопределены перед началом сборки (для каждого компонента выбранного микросервиса)
6. Кастомизация образов компонентов перед сборкой. Перед началом сборки можно выбирать, какой образ использовать при сборке. Например, можно запустить свой микросервис и протестировать его на другой версии Postgres, отличной от той, которая используется в данный момент, просто выбрав нужную версию компонента в списке. Удобно, когда хочется посмотреть, как ведет себя приложение на новой версии БД
7. Изоляция на уровне виртуальных машин и контейнеров. Под каждую сборку создается отдельная виртуальная машина, в которой поднимаются сотни контейнеров, под каждый компонент микросервисов. Разработчики и тестировщики могут создавать любое число таких сборок для любых целей и не мешать друг другу.
8. Кастомные облачные провайдеры и поставщики услуг. На уровне архитектуры приложения, была возможность интегрировать любой облачный провайдер, имеющий внешний API
9. Интерактивный процесс создания сборки. Разработчик может видеть процесс сборки выбранного набора микросервисов, видеть логи сборки в веб-интерфейсе.
10. Различные тарифные планы. При создании сборки можно выбрать тарифный план виртуальной машины, что дает возможность подбирать оптимальную мощность создаваемой виртуальной машины для требуемых нужд при разработке или проведения нагрузочного тестирования, вплоть до самых заряженных машин с 32 ядрами, 128 гигами оперативы и 512 SSD с возможностью подключать дополнительные разделы под сторадж)
11. Удаленный доступ к сборкам по SSH. Для каждой сборки у разрабов/тестеров был доступ по SSH, что позволяло управлять хостом и существенно упрощало процесс отладки.
На каком-то этапе я понял, что бизнесовая разработка мне интересна больше, чем инфровая, после чего перешел в другую команду.
Вокруг этой системы образовалась новая команда, в задачи которой входило создание инструментов для собственной инфраструктуры разработки, деплоймента и управления серверами компании.
Сама же система в последствии обросла большим числом новых возможностей, была переписана на другом языке и ушла далеко вперед, что очень радует.
Своя CI/CD платформа
Разработал прототип своей CI/CD-системы. В серию не пошло, поскольку затащить в одно лицо сразу два инфровых проекта я просто был не в состоянии и переключился на более приоритетный, а этот по моей инициативе мы закрыли. Но был вполне рабочий прототип на Ruby on Rails, который даже варил билды и в риалтайме стримил терминал каждой отдельной билдежки на свою страницу билда (причем православно, корректно отображая все спецсимволы), под капотом прятался RabbitMQ.
Технологии: Ruby on Rails, PHP/Symfony 3, RabbitMQ, Postgres, Docker, Ansible, Puppet, Angular, Bash, Consul, Redis, Gitlab, Jenkins, Nginx, Nodejs
Разработал прототип своей CI/CD-системы. В серию не пошло, поскольку затащить в одно лицо сразу два инфровых проекта я просто был не в состоянии и переключился на более приоритетный, а этот по моей инициативе мы закрыли. Но был вполне рабочий прототип на Ruby on Rails, который даже варил билды и в риалтайме стримил терминал каждой отдельной билдежки на свою страницу билда (причем православно, корректно отображая все спецсимволы), под капотом прятался RabbitMQ.
Технологии: Ruby on Rails, PHP/Symfony 3, RabbitMQ, Postgres, Docker, Ansible, Puppet, Angular, Bash, Consul, Redis, Gitlab, Jenkins, Nginx, Nodejs
2013-2014
ДеньгиОнлайн, аггрегатор платежных систем
Разработчик
Когда-то один из крупнейших агрегаторов платежных систем, который позволял проводить оплату различными способами для интернет-магазинов
2008-2009
ПиН Телеком, оператор связи
Инженер отдела мониторинга центрального узла связи
2007-2008
Один локальный оператор связи
Проводил интернеты в квартиры
С чем работал
Ключевые технологии, с которыми мне приходилось работать на своих коммерческих проектах.
Какие-то использую сейчас на постоянной основе, какие-то использовал раньше.
Что-то знаю лучше (Linux, Bash, Docker, Golang, Graylog, Prometheus, Swagger, Rabbitmq, Ansible, Nginx), что-то хуже (Kafka, elasticsearch), а какие-то — прям совсем в общих чертах (например, Istio, Envoy, Kubernetes).
При необходимости, могу легко погрузиться в нужный скоуп для решения возникшей проблемы.
Сам придерживаюсь мнения, что невозможно быть экспертом во всем и сразу.
Обычно есть какой-то ограниченный стек, в котором ты работаешь и чувствуешь себя более-менее уверенно, используя его для решения конкретных бизнесовых задач, задействуя дополнительные инструменты по мере надобности.
Немного цифр и фактов обо мне
6 лет
Фуллтайм пишу на golang
16 лет
В коммерческом IT
8 лет
Учился по специальности. Сначала колледж, потом университет.Но этого недостаточно — без постоянной учебы и совершенствования навыков никуда.
7
Различных языков программирования использовал в разное время
Go, Java, Python, Ruby, JavaScript, C, PHP.
Когда-то пытался перейти на Scala и экспериментировал с Erlang, но не пошло. В статистику они не входят.
В студенческие годы вполне успешно баловался ассемблером под i8086.
7 лет
Регулярно занимаюсь спортивным плаванием, а как-то раз даже участвовал в соревновании в эстафете по триатлону на дистанции 2км. Уложился в 40 минут, но можно было лучше — если б не петлял зигзагами на открытой воде.
3 года
В среднем на одном месте работы. Стараюсь не менять часто работу, но бывают ситуации, когда уже прям пора.
Заинтересован в долгосрочном сотрудничестве.
Заинтересован в долгосрочном сотрудничестве.
3 роли
Могу выполнять разные роли.От разработчика, до скрам-мастера или руководителя команды.Нельзя сказать, что одновременно хорош во всем сразу, но опыт определенно есть.
Нельзя сказать, что одновременно хорош во всем сразу, но опыт определенно есть.
Мои проекты
Sandbox. Система создания тестовых сред
IQ Option Software, трейдинговая платформа (теперь Quadcode)
Senior developer, команда Continuous delivery
Senior developer, команда Continuous delivery
Спроектировал, разработал систему “Sandbox”, которая предназначена для создания и управления изолированными средами в помощь тестировщикам и разработчикам.
Исходная проблема заключалась в том, что команд и людей было очень много, а тестовых стендов на всех не хватало и люди часто мешали друг другу, ломая стенды, после чего тратили огромное время на поиск и решение проблем с ними.
Возникла необходимость в инструменте, который позволит создавать изолированные тестовые среды по требованию, повторяя реальную production-инфраструктуру.
В результате чего проблемы на одном стенде не будут затрагивать другие и тестировщики смогут параллельно тестировать задачи на собственных стендах, не блокируя друг друга.
Возникла необходимость в инструменте, который позволит создавать изолированные тестовые среды по требованию, повторяя реальную production-инфраструктуру.
В результате чего проблемы на одном стенде не будут затрагивать другие и тестировщики смогут параллельно тестировать задачи на собственных стендах, не блокируя друг друга.
Это был совершенно новый проект в компании. Мне выпал хороший случай оказаться первым, кто начал над ним работать, имея полную свободу действий и возможностей в выборе инструментов.
Что было реализовано:
1. Сборка на лету в отдельной виртуальной машине разворачиваются на лету в отдельной виртуальной машине во внешнем облаке по требованию. Как только сборка становится не нужна, виртуальная машина вместе со всеми контейнерами уничтожается.
2. Конструктор микросервиса. С его помощью разработчик мог создать свой микросервис через веб-интерфейс, указав из каких компонентов он состоит. Например, за несколько минут можно было набросать конфигурацию простейшего микросервиса, состоящего из контейнера с приложением, контейнера с базой данных и контейнера с брокером очередей сообщений. Система уже содержала дефолтные часто используемые компоненты, которые можно просто выбирать из списка. Если нужного компонента нет, разработчик может подключить свой docker-образ, размещенный во внутреннем хранилище docker-образов
3. Собственное хранилище docker-образов. Docker-образы компонентов микросервисов собираются командами самостоятельно с помощью CI и размещаться в общем хранилище образов Registry на наших мощностях (для понимания картины, суммарный объем всех образов был >5TB)
4. Маппинг портов приложений. В интерфейсе управления компонентами микросервиса можно настраивать публикацию портов, которые маппятся на хост-машину, после чего компонент микросервиса становится доступен извне.
5. Возможность управлять переменными окружения на уровне компонентов микросервиса. Переменные окружения могут быть переопределены перед началом сборки (для каждого компонента выбранного микросервиса)
6. Кастомизация образов компонентов перед сборкой. Перед началом сборки можно выбирать, какой образ использовать при сборке. Например, можно запустить свой микросервис и протестировать его на другой версии Postgres, отличной от той, которая используется в данный момент, просто выбрав нужную версию компонента в списке. Удобно, когда хочется посмотреть, как ведет себя приложение на новой версии БД
7. Изоляция на уровне виртуальных машин и контейнеров. Под каждую сборку создается отдельная виртуальная машина, в которой поднимаются сотни контейнеров, под каждый компонент микросервисов. Разработчики и тестировщики могут создавать любое число таких сборок для любых целей и не мешать друг другу.
8. Кастомные облачные провайдеры и поставщики услуг. На уровне архитектуры приложения, была возможность интегрировать любой облачный провайдер, имеющий внешний API
9. Интерактивный процесс создания сборки. Разработчик может видеть процесс сборки выбранного набора микросервисов, видеть логи сборки в веб-интерфейсе.
10. Различные тарифные планы. При создании сборки можно выбрать тарифный план виртуальной машины, что дает возможность подбирать оптимальную мощность создаваемой виртуальной машины для требуемых нужд при разработке или проведения нагрузочного тестирования, вплоть до самых заряженных машин с 32 ядрами, 128 гигами оперативы и 512 SSD с возможностью подключать дополнительные разделы под сторадж)
11. Удаленный доступ к сборкам по SSH. Для каждой сборки у разрабов/тестеров был доступ по SSH, что позволяло управлять хостом и существенно упрощало процесс отладки.
Что было реализовано:
1. Сборка на лету в отдельной виртуальной машине разворачиваются на лету в отдельной виртуальной машине во внешнем облаке по требованию. Как только сборка становится не нужна, виртуальная машина вместе со всеми контейнерами уничтожается.
2. Конструктор микросервиса. С его помощью разработчик мог создать свой микросервис через веб-интерфейс, указав из каких компонентов он состоит. Например, за несколько минут можно было набросать конфигурацию простейшего микросервиса, состоящего из контейнера с приложением, контейнера с базой данных и контейнера с брокером очередей сообщений. Система уже содержала дефолтные часто используемые компоненты, которые можно просто выбирать из списка. Если нужного компонента нет, разработчик может подключить свой docker-образ, размещенный во внутреннем хранилище docker-образов
3. Собственное хранилище docker-образов. Docker-образы компонентов микросервисов собираются командами самостоятельно с помощью CI и размещаться в общем хранилище образов Registry на наших мощностях (для понимания картины, суммарный объем всех образов был >5TB)
4. Маппинг портов приложений. В интерфейсе управления компонентами микросервиса можно настраивать публикацию портов, которые маппятся на хост-машину, после чего компонент микросервиса становится доступен извне.
5. Возможность управлять переменными окружения на уровне компонентов микросервиса. Переменные окружения могут быть переопределены перед началом сборки (для каждого компонента выбранного микросервиса)
6. Кастомизация образов компонентов перед сборкой. Перед началом сборки можно выбирать, какой образ использовать при сборке. Например, можно запустить свой микросервис и протестировать его на другой версии Postgres, отличной от той, которая используется в данный момент, просто выбрав нужную версию компонента в списке. Удобно, когда хочется посмотреть, как ведет себя приложение на новой версии БД
7. Изоляция на уровне виртуальных машин и контейнеров. Под каждую сборку создается отдельная виртуальная машина, в которой поднимаются сотни контейнеров, под каждый компонент микросервисов. Разработчики и тестировщики могут создавать любое число таких сборок для любых целей и не мешать друг другу.
8. Кастомные облачные провайдеры и поставщики услуг. На уровне архитектуры приложения, была возможность интегрировать любой облачный провайдер, имеющий внешний API
9. Интерактивный процесс создания сборки. Разработчик может видеть процесс сборки выбранного набора микросервисов, видеть логи сборки в веб-интерфейсе.
10. Различные тарифные планы. При создании сборки можно выбрать тарифный план виртуальной машины, что дает возможность подбирать оптимальную мощность создаваемой виртуальной машины для требуемых нужд при разработке или проведения нагрузочного тестирования, вплоть до самых заряженных машин с 32 ядрами, 128 гигами оперативы и 512 SSD с возможностью подключать дополнительные разделы под сторадж)
11. Удаленный доступ к сборкам по SSH. Для каждой сборки у разрабов/тестеров был доступ по SSH, что позволяло управлять хостом и существенно упрощало процесс отладки.
На каком-то этапе я понял, что бизнесовая разработка мне интересна больше, чем инфровая, после чего перешел в другую команду.
Вокруг этой системы образовалась новая команда, в задачи которой входило создание инструментов для собственной инфраструктуры разработки, деплоймента и управления серверами компании.
Сама же система в последствии обросла большим числом новых возможностей, была переписана на другом языке и ушла далеко вперед, что очень радует.
Сама же система в последствии обросла большим числом новых возможностей, была переписана на другом языке и ушла далеко вперед, что очень радует.
Прототип микросервиса процессинга платежей
IQ Option Software, трейдинговая платформа (теперь Quadcode)
Senior developer, команда разработки платежных инструментов
Senior developer, команда разработки платежных инструментов
Спроектировал микросервис процессинга платежей и в течение месяца разработал полностью рабочий прототип с одной, основной интеграцией с платежным шлюзом.
— Простая и расширяемая архитектура, которую можно объяснить на пальцах любому новому разработчику в команде
— Интеграция нового платежного способа сводится к написанию отдельного процессора транзакций, реализующего простой интерфейс, принимающего на вход саму транзакцию и отдающему на выходе структуру с результатом процессинга, в которой хранится текущий результат обработки (in-process, paid, failed) и некоторый контекст
— Возможность определения произвольного Flow процессинга под любой платежный метод в рамках процессора транзакций (типичный пример, 3DS авторизация, подразумевающая ряд редиректов на разные страницы, либо один из механизмов выводов через PayPal, в рамках которого может быть до 5 различных редиректов на роуты как на стороне PayPal, так и на нашей стороне для подтверждения транзакции)
— Заявки на ввод/вывод от пользователя связаны со множеством отдельных транзакций 1:N. Есть интерфейс генератора транзакций и при необходимости, можно написать любую кастомную логику, например, пустить часть транзакций через первого поставщика, а другую часть через второго, в зависимости от каких-либо бизнес-требований (более выгодная комиссия, доступность поставщика в данный момент и так далее)
— Микросервис был выделен из монолитного приложения. Это позволяет существенно упростить его вынесение в скоуп PCI-DSS требования которого мы обязаны соблюдать, поскольку работаем с банковскими картами клиентов. Контролировать маленький микросервис с ограниченной функциональностью и несколькими точками входа гораздо проще, чем огромное монолитное приложение, к админке которого имеет доступ половина компании.
Другие проекты, к которым я присоединялся
Вкратце расскажу над тем, с чем приходилось работать в разное время.
Тинькофф Инвестиции:
— Микросервис, отвечающий за данные финансовых инструментов и расписания бирж (отчетности, финансовые показатели, цены, ...)
— По касательной, микросервис отвечающий за стриминг цен с бирж в реальном времени
Quadcode:
— Billing. Внутренняя система для работы с платежами клиентов, различная бизнес-логика по проведению платежей.
— Payment processing. Основной микросервис, обрабатывающий все платежи клиентов и их заявки на вывод средств. Интегрирован с десятками платежных систем по всему миру.
— Crypto services (Bitcoin, Ethereum). Инфраструктура для проведения платежей в популярных блокчейн-сетях.
Что ценю в работе
— Решать сложные проблемы применяя системный подход
— Удаление лишнего кода, замена сложного простым.
— Разумное применение паттернов проектирования.
— Написание простого, понятного, расширяемого и поддерживаемого в будущем кода.
— Проверять свою работу до передачи в тестирование. Тестировщик получает полностью готовую к работе задачу с небольшим описанием того, что было изменено и как можно протестировать (если требуется).
— Взвешенный и прагматичный подход в выборе технологий, инструментов и практик.
— Гибкие методологии разработки, но без "культа карго".
— Рефакторинг, реализация общих решений для множества частных сценариев.
— Покрытие кода тестами.
— Соблюдение общих стандартов разработки.
— Документирование и поддержание этой документации в актуальном состоянии.
— Целостный и непротиворечивый взгляд на вещи.
— Предпочитаю работать быстро и качественно, адаптируясь к потребностям заказчика. Поддерживаю баланс между стоимостью/результатом.
— Предпочитаю работать быстро и качественно, адаптируясь к потребностям заказчика. Поддерживаю баланс между стоимостью/результатом.
— Конструктивную конфронтацию в выборе технологий, подходов, идей
— Честность, открытость и взаимоуважение в команде, атмосферу сотрудничества.
— Признание своих ошибок.
Примеры кода
Как-то раз мне потребовалось выбрать монитор для покупки, вот что из этого вышло.
В целом можно сказать, что так обычно выглядит мой код на работе.
Монитор так и не купил, но зато весело провел время.
Вопрос-ответ
Рассматриваешь релокацию?
Релокацию в другие страны или другой город к сожалению, по личным причинам не рассматриваю.
Из офиса — только Санкт-Петербург, удаленно без ограничений.
У нас работа только из офиса. Тебе ок?
Да, мне вполне ок. За живое общение и подобный формат нравится больше, чем удаленка.
У нас работа только на удаленке. Тебе ок?
В целом ок, хотя я больше за живой формат работы. Но если нет других альтернатив, то сойдет.
Какой график работы подходит?
Стандартные 5/2, 10:00—20:00 с перерывом на обед. В будние дни работаю, в выходные отдыхаю.
При этом понимаю, что могут быть исключительные ситуации, когда сервисам плохо и нужно в любое время срочно подключиться, чтобы их починить или делегировать кому-то решение проблемы после того, как понятно в чем именно проблема и твое непосредственное участие не требуется.
Для таких ситуаций постоянно на связи и готов подключаться. Это нормально.
Как быстро готов выйти на новое место работы?
Если мэтчимся по всем параметрам, то сразу.
Был опыт работы в географически распределенной команде?
Да, причем в разных часовых поясах с неплохим сдвигом. Не скажу, что мне это сильно нравится, но в целом терпимо и работаемо. Все-таки коммуникация ускоряется, когда тебе не нужно кого-то ждать (или кому-то ждать тебя).
Что нравится больше? Разработка или управление?
Очень сложный вопрос. И то и то интересно, есть свои плюсы и минусы. Это просто разные сферы, развиваться можно вполне успешно и там и там, совмещая эти роли в какой-то пропорции.
Хотя по своему опыту могу сказать, что если серьезно уходить в управление, времени на разработку почти не остается как и наоборот, если занимаешься фулово разработкой, то не до управления. Но здесь могу говорить только за себя.
Больше предпочитаю сначала пройти этап разработчика в той или иной команде. После этого, спустя время — когда проект станет понятен, можно рассмотреть вариант анлока позиции руководителя.
Какие задачи нравятся?
Люблю рефакторинг. Большáя часть моей работы была связана с рефакторингом уже написанных проектов.
Какие-то писались в спешке, какие-то начинающими разрабами без применения каких-то стандартов или паттернов проектирования или принятых в сообществе разработчиков устоявшихся подходов.
Проекты разрастались и их было крайне тяжело поддерживать — добавление каждой новой фичи требовало каких-то титанических усилий.
Мне нравится все это переписывать, разбираться в хитросплетениях логики, удалять странный код, упрощать то, что сделано сложно.
Также нравятся архитектурные задачи. Написать крупный модуль, либо микросервис с нуля и покатить все это на инфру на разные окружения, под ключ.
Что предпочитаешь больше — инфраструктурную или продуктовую разработку?
Нравится и то и то.
Есть опыт разработки с нуля сложных инфровых систем, которые управляют микросервисами в облаке (заказывают виртуальные машины, следят за нагрузкой, регают всю вспомогательную балалайку вроде ns-записей, прокатывают провижионеры, закатывают приложения, связывают их между собой чтобы они могли общаться друг с другом и так далее).
Был интересный опыт разработки своей CI/CD-системы (in-house, в компании). В серию не пошло, поскольку затащить в одно лицо сразу два инфровых проекта я просто был не в состоянии и переключился на более приоритетный, а этот по моей инициативе мы закрыли. Но был вполне рабочий прототип на Ruby on Rails, который даже варил билды и в риалтайме стримил терминал каждой отдельной билдежки на свою страницу билда (причем православно, корректно отображая все спецсимволы), под капотом прятался RabbitMQ.
При этом, есть опыт разработки крупных бизнесовых приложений со сложной, ветвленой логикой и дробленкой из различных бизнес-правил, где цена ошибки может быть очень большой (порядок такой: десятки тысяч если повезет или миллионы долларов если не очень повезет).
Связаться
Адрес
Россия, Санкт-Петербург
Когда доступен
Любой день с 10:00—21:00
Как связаться
Telegram: denistv777
