company_banner

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

    Вы применяете 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».©

    Southbridge
    483,98
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

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

      +6

      Class CTO {
      work()=>null
      }

        +3
        DevOps появились потому что Админы в классическом понимании — это эксплуатационники, которым меньше изменений — хорошо. Потому классический админ, это человек который умеет талантливо посылать и тормозит развитие проекта. DevOps же должны двигать продукт и развивать инфраструктуру.
        Сейчас та же ситуация с безопасниками — от них больше вреда чем пользы: им всегда проще всё запретить, чем управлять сложными политиками безопасности. А разрабам проще хакнуть систему, чем ходить на поклон к безопасникам. Так что вот-вот должны появиться DevSec'и, которые будут именно разрабатывать и развивать системы безопасности, а не только всё затягивать по-максимуму.
          0
          … Админы… которым меньше изменений — хорошо

          ну нет же, которым меньше работы и больше автоматизации — это хорошо.
          Если админа постоянно дергают «создай нам тестовую среду и накати туда код и базу», то хороший админ по максимум это автоматизирует. т.е. тот же DevOps, нет?
            0
            Вопрос про функцию полезности. Админ заинтересован в том, чтобы к нему реже обращались с изменениями, ведь Админу главное чтобы не прилетело за то, что инфраструктура легла. У него свой менегер и свой департамент. Разработчики для него люди, которые постоянно что-то ломают.
            Фишечка DevOps'ов, что они в одной команде с разработчиками. Разработчики пилят приложение, а DevOps скипты к terraform. Они на одном скрам-митинге друг перед другом стоят. И релиз у них общий. И цель выкатить релиз, а чтобы выкатить релиз надо инфраструктуру менять/развивать.
              0
              DevOps это практика. В Каждом проекте она разная. Есть кучи проектов где нет ни терраформа ни ансибла, но есть другие вещи за которыми нужны постоянные оптимизации и поддержка.
            0
            Как классический админ может что-то посылать и тормозить?

            Есть админ, который управляет инфраструктурой компании — рабочие станции, AD/ldap, корпоративная почта, корпоративная сеть, безопасность эти все впн-ы, чтобы работать из дому. Он вообще может не знать что в проекте происходит, не иметь доступ к вашему коду и даже NDA не подписывать

            Есть админ, который управляет инфраструктурой провайдера — магистрали, циски, маршрутизация, безопасность, биллинг. Он вообще не знает что у вас случается.

            Есть админ, который работает внутри проекта — поднимает, настраивает, обслуживает все эти дженкинсы, тимсити, локальные фтп/артифактори, сервера где крутится дев/тест/прод, биллинг aws, кластера кубернетеса. Без него у вас будут нормально работать только одностраничники или команды максимум из 5-10 человек.

            Та что же это за «классический админ», который всех тормозит? Вы с эникейщиком не путаете?

            P.S. Тоже не люблю devops инжинер. Лучше software engineer, или configuration/release engineer
              +2
              DevOps Engineer — устоявшаяся позиция зарубежом. По факту — член команды разработки, поэтому знает всю нутрянку и как оно работает и может расписать инфраструктуру на соответствующей технологии — Puppet, Terraform etc. Как отдельная позиция, нужен только когда много работы и команда уже немаленькая — десятки разработчиков. Впрочем, ничто не мешает взять админа и обучить его тому же самому )).
                0

                Так всё-таки кто это? Build (release) engineer, инженер по мониторингу, cloud engineer, dba или что-то из ещё длинного списка "специализаций"? Или многорукий (и, видимо, многозадый — чтобы сидеть на нескольких стульях) Шива?
                Соглашусь с тем, что с подачи работодателей и HR как позиция devops engineer плотно вошла в нашу жизнь. И это отрицать уже нельзя
                Относиться можно по-разному, но это уже ни на что не влияет.

                  +1
                  Те позиции, которые Вы назвали — узкоспециализированные, они нередко встречаются в крупных компаниях, особенно, которые давно на рынке. Сейчас компании берут просто DevOps, который и релиз может подготовить для разных ОС/девайсов/требований, мониторинг настроить и с Cloud Environments на ты. Эпоха dba уходит в прошлое по-тихоньку, так как монструозные базы оракла все менее популярны и хранение кода в процедурах DB считается неудобным подходом, а с остальным и DevOps справится.

                  DevOps — некоторая разновидность Шивы, соглашусь, но человек весьма уважаемый в коллективе, так как Cloud Environments становятся все сложнее и мощнее с каждым годом.
                    0

                    Тут палка о двух концах. С одной стороны, действительно круто, когда специалисты — то, что называется T-shaped и имеют и специализацию, и широкий кругозор. Но проблема в том, что невозможно быть специалистом во всех областях. И типичная agile-команда может столкнуться с тем, что у них не хватает компетенций, например, для оптимизации БД. И что делать?
                    В классическом подходе, когда есть, например, выделенный DBA такая проблема не возникнет, но он сам и его время может стать ограниченным ресурсом (вспоминаем истории, когда тикеты во внутренних учетных системах на какие-то изменения могут висеть месяцами, а ускоряются они попросту за счет личных отношений руководителей).


                    Я прошу не понять меня неправильно — я очень разделяю идеи agile/devops/lean-подходов. Они действительно при правильном применении дают возможность получить стабильную частоту и качество поставок (про наполнение — отдельный вопрос). Но при этом парадокс — с одной стороны, это требует очень высококвалифицированных и высокомотивированных (оба компоненты важны) сотрудников, иначе это попросту не будет работать, а средний уровень разработчика все так же падает куда-то в бездну.

                      0
                      Agile не имеет никакого отношения позицииям DevOps или DBA, это просто разные сущности.

                      С тех пор, как популярность монструозных DB типа Oracle сходит на нет, разработчики используют DB просто, чтобы хранить там данные, а для этого выделенный DBA не нужен. Обычно, один из backend-разработчиков или DevOps занимается проблемами базы. Например, когда стало не хватать производительности, это решается не очень сложно в mysql/postgres/mongodb — смотрим медленные запросы, добавляем ключи или меняем стуктуру хранения или берем более мощное железо. Проблему пофиксили — DB дальше живет сама по себе до следующих проблем. Если в команде квалификации не хватило — всегда можно привлечь сторонних консультантов, которые решат проблему. Это выгодней, чем иметь выделенного DBA.

                      Современный подход по хранению данных без схем(mongodb, json в mysql и postgres) позволяет избежать многих проблем при добавлении сотен новых полей что еще дальше откладывает потребность в DBA для проекта.
                0
                Есть админ, который управляет инфраструктурой компании — рабочие станции, AD/ldap, корпоративная почта, корпоративная сеть, безопасность эти все впн-ы, чтобы работать из дому. Он вообще может не знать что в проекте происходит, не иметь доступ к вашему коду и даже NDA не подписывать

                Простой пример. Ваш админ — он создает учетки по заявкам в АД? Или этим техпод занимается, а админ только за сам сервис отвечает? Если все-таки сам создает, то он запросто может стать узким местом, т.к. вал заявок может быть неравномерный, в них может быть 100500 согласований и простая операция "создать учетную запись для нового пользователя" растягивается на неделю. Но здесь обычно не вина конкретного исполнителя (там делов на 5 минут создать учетку, тем более, если это уже автоматизировано), а скорее процессная — согласования, перепихивание между отделами и пр., чем славятся большие компании.

                  0
                  Вы опять путаете мелкую рутину и технические системного администратора.

                  Как вы думаете, создать учетку для нового сотрудника и создать групповую политику для разных отделов компании с разным доступом — нужна одинаковая квалификация?

                  Системный администратор — планирует архитектуру, решает сколько нужно DC и где их разместить, согласовывет и планирует периметры безопасности с безопасниками.

                  Если компания большая, а в ней всего один админ, который не справляется с валом заявок — то это не проблема специальности «системный администратор». Это проблема конкретно этой компании.
                    0

                    Я не "опять" путаю, а конкретно спросил — у вас этим техпод занимается или нет? /Если есть автоматизация — опять же требования к сотрудникам, выполняющим типовые задачи могут снизиться /


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


                    Системный администратор — планирует архитектуру, решает сколько нужно DC и где их разместить, согласовывет и планирует периметры безопасности с безопасниками.

                    Ой, как это все по-разному у всех.
                    Я уж не говорю о том, что есть терминологическая путаница. Системный администратор — это и от мышку подоткнуть в системник, и до крупнейших веб-проектов. Что объединяет этих людей — они должны поддерживать порядок на вверенном им участке (техники, работ и пр.).

                      0
                      «Нашего» админа я никогда не видел, потому что контора — десятки тысяч человек. При трудоустройстве общался с HR, заявки на рабочее место в веб-системе.
                      Мог физически видеть местного эникейщика, который подключал десктоп.

                      Но вернемся к началу треда — я не очень понимаю, почему «среднестатистический сисадмин» тормозит процесс разработки, если он наоборот — поддерживает порядок, автоматизирует рутину.
                –2
                Да уж, мне как 1С-ку занятому над внедрением ERP и поддерживающий ещё некоторое кол-во баз постоянно приходится тормошить админов, не напинаешь не почешутся.
                  +1
                  dev и sec обязаны быть разными людьми, т.к. у них противоположные цели: девам всё разрешить, сек всё запретить. На противоборстве этих сил и получается минимально необходимые разрешения безопасности.

                  Если это будет делать один человек (без шизофрении), то очевиден перекос в одну из сторон
                    +1
                    Спорный вопрос.
                    Но пока всё выглядит так, что с безопасностью швах: Sec'и запрещают, dev'ы хакают, чтобы легче и проще работать, а не бороться с sec'ами. В итоге получаем 100500 отчётов об утечках баз без поролей через левые порты. По моему опыту sec'и последнее, что хотят делать, это заботиться о продукте и прогрессе. В этом они ещё хуже классических админов.
                    Но то, что делают sec'и сейчас идёт в разрез не только удобству разрабов, но и интересам бизнеса. Интеграция Sec'ов в команду разрабов, чтобы они развивали систему безопасности, мне кажется единственным выходом из ситуации.
                    Посмотрим, как рыночек порешает.
                  0
                  Куда это, интересно, пропадут статистики? только статистик может оценить на глаз репрезентативность выборки и значение диких выбросов. А то один тут фанат R мне впаривал, что он плотность распределения и по двум отсчетам может построить. Строить-то AI будет, только это ничего не будет значить.
                    0

                    Увидел такое мнение в одном из чатиков:


                    DevOps'ов нет и они не нужны.
                    а
                    Я СТО 10 конференции из 10 из Калининграда
                    а
                    Мы набираем челиков в Калининграде, потому что в Москве слишком дорого и поэтому мы эксплуатируем дешевую рабочую силу там
                    а
                    Не вижу разницы между админом и DevOps'ом, а потому называю их "Админ со знанием Kubernetes"

                    https://t.me/devops_ru/612032


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

                      0
                      Создают рабочие места для айтишников вне столиц — уже молодцы.
                        0

                        Понимаете, в чем дело… Создание рабочих мест вне столицы — само по себе нейтральный факт. Он не несет ни позитивной окраски, ни негативной. Вопрос отношения к факту. Вот, например, давайте возьмем недавний пример с Амазоном — вроде как Безос открывает новый РЦ или что у них там и устраивает как будто обратный аукцион — какой регион даст ему максимальные преференции, чтобы именно в нем открыть новый объект. С одной стороны — да, здорово, создает рабочие места, позволяет людям хоть как-то заработать на жизнь. С другой стороны — что толку, если он эксплуатирует этих людей, выжимая последние соки (здесь можно поспорить, но провокационные материалы вида "сотрудникам амазона нельзя даже в туалет сходить" тут проскакивали), а еще и от властей штатов налоговые льготы и пр. получает — лучше бы он эти деньги вернул в казну США назад. А там глядишь и социалку можно было сделать какую-никакую.


                        Короче. Если упростить. Создал рабочие места — ок, молодец. Создал рабочие места и дал зарплаты на уровне московских или европейских (айтишники могут конкурировать на глобальном рынке, а не только локальном) — молодец вдвойне.

                          0
                          Для кого нейтральный факт? Для айтишников, которые не хотят переезжать в столицы, точно положительный. При чем тут пример с Амазоном — не сильно понятно. Есть информация, что в конторе собеседника негуманные условия труда?
                          Про глобальный рынок в айти все красиво на словах, на практике же несколько иначе. И поэтому локальные рабочие места — хорошо. И поэтому же капиталист не будет в Москве и условном Калининграде платить одинаковую зарплату.
                            +1

                            В регионах можно платить условные 30, а в Москве от 200. Проблем с вакансиями в ИТ в регионах нет, проблемы как раз в ЗП.

                              +1
                              30 в регионах безусловно есть, но это далеко не медиана, как и от 200 в Москве.
                              Откроем все тот же Калининград и наберем, к примеру, PHP. 15 вакансий с указанной зарплатой в диапазоне от 60 до 120 т.р., что есть от полутора до трех средних калининградских зарплат, если верить официальной статистике.
                                +1
                                Это естественно. Я просто привел в пример нейтральность факта создания рабочих мест в отличном от СПб и Мск месте, так как у нас нет выборки по ЗП для позиций в этой компании. Если ЗП является достаточно конкурентноспособной для региона — круто, если ЗП на уровне региона — ОК, еще одна компания.
                                PS Открыл hh devops по Калининграду. Три вакансии, из них одна с ЗП в 30к. (:
                                  +1
                                  Если уж добивать тему БюроБюро, то у них в архиве вакансия ПХПшника до 120 тыс. на руки. Видимо, те самые 2-3 местных зарплаты они предлагают.
                                    +1
                                    Да я же не против ведь, только «за» =) Я приводил доводы в поддержку позиции нейтральности факта создания рабочих мест в регионах безотносительно денежных вознаграждений. Также меня всегда смущал факт того, что ИТ в регионах развивается, в большинстве случаев, только с целью сэкономить на труде. Я понимаю, что и другие факторы являются весомыми вроде аренды и прочего, но не могу понять другого. Почему работник с одинаковым набором компетенций и опыта получает разные цифры в столицах и в регионах. Я не хочу вдаваться в полемику относительно удаленки и запросов, просто в большей части бизнеса разность по финансам обусловлена производственной необходимостью ( стоимость производства, логистики, рекламы и прочего ), а относительно создания цифровых продуктов мы имеем одинаковые условия и трудозатраты хоть для Москвы, хоть для любого отдаленного региона России.
                                      +1
                                      Потому что капиталист будет платить меньше, если у него будет такая возможность, сэ-ля-ви. Будто бы это только в России так )
                                        0
                                        К сожалению, подобной выборки по другим странам у меня нет =)
                      +1
                      > Я против такого понятия, как DevOps-инженер
                      > какие требования он видит для должности DevOps-инженера
                      thinking_emoji.gif
                        +1
                        Жду статью с заголовком:
                        DevOps-инженер: «Я против такого понятия, как СТО БюроБюро»
                          +1

                          Вот, интересно получается, Бэкэндщик у Артёма есть, а Девопса — нет.
                          ???

                            +2

                            Коротко о статье, "много букв не очем"...

                              +1
                              Появилась определенная спецификация которую называть «админ со знанием kubernetes» это заведомое упрощение.

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

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