company_banner

Как попасть в DevOps, как учиться и что читать

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

    • Каково главное преимущество DevOps подхода, на твой взгляд?
    • Что больше всего может помешать компании в DevOps трансформации?
    • Как интегрировать специалистов по безопасности в процесс поставки ПО?
    • Как относишься к поднимающемуся хайпу вокруг SRE?
    • Какие инструменты сегодня непременно есть там, где говорят о DevOps?
    • Что отличает хорошего инженера от плохого с точки зрения DevOps?
    • Как логичнее всего попасть в профессию?
    • Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?

    Ответы получились очень любопытными и заодно позволяют составить некоторое впечатление о тех, кто вложил много усилий и немножко души в расписание нашей конференции. Например, ответ на первый вопрос шире, чем сокращение time-to-market. Мнения по поводу SRE разошлись, зато все практически единодушно советуют читать «The DevOps Handbook», но и еще надавали кучу рекомендаций — за ними под кат.


    Данила Штань
    Данила Штань CTO в Яндекс.Вертикалях, пропагандирует DevOps, ценит soft-skills выше профессиональных навыков и любит поговорить. Вот, например, в прошлом году на еще тогда RootConf, Данила рассказывал, как построить самоорганизующуюся сервисную инфраструктуру, обходясь довольно простыми техническими решениями, популярными программными продуктами и соглашениями внутри команды.


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

    — Что больше всего может помешать компании в DevOps трансформации?
    «Я не буду делать чужую работу». Вообще деление работы на «свою» и «чужую».

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

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    А он только поднимается? Мне казалось, что он давно тут. SRE — это glorified ops, мне эта концепция не очень нравится.

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?
    Клавиатура, экран и наушники :)

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?
    Желание быть самым лучшим в мире специалистом по гайкам на 8.

    — Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
    Логичнее всего любить то, что делаешь, а там всё срастётся. Я вообще из проджектов.

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Люблю подборки на highscalability.com, форумы на Reddit и engineering blogs разных больших и маленьких компаний.

    Вячеслав Кузнецов
    Вячеслав Кузнецов возглавляет команду IT Operations в Ecwid с ранних лет жизни проекта. Один из организаторов онлайн встреч сообщества Hangops_ru.


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

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

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

    — Как интегрировать специалистов по безопасности в процесс поставки ПО?
    Безопасник должен быть вовлечен в разработку на как можно более ранних этапах. При этом нужно вести диалог и строить процессы таким образом, чтобы инструменты безопасности были таким же естественным этапом, как linter или code review.

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    На мой взгляд, SRE — это всего лишь реализация DevOps-практик и немного сверху. SRE book by Google является отличным собранием практик. Их хорошо знать для расширения кругозора, но не все из них нужны в каждой компании.

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?
    Чаты, CI/CD, K8S.

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

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

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Есть несколько хороших книг, которые раскрывают суть DevOps:

    • The DevOps Handbook.
    • Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему.

    Кроме этого, мне понравилась книга «Kanban: Successful Evolutionary Change for Your Technology Business» от David J. Anderson.

    Для того, чтобы быть в курсе новостей индустрии есть куча отличных рассылок и каналов в Telegram: Devops Weekly от Gareth Rushgrove, Devops Deflope (подкаст и канал в Telegram), Hangops Ru. Но самые отборные новости индустрии прилетают ко мне в Twitter. Главное — фолловить правильных людей

    Дмитрий Зайцев
    Дмитрий Зайцев работает SRE в Humaniq, но имеет опыт в самых разных индустриях: Gamedev, AdTech, Big Data, FinTech. Развивал DevOps и SRE-практики тогда, когда это ещё не было модным. Совмещал их с ITIL и Cobit, пока они ещё были в моде. Кроме того, участвует в организации встреч Hangops_ru.


    — Каково главное преимущество DevOps подхода, на твой взгляд?
    Скорость изменений продукта и бизнеса, высокая адаптивность в быстро меняющемся мире.

    — Что больше всего может помешать компании в DevOps трансформации?
    Отсутствие необходимости трансформироваться.

    — Как интегрировать специалистов по безопасности в процесс поставки ПО?
    Также, как и специалистов по эксплуатации — смещать их работу как можно левее по цепочке доставки ценности.

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

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?

    • Kubernetes.
    • Prometheus.
    • Terraform.

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?

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

    — Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
    Устроится работать в компанию, у которой есть цифровой продукт. Я сам начинал офисным админом, потом Linux, Gamedev, разработка и снова эксплуатация.

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Рекомендую прочитать:

    • Серию книг The Visible Ops, книгу «The DevOps Handbook».
    • «Google SRE Book», как набор хороших сисадминских практик.
    • «Continuous Delivery» Джеза Хамбла и Девида Фарли, как книгу с ответами о CD.
    • «Сердце перемен» от братьев Хизов, как руководство по изменению людей.

    Еще могу посоветовать сообщество Hangops и его русский бранч Hangops_ru — как способ попробовать индустрию на вкус. Лично я его читаю, потому что там обычно обсуждают самые значимые новости, и поглядываю в разные рассылки типа devops/sre/k8s weekly.

    Валерия Пилия
    Валерия Пилия работает в Deutsche bank на должности Infrastructure Engineer. Занимается автоматизацией деплоев и поддержкой продуктовых команд. До этого работала в Video International, в Мегафоне и OneFactor инженером эксплуатации, поддерживала и развивала платформы на базе Hadoop ecosystem.


    — Каково главное преимущество DevOps подхода, на твой взгляд?
    Сокращение time to market и бОльшая сопричастность всех к результату.

    — Что больше всего может помешать компании в DevOps трансформации?
    Инертность.

    — Как интегрировать специалистов по безопасности в процесс поставки ПО?
    Воспользоваться идеей Security Champions.

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    Я за любой кипеж без драк, который даёт пищу для размышлений вокруг профессиональных практик и их применения в твоей конкретной компании.

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?

    • Любая version control system.
    • Любой software configuration management.
    • Любое нечто для continuous integration/continuous delivery.

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?
    Умение увидеть узкое место в процессе и исправить его.

    — Как логичнее всего попасть в профессию? Ты вышла из Dev или Ops?
    Я из Ops. Мне кажется, что и из тестировщиков можно попасть, было бы желание.

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Классное обсуждение книг было в Hangops_ru, я лучше, чем там, не скажу. Плюс можно посоветовать книги Нассима Талеба и The DevOps Handbook.

    Новости отрасли я читаю в канале Devops Deflope.

    Михаил Чинков
    Михаил Чинков — Infrastructure Engineer в компании AMBOSS. А также евангелист культуры DevOps и участник сообщества Hangops_ru.


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

    — Что больше всего может помешать компании в DevOps трансформации?
    Вероятно, популярным ответом будет инертность менеджмента или исполнителей. Я же назову монополизацию рынка.

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

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

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    Точно так же, как и к любой штуке, которая попадает в известный Tech Hype Cycle. Скоро люди начнут понимать, что такое SRE на самом деле, заставки/позиции в компаниях будут вымирать и в конечном итоге Site Reliability Engineering останется только в тех компаниях, где это действительно нужно.

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

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?
    Важно разделять «говорят» и «делают». В большинстве компаний о DevOps говорят на протяжении нескольких лет, а воз и ныне там.

    Там, где действительно люди стараются внедрить практики, есть: Public Cloud (чаще всего AWS), Kubernetes и Terraform. Остальные слагаемые меняются в зависимости от ситуации.

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?
    Готовность к разделению ответственности за продукт, бизнес-центричность (человек не делает то, что не повышает business value), готовность проявить инициативу (например, стремление улучшить техническую сторону продукта вместо того, чтобы смириться с плохим и принимать как данность), интерес к обратной связи со стороны клиентов, как внутренних, так и внешних.

    — Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
    Мне кажется, что сейчас профессия драйвить DevOps в компаниях, как бы ее не называли, переросла в отдельную предметную область, и логичнее всего учиться сразу тем вещам, которые требуются в компаниях: облака, мониторинг, delivery pipeline и так далее. Coding skill приходит сам в объеме, ровно необходимом для выживания.

    Сам я вышел из админской комнаты родного Пензенского университета, даже не успев вкурить VLAN-ы и особенности поддержки iSCSI-storage, так что мой пример не самый лучший :)

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Статьи лучше всего брать из рассылок DevOpsLinks, WebOps Weekly. Corey Quinn делает классную рассылку по AWS.

    Из книг must-read это:

    1. The DevOps Handbook.
    2. Infrastructure As Code: Managing Services in the Cloud.
    3. «Web Operations» от john Allspaw.
    4. «Unix и Linux. Руководство системного администратора» даже если слово админ для вас это «фи».
    5. «Continuous Delivery» Джеза Хамбла и Девида Фарли.
    6. Топ-книга по языку программирования, который вы выберете для кодинга инфраструктуры.


    Андрей Шорин
    Андрей Шорин запускает взаимодействие людей там, где об этом раньше не думали. Везде видит возможности для изменений и любит их осуществлять. Гордится результатами работы в эксплуатации hh.ru (2011-2017).


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

    — Что больше всего может помешать компании в DevOps трансформации?
    Назначение виноватых. Разборы полётов с наказанием.

    — Как интегрировать специалистов по безопасности в процесс поставки ПО?
    Так же, как и DBA. Предложить им давать рекомендации и ставить задачи в backlog, отказавшись от права блокировать релиз. Это не будет просто.

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    Я хорошо отношусь к идее и практике SRE. Хайп служит тому, чтобы больше людей узнали о её существовании. Люблю, когда команда вникает в суть, и видит за деревьями хайпа лес.

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?

    • Мониторинг не только состояния серверов, но и здоровья каждого функционального блока продукта. Мой любимый — okmeter.
    • Code review. Важен не столько инструмент, сколько выстроенный маршрут работы над задачами.
    • Continuous integration — каждая команда выбирает конкретный инструмент под свой способ работы.

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?
    Желание делать свою работу для пользователя в постоянном сотрудничестве с коллегами.

    — Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
    Интересоваться не только алгоритмами и кодом, но и содержанием продукта, его значением для пользователя. Я перешёл на сторону DevOps из Operations, потому что через этот подход ИТ-мир становится лучше.

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

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

    Виталий Рыбников
    Виталий Рыбников помогает продуктовым командам внедрять DevOps и SRE подходы и практики. Работает SRE Тинькофф Банк.


    — Каково главное преимущество DevOps подхода, на твой взгляд?
    Непрерывное улучшение качества продукта.

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

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

    — Как относишься к поднимающемуся хайпу вокруг SRE?
    Так это ж… я его и поднимаю :) Приходите к нам на митапы DevOps Moscow и на DevOpsConf, обсудим ;-Ъ

    — Какие инструменты сегодня непременно есть там, где говорят о DevOps?

    • Git;
    • Ansible;
    • Prometheus.

    — Что отличает хорошего инженера от плохого с точки зрения DevOps?
    То, как они относятся к своему master и как комитят в него.

    — Как логичнее всего попасть в профессию? Ты сам вышел из Dev или Ops?
    Я думаю, что логичнее всего попасть из Dev, и сам я тоже вышел из Dev. И разработчиков лучше понимаешь, и уверен, что нет ничего невозможного.

    — Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?
    Учиться хорошо на личном опыте и практике. Стажировка или курсы тоже могут быть полезны.

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

    DevOpsConf Russia уже 1 и 2 октября. Приходите в Инфопространство, там соберется 500 классных специалистов по интеграции всего и вся, вместе мы решим любые проблемы.
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Comments 17

      +2
      К указанному списку баззвордов следует добавить, кмк, Ansible (Tower) и Puppet.
        +3
        Че-то почитал ответы, и выглядит все как «золотая пуля» по скорости, но по остальным пунктам, как DevOps ради DevOps. И очень мало про качество. Не хватает живых примеров, что было вот так, а сделали вот так и столько-то ресурсов получили дополнительно, избавились от таких-то проблем и получили такой-то профит от стать «мастером на все руки». Может кто дополнит, а то не совсем понятно, зачем выходить из зоны комфорта, если привык к разделению труда?
          +4
          Из всех опрошенных в части инструментов двое назвали «любая штука для вот такой задачи» (хорошо, трое, потому что шутка про клавиатуру к месту), а трое упомянули k8s как признак DevOps. И вообще, весь этот горький карго-культ, который я тут наблюдаю…

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

          Вместо этого началось:
          — вам пора и нам пора запускать контейнера, обращайтесь на гугловый расчудесный Kubernetes;
          — я разработчик и не хочу разбираться в вашей инфраструктуре, я хочу писать код, вот вам коммиты в ветках, дальше оно само, я пошёл;
          — давайте напилим микросервисов, а когда станем погибать под сложностью связей между ними — ещё service mesh добавим, сеть же всегда хорошо работает.
            +1

            Показательно, что большинство из интервьюированных «пришло в DevOps» из Ops, а единственный SRE — из Dev. Вместо идеи объединения ролей и компетенций он стал обозначать просто хорошего application-админа.

            +1
            После прочтения статьи, для меня, ответ на поставленный в заголовке вопрос не был толком дан. Так дейстивтельно все-таки как попасть в DevOps, как учиться и что читать?
              +2
              Да, меня тоже заголовок в заблуждение ввел. Я думал в статье будет прям точно расписано (читайте такие вот книги, изучайте такие технологии).
              –2

              DevOps — это те, которые няньки для программистов?

                –1
                Это те люди, которые обеспечивают работу того, что наговнокодили программисты.

                P.S. В каждой шутке есть доля…
                +1
                Ответственность не за свою гайку на 8, а за то, чтобы две детали, скрепленные болтом, держались вместе.

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

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

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

                  — Что больше всего может помешать компании в DevOps трансформации?
                  «Я не буду делать чужую работу». Вообще деление работы на «свою» и «чужую».

                  Золотые слова!
                    –2

                    А платят вам все таки за Вашу работу.


                    Любые новые инструменты и методики хорошо оплачиваются пока остаются непонятными. Из моего опыта в нескольких компаниях девопсами становились сисадмины. Выучил пару новых инструментов (вот проблема то), поменял резюме и получил прибавку к ЗП. Щас же девопсы это люди у которым бегут все, когда не знают куда бежать. И эта роль отобрана у тимлидов, которым теперь наверно проще, нет? Короче девопс == бардак. Сам "девопс" если что.

                      +1
                      > А платят вам все таки за Вашу работу.

                      За работу. А не за деление на свою и чужую.

                      > Сам «девопс» если что.

                      Оно и видно.
                        0
                        Платят мне за работу сделанную мной, а не за мою работу. Если я могу что-то сделать лучше и это принесет пользу, я должен это сделать.
                        0
                        > Золотые слова!

                        Спасибо :)
                        +2
                        Только один респондент указал мониторинг как часть DevOps, а ведь это один из важнейших факторов. Ведь нужно не просто быстро доставлять, но и быстро получать релевантную обратную связь, это и дает пресловутую гибкость DevOps.
                          0
                          Валерия релевантная. Остальные плюс-минус.

                          Only users with full accounts can post comments. Log in, please.