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

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

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

О карьере

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

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

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

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

Почему?

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

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

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

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

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

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

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

А в Москве?

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

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

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

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

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

О развитии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О проектах

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

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

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

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

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

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

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

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

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

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

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

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

Как любая хайповая тема, она и модна, и необходима. У нас очень большое количество заказов сделать загрузку «эксельки». Невероятное количество компаний ведут работы в Excel. И им надо сделать так, чтобы эта «экселька» загружалась, парсилась, превращалась в базу данных и дальше можно было работать с ней, а потом выгрузить. Цифровая трансформация должна привести к переходу на нормальные системы работы — CRM, системы контента, СМS. И отказаться от эксельки и жить в нормальном web-мире. Есть такой хороший пример. В предыдущей компании, где я работал до Бюро-Бюро, у нас были две компании-клиента. А мы смогли детально отследить, как всё происходит. В одной компании работа с клиентами шла через 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. Но Kubernetes — это не DevOps. Единственное, что я приемлю для себя, это DevOps-евангелист. Который может прийти в компании и сказать: «Ребята, нам надо двигаться в этом направлении. Научиться общаться и взаимодействовать». Потому что DevOps- это не про технологии. Вообще, вся философия DevOps — это про взаимодействие. Чтобы научились общаться разработка и QA, и в дальнейшем поддержка. И все эти DevOps-инженеры мне напоминают хайп по scrum-мастерам года три назад. Всем нужны были scrum-мастера, никто не мог без них работать. Или лет пять назад всем остро был нужен менеджер по настройке Jira. И если нет человека, который нам настроит «джиру», то работа не будет двигаться. И всё, что с приставкой DevOps — это просто для увеличения своей стоимости на рынке труда.

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

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

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

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

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

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

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

Post scriptum

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