Ценность DevOps-культуры в 2020-х  Публичный пост

Вот смотрите, есть некий DevOps, без которого ни одна техкомпания не может жить.

Что такое DevOps? В официальных интерпретациях это культура, охватывающая набор практик для ускорения цикла разработки – про SDLC, TTM и прочие акронимы. Грубо говоря, пилить софт быстрее, и чтобы он ломался медленнее.

Зачем нужен был DevOps? После всех прочитанных книг о DevOps создается впечатление, что это в первую очередь про "нормально делай – нормально будет". Судя по истории создания, движуха ведет отсчет с конца нулевых, когда кусок разработки уже мог в Agile, а кусок эксплуатации в общем конвеере все еще подвисал. То есть, DevOps затевался для ускорения поставки софта за счет ускорения админских вещей и более близкой коллаборации с админов с разрабами. Отчасти это было еще и про взаимозаменяемость: админ в целом знает, как работает код, разраб знает как работает инфраструктура и что может пойти не так.

Чего добилась индустрия с DevOps?.

  • Софт стали деплоить чаще и чище, это правда.

  • За последние 10 лет появилось неимоверное количество тулкита, решающее те или иные проблемы с CI/CD и автоматизацией инфраструктуры. Даже не про деплои, вот смотришь на тот же Zabbix со стороны Prometheus и больше не хочешь запевать шарманку про "Good Old Days"

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

С учетом того, что слово DevOps встречалось в каждом клочке такого прогресса, можно считать, что прогресс был вызван запросом – а запрос в свою очередь был вызван движением community.

Чего не добилась индустрия с DevOps?.

  • Инфраструктура не стала проще, она стала еще сложнее. Одно время был хайп на инфраструктуру по одной кнопке, как в Heroku, но на деле все это кануло в лету. AWS, Kubernetes, Prometheus, Terraform, Chef/Ansible: все эти инструменты требуют отдельного фулл-тайм специалиста, хотя задумывались, как элементы доступной инфраструктуры для разработчиков.

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

  • Культ карго, отпугивающий адекватный контингент. Зашедший в индустрию в виде чистого холста, на DevOps успели порисовать бюрократы со своими сертификациями; рекрутеры с тайтлом DevOps Engineer (усложняя попытки объяснить чем на деле является DevOps); хайпожоры, пытающиеся за счет имени движения продвинуть свой новый PaaS.

Что говорят о DevOps сейчас?

Перед заходом со своими вопросами в клуб я погулял по Hacker News и нашел множество отличных комментариев. Конкретики в текущее состояние DevOps они, правда, все равно не добавляют.

DevOps is a valuable role, and I'm glad there's a focus on supporting developers and their needs, and in empowering developers to manage their own build and deployment infrastructure. In a larger organization, having a dedicated person or team working closely with developers on software build, test, and deployment automation is great. [link]

DevOps is a movement. There’s no certificate, role, set of tools or prescriptive process. There’s no specification, it’s not a product, or job title. There’s no one true voice on what DevOps is or isn’t. It’s about attitude, ideas, customs and behaviors. Culture, paradigms and philosophy. It’s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It’s a conversation. It’s about taking the best experiences and sharing those with others.

DevOps as an ideal is founded on the concept that there exists a set of people who want to be evenly responsible for both the development and the operations. I have not so far met more than one or two of these people, certainly not enough to staff a company with. Barring such miraculous hiring, viewing DevOps as getting your development people and operations people to work effectively together is just fine. [link]

Исходя из этой картины, у меня сегодня складывается субъективное впечатление стагнации и пессимизма (того самого, технологического). Некоторые задачи были решены в индустрии 3-5 лет назад, некоторые не решаются до сих пор, и прогресса в них не видится никакого.

Поэтому у меня к вам следующие вопросы:

  1. Какие проблемы остались в индустрии, которые может охватить scope DevOps-движухи?
  2. Релевантен ли сейчас вообще топик "DevOps как культура" в наши дни? Не настало ли еще время заменить его другим сводом практик?
  3. От кого должна исходить инициатива, когда мы говорим про внедрение практик? Это больше про технический менеджмент или про непосредственно самих DevOps-инженеров?
  4. В чем основная проблема реализации практик DevOps в вашей компании? Это про нехватку времени на реализацию? Квалификацию инженеров? Неявные результаты?
11 комментариев 👇

Инструментам и тулкитам надо повзрослеть, но это вряд ли случится, пока крупные игроки не наметят какой-то общий вектор развития, а не будут тянуть каждый одеяло на себя, как это происходит сейчас в AWS/GCP/Azure.

Ядро Linux очень сложное, но это инструмент, который кое-как подбит под общий знаменатель, уже является взрослым, никто не ожидает каких-то groundbreaking changes. Кубер же, Terraform, helm и прочие из набора повседневных средств SRE достаточно молоды, нестабильны и фрагментированны. Если на ядре 4.x ты хоть сейчас вполне можешь содержать живой и взрослый продакшн, то с последними достаточно уйти в отпуск чтобы всё сломалось.

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

  Развернуть 1 комментарий

@rcmd, знакомая ситуация – возможно, стагнация это как раз то, что нужно для закрепления DevOps в компаниях для стабилизации кодобаз разных зависимостей

как у Linux был milestone в версии 2.6, после которого душа уже ни о чем не болит, так и здесь надо подождать Kubernetes 2.0 и Terraform 1.x

  Развернуть 1 комментарий

