Хабрахабр

Артём Галонский, СТО БюроБюро: «Я против такого понятия, как DevOps-инженер»

Вот муж-код деплоится на работу. Вы применяете DevOps-подход у себя дома? Кот-мониторинг вовремя ускользает из-под ног, сам чистит свой лоток и громким мявом обозначает, когда жена отклоняется от установленного протокола. Жена-инфраструктура готовит яичницу, варит кофе, гладит рубашки.

Он читал лекцию о CI/CD и введении в автоматизацию. На первом дне Слёрма DevOps я познакомился с Артёмом Галонским, СТО БюроБюро. А заодно делился практическими примерами, вроде построения «общего» пайплайна. Рассказывал о фабричных конвеерных линиях сборки и их применении в IT.

Артём меня ошарашил, заявив, что DevOps-инженеры существуют в той же вселенной, что и розовые единороги. После выступления я выловил его на кофебрейке и попросил рассказать о месте DevOps в его профессиональной деятельности, а заодно какие требования он видит для должности DevOps-инженера. И что для него «нет DevOps-инженеров, есть хорошие админы, которые понимают Kubernetes».

О карьере

Начинал в БюроБюро? Ты в разработке 11 лет.

Начинал, как фрилансер в 2008 году, затем поднимал несколько стартапов. Нет. Просуществовал 2 года и сложился. «Отфермера» был такой стартап. Была небольшая команда — 4 человека. В 2011 году начал заниматься СRM системами для страхового агентства. Был ведущим разрабом, руководителем отдела разработки компании. В 11-12 году стал тим-лидом. И в начале 2018 года я перешёл в БюроБюро. В 2017 стал СТО компании РедСтарт в Калининграде.

Что тебя привлекло?

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

Почему?

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

Что там огромное количество талантливых и умных людей, которые по ряду причин — психологических, социальных, финансовых — не могут переехать в столицу. Мы в Southbridge считаем, что потенциал провинции до сих пор не раскрыт полностью.

Да тут даже не то, что психологические или какие причины… Просто люди не хотят переезжать.

Не все хотят переезжать. Да, я об этом и говорю.

Человек просто не хочет. И это не какая-то проблема — психологическая или финансовая.

Согласен. Да. Скорее «установка». «Проблема» — неудачное слово.

Ему там комфортно. Человек просто не хочет. Мне было сложно утром тратить 40 минут на поездку в метро. Я полгода проработал в Москве, собирая команду. Я сейчас в Калининграде эти сорок минут иду по живописным местам, мимо озёр, мимо красивых домов. Либо в пробках на машине ещё дольше. И дышу чистым воздухом. И эти сорок минут я наслаждаюсь жизнью. 40 минут — и я в Европе. 20 минут — и я на море. И вот уже год наш бэк-офис — разработка, тестирование, аналитика, менеджеры поддержки — находится в Калининграде. Плюс много ребят, которые живут в Калининграде, когда узнали, что я возвращаюсь, сказали «Ок, давай, мы с удовольствием вернёмся в твою команду и продолжим работать с тобой». И мы рады и счастливы.

А в Москве?

Управление, руководители проектов, аккаунт директора, проектировщики интерфейсов, дизайнеры и системные администраторы. В Москве у нас фронт-офис.

И как взаимодействие?

Всё работает практически идеально. Ничего не мешает. Всё зависит от того, как настроить.

Ты сам, как СТО, кого предпочитаешь — удалённых сотрудников или в офисе?

Workflow я опускаю — потому что если workflow не будет налажен, то совсем неважно, как обмениваются знания. Главное, наладить правильный обмен знаниями. А вот обмен знаниями, чтобы люди делились своими практиками — что они изобрели, поняли, сделали — то лучше inhouse, когда они сидят в одном кабинете. Всё равно ничего работать не будет. А когда люди удалённо, они могут и не делиться. Так или иначе начнут общаться на эту тему. Необходимо замотивировать людей, чтобы они делились этой информацией. Потому важно создать базу знаний. И потом делится с другими. Каждую пятницу технологизация, то есть каждый у кого нет «горящего» проекта, вторую половину пятницы занимается самообразованием.

О развитии

Как ты мотивируешь?

Прямо говорю, в «вебе» всё меняется очень быстро, и если ты не будешь развиваться, то ты останешься на этом уровне навсегда. Я мотивирую развитием. И в плане денег ты не вырастешь, и в плане развития.

Одна из моих любимых цитат Льюса Кэролла из «Алисы в Стране чудес»: «Здесь приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее».

За те 11 лет, что я занимаюсь вебом, технологии кардинально изменились. У нас практически так же. Сейчас это везде. Два года назад мы, условно говоря, не знали, что такое Кубернетес и как его внедрять. Потому что будут нагрузки возрастать. И через год это необходимо будет каждому. Начиная каждый проект, мы стараемся внедрить что-то новое. Если ты не будешь прокачивать знания и использовать их в своих проектах, то ты останешься позади. А нам чуть легче — начиная новый проект, мы внедряем новые технологии, которые изучили и обкатали. Работая постоянно на одном продукте, довольно сложно внедрить новое. И от проекта к проекту мы развиваемся.

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

Это вот такая прямая линия, куда мы движемся, уйти с PHP полностью на Go и развиваться в нём. У нас то, что мы сейчас делаем, стек достаточно простой — фронтенд react.js, для бэкенда мы раньше и частично сейчас использовали PHP, сейчас полностью стараемся перейти на Go. То есть наш стек — это React.js, PHP и Go. Это новая, хорошая, стабильная технология, которая даёт отличный прирост скорости — и в разработке, и в скорости продукта самого. Ну, а так стандартные технологии Redis,PostgreSQL, RabbitMQ. Это то, что касается языков программирования.

Мы недавно общались с ребятами — так они друг друга подкалывали тем, что некогда были профи в Perl. Ты можешь вспомнить технологии, которые уже устарели.

Ну, наверное, Perl ещё кто-то использует. Да. Тот же js пришёл в «ноду» и стал node.js. Тот же JS, который развивается постоянно… То, что было до ES6, устарело, или тот же jpl. 2 под современные тенденции развивается. Тот же php, ну кому-то он не нравится — версия 5 была плохая, сейчас 7. Морально, возможно, да. Для меня нет того, что полностью устарело. Раньше, 10 лет назад использовал MуSQL, сейчас на проекты, которые я закладываю, он бесполезен практически везде. Или я вырастаю из технологий. Те технологии, которые были у меня… Скорее всего, я просто вырастал из них, чем они устаревали.

Чем тебе сейчас нравится Go?

Всем. Скорость выполнения, экономия. Горутины, мультиканальность. То, что я вижу, общаясь со своими архитекторами, лидами и разрабами, скажем так, то, что мы привыкли видеть в скриптовом php, осталось это в Go плюс добавились возможности компилируемых языков. Плюс строгая типизация данных. То, чего не было в php, и мы это делали через php-fpm, условно говоря. И ещё быстрая компиляция самого бинарника.

Что для тебя хороший разработчик?

Естественно, он же не будет эти 2-3 месяца ничего не делать. Для меня хороший разработчик — это тот, кто может переключиться на новый язык программирования где-то за 2-3 месяца, чтобы понять его. Быстро прокачается — и начнёт закрывать сложные, хорошие таски. Он будет на стадии «джуна», делать несложные таски.

Ты свою компанию к какой относишь — к оранжевой, бирюзовой?

Скорее оранжевая. У нас не бирюзовая точно. Я сам немного авторитарен в управлении. С вертикальным управлением. Если не доказали, значит, это не надо. Мы делаем так и так — и если ко мне не придут и не докажут с явными примерами, что лучше по другому, меня будет очень сложно переубедить. По этой и вот этой причине. Предположим, приходит сотрудник и говорит: «Артём, нам надо делать так. Да, ты директор и архитектор. Ты предположил плохую идею. И надо делать так.» И если мне явно и на 100% не доказали, то я буду продавливать своё решение. Но ты предложил не очень хорошую идею. Так что не бирюзовая точно.

И как сотрудник сможет тебе доказать, что её стоит использовать, если мало кто ещё применяет и нет ещё репрезентативных примеров и практических кейсов? Скажи, условно говоря, появилась новая технология. Но технология предположительно перспективна.

Ну, не просто: «Посмотри, вот я что сделал». Показать pet-проект. Чтобы человек осознанно это делал, попытался выложить это на продакшн, дать на него нагрузку. Это что-то должно быть уже скомпонованное. Я создал небольшой завершённый продуктик или микросервис». Пришёл ко мне и сказал: «Я нашёл такую-то фичу, язык, технологию. Тут ещё проблема какая — при работе с серьёзным бизнесом нужны устоявшиеся технологии. Тогда я прислушаюсь. А наши заказчики — они иногда монстрообразные, из-за того, что очень большие, особенно государственные — они готовы только к стабильным технологиям и не любят эксперименты. Мы-то можем идти вперёд и двигаться. Мы не будем работать. Помню, два года назад предложил кому-то react.js — и резкий ответ «Нет. Это какая-то библиотека для UI. Зачем? Html, Css, Js — это нам подходит». Нет. Пока технология не стабилизируется, пока они не найдут человека, который будет знать эту технологию и поддерживать её изнутри — рисковать они не будут. В крупных корпорациях государственных структурах так получается, что запаздывает немного освоение новых технологий.

О проектах

Когда тебе легко работать с заказчиком?

Вот тогда становится интересно работать. Думаю, когда на стороне заказчика есть хороший архитектор. И они понимают, как это будет реализовано. Тогда получается и хороший заказ, и хорошие задачи, и хорошие решения. Системы-то очень большие. А когда на месте заказчика только менеджмент и продуктовый аналитик, которые хотят как-то так эту фишечку, вот тогда сложнее. И нам говорят: «Ой, а свяжите вот эти два продукта между собой. И поставляем продукт, который будет являться частью системы. И ты спрашиваешь: «Ребята, окей, а как оно внутри должно происходить? Чтобы пользователь нажал вот на эту кнопочку и у него появилось вот это…» А под капотом там лежит очень много — авторизация, передача данных. Главное, чтобы всё красиво было. Что именно вы хотите?» А они в ответ: «Ой, мы не знаем. Пусть они проверяют — хорошо работает или плохо». А что под капотом — вы расскажите нашей информационной безопасности.

Ты можешь вспомнить пример, когда вы быстро и оригинально решили проблему?

А ЕСИА часто ложится. Есть у нас проекты, у которых авторизация только по ЕСИА. И идёт сверка данных из ЕСИА, что у него не обновился паспорт или иные документы. Человек, когда авторизуется, мы проверяем, что это именно он авторизовался. И у нас группа клиентов, которые пытались авторизоваться, получили сообщение «У вас изменились данные. И тут ЕСИА что-то напутала. ЕСИА начала выдавать новые имя-отчество или новые паспортные данные. Подтвердите, пожалуйста». И мы остановили авторизацию на время. А мы не можем ничего сделать, потому что у нас система так настроена, что ЕСИА — центр правды для нас. Наши админы на уровне балансера пользователей перекинули на страницу «Извините, временно не работает». ЕСИА достаточно быстро всё решила. А новых пользователей не пускали. А мы быстро дописали, чтобы могли авторизовываться только старые клиенты без обновлений временно. Ну, это не совсем наша ситуация, но мы туда подключались для решения.

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

Дочерняя компания Siemens, которая занимается лизингом в России. А: Получил удовольствие… Мы делали личный кабинет для Siemens Finance. Тут удовольствие в том, что со стороны Siemens дали возможность выстроить хорошую архитектуру, заказчик не вмешивался, протранслировал «Ребята, мы вам доверяем». Мы совместно с ними разрабатывали личный кабинет. Очень приятная работа с заказчиком. Мы сделали хороший UI и UX для них. Тут реально получил удовольствием от работы. И это не было вызовом или преодолением. И вот продукт работает, живёт. От продукта, который в итоге получен. А так вызовы у нас постоянно. Он всем нравится — и мне он нравится. В каждой компании по 12 отделов — есть отдел IT, есть отдел инфраструктуры, отдел бизнес-логики, отдел ещё чего-то-там. При работе с крупными компаниями без этого никак. И согласовать какие-то изменения со всеми этими отделами — это вызов. Плюс есть ещё куча вендоров, людей, таких же, как ты сам, которые интегрируют свои CRM. Ты предлагаешь свою архитектуру, общаешься с архитектором основной компании, взаимодействуешь с архитекторами вендоров…

А разве этим не должен заниматься архитектор компании-заказчика?

Есть такая модная тема — цифровая трансформация. Не всегда. Например, биллингом или банковским сектором. Например, в компании есть архитектор, и он занимался непосредственно архитектурой своего решения. Но хороший специалист начинает учиться. Но он как архитектор всей системы не обладает необходимым опытом и компетенцией. И приходится общаться долго и объяснять, мол, ребята, давайте попробуем это прогрессивное решение. А кто не очень или уже в возрасте, тут немного сложнее — потому что они за новыми тенденциями слабо следят. Там достаточно просто — условно, синхронизируемся так, подключаем эти модули так. А где-то есть молодые архитекторы, которые выросли на современном «вебе». И они быстро и грамотно разруливают.

То есть ты уже видишь два разных поколения разработчиков?

Потому что сейчас всё переходит на «веб». В «вебе» — да. А API чаще всего http и https. Сейчас даже внутренние системы — постепенно переходят в микросервисы, которые общаются по API. И проще всего внимать тем, кто работал в web. Архитекторы должны понимать, как это устроено. Очень часто бывает такая ситуация. На мой взгляд. Он видит, какой сайт у конкурента, как этот сайт работает. Заказчик хочет новый крутой сайт. А мы-то занимается только сайтом. И он приходит, требует, чтобы мы наладили всю цифровую историю сайта, вплоть до CRM-ки. И получается так, что мы становимся драйвером изменений для определённой компании. Мы готовы синтегрироваться с чьей-то CRM.

О технологиях

Цифровая трансформация — насколько по твоему мнению она необходима?

У нас очень большое количество заказов сделать загрузку «эксельки». Как любая хайповая тема, она и модна, и необходима. И им надо сделать так, чтобы эта «экселька» загружалась, парсилась, превращалась в базу данных и дальше можно было работать с ней, а потом выгрузить. Невероятное количество компаний ведут работы в Excel. И отказаться от эксельки и жить в нормальном web-мире. Цифровая трансформация должна привести к переходу на нормальные системы работы — CRM, системы контента, СМS. В предыдущей компании, где я работал до Бюро-Бюро, у нас были две компании-клиента. Есть такой хороший пример. В одной компании работа с клиентами шла через Excel. А мы смогли детально отследить, как всё происходит. Это был 2012-2013 год. Там была большая база данных. И одна компания ушла работать в «эксельку». Обычная CRM там не подходила — большое workflow и на обычной CRM настраивать всё это очень долго. В итоге, первая компания через полгода после того, как они дошли до пика продаж, и у них началась работа с клиентами — они схлопнулись. А вторая потратила полгода — и написала свою CRM. А вторая компания со своей CRM наоборот быстро по одной кнопке отслеживали, что за клиент, как он попал к ним, что ему ответили менеджеры. Просто их служба обращений не смогла обеспечить хороший и быстрый сервис. Электронный документооборот — тоже тренд. Они выжили в этот пик роста — и работают до сих пор. Кто оперирует быстрее информацией, тот быстрее зарабатывает. Экономия времени. Если нет хорошего мониторинга и нет хорошего логирования на проекте, то инженеры не смогут понять быстро, в чём проблема. Так во всём. А значит надо не просто забацать красивый сайтец, а необходимо построить правильный сайт и правильную систему логирования. А от этого сейчас по-настоящему зависит выживаемость и успешность бизнеса. Необходимо идти в ногу со временем. Цифровая трансформация нужна. Если есть такие технологии, надо стараться их внедрить.

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

Лет через пять это станет актуально. Будущее за machine learning и AI. Сейчас всё поутихло. Год назад была крипта и был machine learning на хайпе. Работы ведутся — опыт и решения накапливаются. Но всё равно в ближайшие пять лет machine learning выстрелит, как я думаю.

Это касается и учителей, и экономистов. Есть мнение, что с машинным обучением и искусственным интеллектом много профессий просто пропадёт. Какие профессии в IT, как ты видишь, пропадут? И юристы поговаривают, что технология блокчейн подвинет определённые сферы в юриспруденции.

Как мне кажется в ближайшие года три. Исчезнет точно, как я думаю, верстальщики. (смеётся) Скорее всего, скоро напишут machine learning, который будет хорошо верстать. Как говорится, запомните этот твит. А дальше, наверное, пропадут программисты несложных систем. Что-нибудь придумают. Всегда программисты будут. Но всё равно всегда останутся программисты, которые будут проектировать и программировать ядро микрочипа.

O DevOps

Сейчас на рынке есть определённый дефицит DevOps-инженеров…

Послушай, я категорически против такого понятия, как DevOps-инженер.

Почему?

DevOps-инженер — кто это? DevOps — это практика, это философия. Для меня нет DevOps-инженеров, для меня есть хорошие админы, которые понимают Kubernetes. Это прокаченный админ или это хорошо прокаченный «бэкэндщик», который может в админа? Единственное, что я приемлю для себя, это DevOps-евангелист. Но Kubernetes — это не DevOps. Научиться общаться и взаимодействовать». Который может прийти в компании и сказать: «Ребята, нам надо двигаться в этом направлении. Вообще, вся философия DevOps — это про взаимодействие. Потому что DevOps- это не про технологии. И все эти DevOps-инженеры мне напоминают хайп по scrum-мастерам года три назад. Чтобы научились общаться разработка и QA, и в дальнейшем поддержка. Или лет пять назад всем остро был нужен менеджер по настройке Jira. Всем нужны были scrum-мастера, никто не мог без них работать. И всё, что с приставкой DevOps — это просто для увеличения своей стоимости на рынке труда. И если нет человека, который нам настроит «джиру», то работа не будет двигаться.

То есть ты думаешь, что год-два и мода схлынет?

Но люди начнут прокачиваться. Ну, хайп-то уйдёт. Поймут, что такое «пайплайны». Опять же, для чего проходит Слёрм — люди прокачаются, люди поймут, что такое «кубер», где он нужен, а где он не нужен. Я просто не знаю, что такое DevOps-инженер. То, что вчера я рассказывал на Слёрме DevOps. Всё прочее — это чистый хайп. Для меня он не существует. Года через два просто будет админ со знанием Kubernetes.

Об образовании

Какой в ближайшие годы ты видишь дефицит, на какие IT-профессии?

Программистов точно будет не хватать. Дефицит будет на программистов любых уровней. А они сейчас всем понадобятся. ВУЗы выпускают очень мало людей. Как в начале 90-х понадобились админы.

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

Я нахожусь в Калининграде. В этом плане мне чуть легче. У меня где-то процентов шестьдесят ребят оттуда. Я понял, что БФУ имени Канта отлично готовит. Они могут прийти немножко сырыми, как программисты. И они с очень хорошим уровнем — насчёт аналитических знаний, аналитического и логического мышления. Просто проверено для меня временем. Но через определённое время, давая им серьёзные таски, давая им серьёзные нагрузки, они вырастают. Мы нанимаем человека и смотрим, как он будет работать. А по факту я не сторонник тестовых заданий. А за первую неделю, за первый месяц мы видим, чего он стоит. На тестовом задании, на интервью человек мог заволноваться. А есть у него высшее образование или нет у него высшего образования — это абсолютно некритично.

Post scriptum

Телефонист, колесник, вычислитель, водонос, человек-будильник — мы уже с трудом можем понять, в чём заключались эти профессии, только догадываться по названию. Интересный получился разговор. Верстальщик, программист начального уровня, корректор, статистик, бухгалтер, бильд-редактор. И в скором времени вслед за ними в очереди на исчезновение встанут десятки других. Все ли смогут не потеряться при таком стремительном темпе развития технологий и найти своё место? И появятся сотни новых, о некоторых мы ещё даже не подозреваем. Sooner or later time will tell».© «Time will tell.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»