company_banner

Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании



    Что нужно для успеха IT-компании в 2019 году? Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё. Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды.

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

    Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.

    Прежде чем говорить о современных проблемах обеспечения инфраструктуры, давайте определимся, что мы под этим термином подразумеваем. К текущему моменту ситуация сложилась таким образом, что мы вышли на двойственность этого понятия: инфраструктура может быть условно внешней и условно внутренней.

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

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

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

    А кто такие DevOps? Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой. Точнее, современные девопсы вовлечены в процессы разработки и деплоя намного глубже, нежели были когда-либо вовлечены админы, просто заливавшие апдейты на ftp. Одна из ключевых задач DevOps-инженера сейчас — это обеспечение комфортного и эффективно выстроенного процесса взаимодействия команд разработки и инфраструктуры продукта. Именно эти люди ответственны за развёртывание систем откатов и деплоя, именно эти люди снимают часть нагрузки с девелоперов и максимально концентрируются на своей крайне важной задаче. При этом девопс никогда не будет протягивать новый кабель или выдавать новый ноутбук из подсобки (с) КО

    В чём подвох?


    На вопрос «А кто такой DevOps?» половина работников сферы начинает отвечать что-то вроде «Ну, это, короче, такой админ, который…» и далее по тексту. Да, когда-то давно, когда профессия DevOps-инженера только-только выпочковывалась из самых талантливых в плане обслуживания сервисов админов, различия между ними были не всем очевидны. Но сейчас, когда функции девопса и админа в команде стали радикально различаться, путать их между собой, а то и вовсе ставить между ними знак равенства — недопустимо.

    Но во что это выливается для бизнеса?

    Найм, всё дело в нем.

    Вы открываете вакансию «Системный администратор», а там перечислены требования «взаимодействие с разработкой и заказчиками», «система доставки CI/CD», «обслуживание серверов и оборудования компании», «администрирование внутренних систем» и так далее; вы понимаете, что наниматель несет какую-то чушь. Подвох в том, что вместо «Системный администратор» в заголовке вакансии должно стоять «DevOps-инженер», и если этот заголовок поменять, то все становится на свои места.

    Однако какое впечатление создается при прочтении такой вакансии? Что компания ищет многостаночника, который и систему контроля версий и мониторинга развернет, и витуху обожмет зубами…

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

    Нет, нет и ещё раз нет. Инфраструктурные админы, которые будут рулить внутренними серверами компании, или занимать позиции L2/L3-саппорта и помогать другим сотрудникам, никуда не делись и деваться не собираются.

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

    Еще одна проблема DevOps


    На самом деле, только наймом и постоянной путаницей между админами и девопсами всё не ограничивается. В какой-то момент бизнес столкнулся с проблемой доставки обновлений и взаимодействия команды разработки с конечной инфраструктурой.

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

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

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

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

    Вывод простой: без нормального подхода к DevOps как таковому толку от него не очень много.
    Главное, что нужно помнить: DevOps-инженер — не волшебник, и без качественных коммуникаций и двустороннего взаимодействия с разработкой он не будет справляться со своими задачами. Девопсов нельзя оставить один на один с их «проблемами» или дать команду «не лезь к разрабам, их дело кодить», а потом надеяться, что в критический момент всё будет работать, как надо. Так это не работает.

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

    Ну и последнее: хватит обижать администраторов-инфраструктурщиков. У них свой, крайне важный фронт работ. Да, админ может стать DevOps-инженером, но это должно происходить по желанию самого человека, а не из-под палки. И нет ничего плохого в том, что системный администратор хочет остаться системным администратором — это его отдельная профессия и его право. Если же есть желание пройти профессиональную трансформацию, то надо ни в коем случае не забывать, что наращивать придется не только технологические навыки, но еще и управленческие. Всех этих людей сводить вместе и учить общаться на одном языке, скорее всего, придется именно вам как руководителю.
    ITSumma
    793,65
    Собираем безумных людей и вместе спасаем интернет
    Поделиться публикацией

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

      +2

      Это всё результат того, что на волне хайпа люди не разобравшись внедряют что-то своё, а потом называют это хайповым словом.


      Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой.

      Было бы неплохо, чтобы вы раскрыли более подробно, что имеется в виду, потому что как раз именно это все трактуют кто как хочет. Хотя вы в статье начали объяснять, но как-то очень абстрактно.

        +1
        Условно говоря, девопс вырос из попытки найти крайнего за эволюцию процесса разработки продукта. В его зоне ответственности понимание современных принципов сборки и резервирования приложений, выкатки новых версий, отката на старые.

        При этом, он ещё должен научить разработчиков определённым поведенческим паттернам. Т.к. с точки зрения отдельно взятого программиста, его работа по кодированию меняется не очень сильно, ему надо объяснить, о каких вещах в разработке стоит сильнее задумывать в контексте новой парадигмы, о чём стоит советоваться с коллегами-инфраструктурщиками, о каких подводных камнях заранее знать.

        Эту технологическую и социальную интеграцию и обеспечивает девопс.
          +2

          Получается что DevOps-инженер это фактически Системный архитектор и Team Lead/менеджер в одном лице?
          Мне понятно что такое DevOps, но я нигде не могу найти первоисточник или хотя бы внятное объяснение кто такой DevOps-инженер. Это либо каждый сотрудник отделов разработки, тестирования и эксплуатации (ведь они все так или иначе используют эти инструменты и практики), либо некий руководитель, который связывает все эти отделы воедино (но это же Архитектор или Директор по ИТ).
          Но все же что-то свое подразумевают: кто-то думает, что это автоматизатор, кто-то — что чувак, который шарит именно в Ansible/K8s/IasS, кто-то вообще думает что это админ, который должен программировать. В этой сфере какая-то анархия вообще.

            +6

            Всё ведь просто, DevOps-инженер — это тот, кто выстраивает пайплайны.

              0

              Загадка.
              Кейс: Иван Иванович посмотрел на проект и понял, что погоняв тесты, можно создать автоматически новый тег и начать сборку боевого пакета с отправкой его пользователям. Он заводит задачу на создание в gitlab ci новой job'ы, которая будет запускаться после успешных тестов и назначает на Семёна Семёновича. Тот успешно её делает и отправляет MR на своего Team Lead'а Сергея Сергеевича, который принимает этот MR в мастер-ветку.
              Вопрос: кто здесь DevOps-инженер?

                +2
                onegreyonewhite ну у вас тут набор — целая ДевОпс тим! Видимо большая компания :) Нет девопс не тимлид и не менеджер, это точно такой же тайтел, который имеет своих менеджеров, лидов, джунов и тд. При том никто не говорит что девопсы не пишут код, увы не все заканчивается на пейплайнах в «Пополурная CI». Дак кто же он такой?

                Человек который хорошо понимает процесс разработки, доставки и тестирование в компании (или DO lead/manager кто может быстро его понять).
                Человек которому интереснее делать хорошо команде, чем писать крутой HL сервис
                Человек которому интересно всего понемногу (full-stack разработчик) — которого демотивирует нудятина в бакенд отделе HL проекта или битва с очередным фреймворком в отделе фронтенда.
                Человек который любит автоматизировать, а не разрабатывать «умную корзину»
                Который иногда любит пошарить на сервере в конфигурационных файликах и почувствовать себя хакером из кино.
                  0

                  Т.е. получается все остальные не делают хорошо для команды? То что вы написали очень похоже на отдел по автоматизации.
                  Вообще у нас постоянная команда 4 человека +несколько удаленщиков для некоторых проектов.
                  Но у нас все DevOps (как я понимаю, всё как код включает и сотрудников). У нас все делают хорошо для команды, но по разному. Вот Рома, например, делает так чтобы фичи как можно быстрее попадали в GUI (https://habr.com/ru/post/456146/), а ещё один парень занимается тем, чтобы эти фичи могли быть как можно быстрее сделаны. Есть и тот, кто делает, чтобы мы могли управлять инфраструктурой этой через кнопку "Сделать хорошо" из Gitlab'а.
                  Каждый занимается и внедрением самих фич, но в рамках своей компетенции (front-, backend, сборка и установка). Мы придерживаемся Bus Factor, чтобы команда как можно дольше могла работать без одного из членов и быстро подхватить то, что было недоделано. Релиз-менеджер у нас тот, кто может апрувить мердж в мастер-ветку.
                  Мне сложно сказать кто у нас DevOps-инженер — наверное все.

                    0

                    В не больших командах оно так. А теперь представьте что таких команд 2-3 и у каждого есть желание имплементировать кнопку так как хочет он используя какой то набор инструментов предпочтительных ему. В итоге вы получаете зоопарк инструментов технологий и напряжёнка в команде, ведь Вася из отдела Х почемуто может имеет большую свободу чем Петя из отдела Y

                      0

                      А в маленьких командах, получается, Вася и Петя всегда равноправны по умолчанию?
                      Проблема, которую вы описали, не в размере. Проблема в том, что кто-то этим размером не умеет пользоваться: нет коммуникации и адекватного централизованного управления. Когда мы говорим о DevOps, то мы говорим о принципиальном подходе к разработке, тестированию и эксплуатации где "все как код" и "все как сервис". В старых подходах есть для каждого продукта своя команда и там каждый делает как удобно ему. В DevOps лучше всего когда есть "облако ресурсов" и оттуда берутся силы для проекта. Таким образом есть минимальная команда (они же "Совет", который решает как это всё должно реализовываться), а есть "подключаемые ресурсы" (это могут быть удаленщики или просто резервная группа для только для непосредственного решения четко описанных задач).
                      У нас была команда где каждый творил что хотел и как хотел — это был ужас. Но я очень много вдохновлялся командой Gitlab и в целом Open Source сообществом и это очень оживило процесс разработки.

                        0
                        В старых подходах есть для каждого продукта своя команда и там каждый делает как удобно ему.

                        Так в "новом" подходе все то же самое. Только вот уже получается, что в команде должны быть представлены все компетенции (от DBA до девопса). Причем на высоком уровне. Иначе не работает.

                          0

                          Вы про реальную практику внедрения? Тогда соглашусь — именно так и делают. Иногда DevOps "натягивают" на что угодно, но в итоге ЭТО невозможно даже причислить к DevOps практикам.
                          Как вы сказали, если команды разделены, то там должны быть все, но это ж форменный беспредел и неразумный расход ресурсов.
                          Я согласен с вами в другом комменте, что речь в статье про "единорожку", которой быть не может. Просто если сводить используемый термин только к инструментам оркестровки и мониторинга, то это всё равно что слону отрезать "второй" хобот, повесить на шею и говорить, что носишь слона: так-то да, но по факту что-то другое. А говоря про DevOps-инженера многие именно менеджера по оркестровке и имеют в виду, хотя это всего лишь инженер автоматизации.

                            0

                            Да. Могу только добавить, что единый пул ресурсов не всегда ведёт к экономии средств. Потому что есть разные задачи и их эффективнее каждую решать наиболее подходящим для этого способом. Иначе это напоминает попытку использовать единый инструмент для всего, что есть порочная практика. Т.е. нужен некий баланс между унификацией и "у каждого свой огород".
                            К сожалению, это обычно приводит к борьбе между отделами, т.к. у всех свои цели и свои kpi.
                            Простой пример. Если есть в компании некое платформенное решение (скажем, oracle или хадуп), то внедрить другое такое же решение, которое будет эффективно решать проблемы какого-то продукта (пускай он лучше будет лететь на монге и s3, соответственно) — от сложно до почти невозможно. Экономия? Эффективность? Нет, не слышал.


                            В случае же настоящего стартапа даётся карт-бланш, что позволяет быстро вносить изменения. И это является необходимым условием существования стартапа, иначе он очень быстро загнётся. Энтерпрайз же живёт в другой парадигме — максимального сохранения статус-кво.

                        0

                        Не понимаю проблемы.
                        Смотрите. Если мы придерживаемся продуктового подхода, то, да, действительно каждая команда вправе выбирать каким тулингом пользоваться. И какими средствами решать задачу бизнеса в рамках, первую очередь, бюджета. Действительно, нет двух абсолютно одинаковых команд и двух абсолютно одинаковых продуктов. Но если мы рассматриваем ситуацию крупного энтерпрайза, который может себе позволить штат архитекторов, менеджеров, безопасников, админов и пр… Ну, там действительно возможна централизация инструментария и предоставление инфры командам как сервиса. Но в этом случае душатся все начинания девопса и эджайла. Универсальной формулы как "сделать все эффективно" пока не изобрели. Вот и ходим кругами и называем явления и вещи неподходящими терминами.


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

                        Почему вдруг Вася из отдела Х пересекается с Петей из отдела У. Суть разбивки по отделам какая? По функциональностям или всё-таки по продуктам?

                  +1

                  То бишь билд инженер?
                  Дьявол в том, что Девопс инженера нет. Это такой единорог. Мифический зверь. Который нужен всем. Фактически же это история как с врачами. Никто не будет заставлять нейрохирурга лечить простату. С Девопс инженером фактически такая же ситуация. Это может быть билд инженер, разработчик софта, инженер по мониторингу и пр. И в чем разница между "разработчик инфраструктуры" и "администратор инфраструктуры"? Только лишь в том, что первый ее развивает, а второй только поддерживает?
                  Поэтому, мое мнение, статья вредная. Ибо называет вещи не своими именами.
                  Но м разумное зерно тоже есть, т.к. недостаточно присовокупить админа к разрабам и надеяться, что внезапно будет все хорошо

                    0

                    Называйте как хотите — но если, допустим, вы являетесь разработчиком софта и самостоятельно настраиваете пайплайн, то есть настраиваете development operations, а соответственно от части вы являетесь DevOps-инженером)

                      0

                      Повторюсь. Я строго против наименования DevOps инженер. Оно затуманивает смысл.
                      Если же в примере разраб настраивает пайплайн, то он настраивает пайплайн. Не больше и не меньше.

                  +2
                  Исторически примерно так:
                  Стали распространяться компьютеры, для них появились администраторы. Они ползали по полу, протягивая кабели и вставляя в слоты диски с Windows.
                  Компьютеров стало больше. Выяснилось что специалисты кладут кабели и вставляют диски лучше. Их стали называть PC–техниками.
                  Компьютеров и админов под них стало очень много. Появились средства автоматизации, пайплайнов и т.д. Произошло разделение на «админов старой школы» и Девопс. (Одновременно PC–техников стали заменять на программы вроде Foreman)
                  Теперь стало понятно, что инфраструктура это код. Её всю можно описать в коде, и управлять как кодом, и автоматизировать вообще всю. А это уже смена парадигмы. Как разрабатывать код мы знаем, и это значит знания программирования, тесты, версии, среды разработки, проверки синтаксиса и т.д.
                  Сейчас всех, кто использует эти инструменты называют «ДевОпс инженеры», но одновременно идёт разделение на тех кто может программировать, и не может.
                  Те кто не может, в конце-концов будут скачивать и настраивать программы от тех кто может. Появятся какие-нибудь «ДевОпс техники».
                    0
                    Компьютеров стало больше. Выяснилось что специалисты кладут кабели и вставляют диски лучше. Их стали называть PC–техниками.
                    (Одновременно PC–техников стали заменять на программы вроде Foreman)
                    шта? =)
                      0
                      Кабели отдали на аутсорс специализированным компаниям ;)
              +4
              Напридумывают терминов и обмазываются. Примерно такие же пространные обсуждения были, когда придумали термин «облако».
              Всё просто — чем меньше организация, тем больше ролей может взять на себя один человек. Может человек быть и системным администратором, и DevOps-инженером, и даже кадровиком и водителем, если компания на 5-10 человек. И если кто-то в вакансии указывает в требованиях, что ему нужен «многостаночник», то так и есть — отдельно сисадмин, и отдельно DevOps-инженер просто не будут достаточно загружены.
                +1
                А зачем компании 5-10 человек DevOps-инженер и админ?
                  +2
                  Ну вот у нас 3 программиста, 1 тестировшик и я — он же админ, он же девопс, и тд и тп. Правда я на удаленке, потому что незагружен. Но и без меня никак — локальную серверную ферму и кучу вдс кто-то же должен администрировать.
                    +5
                    У нас девопсят программисты сами. Ну кто постарше да поумнее.
                      0
                      Зачем тестер? Человек, умеющий в пайплайны дженкинса, и знающий, как работает продукт, может писать блекбокс и функциональные тесты
                        0
                        А ему это надо? Своей работы полно.
                          0
                          Денег больше хочется же :)
                            0
                            Возможно, но большинство моих знакомых сами бы кому-нибудь приплатили, лишь бы никак с тестами не связываться.
                              0
                              Так лучше понимаешь продукт, и глубже связь с командой разработки (для чего собственно и придумали девопс). Кроме того, тебе за час платят больше, чем QA, а работа по инфраструктуре, ну как у Вас выше, не всегда есть.
                  +1

                  какая путаница?
                  у людей куб проде по 2+ года уже
                  четко по вакансии понимает контора чтото или нет
                  пара наводящих вопросов к команде так же все проясняет

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

                      Не придет, не принимайте его за дурачка.
                      А если и придет, то будет понимать зачем (например, лычка Девопс даёт +30% к з/п) и какой ценой для него это дастся.

                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Очень интересный вопрос! Не уверен, что на него есть единый правильный ответ. Мне кажется, тут всё решается «на земле», в конкретном случае. Разработчики могут быть и изолированы от инфраструктуры Заказчика.

                      Например, у них может быть свой препрод-сервер, куда они выкатывают все обновы и показывают заказчику. А он уже по их документации далее каким-то образом выкатывает обновления у себя на производственных серверах. Будь то новые docker-образы из хранилища или код из репозитория.

                      Либо же наоборот, Заказчик может захотеть никак не связываться с «цифровой» частью проекта и целиком отдать всё на откуп Разработчика.
                        +1

                        Если речь идет про отчуждаемый сервис от остальной инфраструктуры заказчика — заказчик выделяет разработчику отдельный пул ресурсов (например группа виртуалок у облачного провайдера), развертыванием и сопровождением полностью может заниматься разработчик.


                        Если сервис интегрируемый и неотчуждаем от инфраструктуры заказчика — то развертывание осуществляется заказчиком, а разработчик просто не реализует этап Continuous Deployment, т.е. делает всё вплоть до поставки готового артефакта заказчику.

                          +1

                          Но без CD он всего лишь релиз-инженер :)
                          Развернуть инструменты разработки — это ещё недавно было работой обычного админа.

                            0
                            это он у заказчика без CD, а локально на тестовых стендах полный цикл CI/CD на нем
                          0

                          Если это разные команды, и Dev команда не имеет отношения к эксплуатации (Ops), то DevOps сюда не подходит

                            0

                            DevOps — как вместо одной стены (dev vs ops) получить две (dev vs "devops" vs ops).


                            Типичный пример:
                            Продакшен сломался.
                            Разработчики — "Ты же Девопс, иди чини продакшен!!"

                          +1

                          Просто найдите курс на EMC: "DevOps: What, Why, and How".

                          +1
                          > что DevOps-инженер и системный администратор — это две разные сущности
                          Ага, только ни у кого денег нет на то, чтобы они были отдельными сущностями.
                          Классическим администраторам работа осталась только в достаточно специфических компаниях, которые по факту продают инфраструктуру (либо настолько крупные, что сами у себя вынуждены поддерживать парочку крупных облаков). При этом в последних тоже не всё гладко с этим.
                            +3
                            Коллеги, различалка «DevOps инженер — это про технологии и про менеджмент, а админ — это только про технологии» так себе и не дает ответов на многие вопросы, например а чем/кем управляет DevOps инженер, если он про менеджмент?

                            Я все же стою на позиции, что DevOps — это область, а в ней есть множество ролей, минимум их шесть:

                            — инфраструктурный инженер (строит платформу или работает с уже готовой, например инженер по Amazon)
                            — сервисный инженер (например строит сервис аналитики или балансировки нагрузки)
                            — разработчик со знанием DevOps подходов и 12-factor app
                            — инженер по автоматизированному тестированию
                            — релиз-менеджер (синхронизирует выкатки и бизнес)
                            — CTO, который умеет этим всем управлять

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

                              Получается, что само понятие "DevOps-инженер" лишено смысла, ведь есть конкретные понятия. Либо это некий тип very-fullstack-разработчика.

                                +1

                                Именно! Я про это же, но с другой стороны пишу выше
                                Что может быть, вероятно, это менеджер по внедрению девопс-практик. Ведь есть же эджайл коучи? Но это больше не техническая должность тогда.

                              +2

                              Все просто! Бизнес требует CDO по цене DevOps, DevOps по цене сисадмина и сисадмина по цене аникея.

                                +2
                                Самая большая боль рынка в том, что народ путает роли и профессии.
                                Я думаю что DevOps это роль для профессии Software Engeenear и пока не понимаю как их начали роднить с админами (не в обиду инженерам инфраструктурщикам)
                                  +1
                                  точно так же, как и прям в начале статьи породнили эникейщика и обычного админа
                                  +4

                                  Devops — это идея, из которой вышел некоторый набор практик.
                                  Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:


                                  • Билд\релиз инженер — человек, который отвечает за сервисы сборки, релиза, деплоя, помогает выстроить процесс сбора обратной связи.
                                  • Инженер инфраструктурных сервисов — человек, который строит удобное внутреннее\внешнее облако для запуска сервисов. Это он делает мониторинг aaS, базу aaS, сбор трейсинг-спанов aaS, что-то ещё aaS.
                                  • Инженер по надёжности систем — человек, который радеет за то, что сервис будет работать, редко падать и быстро чиниться. Это он учит людей правильным архитектурным паттернам.

                                  Эти роли могут быть распределены внутри команды разработки, а могут исполняться отдельными командами.


                                  P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.

                                    0
                                    Дима, нам нужно про это написать статью! Хотя конечно комментарий твой весь смысл отражает очень полно.
                                    0
                                    А бывает наоборот. На собеседовании на DevOps спрашивают
                                    -«А на каких языках вы программируете?»
                                    -«Эмм… не на каких, я пишу скрипты автоматизации, пайплайны CI/CD»
                                    -«Ой вы нам не подходите, нам нужен девопс который помогает разработчикам указать что у них может быть не так в коде»
                                    -«Лолшто??»
                                    И так больше половины вакансий, я конечно могу сказать разрабу что у него не хватает пакета в requirements.txt по тексту ошибки питона, но если бы я хотел писать код то стал разработчиком сам.
                                    Многим маленьким командам нужен как тут правильно сказали «многостаночник», а поскольку инфраструктуры в основном облачные то желательно девелопер, который будет еще и виртуалочки в амазоне поднимать. Ну что же, удачи этим смелым парням найти такого.
                                      0
                                      У нас таких 2
                                        0
                                        Что подтверждает, что Вы удачливый!
                                          0
                                          Нет, потому что один из них — я.
                                      0

                                      У каждого термина должно быть определение, иначе каждый вкладывает то, что он фантазирует, в итоге получаем бардак.
                                      Становится всё просто и понятно если сказать что: DevOps — автоматизация текущих процессов.

                                        0

                                        не любая автоматизация, очевидно, DevOps.
                                        Вот, например, автоматизация работы бухгалтерии — это DevOps? Скорее нет, чем да. Верно?

                                          +1
                                          Видимо имеется в виду автоматизация не внутри какого-то продукта, а его окружения и инфраструктуры. Автоматизация внутри бухгалтерии это не девопс, автоматизация развертывания тестовых баз, новых версий и конфигураций самой бухгалтерии — куда ближе

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

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