В нашем отделении больницы по аутсорсной разработе такая ситуация наблюдается:

  • среднестатистический клиент хочет всё ops держать у себя — свои люди, своя инфра, свои процессы и тулзы; при этом специалисты клиента не умеют в код особенно и это сейчас главный ботлнек;
  • как только у тебя появляется IaaS и публичные облака, так сразу же приходится забыть о подходе "Девопс" и вернуться к роли "Девопс": ты либо нанимаешь специального человека в команду, кто любимт это дело, кто умеет в конкретное облако и конкретные инструменты, либо внутри команды один из разработчиков перестаёт писать код для фич и вместо этого начинает писать код для инфры и заниматься тулингом;
  • с разработкой и управлением CI/CD пайплайном отлично справляются все разработчики, а благодаря развитию визуального инструментария даже тестировщики и менеджеры;
  • но при этом стоит CI/CD "остыть", как оно всё — глохнет и больше не заводится; это парадоксальная ситуация: вроде бы нет у тебя никаких терраформов, у тебя один Azure DevOps, Octopus Deploy, Azure Cloud и пара локальных серверов — но стоит тебе пропустить один запланированный деплой, как в следующий раз вместо 15 минут ты будешь деплоить 4 часа, причём в режиме шаринга экрана и объединив 4 пары глаз, чтобы найти что же могло поменяться.
  Развернуть 1 комментарий

@zahhar, спасибо за вводную 👍 отчасти напоминает мой заход в аутсорс к ops на стороне клиента и затупами в CI

  Развернуть 1 комментарий

Зачем нужен был DevOps?

Для решения текущих проблем бизнеса.

С учетом того, что слово DevOps встречалось в каждом клочке такого прогресса, можно считать, что прогресс был вызван запросом – а запрос в свою очередь был вызван движением community.

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

Инфраструктура не стала проще, она стала еще сложнее

Инфраструктура стала проще, но для тех кто ей пользуется - self-service это ведь мантра DevOps.

Хотя и для тех кто ей управляет - тоже. Та же облачная инфраструктура - теперь (в общем случае, с некоторыми исключениями) чтобы замасштабировать или развернуть с нуля инфраструктуру под новый проект или рынок, не нужно планировать и выделять огромный бюджет, арендовать новые площади в дата центрах, закупать серверное и сетевое оборудование, отправлять в дата центр на несколько суток спецназ из сисадминов пережимать патч-корды и проводить первоначальную настройку этого всего. Теперь достаточно создать тикет в Джире для команды из нескольких человек, которая за пару спринтов развернет это все с помощью Terraform, Packer, Ansible и AWS/GCP/Azure без отрыва от своих основных задач.

Исходя из этой картины, у меня сегодня складывается субъективное впечатление стагнации и пессимизма

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

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

  Развернуть 1 комментарий

@Mykola, очень хороший ответ, который я полностью разделяю. Мой вопрос: что дальше? Есть еще проблемы, которые DevOps может таким же торжественным образом победить? Или можно уже скакать по (онлайн-) конференциям, покрикивая о смерти DevOps?

Могу также поделиться докладом одного из основателей движухи, он тоже делится наболевшим

  Развернуть 1 комментарий
Петя Сергеев, технический человек 12 апреля в 14:11

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

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

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

  Развернуть 1 комментарий

@ifeya, мой опыт работы в "стартапе" лишь подтверждает описанную тобой ситуацию :)

  Развернуть 1 комментарий
Magistr, Пасу котов, системно архитектю, стратегически планирую, жму на кнопку фотоаппарата 12 апреля в 21:55

Задам наводящий вопрос, а что такое культура ?
(а потом приду и за проповедаю свое мнение и видение)

  Развернуть 1 комментарий

@Magistr, Культура – это телеканал с познавательными передачами из моего детства.

Отвечать вопросом на вопрос такое себе. Лучше переходи сразу к делу :)

  Развернуть 1 комментарий
Magistr, Пасу котов, системно архитектю, стратегически планирую, жму на кнопку фотоаппарата 28 апреля в 16:26

Так вот, культура это такое интересное явление которое можно начинать изучать когда прошло какое-то время, хотя-бы лет 10.
А до этого времени там слишком много всего лишнего и важные аспекты не выделены. Поэтому в 21м году можно обсуждать культуру сисадминства, а вот devops как-то еще рано.

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

Есть мнение что Devops подход появился как эмержентная практика когда программисты начали делать экстремальное программирование и подходов сисадминства стало не хватать. И Девопс отлично вписался когда появилась архитектура условных микросервисов (или хотя бы 1 сервис 1 виртуалка) в этот момент сисадминство перестало мастшабироватся и быть способным справится с управлением этой инфраструктурой.

Попутно там добавлялось ожидание того что девопсы еще налаживают коммуникации и ваще вся компания может делать девопс, но ынтерпрайзы не захотели менять политику и поэтому появились отдельный девопс отделы где ямл инженеры пилят код ибо так написал Гартнер. Ну и появилось семейство билд-инженеров - человек собирающий релизы, CI/CD - людей которые пишут pipeline сборки, infra/cloud инженеров которые пишут IaC, что там еще а ну logging/monitoring тоже отдельный инженер...

Получили еще пачку колодцев, а коммуникации запатчить забыли и получился ажаль вместо девопс-культуры ))

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

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

Тем не менее неявно считывается вопрос а что дальше ? куда двигаться что будет в будущем ?

Один умный человек сделал карту того как появился devops и что ждать в будущем и там фокус на serverless и ожидание того что serverless повлечет за собой создание новой архитектурной практики.. Ждемс..

Кроме того devops неплохо покрывал шаги в вот этой доктрине

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

воспользуюсь моментом и пиарну свой канал где пишу об этом вот всем и копипащу умные мысли умных людей https://t.me/deep_thought_aas

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб