company_banner

Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает

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

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

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

    Трудности перевода

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

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

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

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

    Байка про хромого девопса

    Недавно нас позвали на помощь в один проект, где стояла, на первый взгляд, простая задача. Web-приложение работало через web-сокеты, но было развернуто внутри периметра, а на фронте стоял ISPManager, который в качестве reverse proxy использовал apache. Юный девопс, работавший в этом проекте, перепробовал все примеры конфига апача, которые нашел в Гугле, и вконец разочаровавшись в его поисковых способностях, перешел уже было к Яндексу, но тут менеджер проекта забил тревогу. На задачу к тому моменту было потрачено 72 часа. 72 часа, Карл! Кто вам сказал, что методология DevOps ускоряет разработку и сокращает time-to-market? ;)

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

    Согласитесь, чтобы говорить на иностранном языке, недостаточно изучить только слова. В любом языке есть еще и правила – грамматические, лексические, стилистические. Более того, основу языка составляют уважаемые буквы. Практики DevOps – своего рода тоже язык, где работает та же логика. Недостаточно просто освоить модные инструменты. Без технической и концептуальной подготовки они рискуют просто оказаться микроскопом, которым колют орехи.

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

    Про технологии

    DevOps – это про культуру и философию совместной работы, но с этим понятием также сопряжен определенный технологический стек. Скорее всего я не ошибусь, если скажу, что какие-нибудь NetApp, Cisco, AIX или MS SQL воспринимаются как старый добрый олдскул (хотя это не совсем так, и классические вендоры делают гигантские шаги в новом направлении), а вот, скажем, Docker, Ansible, Jenkins и Prometheus в нашем сознании прочно ассоциируются с DevOps, SRE и новыми веяниями. 

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

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

    И отдельная боль – это сеть. В сети надо разбираться, владеть инструментами диагностики. Сеть не зависит от платформы, она есть везде и напрямую (а порой больно) влияет на работоспособность и производительность всего остального. Когда человек, грезящий себя девопсом, наивно полагает, что надо установить свежую версию Kibana, потому что она умеет конвертировать адреса IPv6 в IPv4 – это звучит как анекдот. Но потом он, например, берет и орудует с сетью вот так:

    или вот так:

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

    А давайте-ка все распилим на микросервисы, засунем в Docker и запустим в Kubernetes

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

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

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

    Вот, кстати, символичный фрагмент одного из скриптов по деплою:

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

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

    А про кубер вспоминается недавно гулявший ролик, где старый фильм озвучили новыми словами:

    - А у вас есть kubernetes?

    - Да, конечно, ну как у всех! Как полагается.

    - А зачем?

    - Ну как это зачем? Это же…

    Дальше следует немая сцена, гримаса ужаса и спустя некоторое время человек, вероятно, идет топиться.

    Я считаю себя евангелистом подхода Infrastructure as Code (IaC).  Мне спокойно только тогда, когда продукт не просто освоен, а когда его развертывание и настройка автоматизированы. Специально не добавляю слово «документированы», потому что декларативный характер инструментов IaC – что приятно – во многом порождает автодокументируемый код.

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

    Для иллюстрации пример, который подвернулся на скорую руку – это варианты, как можно запустить телеграм-бот для Alertmanager (взято отсюда).

    Просто через docker run:

    docker run

    docker run -d \

    -e 'ALERTMANAGER_URL=http://alertmanager:9093' \

    -e 'BOLT_PATH=/data/bot.db' \

    -e 'STORE=bolt' \

    -e 'TELEGRAM_ADMIN=1234567' \

    -e 'TELEGRAM_TOKEN=XXX' \

    -v '/srv/monitoring/alertmanager-bot:/data' \

    --name alertmanager-bot \

    metalmatze/alertmanager-bot:0.4.3

    С помощью docker-compose

    docker-compose

    networks:

      alertmanager-bot: {}

    services:

      alertmanager-bot:

        command:

        - --alertmanager.url=http://localhost:9093

        - --log.level=info

        - --store=bolt

        - --bolt.path=/data/bot.db

        environment:

          TELEGRAM_ADMIN: "1234"

          TELEGRAM_TOKEN: XXXXXXX

        image: metalmatze/alertmanager-bot:0.4.3

        networks:

        - alertmanager-bot

        ports:

        - 8080:8080

        restart: always

        volumes:

        - ./data:/data

    version: "3"

    А вот тот же сервис в Kubernetes

    кубер

    apiVersion: v1

    items:

    - apiVersion: v1

      data:

        admin: MTIzNA==

        token: WFhYWFhYWA==

      kind: Secret

      metadata:

        labels:

          app.kubernetes.io/name: alertmanager-bot

        name: alertmanager-bot

        namespace: monitoring

      type: Opaque

    - apiVersion: v1

      kind: Service

      metadata:

        labels:

          app.kubernetes.io/name: alertmanager-bot

        name: alertmanager-bot

        namespace: monitoring

      spec:

        ports:

        - name: http

          port: 8080

          targetPort: 8080

        selector:

          app.kubernetes.io/name: alertmanager-bot

    - apiVersion: apps/v1

      kind: StatefulSet

      metadata:

        labels:

          app.kubernetes.io/name: alertmanager-bot

        name: alertmanager-bot

        namespace: monitoring

      spec:

        podManagementPolicy: OrderedReady

        replicas: 1

        selector:

          matchLabels:

            app.kubernetes.io/name: alertmanager-bot

        serviceName: alertmanager-bot

        template:

          metadata:

            labels:

              app.kubernetes.io/name: alertmanager-bot

            name: alertmanager-bot

            namespace: monitoring

          spec:

            containers:

            - args:

              - --alertmanager.url=http://localhost:9093

              - --log.level=info

              - --store=bolt

              - --bolt.path=/data/bot.db

              env:

              - name: TELEGRAM_ADMIN

                valueFrom:

                  secretKeyRef:

                    key: admin

                    name: alertmanager-bot

              - name: TELEGRAM_TOKEN

                valueFrom:

                  secretKeyRef:

                    key: token

                    name: alertmanager-bot

              image: metalmatze/alertmanager-bot:0.4.3

              imagePullPolicy: IfNotPresent

              name: alertmanager-bot

              ports:

              - containerPort: 8080

                name: http

              resources:

                limits:

                  cpu: 100m

                  memory: 128Mi

                requests:

                  cpu: 25m

                  memory: 64Mi

              volumeMounts:

              - mountPath: /data

                name: data

            restartPolicy: Always

            volumes:

            - name: data

              persistentVolumeClaim:

                claimName: data

        volumeClaimTemplates:

        - apiVersion: v1

          kind: PersistentVolumeClaim

          metadata:

            labels:

              app.kubernetes.io/name: alertmanager-bot

            name: alertmanager-bot

            namespace: monitoring

          spec:

            accessModes:

            - ReadWriteOnce

            resources:

              requests:

                storage: 1Gi

            storageClassName: standard

    kind: List

    Если решение все же принято, вам предстоит перелопатить горы документации, написать тонны yaml-a, мучительно искать, где пропущен отступ, по 10 раз пересобирать контейнеры. И в этом момент вы еще и не знаете, что через пару недель пройдете новый круг ада, подстраивая ваш деплоймент под Pod Security Policy и разные энтерпрайзные фичи. Конечно, когда вы это дотащите до конца, вы получите красивый сервис, который легко скейлится, автоматически перезапускается при сбоях, который можно обновлять, используя, например, канареечные релизы или какой-нибудь blue-green deployment. 

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

    Автоматизация как истинный путь джедая

    Наши бэкапшики помнят один случай, как сотрудник заказчика собирался в консоли что-то удалить – то ли ненужный симлинк, то ли копию конфига. А его то и дело дергали. По воле случая в один момент так сошлось, что товарищ успел набрать rm -rf /oradata, работая от рута, потом чихнул, что в свою очередь пробудило в его организме рута позывы на исход жидкости, а по дороге обратно он зацепился языками с товарищами. Когда он вернулся на рабочее месте, его экран спал. Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter. В общем, когда все делаешь руками, нелепые вещи случаются сплошь и рядом.

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

    Самое плохое в автоматизации – это время, которое надо на нее потратить. И самое хорошее в ней – тоже время, которое она впоследствии высвобождает. Например, пару лет назад нам потребовалось в нашем облаке IaaS развернуть инфраструктуру под нового e-commerce заказчика. Архитектура проекта: кластер БД, пул серверов приложений, распределенное хранилище, слой кэширования, сетевые балансировщики, WAF, ну и стандартная обвязка в виде телеметрии, СРК и сбора логов с визуализацией. Конечно, виртуальные машины мы давно создавали при помощи terraform, благо под наше облако можно использовать AWS-провайдер, так как мы по API совместимы. Программные компоненты и раньше ставили через ansible, и опыт настройки всего по отдельности, в общем, был. Но мы задались целью описать инфраструктуру проекта в виде единого пайплайна. На это ушло время, ну и до сих пор части этой автоматизации совершенствуются, так как еще много где были нами после переиспользованы.

    Когда нам позже подвернулся аналогичный проект, различия описывались на уровне файла ответов. Мы развернули проект за 2 дня, причем большую часть времени занял перенос данных. В Gitlab CI запускался pipeline, который заполнял переменные для terraform, который затем запускался runner-ом. Тот создавал в облаке сети, диски и ВМ. ВМ запускались с cloud-init, который ставил внутрь puppet agent, который после старта связывался с foreman, забирал настройки для своей роли и деплоил все ПО. Через service discovery подключался мониторинг всех служб, везде встал и настроился filebeat, а бакап полился в S3. Voila! Все быстро и четко, без ошибок и ручных тестов на каждом шаге.

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

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

    • осмысленный сайзинг ресурсов;

    • отдельные точки монтирования (отдельный диск/раздел) под данные приложений и все, что может быстро пухнуть;

    • синхронизацию времени по ntp;

    • переход на использование ключей вместо паролей в ssh;

    • настроить ротацию всех логов;

    • иметь автоматический механизм обновления протухающих SSL-сертификатов

    • покрыть мониторингом все ключевые показатели жизнеспособности системы и не забыть про алерты;

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

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

    Эти простые меры – по принципу Парето – составляют не более 20% действий по первичной настройке, но дают 80% вклада в стабильную и автономную их работу в будущем.

    Если у вас уже есть provision-система, то следом можно подключить инструмент IaC, и накатывать все эти настройки всегда по умолчанию, через какой-нибудь базовый профиль. Я в такой профиль еще включаю набор обязательных утилит, чтобы, к примеру, в экстренной ситуации не оказалось, что в системе нет lsof, tcpdump и т. п.

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

    Как не стать героем баек

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

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

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

    И напоследок – завет работодателям

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

    Если вам понадобился девопс, у вас вероятно уже есть разработка. Задачи, которые выполняет девопс – это та же разработка, только инфраструктуры и процессов, поэтому к ней в целом применимы те же правила. Над девопсом должен быть senior или тимлид, который через систему контроля версий делает code review, проверяет и одобряет PR/MR. И совершенно точно не стоит доверять архитектурные вопросы человеку без подтвержденного архитектурного опыта. Лучше поищите стороннюю экспертизу для подстраховки.

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

    В этом месте ставлю не точку, а многоточие, так как тема неисчерпаемая и весьма холиварная. Комментарии, как говорится, покажут.

    КРОК
    IT-компания

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

      +4
      бэкапшики
      Оговорочка по Фрейду, не убирайте пожалуйста)
        +1
        Раньше было: Хуяк-хуяк и в продакшн.
        Теперь: Хуяк-хуяк и в контейнер.
          –2

          И это называется красивым термином "Continuous integration"

          0
          — У нас БД упала! Где бэкапшик?
          — Уволился.
          0

          Жыза.

            0

            "Задачи, которые выполняет девопс – это та же разработка, только инфраструктуры и процессов".


            Ну как и следует из названия — "DEVeloper OPerationS". Во всех индустриях роль operations вполне себе определена (как и остальных бизнес-функций), а в IT до сих пор жаркие споры и непонятки. :-)

              0
              А откуда вы взяли такое название? в wikipedia немного по другому…
              И с operations все просто en.wikipedia.org/wiki/Data_center_management#Operations. Боюсь, что непонятки исключительно на великом и могучем.
                +1

                Ну вот же: https://en.wikipedia.org/wiki/DevOps
                Первая строчка.

                  +1
                  >DevOps is a set of practices that combines software development (Dev) and IT operations (Ops).
                  DevOps это набор технологий которые обьеденяют разработку програмного обеспечения и системное администрирование.
                  Если вернуться к истокам и просмотреть первую презентацию с употреблением слова DevOps, то можна услышать что автор презентации рассказывает о шаблоне — когда разаработчики пишут код, который сдают на определенном этапе готовности админам. Что создает много проблем. Методология DevOps предполагает активное участвие админов на более раннем этапе разработки — еще во время проектирования и тд тп
                    0

                    Не технологий, а практик. Практики не только и не столько в технологиях заключаются.

              0
              Для иллюстрации пример, который подвернулся на скорую руку

              Плохой пример. docker и compose примитивные, а в кубер манифесте намутили все подряд — секреты, лимиты, политики все подряд, pvc. Ну вот совсем разные.

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

                Он не просто длиннее будет из-за kind, apiVersion и прочих spec, но и содержать больше сущностей в принципе.


                А эквивалентно или нет — это от точки зрения зависит. Кто-то считает, по определению не может быть эквивалентно, потому что если нода упадёт, то контейнер переедет в кубере и сдохнет в докере (забывая, впрочем, об однонодовых сетапах кубера и многонодовых, понимающих compose ), а для кого-то эквивалентность означает, прежде всего, возможность увидеть свой hello world в браузере и пофиг на HA, автомасштабирование и прочую безопасность.

                0
                Скажите, я правильно понял, что devops-разработчик — это просто переименованный админ? Ведь концепция DevOps (в идеале) состоит в том, чтобы слить команды разработки и эксплуатации
                  0

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

                    +1

                    Почему админ, а не разработчик? )

                      –1
                      потому что ты администрируешь инфраструктуру по прежнему, только теперь через код
                        +1

                        А код пишут разработчики обычно...

                          –1
                          отчасти поэтому в слове devops есть «dev» :-) но строго говоря devops это все же в основном эксплуатация, мы же не будем взаправду называть плейбуки и манифесты настоящим исполняемым кодом?
                            +2

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

                            0
                            А код пишут разработчики обычно
                            ну вот например научным сотрудникам некоторых областей тоже приходится писать код на питоне, но они не перестают быть учеными и не становятся программистами от этого. А с еще более другой стороны — devops стал должностью во многих компаниях, и должность эта — сис.админская, но начинался devops как набор практик, как подход к выполнению работы.
                          0
                          Я так понял, что идея DevOps в том, что бы избавится от отдельных админов вообще. То есть, сами разработали, сами и эксплуатируем. В такой ситуации наличие devops-разработчика — это нонсенс. Соответственно, там где он есть — это просто админ, переименованный по-модному.
                            0

                            И "админ, переименованный по-модному" сможет создать csi к8с оператора?! Со всеми необходимыми процесамми для разработки и поддержки? Или это задача для девелоперов?

                              0
                              А как это зависит от названия должности? Вопрос же не в названии, а в том, есть ли отдельная команда эксплуатации/развёртывания, или это делают те же самые люди, что и разрабатывают продукт. В последнем случае — это методология devops.
                                +1

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

                              +4
                              Так то оно так, но тут есть некоторый неочевидный эм, изъян.
                              Современная эксплуатация, если говорить за решения хотя бы среднего размера, по сложности освоения и обширности необходимых знаний весьма велика и весомо так превосходит объем знаний об этой области линейного программиста. И даже не особо линейного. И, возможно, она вообще по объему больше, чем обычный frontend/backend программист знает в рамках обязанностей по созданию продуктов.
                              Отсюда появляется специализация. Очень сложно хорошо знать две хоть и смежные, но очень объемные и разные области.
                              И эта самая специализация и приводит нас к тому, что «devops-разработчик» внезапно появляется в команде, потому что хоть кто-то должен обладать полнотой знаний в области «как заставить это правильно работать в рамках инфраструктуры». Люди, которые могут и продукт хороший написать, и качественно его поддерживать конечно существуют, но их 1. мало, 2. они стоят ну очень много денег и как следствие нанимаются каким-нибудь гуглом на позицию SRE, о которой ниже.
                              Есть еще вариант купить экспертизу на стороне, но проблемы как таковой это не решает.
                              Кстати Google эту проблему компетенций осознал весьма давно и вместо внедрения DevOps придумал структуры работы, где появляется позиция SRE, на которую нанимаются те редкие люди, которые неплохо понимают и в программирование как таковое, в рамках создания продукта, и в эксплуатацию этих продуктов. Вкупе с жесткими правилами и условиями попадания продукта в прод это в целом позволяет им неплохо и стабильно работать. Что конечно не исключает наличия больших выделенных команд, которые занимаются более специализированными вещами — сервера, сети, базы, автоматизация и вот это все.
                              То есть нет, devops — это далеко не классический админ, его область ответственности и знаний гораздо шире. DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. Ни у кого же не вызывает удивление, что frontend/backend/mobile/embedded программисты имеют специализацию, так почему не может быть еще одной, с фокусом на интеграцию и эксплуатацию?
                              Более того, эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
                            +1
                            Нет, вы неправильно поняли. Devops-разработчик это разработчик который внедряет DevOps практики или методологии при разработке приложения.
                            Devops Developer есть в линкедине с обьяснением, что это такое.
                            +3
                            Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter.

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

                              0
                              Я обычно чёрного властелина ставлю.
                              Но все-таки не скринсевйер с паролем а таки «попу поднял win+L нажал». Скринсейвер слишком легко обойти.
                                +2
                                Или просто завести привычку пробуждать по ctrl например (даже удобно — кнопка в углу), ну или alt ;)
                                +1

                                Самая типичная ошибка — называть людей девопсами

                                  0
                                  С автором абсолютно согласен. Замечательная статья, и есть над чем под размыслить. Очень хорошие и жизненные примеры по описанию работы DevOps. От себя так же скажу, что для полноценного разворачивания DevOps в компании, требуется хорошая команда. И как минимум не с одним специалистом в каждой отрасли.
                                    +4

                                    Девопс это человек, программирующий на ямле

                                      0
                                      товарищ решительно разбудил его точным ударом в Enter

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

                                        +2
                                        Как раз опасения подобных факапов бужу экран чем-то более «noop», к примеру, Ctrl или Shift, а вот Esc может и чего-то отменить лишний раз :)
                                        0
                                        Читается, как «подгорело от того что приходят новенькие и в случае проблем и поиска их решений, все остается на месте». Все что написано так и есть, также как есть запуск контейнеров, которые перед тем как запустится выполняют ряд предварительных ласк и не факт что запустится. Есть проблема — бери и делай, называй инженера хоть Сьюзана, хоть DevOps главное достойная оплата ожиданиям кандидата и такие же ожидания от работодателя. В случае если всех все устраивает, то радуемся. Если какую то из сторон не особо, то мы знаем где находится выход.
                                        Всем удачи!!! Как и компаниям, которые оказывают услуги аутсорсинга.
                                          0

                                          А где должна быть граница между обязанностями девопса и дева? Есть крайние точки зрения, от "девы пишут код, а за попытки лезть в IaaC нужно бить по рукам” до “девопс обеспечивает инфраструктуру для разворачивания приложений (грубо, кубер и гитлаб), а всё остальное (манифесты, чарты, пайплайны ) делают девы, а девопс не знает и не должен знать даже какие приложения крутятся там, этакое внутреннее managed IaaS решение. Понятно, что это крайности, но где разумный компромисс?

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

                                              PS. Я правильно понимаю, что DevOps это как клапана без гидрокомпенсаторов, в перманентно не настроенном состоянии? :)
                                                –1
                                                по хорошему в айти все должны быть в таком состоянии, иначе не будет никакого развития
                                                +1

                                                Первый абзац раздела "Байка про хромого девопса" — так и не понятно, какая была задача.

                                                  0

                                                  А зачем? Тут же в концовке все поясняют…
                                                  "Лучше поищите стороннюю экспертизу для подстраховки."

                                                  0

                                                  А арт-директора из вступления не Андреем звали?;)

                                                    +1

                                                    Я так понимаю посыл статьи: "девопс сложно, там ни кто ни чего не понимает — приходите к нам"?
                                                    Или все же про бизнес который требует от бекенд разрабов еще и деплоем заниматься, не позаботившись спросить об опыте и желании? Ну и за одно приглядеть за сервером, чтоб 2 раза не вставать… Если человек уволился, это явно не от радости.
                                                    Про сеть замачено правильно, предмет сложный и потому нередко их разделяют, например на продопс и нетопс, потому винить девопс за то что на них повесили все… притянуто за уши.
                                                    В сухом остатке статью можно изтолковать так: Приходите к нам, заплатите в "5 раз больше" и будете это делать постоянно, за то не надо будет разбираться как управлять ит.
                                                    И в этом нет ни чего плохого, с покупкой бу или нового авто ситуация аналогичная.

                                                      0
                                                      Ну аутсорсинг имеет смысл на мой взгляд. Например небольшая продактовая компания вышла на большого заказчика. Потом оказалось, что у них очень много ботлнеков и на обьеме данных заказчика ничего не работает. Заказчику концептуальная идея продукта понравилась и он согласился на доработку. После 2х лет вливания денег и нулевых результатов большой заказчик обратился к аутсорсерам. Он получил код продукта, кое какую документацию и уныло работающий продакшен в амазоне.
                                                      Я пропущу детали и остановлюсь на «devops» решении анализа логов. Традиционный ELK сжигал примерно 70% сетевого трафика, на минимальном датасете (20% от максимального) терял до 40% логов.
                                                      Примерно лет 15 назал linkedin ввел понятие application monitoring'a. Например в ELK мы посылаем около 500 разных строк лога, которые ELK нам парсит, классифицирует и токенизирует. В результате — таймстемп + текст + 2-3 цифры на строку лога. Текст не меняется. Инновация в том, что бы вместо 800 байт строки лога отсылать упомянутые 2-3 цифры. Мы очень много экономим на трафике и обработке. Красивые маркетинговые ролики можно посмотреть на сайте AppDynamics и разных других аналогах.
                                                      Но для такого подхода вместо строки в лог нужно проектировать саму систему логирования. Срабатывает стереотип — они усложняют — мы сделаем проще… но проще не работает.
                                                      Подведя итог — методологии у крупного аутсорсера несколько другого уровня чем у среднестатического «девопса».
                                                      0
                                                      от программистов микроконтроллеров до арт-директора, который после 40 вдруг узрел новое призвание. Был даже студент-африканец, который едва говорил по-русски, но уже сделал головокружительную карьеру ростовой куклы, распугивающей пассажиров у выхода из метро.

                                                      Эхх ничего не меняется.
                                                      Это было в начале 2000-х каждый кулик кто занимался перепродажей компов и принтеров мнил себя аутсорсером и супер-мега интегратором.
                                                      Это было с печатной техникой. Каждый мнил себя инженером в печатном и допечатном оборудовании. Был живым свидетелем как товарищи сломали А0 и как на демо-образцах садились на проекционное стекло.
                                                      Это было когда зарождалась мода на ЕРП и прочее внедренчество. Каждый кулик мнил себя гуру ит-консалтинга.
                                                      Это было в начале второго десятилетия. Каждый кулик мнил себя если уж не офицером по безопасности, то как внедренец с многолетним опытом.

                                                        0

                                                        Хорошая, злободневная статья.
                                                        Касательно автоматизации есть хороший комикс от xkcd, по которому легко понять — нужно ли ею заниматься, или проще закидать людьми (дешевле будет):
                                                        https://xkcd.com/1205/

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

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