Кто такой DevOps и когда он не нужен +32







Тема DevOps за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.

Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.

Кто такой DevOps


Идея написать статью возникла после очередного вопроса: «кто такой DevOps?». До сих пор нет устоявшегося термина, что или кто это. Часть ответов уже есть в этом видео. Сначала выделю главные тезисы из него, а затем поделюсь своими наблюдениями и мыслями.

DevOps — не специалист, которого можно нанять, не набор утилит, и не отдел разработчиков с инженерами.

DevOps — это философия и методология.

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

С появлением DevOps структура и роли специалистов остались такими же (есть девелоперы, есть инженеры), но изменились правила взаимодействия. Размылись границы между отделами.

Цели DevOps можно описать тремя пунктами:

  • Софт должен обновляться регулярно.
  • Софт должен делаться быстро.
  • Софт должен развертываться удобно и в короткие сроки.

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


И это только часть инструментов DevOps

Уже больше 2-х лет собеседую людей на позицию DevOps-инженера и ко мне пришло осознание, насколько важно четко понимать суть термина. Накопился специфический опыт, наблюдения и мысли, которыми хочу поделиться.

Из опыта собеседований я вижу такую картину: у специалистов, которые считают DevOps должностью, обычно есть недопонимания с коллегами.

Был яркий пример. На собеседование пришел молодой человек с кучей умных слов в резюме. На последних трех местах работы у него был стаж 5-6 месяцев. Из двух стартапов ушел, потому что «не взлетели». А вот насчет третьей компании сказал, что там его никто не понимает: разработчики пишут код по Windows, а директор заставляет этот код «заворачивать» в обычный Docker и встраивать в CI/CD-пайплайн. Парень много чего негативного рассказал по поводу его текущего места работы и его коллегах — так и хотелось ответить: «Так ты слона не продашь».

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

— Что лично для тебя означает DevOps?
— Вообще или как я это воспринимаю?

Меня интересовало его личное мнение. Он знал теорию и происхождение термина, но был категорически с ними не согласен. Он считал, что DevOps — должность. Здесь и кроется корень его проблем. Как и других специалистов с таким же мнением.

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

Методология и философия DevOps


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

Методология DevOps — лишь средство достижения поставленных целей.

Теперь о том, что такое философия DevOps. И это, наверное, самый трудный вопрос.

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

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

Я на своем опыте постарался формализовать некоторые «постулаты» этой философии. Получилось следующее:

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

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

Что делает DevOps


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

Про западный рынок труда говорить со 100% уверенностью не могу. Но вот о рынке DevOps в России знаю довольно много. Кроме сотен собеседований, за последние полтора года я участвовал в сотне технических пресейлов по услуге «Внедрение DevOps» для крупных российский компаний и банков.

В России DevOps ещё очень молодая, но уже трендовая тема. Насколько я знаю, только по Москве дефицит таких специалистов за 2019 год составил более 1000 человек. А слово Kubernetes для работодателей почти как красная тряпка для быка. Адепты этого инструмента готовы использовать его даже там, где это не нужно и экономически не выгодно. Работодатель не всегда понимает в каких случаях, что уместнее использовать, а при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме. Используйте его там, где он действительно нужен.



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

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

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

Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.

Но есть команды, которые, наоборот, рады внедрению новых инструментов и методов, и живо участвуют в этом процессе. Хотя даже в таком случае коммуникации между DevOps-инженером и командой никто не отменял.

Когда DevOps не нужен


Бывают ситуации, когда DevOps не нужен. Это факт — его нужно понять и принять.

В первую очередь, это касается любых компаний (особенно малого бизнеса), когда их прибыль не зависит напрямую от наличия или отсутствия IT-продуктов, предоставляющих информационные сервисы клиентам. И здесь речь не о сайте компании, будь он статической «визиткой» или с динамическими новостными блоками и т.п.

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

Ярким примером является один известный банк. У компании нет привычных клиентских офисов, документооборот осуществляется через почту или курьеров, а множество сотрудников работает из дома. Компания перестала быть просто банком и, на мой взгляд, превратилась в IT-компанию с развитыми DevOps-технологиями.

Много других примеров и лекций можно найти в записях тематических митапов и конференций. Часть из них я посетил лично — это очень полезный опыт для тех, кто хочет развиваться в этом направлении. Вот ссылки на YouTube-каналы с хорошими лекциями и материалами по DevOps:


Теперь посмотрите на свой бизнес и подумайте вот о чём: как сильно ваша компания и её прибыль зависят от IT-продуктов, обеспечивающих взаимодействие с клиентом?

Если ваша компания торгует рыбой в небольшом магазинчике и единственным IT-продуктом являются две конфигурации 1С: Предприятие (Бухгалтерия и УНФ), то вряд ли есть смысл говорить о DevOps.

Если же вы работаете на крупном торговом и производственном предприятии (например, производите охотничьи ружья), то стоит задуматься. Вы можете проявить инициативу и донести своему руководству перспективы внедрения DevOps. Ну, и заодно, возглавить этот процесс. Проактивная позиция — один из важных постулатов философии DevOps.

Размер и объем годового финансового оборота не является основным критерием для определения, нужен ли вашей компании DevOps.

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

Их клиенты — это ограниченный список автомобильных дилеров. И к каждому прикреплен специалист от производителя. Весь внутренний документооборот происходит через ERP SAP. Внутренние сотрудники, по сути, являются клиентами информационной системы. Но управление этой ИС осуществляется классическими средствами управления кластерными системами. Что исключает возможность использования практик DevOps.

Отсюда вывод: для подобных предприятий внедрение DevOps не является чем-то критически важным, если вспомнить цели методологии из начала статьи. Но не исключаю, что какие-то инструменты DevOps используются ими сегодня.

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

Основной критерий для понимания нужен ли DevOps: какое значение ваши IT-продукты имеют для компании и клиентов.

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

Любые игры существуют благодаря финансированию: прямому или косвенному со стороны игроков. В Playgendary мы разрабатываем бесплатные мобильные игры, в непосредственном создании которых участвуют более 200 человек. Как мы используем DevOps?

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

Сейчас у нас активно используется Jenkins как инструмент CI/CD pipelines для выполнения всех сборочных конвейеров с Unity и последующего деплоя в App Store и Play Market. Еще из классического набора инструментов:

  • Asana — для управления проектами. Настроена интеграция с Jenkins.
  • Google Meet — для проведения видеовстреч.
  • Slack — для коммуникаций и различных оповещений, включая нотификации из Jenkins.
  • Atlassian Confluence — для документирования и групповой работы.

В ближайших планах внедрить статический анализ кода с помощью SonarQube и провести автоматизированное UI-тестирование средствами Selenium на этапе Continuous Integration.

Вместо заключения


Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.

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

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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (103):

  1. DarkHost
    /#21425928 / -2

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

  2. xpostman
    /#21425932 / +3

    Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.


    Здравствуйте, я такой фронтендщик, есть ли какое-то решение проблемы? Или предлагается «принять философию»?

    • kern-panic
      /#21426236 / +1

      Здравствуйте. Простого рецепта здесь, к сожалению, нет. Пока в вашей компании не появится DevOps (SRE) Engineer — сложившуюся ситуацию изменить будет довольно сложно.

      • xpostman
        /#21426490

        Пишу из большой компании, где есть целый отдел девопсов, готовых помочь. Я не сомневаюсь в их профессионализме, и не оспариваю всю идеологию, пусть она вся состоит сплошь из преимуществ. Но я совершенно точно ощущаю на себе возросшую необходимость изучать не очень релевантные технологии. Например, мне приходится самому конфигурить дженкинс, кубернетис, ингресс и прочие чудеса, каждое из которых предполагает изучение новых сред и языков со своими особенностями и прибамбахами. Дженкинсфайл вроде бы пишется на груви, но недостаточно прочитать мануал по груви, потому что это не совсем груви, а ещё он работает не по всему дженкинсфайлу, а при каких-то определённых условиях. Коллега из SRE присылает мне пулреквест в докерфайл, чтоб тесты и линтер запускались внутри поднятого контейнера, а не в пайплайне, потому что это обладает преимуществами. Все эти процессы выглядят очень разумно, мне здесь нечем возразить. С точки здрения SRE-инженера, у нас, как у фронтендщиков теперь есть больше возможностей. Мы теперь можем сами сконфигурить себе пайплайн, под нужды конкретного проекта. У нас есть контроль над всеми происходящими процессами. Но я уже забыл, а что я делал-то вообще. У меня вроде стояла задача сделать какой-то UI, мне бы хотелось заниматься компонентами, рендерингом, состоянием, UX, визуальной красотой в конце концов, но почему-то я давно застрял в пайплайнах. Мне точно нужно всё это знать? Решают ли эти методики проблем больше, чем создают?

        Я бы объявил идеальным девопс-специалистом не такого своего коллегу, который хорош в коммуникации и взаимоотношениях, а такого, который смог бы организовать процесс не требующий столько моего внимания. В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.

        • kern-panic
          /#21426688 / +1

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

          Не берусь судить об организации DevOps в вашей компании, но невозможно получить DevOps и не общаться с теми, кто его реализует. Мы просто не сможем узнать, что у разработчиков в головах. Я не могу построить пайплайн без участия девелопера: нужно знать тысячу мелочей, которые необходимо учитывать при сборке и деплое.

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

          • xpostman
            /#21426964

            У нас в фирме создано впечатление, что нам (разработчикам) следует всё же изучать эти инструменты, потому что они теперь являются базовыми, как, например, умение работать с git или с командной строкой (что тоже как бы не фронтенд, но всем необходимо).

            Как вы считаете, куда сейчас «дует ветер»: это правильное впечатление, и нам всё же следует всё это осваивать, или нормально было бы в нашем случае возмущаться и требовать, чтоб девопсы приходили и сами пилили свои дженкинсфайлы в наших проектах?

            • Belibak
              /#21427620

              Я хоть и админ, и мне лень, но Вам однозначно стоит возмущаться и требовать.

            • yetanotherman
              /#21427854 / +2

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

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

              По-моему второй год так живем уже, все довольны, из основных плюсов — пропал головняк с чистотой окружений и сопутствующее перекидывание какашками между отделами, стало относительно легко делать что-угодно-as-a-code.

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

        • gecube
          /#21427658

          Да, все верно, но здесь вопрос в том, кто ответственный. Как распределяются задачи. То что вы говорите — это инфраструктура + поддержка разработки. По уму "devops'ы" должны продать внутреннему потребителю некий пакет услуг по заворачиванию кода в продукт и доставке его. Далее этот процесс уже не требует поддержки — он растиражирован на все команды и может централизованно меняться (например, добавление новых модулей — статический анализ и все прочее), либо ребята девопсы предоставляют 90% пайплайна, а вы сами кастомизируете под свои задачи — но это ТЕМ БОЛЕЕ ПОКАЗЫВАЕТ НЕОБХОДИМОСТЬ КОММУНИКАЦИИ. Чтобы очертить границы, договориться о правилах игры, помогать друг другу в случае проблем, делиться компетенциями.

        • akdes
          /#21429542 / +1

          я сейчас играю в девопса у нас на фирме.
          Разработчики, без собственного интереса вообще не в курсах как у нас там всё тикает. Все конфиги, докерфайлы, k8s ямлы, пайплайны полностью в моей собственности. Я лишь прошу меня оповещать о каких-то изменениях, касающиеся либо сервера, либо конфигов: библиотеку новую подтянуть, новую переменную в конфиг нужно прописать, миграции и т.д.
          И для разработки я в осном полностью предоставляю проект в докере, который запускается одной командой, включая бэкенд(ы), базу и т.д.

          Т.е. в принципе, как Вы и хотите, но конечно, полностью без общения — никуда.

          Но тут фишечка то вот в чём. Я девопс из разработки, а не из сисадмина стал… Т.е. я знаю по себе боль разработчика, и понимаю многие необходимые моменты.

          С другой стороны я сисадмина заменить не могу… Сети, фаерволы и т.д., но я перенимаю коммуникацию с ним.

      • rzerda
        /#21426492

        Статья про «DevOps это методология», а ответ «найдите/родите/украдите девопс инженера», вот это номер.


        Ситуация в том, что узкие специалисты за пределами своей песочницы, как правило, ничего не видят и не хотят смотреть (есть ещё вариант, что им не дают под соусом «некогда объяснять, надо фичи пилить»). Для того, чтобы координировать действия таких не очень смотрящих по сторонам людей, придумали менеджмент, в обязанности которого и входит обустройство коммуникаций между людьми и подразделениями. Если этот менеджмент действительно считает, что основной задачей разработчика является написание кода, то можно дивизию девопсов нанять и ничего не получить в итоге. Это объясняется в самой статье прямо словами «девопс это про организацию».

        • tagirb
          /#21426714 / +1

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


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

          • pbatanov
            /#21427002 / +1

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

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

            • VolCh
              /#21427664

              То есть чарт писать всё-таки разработчику? А девопс инженер что будет делать? Или разработчик оценит, что девопс у нужно три часа или три девопс поинта и создаст таску на него какой чарт ему нужен?

              • pbatanov
                /#21427744 / +1

                Или разработчик оценит, что девопс у нужно три часа или три девопс поинта и создаст таску на него какой чарт ему нужен?


                Здесь вы описываете классический процесс с опсами без девопса. Нам что-то надо поменять в инфре — мы ставим задачу опсам. Они его когда-то сделают, у них там свой беклог задач, может через полгода до нашей доберуться. А там как раз и снова про наш проект вспомнят.

                Само по себе наличие задачи «написать чарт» или использование волшебных технологий не делает процесс «девопсным». Все эти технологии можно использовать и с классической схемой «отдел разработки пишет код, отдел эксплуатации его деплоит и саппортит».

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

                В этом случае вы сможете командой оценить трудозатраты и командой же реализовать проект от и до не в мифических «девопс поинтах», а именно в тех единицах, в которых работает команда.

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

                • VolCh
                  /#21427954 / +1

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


                  У нас такая команда есть, но бас-фактор где-то 1,3, где 1 — это я. И вот честно отдавать половину, а иногда и больше рабочего времени разработчика на подобные задачи, мне больше совсем не хочется. Не хочется просыпаться по ночам с "гениальной" мыслью, что перезагружать автоматически под при изменении конфигмапы можно добавив контрольную сумму этой конфиг мапы в аннотации пода или что инит контейнеры можно использовать для проверки что в файловой системе все права правильно установлены, а не всобачить такую проверку в ентрипоинт.


                  Подправить что-то, типа добавить новую енв переменную в ту же конфигмапу — ради бога (для меня лично, а половина команды разбираться не хочет). А вот разбираться как заблокировать PV/PVC от удаления и как его перемонтировать туда же в нормальном состоянии, когда уже в deleting — это перебор.


                  Извините, наболело.

                  • pbatanov
                    /#21428860 / +1

                    А вот разбираться как заблокировать PV/PVC от удаления и как его перемонтировать туда же в нормальном состоянии, когда уже в deleting — это перебор.

                    А вот в этот момент надо вспомнить что в DevOps кроме Dev есть Ops. Которые (ну опять же в моем понимании и мы у себя к этому вроде идем) помогут разобраться, отревьюят твои изменения в чартах, дадут свои рекомендации и какие-то общие направления для всех разаработчиков (ну типа «давайте все перестанем делать так и будем делать так, потому что..»).

                    В вашей ситуации я вижу наболело потому что Dev полностью погружается в опсовую историю (при том походу самостоятельно, если ему приходится разбираться про pv\pvc). Но должно быть не так. Опсы должны давать удобные инструменты и инфраструктуру в котрую девелоперы смогут заезжать самостоятельно и без боли. Если не самостоятельно или с болью, то где-то недоработки и надо побольше пообщаться чтобы решить эти проблемы

                    • VolCh
                      /#21429522

                      Опсы дают кластер с какими-то предустановленными штуками и конфиг для kubectl c "рутовыми" правами. Также отвечают за функционирование, мониторинг, бэкапы и т. п. как нод кластера, так и машин с базами данных, очередями, nfs и т. п. Грубо отвечают за железо, ОС и один процесс на машине.

                      • pbatanov
                        /#21429550

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

            • tagirb
              /#21429868 / +1

              Мне кажется, вы в первом абзаце сами себе противоречите.


              А, ну да, в вашем комментарии ниже:


              Так что да, идея как раз в том, что разработчику — самому писать чарт.

              А если он отлично знает бизнес-логику, ну просто в совершенстве, но очень далёк от инфраструктуры и она ему неинтересна. Заставлять "интересоваться"? Уволить и искать другого?


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


              На самом деле, нужно просто налаживать простое и человеческое взаимопонимание в коллективе. Тогда и техника заработает как надо.

              • pbatanov
                /#21430020 / +1

                А если он отлично знает бизнес-логику, ну просто в совершенстве, но очень далёк от инфраструктуры и она ему неинтересна. Заставлять «интересоваться»? Уволить и искать другого?


                Это уже вопрос микро-менеджмента в конкретно взятой команде. Насколько вы управляете бас фактором, насколько вы шарите знания и т.д.

                Этот вопрос вообще к девопсу никакого отношения не имеет. Тот же самый вопрос может возникнуть если у вас в команде есть несколько направлений (например в нашей команде на поддержке несколько систем разных) и человеку может нравится заниматься одним и не нравится заниматься другим. Что вы сейчас делаете в таком случае? Увольняете и ищете другого? Я думаю что подход (какой бы он у вас ни был) будет примерно таким же.

                Да, конечно, все решается человеческим взаимопониманием, тут абсолютно согласен. В частности у нас в команде нет принудиловки в этом плане, но в целом 3 человека могут заниматься этим полноценно и еще пара понимает как это работает, что уже, на мой взгляд, позволяет нам грамотно оценивать и планировать такие задачи и ставить их в спринт как обычные.

                • tagirb
                  /#21430192

                  Это уже вопрос микро-менеджмента в конкретно взятой команде.

                  Этот вопрос вообще к девопсу никакого отношения не имеет.

                  А что тогда такое девопс? Организация процесса работы команды. Вы себе опять противоречите.

                  • pbatanov
                    /#21430762

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

    • tagirb
      /#21426692

      Решение всегда есть, но оно для каждого своё. У нас, например, фронтенд и бэкенд в разных проектах. У бэкенда есть stage, с которым фронтендеры и соединяются. И не нужно каждому держать всё на своём лаптопе, хотя, это возможно и есть и такие примеры.

      • VolCh
        /#21427676

        То есть фронт ждёт пока бэк имплементирует свою часть бизнес таски, её как-то протестируют без фронта и вольют в стейдж? Или собственно фронт и тестирует первым?

        • grinCo
          /#21428248

          Это зависит
          У нас микросервисы и все релизиться независимо. Так что бекенд может уйти в прод за месяц до фронтенда.

        • tagirb
          /#21429874

          По разному бывает. Просто договариваются между собой, кто, что и когда делает.

    • acklamterrace
      /#21427584

      А чем не подходит реальный бэкенд, который у вас уже есть? Настройте http-прокси и дергайте API настоящего dev/staging или что там у вас.

    • grinCo
      /#21428222

      Обычно у юащиков локально только их код который дергает апи на удаленном энвайроменте.

  3. Kopilov
    /#21425944

    при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме


    Хм, а что есть «обычная кластерная схема»? Вроде, то, что Kubernetes становится стандартом — один из его главных плюсов. Можно отладить на одном кластере и почти не ждать траблов на другом

    • kern-panic
      /#21426252

      Kubernetes стремится стать отраслевым стандартом, но эта цель еще далека. А его рыночная ниша — веб-приложения. К тому же, это не «серебряная пуля». Есть куча кластерных приложений, которые в ближайшее время (а может и никогда) не будут адаптированы под Kubernetes. В основном это различные enterprise-продукты. Например, SAP или 1С:ERP. И аналогичных клиент-серверных приложений великое множество.

      • gecube
        /#21427662

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

  4. ganqqwerty
    /#21425948

    вы не могли бы кинуть мостик от всех этих высоких материй к сложившемуся бытовому пониманию девопса как сисадмина дженкинсов и опен-шифтов?

    • kern-panic
      /#21426586

      Чтобы погрузиться в DevOps, нужно прокачиваться, пробовать разные инструменты и задавать себе примерно такие вопросы:

      Почему Jenkins? Что такое Jenkins? В чём практическая разница решения аналогичной задачи в Jenkins, GitLab CI, TeamСity?
      Какой результат нужен руководству, когда ставит мне какую-либо задачу?
      Есть ли какие-то альтернативные варианты?
      Каковы при этом будут финансовые и временные затраты?

      Как только самостоятельно начнете искать ответы на них (обычно сквозь боль и полученный опыт), то станете видеть общую картину процессов. Это и есть «путь DevOps».

      • pepemon
        /#21427214 / +2

        Именно, познание смысла всех инструментов через пекло (в первую очередь, а какие проблемы эти инструменты решают и почему мне должно быть дело до этих проблем) и приближает "сисадмина кубера" к DevOps-дзену. А то вон как комментатор ниже, жонглирование баззвордами без какой-либо осознанности и их же продажа таким же неосознающему смысла происходящего работодателю.

        • Vkuvaev
          /#21428218

          Добавлю про такую штуку как диаграмма value stream. Она интересна тем, что показывает как выглядит процесс разработки продукта по этапам от начала до конца, и вот поняв смысл ее и поняв какое отношение к ней имеет идея DevOps, можно будет говорить об осознании, что это и зачем оно нужно.
          Я бы сказал так, идея DevOps сделать понятным, прозрачным и быстрым процесс от идеи до продукта. Чем и как вы этот процесс реализуете не регламентировано. Но суть именно в словах выше.
          В частности, как следствие, возникают задачи автоматизации, ведь только так можно ускориться, и только так можно непрерывно улучшать процедуры избегая проблем с ручными ошибками. Короче это сродни построению конвейера на производстве.

  5. onix74
    /#21425958

    До сих пор нет устоявшегося термина, что или кто это.

    и ко мне пришло осознание, насколько важно четко понимать суть термина.

    WTF?

    • PlatinumR
      /#21426016 / +1

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

      • onix74
        /#21426022

        Если нет термина, как можно четко понимать его суть?

        • PlatinumR
          /#21426404 / +1

          Нет единственного устоявшегося термина и нет термина вообще, на мой взгляд, разные вещи.

  6. elve
    /#21426170 / +1

    Так много слов, но тема заголовка не раскрыта ;).

    Если сократить, то девопс это все же специализация инженера (должность сисадмина всеобъемлюща поэтому уточнил =) ). Кто-то поддерживает сети, кто-то AD, а кто-то рабочую среду для программистов.

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

    Позиция «я не могу сформулировать, но вы сами должны понимать» не очень конструктивна. Вам не кажется?

    • Mes
      /#21426564

      Зато в статье раскрыта информация, как пройти собеседование у Савосина В.

    • gecube
      /#21427680 / +1

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

      • elve
        /#21428360

        И вот опять куча слов и сложно с конкретикой =). В принципе похоже на поведение тех самых «коучей» =). DevOps по вашим словам это приглашенный извне тренер, который обучит фирму работать по новому? Из ваших слов я понял так.

        И хотелось бы услышать от вас, как вы понимаете слово инженер. А то пока сложилось мнение, что вы не знаете значение этого слова. Это не наезд. Просто если два человека вкладывают в одно и то же слово разный смысл — они не поймут друг друга.
        Пока сложилось мнение, что вы можете мальчика, который освоил 3 кнопки в облачном сервисе амазона, назвать не только «специалистом по облакам» но и инженером.

        • pepemon
          /#21428872

          Ну справедливости ради, освоить AWS — это отнюдь не три кнопки запомнить и правильную последовательность их нажатия.

  7. Showreel
    /#21426216

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

  8. rmuhamedgaliev
    /#21426254 / +1

    Хорошая книга на эту тему "Руководство по DevOps"

  9. Jammarra
    /#21426434 / +2

    В текущих реалиях сколько не рассуждай но DevOps и SRE это хайповые название для работы админов иногда разрабов что бы продавать какаю то херню за дорого. Которую сделали популярным маркетологи со своими "облаками, IaC и т.д. которые им нужно было впарить"


    P.S. я как админ не против. Делаю тоже самое получаю в 2 раза больше. Всего то нужно написать модные слова в резюме.


    По сути всю жизнь занимались тем же самым. И до всего этого хайпа. Да инструменты были другие, был например jail, а не docker и скрипты на bash а не ansible. Ну так индустрия не стоит на месте. У разрабов IDE тоже меняются.


    А если рассматривать DevOps как метадологию, то почти все по ней раньше и работали. Вот она и легла хорошо на старую методику. Только называлась она не так красиво а "Х##к-х##к, и в продакшн"

    • justhabrauser
      /#21426622

      > а «Х##к-х##к, и в продакшн»

      И совершеннейшая неправда.
      «Х##к-х##к, и в продакшн» — это CI/CD.
      А DevOps и SRE — это надмножество «Х##к-х##к, и в продакшн».
      PS. вспомнилось из старого анекдота — совещание в некой фирме:
      — И хочу напомнить отделу продаж, что выражение «всякая х… ня» не в полной мере отражает всё многообразие продуктов и услуг нашей компании.

    • pepemon
      /#21427206

      Даёт ли bash идемпотентность? Джейлы — лишь небольшая часть паззла решения по доставке и запуска иммутабельных артефактов, которое формирует Docker и его последователи. Современный эксплутационный стэк, в первую очередь, теперь позволяет решать типичные эксплутационнные проблемы, ради которых раньше требовалось организовывать отдел, одним инженером с нужной экспертизой. И простое наличие нужных баззвордов в CV экспертизы не даст. Ansible, Docker, Kubernetes, Terraform и прочие — лишь инструменты, позволяющие реализовать подход, дающий все релевантные бенефиты разработчикам и бизнесу — и вот поэтому "DevOps-инженерам" и готовы платить деньги.
      Условно говоря, люди десять лет назад на условном Puppet управляли состоянием инфры и получали за это инженерные деньги, то что HR-зомби ищут "мифического девопса" на каждом шагу, квалифицированному инженеру погоды не сделает.
      Ну и про "вывалить в прод" — это не DevOps никак вообще. Graceful degradation, blast radius limitation — все эти концепции были выкованы огнём и мечом, ваша картина восприятия той индустрии, которая вас кормит — как бы мягко сказать неверна.

      • Jammarra
        /#21427692

        Сколько слов то умных английских. Я простой глупый админ в такие не умею=) Так что киваю головой и соглашусь, да да это стоит много денег…
        Надо ещё на бумажку выписать и заучить. Тоже на собеседовании за умного сойду =)


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


        То то теперь нужно для работы по офигетельной методологии DevOps 3 отдела, 8 менеджеров и по 5 собраний в день… будни обычной "современной и прогрессивной" компании. )
        Как сказал мой знакомый про одну из таких "знаешь мне там просто надоело работать. Если бы я 3 года ходил и говорил что то невнятное на митапах, никто бы не понял что я больше ничего не делаю. Никто вообще не понимает что мы делаем и зачем. Половина просто фигней страдает"

        • pepemon
          /#21427998

          Если убрать твой сарказм, ты-то сам понял что написал? Я говорю что один специалист теперь может рулить инфрой на 100+ хостов минимум (а при правильно построенных практиках на уровне департамента и 1000+), в которой постоянно что-то тестируется, выкатывается, мониторится, алертится и т.д. и требуемый для этого набор навыков — один из элементов эксплутационной части DevOps-парадигмы, ты же мне зачем-то говоришь про ничего не делающий отдел, когда я как раз чёрным по белому написал полностью наоборот.

          • elve
            /#21428392 / +1

            Так там вся соль в этом сарказме. Человек не понимает почему, если у нас появился инструмент с помощью которого один инженер может управлять 1000+ хостами в одно лицо, надо «наводить тень на плетень» с новым термином и создавать под это дело бесполезный отдел, который будет совещаниями есть рабочее время того самого инженера.
            И я с ним в целом согласен. Слишком много шума вокруг обычной специализации инженера.

          • tagirb
            /#21429952 / +1

            А знаете, что подумал. Если взглянуть на это со стороны, ну можем мы всё это, и что? Бизнес видит, что один инженер может не 1-10, а 100-1000 хостов координировать и увеличивает свои запросы.


            И бежит белочка дальше по своему колесу, только на колесе теперь написано Ansible вместо bash или Kubernetes вместо vSphere...

            • pbatanov
              /#21430026 / +1

              Ну почему бы и нет, если это сопровождается вменяемой денежной мотивацией для сотрудника. Человек прокачался, человек может больше, человек получает больше. Если нет, то тут уж простите, ССЗБ, эффективная сова и вот это вот все.

              • tagirb
                /#21430206

                Ну вот в таком обществе и живём: ты человек, пока с тебя можно что-то получить.


                Грустно всё это, на самом деле. И самое грустное, что мы все это воспринимаем как норму.

      • elve
        /#21428512

        А дает ли python идемпотентность? А ruby? И как это вообще можно требовать от языка программирования, а не от написанной на нем программы?

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

        • pepemon
          /#21428862

          Разумеется язык программирования не может дать никаких подобных гарантий. Я имел ввиду что один из основных принципов Ansible как системы управления конфигурациями это идемпотентность применяемых ресурсов. Хотя в отличии от например Chef, Ansible позволяет себя использовать как тот же Bash на стероидах. Хотя как по мне, нужно сразу двигаться к правильному использованию инструмента.
          Насчёт логической ошибки — даже если это и так, хотя я развернул сейчас свою мысль, такой подход в диалоге называется сверхобобщением — идущие после него выводы не могут быть правдивы.

          • gecube
            /#21428896

            как системы управления конфигурациями

            ага, в частности, когда ансибл используют для деплоя, миграций и кучу еще вещей (удобно же!)

  10. lelik363
    /#21426900 / +1

    Кто такой DevOps и когда он не нужен

    Можно ли использовать DevOps, помимо разработки ПО, в других отраслях?

    • DmitryVS
      /#21427710 / +1

      PDCA же, придумано 70+ лет назад. Классика систем управления качеством. Сдаётся мне, IT'шникам кто-то случайно рассказал про цикл Деминга :)
      Вообще, не надо хотеть от разработчика внедрения этого вашего DevOps или от инженера — PDCA. Это прерогатива совсем других людей в компании, quality assurance department их зовут или отдел качества, по-нашему. И к «технарям» они относятся почти что никак. Они уже и занимаются всем этим «сектантством», и для «технарей» разрабатывают (ну или должны разрабатывать) простые и понятные процедуры выполнения рабочих процессов в рамках своих теорий управления.
      Ясен перец, что даже для средних компаний держать свой развёрнутый и действующий QA, ну так себе идея. Хотя просто следовать идеям цикла улучшения качества «из общих соображений», конечно, ни разу не возбраняется.

      • gecube
        /#21427724

        потому что получается вот так
        image


        agile и devops — очень хорошо пушат друг друга


        p.s. картинка уперта из https://habr.com/ru/company/jugru/blog/489488/

        • sergeaunt
          /#21428394

          Судя по этой картинке, разработчикам, которые пилят по Agile, вообще всё пох, а «опсы» как-то умудряются это подхватывать, причем больше всего страдает release.
          Раньше были оговорки по Фрейду, а теперь вот схемы по Фрейду пошли.

  11. Magikan
    /#21427028 / +1

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

    • grinCo
      /#21428488

      Советую вам найти нормальное место работы.

  12. NadezhdaBaranova
    /#21427056 / +2

    "Но есть команды, которые, наоборот, рады внедрению новых инструментов и методов, и живо участвуют в этом процессе. "


    "Выгоревший миллениал mode on"


    Скажите честно, вы с такими работали? Они вообще существуют в природе? Я 4 года внедряю в нашу уездную корпорацию всякие улучшалки: автотесты, дженкинс, контейнеры, а иногда начинать приходится тупо с битбакета. От силы 1 человеку из 10 (кроме менеджера) это хоть как-то интересно, остальные пользуются только если их заставляют. Тренинги, демо не особо помогают, а я их провела немеряно. Помогает только публичное унижение, если каждый день на дейли спрашивать как бы невзначай, запушил ли Петя свои изменения в битбакет, то рано или поздно, скорее всего, после пары писем от менеджера, Петя сподобится и запушит. Ура. Теперь надо чтобы он билдил и деплоил через дженкинс, а не локальным мавеном, копируя джарники через путти. 2020 год на дворе, чо.


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


    И, что бесит больше всего, что реальной власти у девопса никакой нет. Он не начальник, требовать и карать не может. И это необычайно горько, да.


    "Выгоревший милениал mode off"


    Ну ну да, никто не говорил что будет легко. И ценность сотрудника как раз и определяется тем, на колько он может свои идеи воплотить в реальную жизнь. Улыбаемся и пашем.

    • kern-panic
      /#21427302 / +1

      Да, улыбаемся и пашем)
      На самом деле в моей практике есть случаи, когда работу принимают с огромной благодарностью и энтузиазмом. Но это скорее исключения. Например, в одном крупном банке инициатором контракта был отдел тестирования ПО для ДБО ЮЛ. Там вся работа тестировщиков была только «врукопашную». Мы пришли целой командой с автоматизаторами и нагрузочниками. И нам помогали всеми силами и возможностями. Заказчик остался очень доволен результатами.

      • NadezhdaBaranova
        /#21427446

        Да, с тестировщиками лучше, они чаще ценят автоматизацию, особенно какие-нибудь регрессии гонять.

    • rzerda
      /#21427534

      Я 4 года внедряю в нашу уездную корпорацию всякие улучшалки

      Зачем? Из Вашего описания следует, что это корпорации не нужно. Можно довольно долго и успешно партизанить через этого одного из десяти, но это дорого, и крыша едет со временем всё равно от несоответствия декларации и действительности.


      ценность сотрудника как раз и определяется тем, на колько он может свои идеи воплотить в реальную жизнь

      «Я выкопал котлован под дом чайной ложкой, я ценный сотрудник» — ну нет же. Как и любого наёмника, Вас заменят быстро, без сожалений, на более лояльного и, возможно, менее квалифицированного человека. При первой необходимости.


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

      • NadezhdaBaranova
        /#21427604

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

        • gecube
          /#21427694

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

        • grinCo
          /#21428514

          И я не особо верю, что где-то сильно иначе, честно.

          А я не верю, что есть так как описываете вы :)
          На самом деле верю — я работал в самом начале полгода в такой конторе. Но благополучно свалил и работаю в нормальных конторах с нормальными процессами.

    • tmin10
      /#21427550

      Но неужели нельзя было найти место, где больше ценят автоматизацию и облегчение труда? 4 года потратить на то, что никому не нужно — не очень приятно для себя…

    • Singaporian
      /#21427628

      И, что бесит больше всего, что реальной власти у девопса никакой нет. Он не начальник, требовать и карать не может. И это необычайно горько, да.

      Это плата за то, что подыграли рынку на хайпе и назвали себя DevOps-ом. Потому что вы не были DevOps-ом. Никто не мог быть DevOps-ом, потому что человек-human-being не может быть методологией.


      DevOps, по определению, — ответственность Dev-ов перед Ops-ами и обратно.
      Как только какая-то компания берет на службу DevOps-а, то тем самым она, какбэ, говорит:
      "Я снимаю ответственность с Dev-ов перед Ops-ами. Снимаю также ответственность Ops-ов перед Dev-ами. Теперь у нас есть специальный выделенный человек, который несет на себе ответственность за обоих. А задача его заключается в том, чтобы сочинять костыли автоматизацию для связки двух подводов труб, по которым с завидным постоянством стекает дерьмо безответственных людей."


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

      • NadezhdaBaranova
        /#21427682 / +2

        Я себя девопсом не называла, они сами так меня назвали, когда слово модное услышали. Была тестером изначально. Мне что, девопс так девопс, лишь бы скрипты писать не мешали.


        Думаю да, один человек не может заменить налаженную коммуникацию между командами и всех замотивировать, если это не Тони Робинс. Но начальству проще свалить это на инженера, конечно, чтобы было с кого спросить.

  13. Andrey_Rogovsky
    /#21427730 / +1

    Бизнес — почему приложение работает так нестабильно и медленно?
    Разработчик — у меня код отрабатывает идеально, сами посмотрите. Ну давайте я опциями поиграю.
    Сисадмин — у меня сервера настроены идеально, сами посмотрите. Ну давайте я настройками поиграю.

    Или стабильно но дико тормозит, или очень быстро но с вылетами

    Бизнес: подать мне такого, кто решит эту задачу!

    DevOps — проблема решена раз и навсегда
    Бизнес — о, вот спасибо, а то уже замучались!
    Разработчик — подумаешь, пару опций сменил. Я бы и сам мог сменить (если бы знал).
    Сисадмин — подумаешь, изменил пару настроек. Я бы и сам мог изменить (если бы знал).

    Очевидно, что DevOps как персона — это некто с опытом разработки и системного администрирования от 5 лет каждого, который может решить задачи бизнеса, потому что понимает, что идеально настроенные сервера или прекрасная отработка кода на лаптопе разработчика — совсем не то, что нужно для бизнеса.
    Для решения этих задач нужно понимание и экспертиза. Как в том анекдоте про удар молотком и место, куда надо бить.

    • Jammarra
      /#21427752

      Бизнес — почему приложение работает так нестабильно и медленно?
      Разработчик — у меня код отрабатывает идеально, сами посмотрите. Ну давайте я опциями поиграю.
      Сисадмин — у меня сервера настроены идеально, сами посмотрите. Ну давайте я настройками поиграю.


      Бизнес: Давайте сменим админа на нормального.


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


      Поэтому меня например всегда прикалывало мнение что админ это человек который "настроил и больше ничего не делает"

      • ctacka
        /#21427950

        Так большинство девопсов и есть хорошие админы, которые нормально сотрудничают с разработчиками, а не плюют через губу "ваша программа не работает, код у вас дрянь, да и сам ты дурак, не знаешь как cisco настраивать". Таких ведь админов тоже достаточно.

        • Jammarra
          /#21429080

          Это странные люди. Я если честно считаю что после определенного уровня специализация специалиста определяется только опытом.


          Ну то есть смогу ли я программировать? Да без проблем. Просто не знаю специфичных инструментов, библиотек и т.д. Но логику работы без особых проблем продумаю. Например сейчас делаю на выходных свой стартап. Да у разрабов кровь из глаз пойдет когда мой код увидят. Но бизнес логика работает, на уровне "проверить взлетит или нет".
          Если буду кодить каждый день по 8 часов то через год буду вполне нормальным разрабом среднего уровня.


          И любой адекватный разраб, точно так же разберется в мой кухне. Что он не сможет ансибл править и коросинх настраивать с цефом. Да без проблем. Просто ему с этим нужно будет поработать и приложить пару продовых серверов).


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


          База работы ЭВМ и приложений, то один черт одна и та же всегда и не меняется. Ты можешь не помнить как там устроена файловая система в деталях, но логику работы +- всегда будешь понимать.


          Как бы это сказать, после определенного уровня IT перестает быть магией. Это просто рутина и обычная работа. И вопрос всегда только во времени которое потребуется что бы почитать документацию и разобраться. Выделываться типо я знаю, а ты нет. Это только в интернете можно если скучно. А на работе то зачем. На самом деле человек не может знать все в нашей области. Тут сильно много информации.

          • VolCh
            /#21429562

            И любой адекватный разраб, точно так же разберется в мой кухне. Что он не сможет ансибл править и коросинх настраивать с цефом. Да без проблем. Просто ему с этим нужно будет поработать и приложить пару продовых серверов).

            Вопрос в том, нужно ли это лично ему? Субъективно большинству разработчиков не нужно, как и большинству админов с кодом разбираться, вот тут и возникает потребность в людях, которые достаточно хорошо разбираются в обеих областях, и если не сами будут решать задачи на стыке, то ставить задачи обеим сторонам.


            Пускать на самотёк взаимодействие разработки и эксплуатации...

            • Jammarra
              /#21429610

              "вот тут и возникает потребность в людях, которые достаточно хорошо разбираются в обеих областях"


              Скажу откровенно. Таких не бывает. Человек не может разорваться. Он может сделать вид что знает. Но один черт у него нормального опыта не будет и там и там.


              Я даже в администрировании дофига чего не знаю. Например не лезу в сети, винду, sip телефонию и т.д.


              Если человек говорит что "знает все" значит он это знает очень плохо. Забавно например сравнивать мое резюме после универа и сейчас. У меня там лет 10 назад был лист а4 исписан тем что я "как бы знал". Сейчас это 2 строчки.


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

          • ctacka
            /#21429780 / +1

            В IT может/не может определяется не только набором знаний и умений, но и мотивацией. Ну да, опытный разработчик без труда может решать задачи администрирования. И потестировать может, и настроить wifi. Но ему это не интересно, и потому неэффективно давать ему такие задачи, так что условно скажем, что делать он этого не может.

    • elve
      /#21428408

      Т.е. фактически по вашим словам devops это инженер с определенной квалификацией и специализацией. Правильно?

      А что касаемо ситуации — то там либо неквалифицированный персонал, либо саботаж рабочего процесса на фоне личных загонов.

  14. VolCh
    /#21427870

    Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.

    У нас централизовано распространяется набор скриптов и конфигов для поднятия системы локально фронтендерами, бэкендерами и QA. Собственно набор это баш скрипты для поднятия локального k8s и отдельно баз данных и т. п., плюс отдельный набор values для чартов. Ну и поднять это всё локально довольно мощный комп нужен. И сопротивляться никто особо не сопротивляется, скорее высказывают хотелки типа "зачем 4 скрипта запускать — сделайте один", "слишком долго билдится — сделайте какой-то кэш и персистентность", "сложно в списке из 15 реп каждый поставить на нужную ветку", "надоело отслеживать, что IP поменялся — автоматизруйте запись в /etc/hosts". В целом наша команда хочет девопса, чтобы как раз не заниматься этим всем, чтобы разработчики писали код и тесты, чтобы тестировщики писали тесты и руками тестировали, а CTO рукводил процессами, а не фиксил локальные окружения.

  15. ctacka
    /#21427944

    Не соглашусь с единственным постулатом статьи о том, что необходимость DevOps определяется наличием развитых клиентских сервисов. Возможно, вы путаете DevOps с SRE (хотя если вы постоянно внедряете DevOps, то наверное не путаете).
    На мой взгляд, ван нужен DevOps, когда у вас есть развитая разработка ПО. И не важно, это высоконагруженный клиентский сервис или сложная система управления производством. DevOps практики — это практики именно разработки ПО, а не его поддержки. И когда ваша команда начинает задаваться вопросами управления конфигурациями, CI/CD, автоматизированными тестами, когда становятся data-driven и начинают считать метрики и эффективность — вот тогда на помощь команде разработчиков приходят devops-инженеры. А уж откуда они придут — будут наняты или выделятся из команды — не так важно (хотя конечно нанять инженера, который уже решал все такие вопросы в разных компаниях кажется более эффективным).

    • VolCh
      /#21427976

      Ещё эффективность в мотивации. Если судить по мне, то все эти CI/CD и кубернетесы/свормы мне интересны, чтобы понять их возможности и ограничения, чтобы разрабтывать софт с учетом этого, чтоб понимать какую часть сложности лучше переложить на IaC, а какую проще на код. Автоматизировать свою работу. Вот для только что созданного мною сервиса и пайплайн написать, и чарт не просто жалко, а в удовольствие. А вот когда приходят и говорят "у нас тут новый сервис соседняя команда написала, нужен пайп лайн и чарт" совсем другое отношение

      • ctacka
        /#21428160

        Кому-то интересно этим заниматься, кому-то нет. Но все равно такие задачи никуда не деваются. У нас вот есть несколько разработчиков, которые сами пишут terraform для деплоя в AWS своих сервисов. Для кого-то это кажется нормальным, другие считают, что они делают чужую работу. Но если им есть с кем обсудить проблему, кого попросить с чем-то помочь, то мотивации у них прибавляется.

  16. grinCo
    /#21428214

    Непонятно о чем статья, непонятно зачем она.
    В комментах больше пользы чем в ней.

  17. vlsinitsyn
    /#21428396

    Я вот не понимаю, нанимают человека для определенной инженерской работы, а начинают ему задавать вопросы про философию и «фсе вот это вот».
    Причем автор сам признает, что правильных ответов вообщем и нет, все очень зыбко, терминология не устоялась…
    Должность это или не должность — какая вообще разница? Тебе шашечки или ехать?
    Нанимаешь инженера с конкретным кругом обязанностей — администрить то то и то то, знать такие то системы. Ну так это и спрашивай. Нашел тоже место для удовлетворения своего эго — интервью соискателя. Мол, я понимаю философи девопса, а вы нет.
    Иди вот на открытые площадки со своими идеями, доказывай в открытых дискуссиях. Зачем этим заниматься на интервью?

    • ctacka
      /#21429792

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

      • vlsinitsyn
        /#21430274

        Ну так и проверяйте его «софт и соушал скилы». Какое отношение к этому имеет сугубо личный субъективный взгляд автора на то, что такое «философия девопс»? При том что сам автор признает что все зыбко и неоднозначно? Обучи людей, организуй процессы, докажи на деле. А зачем мутить эту тему на собеседовании? У кандидата еще может еще 3 собеседования в тот же день и у все свое понимание о том, какой должен быть девопс.

        • ctacka
          /#21430326 / +1

          Каждый волен мутить свою тему на своем собеседовании. В конце концов, особенно если у кандидата еще 3 собеседования, он вполне может послать такого собеседователя и уйти.

  18. MTX-Legion
    /#21428404

    DevOps это технолог. а не философия. У меня мама на фабрике работала, так вот ее работа была зделать так что бы пекари и технички работали в гармонии, «Размыть» грань между отделами, и зделать так что бы торты пеклись вовремя и вкусно соблюдая все нормы производтсва. А ваша философия о Development Operations это бред, просто новое слово которое дали поиграться новоиспеченым программистам которые никогда не слышашли про технологов.

  19. druss
    /#21429578 / +1

    Кратко расскажу как работает DevOps/SRE в нашей компании, может кому будет полезно/интересно. Сначала про структуру компании: 250+ человек из них 80+ инженеров (программисты, DevOps, админы), пару офисов по всему миру. Все продукты работают в Azure, офисная инфраструктура тоже там (Office 365, AD, CI/CD, etc).

    • Два админа (настройка сети офисов, VPN, wifi, Azure AD, покупка офисного железа).
    • 9 продуктовых команд (стек в основном .net (и новый и старый), angular)
    • 10+ DevOps/SRE, делятся на 3 команды:
      1. infra — настройка pipelines, ресурсов в Azure, и т.д. (3 человека)
      2. reactive — Фикс критических багов, мониторинг систем (в том числе on-call), консультация support команды
      3. proactive — разработка внутренних тулов (админки для продуктов, тулы для support команды и для devops, и т.д.), настройка и улучшение мониторинг систем, помощь продуктовым командам.


    Команды reactive и proactive динамические, т.е. каждые 3 недели (длинна спринта) команды меняются. В reactive и proactive все девелоперы (т.е. умеют писать production ready код, пилить фичи, «общаться» с бизнесом) и умеют настраивать инфраструктуру и мониторинг.

    По сути наша задача:
    1. Обеспечить работоспособность всех продуктов
    2. Заметить и починить проблемы до того как они повлияют на пользователей
    3. Улучшить жизнь работникам компании через разработку внутренних тулзов
    4. Оградить продуктовые команды от критических багов (обычные баги они фиксят сами) что бы не отвлекать их от целей спринта.

    Не знаю соответствует ли это «философии» DevOps или нет, но работает довольно хорошо.

    • VolCh
      /#21429620

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

      • druss
        /#21429688

        Команда которая разрабатывает новый сервис + кто-то из infra и proactive (для настройки пайплайнов, мониторинга и т.д.). Плюс, базовые вещи у нас автоматизированы/стандартизированы. Есть ARM темплейты, либы для логирования, и экспортеры метрик и стандартные шаблоны проектов для новых сервисов. Но так как продукт на рынке уже 9 лет, есть и легаси о котором не стоит забывать, но которое планомерно мигрирует в новую инфраструктуру (k8s)

        • VolCh
          /#21429796

          То есть разработчики все-таки довольно глубоко должны погражутся в тот же k8s? Или по желанию, но так получается что хотя бы один желающий в команде находится?

          • druss
            /#21429862

            Погружаться должны, но насколько глубоко, тут зависит от продукта, команды и внешних обстоятельств. Мне кажется что в современном мире разработки, особенно если разрабатывать распределенную систему под высокую нагрузку, просто нереально разрабатывать не зная про слой инфраструктуры на котором это все будет работать (будь то k8s, service fabric, просто клауд или даже on premise). Как ни крути, но разрабатывая фичи приходиться учитывать как и куда они будут деплоится (что бы обеспечить обратную совместимость, канареечные релизы, и т.д.) как мониторится и прочее.

            • VolCh
              /#21429906

              Ну вот как и куда — это одно дело, а вот самому писать скрипты/конфиги/рецепты/манифесты/чарты и т. п. — совсем другое.

            • rzerda
              /#21430606

              просто нереально разрабатывать не зная про слой инфраструктуры

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


              Например, можно в переписанном с нуля сервисе использовать половину от всего функционала Amazon S3, а потом с удивлением обнаружить, что в проде всю дорогу используется не «настоящий» S3, а его on-premise опенсурсная реализация, и функционал хитрее «дай мне вот этот объект» там работает из рук вон плохо. Зато как можно причитать на тему «ну как же, в документации к Amazon S3 написано, а вы, а у вас, нам тут полгода переделывать тогда, что же ваша инфраструктура такая негодная-то».

  20. leossnet
    /#21431200 / +1

    В очередной раз убедился, что если вместо нормальных русских слов люди используют англицизмы, то в результате получается обычная хренотень. Вот так выглядит статья в моем мозгу (пишу для примера первые три абзаца, кому интересно, может продолжить ряд самостоятельно):

    Тема Хренотени за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.

    Некоторые указывают в своем резюме Хренотень, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «Хренотенопсом». Это, конечно, не так.

    Несколько последних лет я занимаюсь в основном внедрением Хренотени в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — Хренотень Lead Engineer в Playgendary.
    ...

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