Comments 50
Вдогонку другая картинка на ту же тему с https://roadmap.sh/:
DevOps — это набор методических рекомендаций, согласно которым все производственные процессы в компании строятся по таким же принципам, как при работе с кодом. То есть, всё, что только можно, версионируется, автоматизируется, тестируется, и обкладывается сбором статистики. От топологий железа до заключения договоров и техподдержки.
DevOps предполагает сборку единого, управляемого алгоритмически, конвейера доставки конечного продукта. (См. также «жизненный цикл».)
Если у вас есть выделенный человек на «DevOps задачи», значит, вы неправильно понимаете суть данного методического подхода, либо пытаетесь внедрить его в узкой нише, не затронув остальную часть процессов. Но так оно, как правило, не работает.
Также, конкретный инженер не обязан знать всё, что перечисляется на таких вот бессмысленных слайдах. Он может (и должен) заниматься своим делом, но при этом относиться к своей работе как к части конвейера доставки, но иметь представление о, и быть готовым отвечать за его корректное взаимодействие с остальными частями.
Спасибо, что выслушали. Искренне ваш, DevOps-евангелист.
Бизнесу так удобнее нанимать специалистов с определенными знаниями, и никакие (по моему конечно же скромному мнению) бессмысленные эвфемизмы типа SRE это все не вытеснили.
Если прямо сейчас на одном из израильских сайтов по поиску работы вбить словосочетание DevOps Engineer то выйдет порядка 50 упоминаний.
Если же вбить DevOps Evangelist то увы 0
(А «евангелист», между тем, не профессия, и даже не роль, а что-то типа играющего тренера. Тот, кто понимает, как менять процессы.)
Еще ни разу бизнес не требовал от меня того, чего мне не хотелось бы делать, и что противоречило бы моим навыкам и умениям.
Если мне накинут задачу, например настраивать принтеры или тянуть патчкорды то бизнес слишком дорого заплатит за это, т.к. это будет стоить мое рабочее время согласно моей зарплате.
Если же, например, с другой стороны бизнес захочет чтобы я начал фиксить им их приложения, то опять же им это будет стоить слишком дорого так как я на проект не заходил как девелопер, их код не изучал и возможно вообще не практиковал программирование на их стеке несколько лет.
Чего мне стоит бояться? Того что вдруг на следующей неделе мне надо будет сконцентрироваться на CI/CD?
Или послезавтра посмотреть проблемы в AWS?
Где в приведенных выше рисунках, несмотря на то что к ним можно конечно же придраться, области требующие четкого разделения специалистов на какие-то сабкатегории?
Желательно с примерами: вот тут человек отвечает чисто за логи, вот этот за CI, а вот за кубернетис итд итп
Даже если такое разделение и бывает (например в рамках девопс-отделов), то скорее всего каждый из них в итоге заработает при прочих равных меньше чем универсальный солдат могущий быстро найти проблему или банально договориться с тем же девелопером посидеть подебажить вместе.
Резюмируя. Спасибо за заботу лично обо мне, но меня все устраивает.
В тех же случаях когда задача выглядит неадекватной, то в дело вступает мой менеджер умеющий указать заказчику на то что использовать лично меня на ней неэффективно.
А вот разработчиков, которых заставляют изучать какой-нибудь терраформ, или админов, которым приходится писать инсталляторы — объясняя, что «у нас же DevOps», — намного больше. И мало кому это нравится, жалобы на такие «странные» требования я слышу постоянно.
Но девопс не означает, что стоит требовать от людей заниматься категорически не своим делом. Девопс означает, что operations-инженер должен быть включён в единый процесс, в котором есть место и для админа, и для разработчика, и главное, налажена связь между всеми участниками через общий трекер и, возможно, даже общий репозиторий.
Вы, я так понимаю, специалист именно по operations, и ваш основной фокус — процессы. А я, например, техлид, и мой основной фокус — проектирование, прототипирование, и ревью.
Что это за организация где полезного и недешового программиста заставляют заниматься относительно простыми вещами (терраформ абсолютно не требует гигантского опыта и довольно прост во вхождении)? Почему тратится время этого специалиста на такие задачи?
Я допускаю тот случай когда руководство подходит к программисту Пете и говорит «ты у нас теперь девопс, будешь меньше уделять времени коду и больше опс части».
Но тогда существуют вполне резонные способы решения «проблемы»:
— Петя может не согласиться и сказать что не в его интересах этим заниматься, и вместо Пети нанимается Вася или нанимается аутсорсер Коля
— Петя попал в мелкий стартап где еще не наняли админа а облачную инфру надо «вчера», при этом удивительно но он единственный человек с опытом в облачной инфре — решается прокликиванием в консоли, с захватом экрана и сохранением видео. Дальше Петя возвращается к своим программописательским делам
Пример с «админа заставляют писать некие инсталляторы» я правильно понял что речь идет о скриптах? Не о части бизнес-кода аппликаций разрабатываемых компанией?
Что это за организация где полезного и недешового программиста заставляют заниматься относительно простыми вещами (терраформ абсолютно не требует гигантского опыта и довольно прост во вхождении)?
Это интересный ход мысли. Хотелось бы услышать Ваши соображения — за счет чего программист "недешевый", в чем, в каких технологиях заключена "сложность"?
Мы же не говорим о случаях когда фирма вдруг внезапно решила одного из своих джунов озадачить IAC?
Если все же речь идет об условных мидл-сеньор девелоперах, то обычно их нанимают заниматься разработкой того самого программного продукта. Если отвлекать человека от этой безусловно важной задачи, то…
похоже у нас в компании переизбыток программистов, люди сидят на скамейке и мучаются чем бы себя занять?
Да, в такой ситуации напрячь кого-либо из программеров задачами выходящими за рамки его опыта и компетенций (то бишь IAC) выглядит как некое соломоново решение, потому что альтернатива это уволить этого бедного разработчика. Опять же я редко встречал такие ситуации, чаще всего для программиста находятся другие задачи по рефакторингу, разгребанию техдолга, допиливанию nice to have фич итд.
Несомненно ситуацию когда опытному разработчику дают не его стек исключить полностью нельзя, уверен такие случаи бывают. Но с другой стороны если бизнес готов платить за эти усилия, а человек сам не против этим позаниматься, то почему нет?
«Сложность» в данном конкретном случае мы рассматриваем Terraform как яркий пример хорошо задокументированного, популярного в своей нише, стабильного инструментария реализации IAC.
Это безусловно не требует таких мозговых усилий как имплементация бизнес логики, хотя конечно же особо хитрые кейсы с tf depends имеют место быть, но чаще всего новичок сделает простые модули без всяких зависимостей, и это БУДЕТ РАБОТАТЬ.
Очень частая ситуация в небольших компаниях (вернее в компаниях с небольшим штатом ИТ, компания сама может быть достаточно крупной), что отдельного человека на инфраструктуру разработки и тестирования вообще нет. Команда (нередко из одного человека) эксплуатации занимается продакшен средой и прочим ИТ и телеком обеспечением основного бизнеса, а на нужды разработки и тестирования максимум виртуалочки будут давать по запросу. Или полноценный сервер, может даже несколько и "делайте, что хотите, хоть облако разворачивайте, только нас не дергайте кроме как ОС переустановить когда сломаете". И в разряд nice-to-have попадают такие фичи, как автоматизация процессов разработки, развёртывания, настройки инфраструктуры разработки и тестирования.
Мы же не говорим о случаях когда фирма вдруг внезапно решила одного из своих джунов озадачить IAC?
В чем конкретно заключается ценность работы "мидл" или "сеньор", какой именно навык делает нецелесообразным загружать его "не требующим таких мозговых усилий" терраформом и другим девопс?
Я понимаю, что у всех по разному все, собственно, и хотелось бы услышать больше конкретики. Исходя из моей практики ситуация как раз обратная — я бы без больших сомнений загружал разработчиков терраформом и прочим "девопс", но порог вхождения в него весьма высок, люди просто не справятся, за ограниченное время. Технически, пожалуй, это сложнее, чем писать бизнес-логику по отбработанной схеме.
Собственно, я считаю именно поэтому "девопс" и нужен, как отдельная специализация в IT.
с опытом скорее дефицит, на проектах у них хватает задач и без погружения в чудесные практики devops.
И если их будут насильно заставлять этим заниматься супротив воли (например накинув в довесок поддержку инфры), то они скорее всего просто махнут лапкой.
Ситуации когда разработчики становятся девопс-инженерами тоже встречаются часто, но сугубо как говорил монтер Мечников — «при полном непротивлении сторон».
И если их будут насильно заставлять этим заниматься супротив воли
Этот аргумент мне понятен
Некоторые погружаются в практики автоматизации процессов, настолько глубоко, что могут даже зарплату свою повысить, переименовав резюме программиста в девопса, исключительно с одной мотивацией "задолбался разбираться что кто опять накосячил при деплое и справлять, а больше автоматизировать некому". И тут, главное, не накидывать больше, чем взято добровольно, правда не уверен, что "добро" тут подходящее слово. Например, не вменять в обязанности поддержку сделанных им пайплайнов.
Прокликиванием в консоли чего и записи видео для кого?
Для чего нужна видеозапись? В качестве инструкции. Для повторяемости, если времени разбираться с терраформом нет, а завтра нужно будет это же сделать другому человеку
По опыту это плохо работает по разным причинам, например:
- вот прямо точно то же самое редко нужно делать, а без знаний, понимания, интуиции, полученной с опытом не всегда получится адекватно адаптировать инструкцию к текущей задаче, особенно ничего не сломав
- эти инструкции устаревают как по внешним причинам (тот же амазон что-то изменил), так и по внутренним (инфраструктура изменилась)
Но если идет трейдофф между срочностью (а он судя по всему идет, раз накликивать IAC через терраформ озадачили аж разраба) и удобством то жизнь внесет свои коррективы.
В любом случае ситуация когда IAC делает разработчик выглядит странной, и именно для этого существуют в том числе outsource devops компании имеющие людей с определенным набором скиллов (тех что на картинках выше)
Странной она выглядит для тех, кто привык к чёткому разделению труда, а не к "тыжпрограммист" :(.
А экономически вполне может быть выгодно использовать, например, 25% времени своего разработчика вместо, например, 10% времени сотрудника аутсорс девопс компании из-за ценообразования этой компании и бюрократии.
Из личной практики: относительно недавно на одном из прошлых проектов такая компания выставляла счета из расчёта больше сотни евро за час работы по чётко описанным тикетам при зарплатах своих разработчиков не больше 20. Я сам предложил заняться этими задачами лично, хотя бы для увеличения премиального фонда. :)
Поэтому я не совсем понимаю нашего дорогого «Devops евангелиста» в том как он поможет бедным разрабам не делать то что они не хотят, просто сказав что «devops инженера» не бывает.
Ну не бывает ок. Кто то за него работу сделает и зарплату получит?
Я же смотрю на процессы несколько шире. Продукт — это далеко не только код и инфра. Это документация, техподдержка, локализация, бухгалтерия, и ещё куча всякого сопутствующего, включая рекламу в профильных изданиях. Бизнес работает вокруг продукта, а не сугубо технических вещей.
И DevOps — это как раз про автоматизацию бизнеса в целом. Когда все процессы ведутся так, как будто бы это работа с кодом.
Вот скажите, вы точно уверены, что в ваши обязанности входит автоматизация customer relations и автоматизация перевода продукта на 15 языков?
Почему тогда вы называете себя DevOps-инженер?
Как мне себя еще называть? SRE? Потому что так Гугл хочет?
Я хотел бы в свою очередь понять как называется ваша лично должность, раз уж мы выяснили что devops evangelist это не профессия
Отвечу вашей же цитатой:
«а не пытаться нанимать людей с неопределённо широким кругом умений, и вешать на них неопределённо широкий круг задач… Как я уже сказал, эт ни фига не работает.»
Не знаю и не имею скиллов по автоматизации бухгалтерии, рассылки рекламы, раздачи пиццы на тимбилдингах и прочих таких вещах.
Можете оставить эти спецификации себе а нам несуществующим «девопс-инженерам» оставьте работу с «сугубо техническими вещами»
Девопс означает, что operations-инженер должен быть включён в единый процесс, в котором есть место и для админа, и для разработчика, и главное, налажена связь между всеми участниками через общий трекер и, возможно, даже общий репозиторий.
Вот этот "единый процесс" — он же должен кем-то разрабатываться и поддерживаться, нет? Вот тут и нужен "DevOps-инженер"...
Как быть с тем, что технологии автоматизации рабочих процессов начиная от сбора требований и заканчивания сбором метрик с работающей системы весьма и весьма непросты?
Каим образом команде поможет методист, который в этом не разбирается? На выбор нужного стека и овладевание им уйдет куча времени. Да и кто это будет делать? Админ? Нет. Разработчик? Тоже нет. Методист? Но он не владеет технологиями.
Но я, например, имею 15-летний опыт сеньорства в командах размером от 2 до 50 человек, и занимался всем на свете (от скриптования на PHP до оракловых БД, от энтерпрайзщины на EE до автотестов, от техписательства до проектирования UX), включая преподавание. Был техлидом и «архитектором» (не люблю, когда system designer так переводят). Эт помимо редхатовской сертификации по Enterprise Linux и кучи времени, потраченных на geospatial проекты. Поэтому я могу выступать в роли такого методиста, чем и занимаюсь уже который год.
И нас таких немало.
А как различить админа, который что-то там в lamp'е ковырял, от спеца с навыками программирования и инфраструктурного тестирования?
С целью отсеивания ещё до собеседования. Что в заголовке вакансии писать?
Не-а. Нам был нужен devops, который может не только развернуть тестовую среду, но и написать регрессионный тест. А при случае — и модуль к ансиблу. Или тераформу. Ну или, там, патчик для софта наваять (C/Java/Python/Go/Ruby). Вполне себе специализация.
Сейчас вы мне ещё раз расскажете, что евангелисты девопса "компьютерами не занимаются, их задача — евангелизировать CI/CD-пайплайны", но у нас полный отдел людей, которые в один день делают 2to3 миграцию на питоне, в другой день колдуют над правильными значениями MED при HA-кластере на BGP, потом могут пойти и закопаться в провайдер тераформа, который что-то не так делает, а потом, на сдачу, прикрутить code coverage для проекта на трёх языках.
Вы, конечно, уверены, что таких людей не бывает и мы слишком много хотим в своих вакансиях, но мы все вакансии закрыли, и у нас получилась отличная команда хороших девопсов. Правда, ни одного евангелиста среди них нет, потому что люди-то требовались "со знанием компьютеров".
Что, совсем не работает то же построение CI/CD пайплайнов для разрабатываемого софта?
Работает, но когда используется только для кода (без расширения на полный ЖЦ), не настолько эффективно, насколько может.
Что я имею в виду под «полной» поддержкой ЖЦ:
- интеграцию кейсов техподдержки (когда выкат новой фичи автоматически добавляет новые пользовательские сценарии);
- автоматизированный сбор телеметрии и пользовательских отзывов (с верхнеуровневой аналитикой, которая собирает метрики каждого релиза в трекер);
- автоматическое формирование комплекта изменений к TOS, договорам, и другим юридически значимым документам, если это подразумевается;
- любые другие вещи, которые непосредственно к коду не относятся, но являются частью продукта или сервиса.
Всё это начинается с CD и строится вокруг него, но наличие CD — эт только начало пути.
И обычно там же и конец, что довольно прискорбно.
Если вы евангелист, то у вас какое-то очень специальное представление о том, что такое код.
Вот, представьте себе, что у вас приложение, которое делает stateful firewall с помощью xdp/bnf. В каком месте там надо встраивать автоматический сбор телеметрии, и как именно пользовательские отзывы должны собираться?
Вот вы написали, а я так и у видел, что в вашем представлении приложение — это очередной веб-интерфейсик, типа гитлабика. А бывают приложения чуть-чуть более сложные. Например, как ваша методология со интеграцией кейсов техподдержки позволит улушить качество кода для шагового двигателя (условного) марсохода?
Но, npm make black hole и всё такое, да.
Если у вас есть хотя бы три проекта, в каждом из которых вам нужно какой-то ДевОпс, то имеет смысл вынести из каждого проекта девопсов в отдельную команду, чтобы они занимались только этим и делились опытом и экспертизой между собой.
Потому что размазывание девопс задач по опсам, админам и прочим программистам приводит во-первых, к открытию америк в каждом отдельном проекте в своём темпе, а во-вторых, к зоопарку несовместимых между собой наборам практик.
Так вроде бы суть девопса в тесном взаимодействии. Мой опыт показывает, что выделение специалистов одного профиля в отдельную команду резко ухудшает взаимодействие этой команды с остальными. В частности у этих команд явно или неявно появляются свои цели, более приоритетные для них чем цели проектов. Да вот даже цель унифицировать практики и технологии на проектах скорее всего негативно повлияет минимум на один проект, особенно если проекты сильно различаются по масштабам.
Относительно вреда отдельных команд мало кто понимает, к сожалению. Почему-то управленцы стремятся как раз всех поделить, и приходится тратить кучу сил, чтобы убедить их перестать это делать.
Оракл просто вообще не в тему. Либо контора вокруг него построена, либо это шлак и выкинуть.
DevOps в команде с разработчиками и тестерами помогают выкатывать релизы.
Infra team — заботятся об инфраструктурах компании (dev, uat, prod, dr, etc.) и включают мониторинги, метрики, балансировки нагрузки и т.п.
В диаграмме объединены 2 команды. В более крупных компаниях встречаются и разделения.
Мне импонирует full-stack DevOps :), но все равно стоит отметить.
DevOps Roadmap или пора бы автоматизироваться?