Как работают ИТ-специалисты. Максим Зелинский, компания «Сбербанк-Технологии»

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

    Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.

    Сегодня наш гость — Максим Зелинский из компании «Сбербанк-Технологии». В его компании много внутренних проектов. Максим предлагает лайфхак, который подходит для тех, кто не считает себя гениями-многостаночниками.



    Чем занимаетесь в компании?

    Я отвечаю за развитие Платформы для задач Единой Фронтальной Системы — системы, которая будет обслуживать всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и так далее). Наша команда занимается high-load и high-availability архитектурой, отвечает за выбор технологических решений и создает системные и инфраструктурные сервисы.

    Одно слово (словосочетание) лучше всего описывающее как вы работаете:

    Хардкорный Research & Development (R&D).

    Сколько часов в сутки вы уделяете работе?

    У меня получается, что я начинаю работать, когда еду в метро. Когда приезжаю на работу, начинаются митинги, совещания, и где-то под вечер я могу продолжить работать, затем заканчиваю дома. В сумме получается 11-12 часов.

    Что еще делаете по пути на/с работы?

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

    Сколько часов вы спите?

    Стараюсь спать 8 часов.

    Каким to do менеджером пользуетесь лично вы?

    Я пробовал Trello. И сейчас иногда им пользуюсь.

    Каким таск-менеджером / issue-tracker’ом / репозиторием пользуетесь?

    СберТех использует стек Atlassian: JIRA как issue-tracker, Confluence – для wiki и Bitbucket – для Git-репозиториев.

    Какое рабочее окружение используете? Фреймворки, другие сторонние продукты?

    Для артефактов мы используем Nexus, где помимо Java-артефактов мы так же храним JavaScript-артефакты в виде NPM модулей. Сборка у нас на Jenkins.

    Вообще у нас все довольно просто: фронтенд – это JavaScript, бекенд – это Java.

    Что касается технологий, то мы плотно сидим на React’е как для web, так и для mobile. Сейчас мы активно пилотируем React Native для приложений, которые используют сотрудники Банка.

    Есть ли в вашей команде какие-то внутренние проекты, библиотеки и для чего они создавались?

    Наша команда, по сути, только и занимается созданием библиотек, предназначенных для разработчиков, которые уже реализуют бизнес решения на базе Платформы для разных каналов (интернет банки, мобильные приложения и так далее).

    При этом мы стараемся быть практиками и создавать библиотеки только для тех кейсов, которые, во-первых, реальны (порой приходиться апеллировать к YAGNI), во-вторых, подразумевают переиспользование между разными командами.

    На бекенде мы используем проекты Spring, при этом мы их постепенно переписываем под наши задачи. Вообще проекты, которые развиваются в составе Spring, если не брать Spring Framework, очень разные по качеству и порой не совсем совместимы: Spring Session, который мы использовали, не до конца поддерживает Servlet спецификацию в части работы с HttpSession, что проявлялось в очень странном поведении Spring Web Flow, который мы так же использовали.

    При этом сам Spring Web Flow под наши задачи то же перестал подходить: нам пришлось его сначала сильно модернизировать для поддержки SPA (SWF заточен на server-side отрисовку), и после многочисленных попыток заставить его стабильно работать (и отчасти из-за непродуманных механизмов для расширения) мы написали свой аналог, полностью рассчитанный на работу с SPA, и который, я надеюсь, мы в скором времени выложим в open source.

    Что вас раздражает больше всего, когда вы работаете?

    Все мою карьеру я всегда придерживался принципа You Build it – You run it. Когда команда разработки и команда сопровождения – это одна команда (пускай линейно подчиняющаяся разным менеджерам), имеющая одну цель, отвечающая как за time-to-market нового функционала, так и за его надежность и производительность.

    В Сбертехе отдельная команда разработки и отдельная команда эксплуатации. Мы стараемся взаимодействовать, общаемся очень тесно, но наши KPI не всегда совпадают. Из-за этого возникают конфликты: мы хотим что-то быстро внедрить, а отдел эксплуатации заинтересован в том, чтобы все было от и до протестировано, имело абсолютно все механизмы по отказоустойчивости. Иногда это оправдано, но иногда это просто overhead. В эпоху Agile подобная конструкция, по моему мнению, должна претерпеть изменения. В качестве важного шага сейчас в Сбербанке и СберТехе идет проект по внедрению практик DevOps, мы все увидим первые результаты уже в 2017 году.

    Мне импонирует система, которая применяется, например, в Google – когда у каждой команды есть свой бюджет по доступности системы, которым она распоряжаются. То есть, если на протяжение нескольких релизов система постоянно падала, то пока не наверстается бюджет, эксплуатация блокирует новые релизы. Но при этом если бюджет есть, то команда сама выбирает какие решения по надежности она применяет и как, и эксплуатация не вправе блокировать релизы.

    Какую профессиональную литературу вы бы могли порекомендовать?

    На мой взгляд, самая лучшая книга по архитектуре – Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Там рассмотрены все аспекты: что такое архитектура, кто является ее заказчиком, какие аспекты надо освещать в архитектуре и так далее.

    Вторая книга по архитектуре с упором на надежность – High Availability and Disaster Recovery: Concepts, Design, Implementation. Она немного устаревшая, но там есть такой раздел: анализ ценности решений по отказоустойчивости. Мы обычно начинаем с каких-то простых и относительно дешевых решений: например, ставим балансировщики. При этом мы можем закончить ужасным адом, который совсем чуть-чуть добавляет проекту надежности, но разработка этого фрагмента функциональности стоит безумных денег. Эта книга учит рациональному подходу: всегда есть single point of failure, и что если его нет, то мы о нем просто не знаем.

    Из легкого чтения я рекомендую – Release It. Я считаю эту книгу полезной абсолютно всем: разработчикам, архитекторам, менеджерам.

    Что предпочитаете: электронные читалки или бумажные книги?

    Предпочитаю бумажные. Но обычно техническая литература – это книги по 600 страниц. Поэтому приходится часто использовать электронные читалки — я для этого использую iPad первого поколения. Но я все равно стараюсь покупать бумажные книги, чтобы они хотя бы стояли в моей домашней библиотеке.

    Какую технику (компьютеры, планшеты, смартфоны) и операционные системы вы предпочитаете на работе и дома?

    Все мои мобильные устройства – это Apple. По крайней мере, несколько лет назад было актуально их главное преимущество – высокое качество. К сожалению, сейчас они стали гораздо хуже. Но у меня есть старый белый пластиковый MacBook, просто не убиваемый: я там батарейку только периодически меняю, и все. Даже HDD стоит родной.

    На работе у нас Windows (кроме iOS разработчиков, естественно), но недавно был запущен пилотный проект по переходу на Linux. Многие коллеги сразу же в этот проект вписались.

    Вы слушаете музыку, когда работаете?

    Нет, я предпочитаю тишину. Музыка меня отвлекает.

    Какой лайфхак позволяет вам быть эффективнее?

    То, чему я научился на своем опыте – это необходимость делегирования. При этом надо стараться нанимать людей, которые умнее тебя, чтобы можно было со спокойной душой доверить им задачи, которые даже тебе не по зубам. Все самому успеть невозможно.

    Без каких приложений и сервисов не можете обойтись ни в работе, ни в личной жизни?

    Очевидно, почта. WhatsApp – у меня там почти все друзья сидят. Trello – это мой трекер задач и активностей.

    Что бы вы порекомендовали человеку, пытающемуся пройти тот же путь?

    Самообразование – это самое важное. У тебя может быть опыта мало, и ты сейчас еще учишься в институте, но хорошо знаешь, например, Core Java, пробовал для себя разные технологии и делал какие-то свои маленькие проекты. В этом случае ты уже достоин работать в компаниях, где относятся к соискателям как к людям. Просто в некоторых компаниях есть жесткий прескрининг: нет опыта – даже не смотрят.

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

    Поэтому надо постоянно заниматься самообразованием. При этом надо именно хорошо разбираться в основах – ничего страшного, что кандидат забыл API какого-то компонента, но если он может рассказать, как он работает внутри (или хотя бы предположить, пусть и не совсем правильно), это уже 100 очков вперед.

    То же самое касается и языков программирования – я считаю, что надо всегда хорошо ориентироваться как минимум в двух языках, желательно диаметрально противоположных: например Java и Python, или .Net и Erlang. Порой экосистема одного языка или технологии очень сильно ограничивает мышление.
    Поделиться публикацией

    Комментарии 26

      +1
      Уж не знаю на тему KPI, но после сообщения про одну дыру прошло полтора месяца, а вот и ныне там. Т.е. вроде все все прочитали, но никто не заинтересовался, хотя исправление заняло бы от силы полчаса
        +2
        Привет! А продублируйте на nvfilippova.sbt@sberbank.ru, пожалуйста
        0

        Что-то мне кажется у интервьюируемого сейчас этап завышенных ожиданий в СБТ. Проекты платформы ЕФС сейчас в Сбере — наиболее гибкая часть компании, но и самая нестабильная. Но, похоже, люди работающие в них, так и на миддл-топ менеджерские местах плохо представляют, что такое Agile, и что он не обязан, в отличие от DevOps, интегрировать в процесс поддержку. А пропасть на самом деле между продуктовой командой(-ами) и сопровождением гигантская. Это и разные пространства имен, и разные юр. лица и разные задачи, вплоть до острых конфликтов. Да что там говорить — одной поддержки только несколько видов, и все грызутся.


        Пока на уровень линейных управленцев не снизойдет технические откровения гибких и автоматизированных подходов, а до разработчиков обязательное требование прокадывать конвеер от идеи, затем через тестирование в сопровождение в автоматическом режиме, с участием тестеров, бизнеса и поддержки на всех этапах — то процесс не покатится, как бы Греф с Мельниковой не утверждали, что в Сбере есть Agile. Ну, разве что такие лица говорят об уровне 1-2 команд разработки на весь банк.

          +1
          Сейчас в agile переведено несколько сотен сотрудников СБТ и перевод продолжается волнами, 2017 год будет еще активнее. Мы понимаем, что компания большая и физически невозможно внедрить эти изменения моментно — как бы нам самим ни хотелось :)
            0

            Я не о массовости. Какие сотрудники? Разработчики и аналитики? А тестирование где? А приемка, хотя бы UAT? Как был ватерфол, так пока он и есть.

              0
              Мы формируем agile команды так, чтобы они самостоятельно обеспечивали полный цикл разработки и выпуска релизов своего продукта. Поэтому команды состоят из участников, обеспечивающих данный цикл, это и разработчики, и аналитики. Эти же участники должны обеспечивать и тестирование своей разработки внутри команды. Участники команд – некие универсальные солдаты :)
              Тестировщики, как таковые, выделяется в команды/трайбы только в отдельных случаях. Это одно из основных отличий от waterfall.
                0
                Вы точно ничего не путаете? Вы вообще в курсе, что такое Agile?
                Да, это самоорганизующаяся кросс-функциональная команда, но одно из главных отличий от водопада — это участие всех заинтересованных сторон с момента идеи (формирования продакт бэклога) до снятия системы с эксплуатации\расформирования команды. И «заинтересованные стороны» — это и представители бизнеса — PO (хотя бы, а лучше с участием кур на Backlog grooming\PI planning), и тестирование, которое проводит валидацию в соответствии с пользовательскими историями, полученными от PO\кур. А не какая-то сферическая разработка с последующей жалобой на сопровождение, которое вы даже не пытаетесь в команду привлечь.
          0
          Хотелось бы по подробнее услышать о принципах работы команды разработки и эксплуатации… Это просто беда.
            +1
            с чем именно беда, напишите свои вопросы)
              –1
              Пришёл утром в понедельник оформлять заявку на кредит, заполнили анкету с сотрудником на компьютере, он нажал печать.
              Перед тем как подписывать, решил проверить анкету, там оказался перепутан пол, доход в месяц с расходом, образование сбросилось и т.д.

              На мой вопрос — «Что за фигня?» Сотрудник с ответил с безразличием — «похоже платформу обновили в выходные, если хотите, чтобы нормально заполнилось — лучше прийти завтра».

              p.s. Завтра стало лучше, но кредит мне в итоге так и не одобрили, вот теперь думаю — почему.
                0
                В общем я работаю с почтой РФ… Мы работаем в сопровождении)… а разработчик, это другая наша дочерняя компания, так вот все то что описано в статье и возникает, только конечно проблем еще больше, потому у Сбертеха хоть одна компания)))
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                а когда проходили?)))
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    Так это такие дремучие времена. Попробуйте еще раз хотя бы для интереса, посмотреть на изменения. Потом поделитесь впечатлениями))
                    • НЛО прилетело и опубликовало эту надпись здесь
              • НЛО прилетело и опубликовало эту надпись здесь
                  –2
                  Вроде всё правильно и красиво написано, но не могу отделаться от ощущения, что в статье забыли упомянуть один из основных любимых ресурсов интервьюируемого: лук эт ми :)
                    0
                    Да вроде ага борода модная и все классно. Но все банки с нами реализовали проект за две недели, а сбер за два года. А последний раз возник казус во взаимодействии API и сотрудник сбера примерно так сказал: сделайте чего нибудь с вашей стороны, а то с нашей это на долго.
                      –1
                      Часть про смузи пропущена
                        0
                        Действительно стоящие книги перечислены? Release it!
                          +3

                          Интересно, 11-12 часов в день — overtime оплачивается? В чем смысл — настолько интересно работать, неэффективная организация работы, малое количество сотрудников, попытка выслужиться?


                          Я не верю, что можно работать 11-12 часов в день на протяжении длительного времени. И разве жизнь для этого дана? Работа — важная составляющая жизни, но если работать 12 часов, прибавить сон, прибавить дорогу — времени на саму жизнь не останется, нет?..

                            0

                            Все переработки оплачиваются по ТК РФ

                              +1
                              NFil лучше б не переработки оплачивали, а вместо двух системных блоков и одного монитора, ставили бы два моника и один системник с интернетом.
                              Давали бы Linux/Mac/Win на выбор, вместо принудилова на винду и разработку в Альфе без инета с кривым зеркалом npm репоза. Разрешили бы Docker, чтобы люди по 4е дня проекты не собирали. Не принуждали переходить на Typescript, многие разработчики не разделяют любовь к этой поделке от MS.
                              Рассказали про разработку через тестирование. И не заставляли аутстафф ездить в ваши офисы. Исходиники ЕФС давно на всяких bitbucket'ах, gitlab'ах и github'ах валяются. Но в любом случае: удачи в переходе на agile ;)
                              +1
                              Да, с временной оценкой там беда и не аджайл пока, а сберджайл. Но они меняются, корпорация большая и на это нужно время.
                              0
                              Уважаемые клиенты интернет эквайринга ПАО Сбербанк, инцидент "Нестабильная работа процессинга" устранен в 21:25

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


                              Или устранение инцидентов выглядит:


                              ssh root@ultrahugedb.sberbank.ru
                              >>> sudo rm -r fucking-giant-logs/*.log
                              >>> sudo reboot

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое